kriswest
commented
2 years ago 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:
"...an App Directory which is used primarily to associate apps with Intents".
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:
- 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.
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 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 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.
- 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.
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.
- 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.
I agree that the quoted statement is stronger than is justified by the standard and should be adjusted.
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.
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 (appid@fqdn) and the location of the app directory from whence it came. That definition then contains a URL to the app. DNS/SSL provide the only actual protection against MITM/spoofing attacks when you connect to that URL. However, they also provide confirmation that you connecting to the expected app directory and if you trust its publisher (not to include evilcorp.io apps), you should be able to extend that trust to the applications that you access via HTTPS - even more so if the appD is hosted by an org/on a domain that has authority over that app. This nuance is missing from the AppD overview and should be added.
In the W3C's draft Web Application Manifest standard, 'identity' is based on an id field within the manifest resolved against the apps start URL, which is itself resolved against the manifest URL (see web app manifest spec ). You could happily have a manifest for an evilcorp.io app at an evilcorp.io URL and include it in an alternative directory or config format and the same issue you envisage would arise.
I think the best way forward on this particular issue is to correct/enhance the documentation, rather than dropping the whole standard.
Finally:
How a Desktop agent fetches its app definitions is outside of the scope of describing what interoperability capabilities an individual application has.
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.
dschleifer
lspiro-Tick42
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.