Desktop Agent Bridging Discussion group

[lspiro-Tick42]

Enhancement Request

Extend the FDC3 API's to improve support for producing bridges between FDC3 implementations aka Desktop Agents.

In this context an FDC3 Bridge would allow an application running on one Desktop Agent, to be able to integrate with FDC3 applications running on a second Desktop Agent for the same user.

The interop between applications running on different Desktop Agents aka Platforms would ideally cover

• Channels
• Intents
• Application Launching

Use Case:

1. A Client has two Desktop Agent environments running on their desktop and wants to be able to raise an intent from an application running on Desktop Agent 1 (say Glue42) and the intent is implemented on Desktop Agent2 (say OpenFin).

2. A similar use case occurs `round User Selected channels, where a user wants to see applications running on the 'same channel' from the multiple desktop agents, synchronise on a common symbol.
   NB This assumes that from a user PoV a red channel on Platform is the same as a red channel on Platform 2.

3. An existing platform, say a Terminal offers interop between its applications using its own (non FDC3) API's. It wants to allow applications running on other Platforms to interwork with apps running on the Terminal. This could be acheived by delivering a Bridge for whatever Platforms a user may be running.

Additional Information

If this use case is accepted we can imagine two implementations, either adding a few extra API methods (for which change requests will be added) or by defining a Desktop Agent to Agent interop bus/api. But our view of the agenet to agent API is that it is too big a change.

[kriswest]

Consense reach at #481 that this issue is within the FDC3 charter and that work should be undertaken to achieve it.
Possible approaches to be presented at SWG next meeting.

[kriswest]

A discussion group is being started up to discuss and develop proposals to resolve this issue:

• Desktop Agent Bridging Discussion group #523

[saurabhguptanwm]

Addditional Usecase

1. A client has 2 monolithic application created in C# and wants to send a FDC3 Context or Intent from one app to another.

2. A client with 2 machines has 1 monolithic applcation running on Machine 1 and Desktop Agent (say Finsemble) running on Machine 2 and client would like to exchange context or Intent with each other.

[kriswest]

I've posted a poll for the next meeting date/time at: #543 (comment)
Let me know what works for you!

[kriswest]

Below is a copy of the requirements for a Desktop agent bridging feature agreed by the group (10th Feb 2022) and notes on problems to solve/questions to answer that I briefly ran through at a previous meeting.

Requirements for Desktop Agent Bridging (Updated 10 Feb 2022):

1. All major app interop features support by FDC3 support bridging such that an operation can be requested on one desktop agent, (where necessary) pass across the bridge and be completed by another desktop agent.
   1. Communication via channels should be bridged such that messages broadcast on one agent can be received on channels in another agent.
      1. (open question: do channel names need to be mapped for user channels - app channels should not need mapping as they are defined by applications)
   2. Intents raised via one Desktop Agent should be resolvable by an application hosted in another desktop agent.
      1. Programmatic intent discovery and resolution (findIntent) should be possible across the bridge and raising an intent without a target application or agent should be possible (show intent resolver for the desktop agent that the intent was raised on, include options from other agents)
      2. Automatic intent resolution (where only one option is available) should be possible across the bridge.
      3. The IntentResolution returned should identify the application (and Desktop Agent) resolving the intent.
      4. It should be possible to target an application running on another desktop agent both programmatically and via a resolver UI.
      5. It should be possible to specify that only options from a specified desktop agent should be returned.
      6. FDC 2.0 features should be supported
         1. Data responses from intents must be returned across Desktop Agent bridging
         2. Channel and PrivateChannel responses to intents must be returnable across Desktop Agent bridging and for communication to then be possible.
            • N.b. additional metadata on Channels will be required.
         3. Intent resolution to particular instances of apps will need to be possible.
   3. A desktop agent should be able to open an application (fdc3.open) on another desktop agent via bridging.
2. The configuration and control of Desktop Agent bridging should be the province of the desktop owner, rather than applications running on the desktop
   1. i.e. no API (on the global fdc3 object provided to apps) to control or set up the bridge is provided to applications - although support for using an established connection will be provided.
3. Details of whether bridging is supported and/or enabled should be provided in the 1ImplementationMetadata1 object retrieved via fdc3.getInfo along with details of what other agents are currently connected via bridging.
   1. Providing connection details MAY also be useful
4. The normal FDC3 API(s) should be unaffected by the addition of Desktop Agent bridging
   1. Apps should be able to interact with the API in exactly the same way whether or not Bridging is being used.
   2. Desktop Agent bridging should be handled by the desktop agent so that individual apps don't have to be customized to use bridging and that the use or effect of API calls should appear the same to an integrated application (with the exception of additional metadata provided on the Desktop Agent hosting a resolving app).
      • For example, findIntent might return an AppIntent containing results from both the local and one or more remote DesktopAgents. Each result is an AppMetadata object, which may be passed to other API calls to target a specific application; the apps from the remote application would have additional metadata identifying the remote desktop agent, but can be used in the same way as results from the local desktop agent.
   3. any new APIs created to enable bridging should not be accessible to integrated apps directly
5. Where a Desktop Agent supports multiple app technologies (e.g. HTML5, .Net and Java) bridging SHOULD apply to them all.
6. Desktop Agent Bridging MUST support connecting >2 desktop agents into a network
7. Desktop Agent Bridging SHOULD support multiple topologies
   1. E.g.
      1. Peer-to-peer, with support for >=2 agents
      2. Trunk/repeater based (e.g. all agents connect to one agent which will repeat messages or requests sent by another agent to all others)
   2. I.e. Desktop Agent bridging:
      • SHOULD not require a specific topology
      • MUST support an agent connecting to 1 or more other agents
      • MUST support connection from one or more other agents
      • MUST support bi-directional bridging across a single connection, regardless of which end initiated the connection.
8. Desktop Agent Bridging MAY support connecting desktop agents running on multiple machines be used by the same user.
   • requiring support for this is likely to introduce a lot more complexity, but it should not be specifically precluded
   • It has been noted that this is possible without specific API support if a Desktop Agent itself supports use on multiple machines (such as the Backplane implementation that was demonstrated by Natwest Markets).
9. Desktop Agent Bridging MUST support inter-connection between Desktop Agents from any compliant FDC3 implementation (which implements Desktop Agent Bridging)
   • Note this requirement is dependent on whether bridging is itself required for compliance.
10. The design of Desktop Agent Bridging should NOT preclude the implementation of security restrictions within a single Desktop Agent implementation
    1. A Desktop agent MAY be configured to prevent interconnection with other desktop agents.

Problems that need to be solved:

1. Connection or wire format

   1. How should the desktop agents implement communication with each other?
      1. Websockets?
         1. Port collisions? Requires configuration for each
      2. Securing the connection (SSL certificates for localhost? Or assume secure?)
   2. Message format(s) must be defined
   3. 2-way comms: How should responses be tied to queries? E.g. findIntent? raiseIntent IntentResolution and data responses etc..
   4. Container identity needs to be defined
      1. Particularly when running multiple copies of a container for different purposes/from 3rd party vendors.
   5. Should Destkop Agents be discoverable or configured for connection to each other?

2. Topology

   1. Should a desktop agent repeat messages it receives from a 2nd party DA to a 3rd party DA?
   2. Reciprocal connections: Agent A connects to Agent B, Agent B either uses the same connection OR establishes its own connection
      1. Race conditions where two agents discover each other at about the same time
   3. Would/should/could the bridge be implemented by the desktop agent itself OR an application running under the desktop agent?
      1. Bridging app acting as a proxy to another DA
         1. A bridging app could be used under multiple different containers and frees the container from implementing support itself
         2. Configuration would be difficult, e.g. would have to register every intent that the destination containers apps can resolve (and vice versa)
         3. Channels are not discoverable and other DA APIs were not designed for relaying…
      2. An API with access greater than the current FDC3 API should not be exposed to desktop apps as this may introduce security and governance issues (3rd party apps (ab)using the bridging API).

3. Any API for setting up bridging may need to be proprietary (i.e. in a different place for each desktop agent).

   1. There is no common point or standard API for configuration currently - we should NOT be adding one accessible to apps for security reasons.
   2. Focus on the interconnections instead - i.e. define the wire format/protocol then let each implementation deal with how it is configured?

4. Channels

   1. No discovery mechanism for App channels.
      1. Can't use public API as you need to know channel names in order to listen
   2. System channel names display metadata are not defined in the standard and will vary between implementations.
      1. Standardize?
      2. Configurable mapping?

5. Intents

   1. Two-way communication is required:
      1. Use-cases:
         1. Current: need to retrieve intent resolution options (findIntent)
         2. Future:
            1. Need to return data responses from resolving application to application that raised the intent across the bridge
            2. Need to return channel responses (feeds) from resolving apps
            3. Maintaining privacy for PrivateChannel
      2. With multiple apps interacting with each agent, messages and responses will be interleaved.
   2. Intent Resolution and UI recommendations:
      1. Should an intent resolver UI be used on the DA raising the intent or on other DAs. If other DAs should it be auto-dismissed when intent is resolved elsewhere?
   3. IntentResolution and targetting raised intents
      1. IntentResolution will need to be able to identify that an app is integrated via a different DesktopAgent.
      2. Need to be able to target an application integrated with a different desktop agent
      3. Ideally should be handled via an optional field on the AppMetadata interface rather than a new (optional) parameter added to the API functions themselves
      4. IntentResolution will soon support instances of apps (and does already in some implementations), however, the appD has no knowledge of app instance (only the desktop agent does).
   4. Synchronisation during app launch when an intent is raised
      1. Where resolution of an intent causes an app to be spawned, the context and intent can't be transmitted to it until the intent handler has been registered - this is handled internally by most desktop agents.

6. Other

   1. No discovery mechanism for apps that you can fdc3.open exists (findIntent functions require an intent and/or a context to return app details) - other than the AppD (access to which may be authenticated).

Implementation ideas

• Firehose for messages on channels
  • Identify channels in message and repeat on same named channel
• Expose findIntent functions through DA bridging to allow querying for resolution options
  • Extend AppMetadata to identify agent, when bridging is enabled
  • Used for both findIntent calls and to present resolution options in DA that raises intent without targetting
• Allow use of extended AppMetadata to target apps in other DAs
• Allow AppMetadata to specify intent should be raised in other DA (without target app - involve that DA's resolver)?
• Separate 'channel' or format for intent messages vs. channel messages?

[kriswest]

Poll: Discovery vs. Configuration

• 🚀 DA's are able to discover each other and self organise/connect
• 👀 Connections between Desktop Agents should be configured manually

(please feel free to add comments as replies)

[kriswest]

Poll: What is your minimum requirement for authentication when bridging Desktop Agents:

• 😄 Connections between Desktop Agents should be authenticated in at least one direction
• 🎉 Connections between Desktop Agents should be authenticated in both directions
• ❤️ Connections between Desktop Agents don't need to be authenticated

(please feel free to add comments as replies)

[kriswest]

@Soul-Master made an interesting comment re: authorisation vs. authentication which I'll duplicate here:

I think it should be better for end-user to show some confirmation window about desktop agent client connection. It should allow user to reject connect if they don't know/trust desktop agent client.

Personally, I like the idea of turning over the authentication/authorization issue to the user. Using external SSO was also suggested during the last meeting.

[kriswest]

You can find the latest version of the Desktop Agent Bridging proposal at: #861 (recreated on new PR!)
Preview: https://github.com/finos/FDC3/blob/544-Desktop-Agent_bridging-Proposal-mk2/docs/api-bridging/spec.md