Support any App Definition so long has it has an 'fdc3' property

[openfin-gavin]

FDC3 app definitions overlap heavily and sometimes conflict with the W3C Web App Manifest specification which is being driven by Google, Microsoft, and Intel among others. This specification is far more likely to be a global standard and FDC3 should use it rather than trying to provide an alternative.

The App Directory specification currently includes the following properties for intents that are needed by the DesktopAgent for Intent resolution.

"intents":
[
  {
    "name": "string",
    "displayName": "string",
    "contexts":
    [],
    "customConfig": { }
  }
]

Other than these properties, all other properties in the App Directory specification are covered by the W3C Web App Manifest or are not needed for interoperability (e.g. “contactEmail”) or both.

We propose to codify these intent properties, and any other properties solely related to interoperability, and make them part of the FDC3 specification, not as part of an App Directory specification, but as a well defined Interface that could be used in various Application Descriptors. This means that well formed 'FDC3' interop properties could be added to any application description format, such as an extended WC3 specification, or indeed an application manifest format used by a particular desktop agent.

This approach has several benefits:

1. Aligns FDC3 with W3C and the world’s largest technology players.

2. Leaves the implementation of intent resolution and other FDC3 capabilities to the FDC3 DesktopAgent where it belongs.

3. Reduces complexity in the overall FDC3 specification.

4. Eliminates the mistaken claim that FDC3 creates trusted app identity.

We would suggest that a common schema is defined that specifies what FDC3 Interoperability capabilities a given application supports. This schema could then be used as part of any application definition schema used by a given desktop agent.

For example, we may wish to define an ‘Interop’ configuration object as follows:

interface Interop {
  intents?: Intents
  userChannels?: UserChannels
}

interface Intents {
  supportedIntents: []{ 
    name: string,
    description: string,
    acceptedContextType?: string[] 
  }
}

interface UserChannels {
  availableChannels: {
    name: string,
    color: string
  }
}

Please note that these example data structures are illustrative only, and if this proposal is accepted the next task would be to formally specify the ‘Interop’ schema.

Taking this approach would allow desktop agents to decide how to model application capabilities, for example, the following example shows two different agents example application descriptions. Both contain an 'fdc3' property that uses the FDC3 interface to describe their available intents.

Example App Manifests

Desktop Agent 'A'

An applciation manifest used by desktop agent that includes an ‘fdc3’ property using the FDC3 interop schema

{
  "name": "HackerWeb",
  "appDetails": {
      "url": "https://play.google.com/...",
      "height": 600,
      "width": 800,
  }
  "description": "The Hacker News app.",
  "icon": [{
    "src": "img/icon48.png",
  }],
  "fdc3": { 
    "intents": {
      "supportedIntents":  [{
        "name": "ViewChart"}]
    },    
  },
}

Desktop Agent 'B'

This desktop uses W3C manifests, but with an extra ‘fdc3’ property using FDC3 Interop schema

{
  "name": "HackerWeb",
  "short_name": "HackerWeb",
  "start_url": ".",
  "display": "standalone",
  "background_color": "#fff",
  "description": "The Hacker News app.",
  "icons": [{
    "src": "img/icon48.png",
    "sizes": "48x48",
    "type": "image/png"
  }],
  "related_applications": [{
    "platform": "play",
    "url": "https://play.google.com/..."
  }],
  "fdc3": { 
    "intents": {
      "supportedIntents":  [{
        "name": "ViewChart"}]
    },    
  },
}

[kriswest]

As this is largely similar to the previous proposal it supersedes, the existing comments from the Nov SWG meeting still apply: #505 as do the comment applied to the original issue #468

I disagree with several of the purported benefits of this issue:

This approach has several benefits:

1. Aligns FDC3 with W3C and the world’s largest technology players.

By proposing to allow any app definition format this proposal does not align FDC3 with W3C or indeed any other organisation, only adoption of a format as a required or at least recommended format would do so.

Further, in order to adopt a format, we would need to ensure that it can handle details required to launch native and hybrid applications, which are also intended to be supported by FDC3 (and are already supported alongside web applications by a variety of implementations). An extension to the web application manifest, for example, would be needed to adopt that format as FDC'3s app definition format (an alternative proposal, that I do think warrants consideration).

2. Leaves the implementation of intent resolution and other FDC3 capabilities to the FDC3 DesktopAgent where it belongs.

