Remove the Application Directory from The FDC3 Specification #551
Comments
|
As this is largely similar to the previous proposal it supersedes, the existing comments from the Nov SWG meeting still apply: #505 and do the comment applied to the original issue #468. Its also closely related to the other issue raised alongside it (#550) and hence comments on that issue may also apply. I disagree with many of the points made in this issue, starting with:
Association of applications with intents is indeed an important part of the App Directory's role, but that is perhaps secondary to its role in providing other details of the application such as human-readable names & other descriptive data such as app icons, details required to launch applications and unique identifiers (which can be made globally unique by appending the appD's fqdn) for applications, which are used to refer to the app through FDC3 DesktopAgent API. By adopting a common app definition standard AND method of search/retrieval for those definitions we encourage vendors to publish details of their applications in a single format that can be integrated by multiple 'platform providers'. Recently, multiple firms commented (at the Nov SWG meeting, members meetings in London and NY and at least one OSSF talk) that the existence of the AppD specification had simplified the adoption of app interop for them by providing a single recommended standard (for both the app definition format and directory from which they are retrievable). Regarding the problems with the specification raised in this issue:
FDC3 standard is not actually prescriptive about how intent resolution is performed and does NOT require queries to be passed through to an AppD (o my knowledge, the standard does not specify how resolution is to be performed anywhere). It does state that intent registration is typically handled via registration with an App Directory, however, by providing a means to retrieve data (app definitions) to support app launching and intent resolution (and other FDC3 capabilities in the future) the App Directory does not implement intent resolution nor take the responsibility for it away from Desktop Agent implementations. Rather it simply provides a standardized mechanism for providing data in support of intent resolution to a Desktop Agent - and does not require that it is the only mechanism by which that data is provided. Further, the API spec states that Intents may be registered at the application level / ad-hoc registration through the API may be supported.
The app directory specification is not particularly complex in of itself. However, it does specifically solve for one particular problem facing apps that need to “interoperate in a plug-and-play fashion, without prior bi-lateral agreements”, namely how to provide information necessary for application listing, launch and intent resolution to a Desktop Agent. Were the standard to avoid making at least a strong recommendation in this area it would be promoting fragmentation, rather than standardisation, likely resulting in a more complex situation for all stakeholders (app vendors, platform providers and consumers of those platforms). As it stands FDC3 currently requires connection to at least one app directory (See FDC3 Compliance). It may be that we can explore reducing this to a strong recommendation by applying the 'SHOULD' keyword - however, some may feel that even this is a retrograde step for the standard.
Authentication IS currently supported by AppD (via JWT tokens), however the documentation is light, see: https://fdc3.finos.org/schemas/next/app-directory#section/Authentication It would be relatively easy to extend the AppD's API to deal with the other concern (pagination) and any other shortcomings (search would be fairly easy to improve). Whereas encouraging, nay, requiring each platform provider to come up with their own solution would promote fragmentation and greater complexity within the ecosystem for most if not all stakeholders. I would go as far as to state that one of the key goals of FDC3 is to encourage DesktopAgent vendors/implementors (platform providers) to agree on a common standard that meets their specific needs, and reduce or prevent the fragmentation that I believe dropping the App Directory standard would promote.
I agree that the quoted statement is stronger than is justified by the standard and should be adjusted.
I wasn't clear if the first statement above was meant to be applied to the App Directory standard, web apps generally or the W3C's web application manifest spec. The App Directory standard provides both a URL for each application's definition and an ID scheme that can be used to derive both that ( In the W3C's draft Web Application Manifest standard, 'identity' is based on an I think the best way forward on this particular issue is to correct/enhance the documentation, rather than dropping the whole standard. Finally:
The above statement is only true in so far as it's the responsibility of the application definition to describe the capabilities, rather than the directory used to retrieve them. The directory and the definition are currently conflated in the FDC3 spec, which is something we could resolve. The directory has always had other responsibilities, such as providing a standardized format for providing details of launchable apps to a DesktopAgent, which it solves for well enough. Being able to publish and/or consume a curated list of applications in a standardized format has value - which we've repeatedly heard in SWG meetings (where the predecessor to this issue was discussed), talks at OSSF and other conferences and at the FINOS members meetings held this year. I don't see how the proposal in its current form adds value to FDC3 and believe that adopting it would result in more fragmentation and less uptake of the FDC3 standard as a whole. However, there are areas that can and should be improved upon (as highlighted in the issue and this response) which I would recommend that further work (and meeting time) focus on. |
kriswest
added
app-directory
deprecation
|
The future of application interoperability requires not just a standard API for apps, intents to launch them, and context messages to pass between them, but open directories to discover applications that can handle those intents and context messages. Small fintech vendors will hopefully list themselves in an open directory (ideally hosted by FINOS itself for certified FDC3-compliant apps). Large vendors with portfolios of applications will host directories of the many apps they offer tied to their own auth and entitlement systems. End user firms will host their own internal directories of in-house built apps. Whether an end user firm allows desktop agents to connect to outside directories or uses something like an NPM Artifactory will be up to them. End users will discover, select, and launch the applications they’re authorized for. From my perspective, that’s what’s implied by the highlighted portion of the FDC3 mission statement:
If desktop agent only connect to the vendor’s proprietary, walled garden app directories, perhaps even charging vendors to be listed or requiring exclusivity (as we’ve heard from multiple fintech vendors is being proposed to them), the future of open interoperability in our industry will not materialize. It is my position, and that of Cosaic as a company, that AppD is a critical part of achieving the FDC3 mission (and that issue 551 should be rejected), and that support for connecting to any AppD-complaint directory should be a Required element for Desktop Agents. Desktop Agent vendors should be free to establish their own walled garden, proprietary app directories if they wish, but also need to support connection to AppD-compliant directories. Failure as a community to develop, adopt, and evolve an AppD specification and for every FDC3-compliant Desktop Agent to implement that specification, would be detrimental to the future of interoperability. |
|
In addition to the case of App Vendors who offer FDC3 compliant, platform independent applications, and who wish to provide their own application directories, described above. The AppD specification is also required to allow us to publish FDC3 compliant directories of test, demo and dev support applications which can be then be opened by any FDC3 compliant platform. Without an FDC3 AppD specification, FINOS could not host an app directory, since it would end up needing to support each proprietary AppD format. We therefore support keeping the AppD spec in FDC3 and making it a mandatory requirement for full conformance, |
|
A vote of the fdc3-participants was held on this issues 28th Feb - 7th March, the votes cast can be reviewed in the fdc3-participants archive The result of the vote represents a strong consensus to close the issue:
|
Overview
The FDC3 standard includes a specification for an App Directory which is used primarily to associate apps with Intents. When an Intent is raised by an app, the FDC3 DesktopAgent can query an App Directory to find apps that can handle the Intent.
There are four main problems with the App Directory specification:
The task of resolving an Intent falls to the FDC3 DesktopAgent. How the DesktopAgent resolves the Intent is an implementation detail specific to each DesktopAgent. For example, the DesktopAgent can query a database directly to find apps to resolve the Intent or perhaps the DesktopAgent wants to search the desktop for installed apps that can resolve the intent. The FDC3 standard should not be prescriptive about how the DesktopAgent performs this task.
The App Directory specification creates complexity that is not needed in service of FDC3’s mission to enable apps to “interoperate in a plug-and-play fashion, without prior bi-lateral agreements”.
The API exposed by the App Directory is too limited and doesn’t include (for example) methods for authentication or pagination. While the specification could be extended to support these capabilities, this is better left to each DesktopAgent to implement based on its own specific needs.
Finally, the specification states that “The FDC3 App Directory provides trusted identity for financial desktop apps.” In fact, the App Directory does not provide trusted identity. For web apps, trust is based on the URL of an app manifest. If an App Directory lists evilcorp.io/app.json, other apps should not trust the Evil Corp app just because it’s in an App Directory.
Proposal
Given the problems above, we propose that the FDC3 App Directory specification should be deprecated. How a Desktop agent fetches its app definitions is outside of the scope of describing what interoperability capabilities an individual application has.
The text was updated successfully, but these errors were encountered: