Remove App Directory specification, restrict manifest concerns to FDC3 capabilities

[openfin-gavin]

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 five main problems with the App Directory specification:

1. 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.

2. 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.

3. 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”.

4. 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.

5. 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 the following:

1. Deprecate the FDC3 App Directory specification

2. Define an interface for App providers to give Desktop Agents which defines an application’s fdc3 capabilities.

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 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, 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 next page shows two different agent’s example application descriptions. Both contain a property that uses the FDC3 interface to describe their available intents. It would be up to the desktop agent what that property is named, although we would suggest that ‘fdc3’ is a sensible choice!

Example App Manifests

Desktop Agent 'A'

An applciation manifest used by desktop agent that includes an ‘interop’ 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",
  }],
  "interop": { 
    "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"}]
    },    
  },
}

[openfin-gavin]

@kriswest @rikoe Would be keen to discuss this item as a suggestion for 2.0

[kriswest]

@openfin-gavin duly noted. We've got a few existing commitments on issues to discuss at the next SWG meeting (28th Oct), I'll confirm if we can discuss it then (or the next meeting) when I've had a chance to work on the agenda.

[nkolba]

Hi @openfin-gavin

My 2 cents:

I totally agree that we should be aligning with Web App Manifest, there are many extraneous decorators in the current specification (e.g. icons), and FDC3 should not be attempting to create a new manifest standard. I also like the idea of decorating the Web App Manifest directly.

However, there is value in app directory providing a standard for a basic interface to support desktop agents connecting to and querying a directory and for directories to federate.

I also agree that the the standard should not be proscriptive wrt how a desktop agent resolves intents and what inputs it uses to do so. But where in the standard is app directory required as the only way of implementing intents discovery?

The app directory standard only applies if you are implementing one and no other part of the standard requires an app directory.

Finally, an app directory provides security via the curation of apps within the directory. E.g. an organization to managing its own list of trusted applications. Trust is a bit more complicated than just 'does this url point to evilcorp.com?'. Apps in FDC3 are provided with the potential for cross-origin communication, and this warrants additional layers of control. While app directory is not a full - or the only - mechanism for security in FDC3, it is an important tool for doing so.

-Nick

[kriswest]

@openfin-gavin we'll put this on the agenda for the 18th November SWG meeting as its not going to fit into the agenda for 28th Oct meeting #481. We'll mention it at the 28th Oct meeting and ask people to read up ready to discuss.

[lspiro-Tick42]

I think defining an additional application manifest based on W3C standards might be useful, but the idea of removing the concept of an FDC3 defined application directory is a mistake.

Consider the following cases, all of which benefit from having a container independent, FDC3 specified, Application Directory:

• The AppD spec is not only used to define the Intents that an application can deliver, it is also used to define applications that can be started by an FDC3 application, such as a task bar.

• A software vendor (or training organisation) wants to provide a list of FDC3 compatible applications. The Application Directory spec, and the new container agnostic manifest allow this to easily delivered, and used in whatever FDC3 container the user organisation is using.

• Consider organisations with multiple Containers (the use case we discussed this week around Desktop Agent bridging), again an FDC3 defined App Directory is useful since it allows a single application definition to be used in whichever Container the user requests.

[openfin-gavin]

Issue has been broken into into 2 distinct issues:

Support app descriptions with an FDC3 property - #551
Remove App Directory - #550