By providing data for intent to support intent resolution (and other FDC3 capabilities in the future) the App Directory's app definition format does not implement intent resolution nor take the responsibility for it away from Desktop Agent implementations. Rather it simply provides a standardized format 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, this proposal doesn't actually seek to change that as it expressly retains that data format for use in extending other formats.

3. Reduces complexity in the overall FDC3 specification.

...but not in the eco-system of financial services applications that FDC3 is intended to support. By supporting any app definition format (containing the proposed fdc3 element) this proposal promotes fragmentation, rather than standardisation, amongst vendors and in-house development teams across the industry and hence runs, in my opinion, directly counter to FDC3's goals.

By adopting a common app definition standard we encourage vendors to publish details of their applications in a single format that can be read by multiple 'platform providers'. Whereas, under the fragmented scheme proposed vendors would have to publish those details in multiple formats, support only a subset of providers or force consumers to author the app definitions themselves (which increases the complexity of maintaining those definitions as web-based applications or their deployments change). It is likely that we would see a mix of these approaches being adopted.

In contrast, 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.

Further, the App definition format isn't particularly complex. In its current form (proposed for 2.0), it can wrap Objects or reference them via URL representing other app definitions (see the hostManifests property) if it needs to (a start URL is now also provided for web apps, reducing the need for this), which seems a simpler solution than inserting a chunk into other standardized formats.

4. Eliminates the mistaken claim that FDC3 creates trusted app identity.

I agree that the claim, made in the App Directory Overview, is hard to support and that the AppD doesn't obviously a lot of value in "preventing spoofing and man-in-the-middle attacks when apps communicate with one another and exchange data", particularly where that exchange happens anonymously over context channels). The Application definition does not itself provide a mechanism to authenticate individual applications (although that is something we could look at doing - it would require API support to achieve).

However, when an appD is accessed via HTTPS, SSL & DNS confirm for us that we are retrieving app definition data from the expected source. If we trust that source AND it is authoritative for the application (e.g. a domain owned by a vendor that publishes the app, or by one's own firm pointing to their own deployments of in-house or vendor apps). We can then use HTTPS URLs to launch and communicate with the (web) application, secure in the knowledge we are protected from spoofing or MITM attacks.

Hence, there are ways that an AppD can provide a trusted identity (for a web app) - but the statement in the AppD overview is far too broad and doesn't acknowledge the above caveats.

---

The App Definition format used by the FDC3 Application Directory is not perfect by any means. I support the idea of aligning it with other standards and see multiple approaches by which we could do so. However, I am strongly against this proposal to support any app definition format embedding an fdc3 property as I believe it promotes fragmentation and will reduce the adoption of all aspects of the FDC3 standard.

Instead, I believe further work should attempt to improve on the AppD specification, a specific goal of FDC3 2.0 and one of the main reasons a major revision was proposed for the next iteration of the standard.

Finally, there certainly is merit to improving the interop data in AppD - happy to see an extension to it proposed, although I'm confused by the inclusion of userChannels in the data for a single application. These are usually provided by the DesktopAgent and are common across all apps that they interact with (as the Desktop Agent rather than the app control them). Perhaps detailing the App Channels (where a vendor wants to expose that information - as per issue #371) and context types used (as per issue #247) would be more useful.

[kriswest]

@openfin-gavin this issue was briefly discussed at the AppD discussion group today. We propose to leave it open until the next meeting (Tuesday 3rd May) to give you a chance to speak about it and then to close it if there is no further activity/interest.

[robmoffat]

I have a further suggestion: the app-manifest should be a component within our app directory record (actually this is an idea @nkolba came up with in a discussion with me). Although you make some good points @kriswest I think it will reduce the surface area of our standard if we use the app manifest as far as possible.

[kriswest]

@robmoffat That is already the case in the 2.0 pre-draft live on the FDC3 website, since 18th Jan. Multiple manifests can be embedded or linked via URL in the record via the hostManifests element:

https://fdc3.finos.org/schemas/next/app-directory#tag/Application/paths/~1v1~1apps~1{appId}/get

In FDC3 <=1.2 you could only add a single manifest, string encoded, in the manifest field:

https://fdc3.finos.org/schemas/1.2/app-directory#tag/Application/paths/~1v1~1apps~1{appId}/get

These manifests are generally vendor-specific (with the exception of the web application manifest). Hence, the details element was also added in order to try and help us move to a more vendor-agnostic approach (where a vendor manifest is optional rather than required).

[donbasuno]

Thanks for all the comments!

After discussions with @openfin-gavin and the latest developments in the AppD spec we are ok with closing this one.

Best regards,

Johan