Desktop Agent Bridging Discussion group 6th July 2022

[kriswest]

Group overview

Discussion group for developing proposals for producing bridges between FDC3 implementations (aka Desktop Agents), allowing applications running on one Desktop Agent, 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
• Raising and resolving Intents
• Launching Applications

Relevant issue tags

• Current open issues that relate to the above concepts with the label:
  
• The original issue is now a github discussion where content can be added and this issue discussed:
  Desktop Agent Bridging Discussion group #544

Meeting Date

Wednesday 06 July 2022 - 9am EST / 2pm BST

WebEx info

• Meeting link: https://finos.webex.com/finos/j.php?MTID=m55d4aa79e148c948bf53163690e74fee
• Meeting number: 2558 920 8729

More ways to join

• Join by video system:
  • Dial 25589208729@finos.webex.com
  • You can also dial 173.243.2.68 and enter your meeting number
• Join by phone
  • +1-415-655-0003 US Toll
  • +44-20319-88141 UK Toll
• Access code: ### ### ###

Meeting notices

• FINOS Project leads are responsible for observing the FINOS guidelines for running project meetings. Project maintainers can find additional resources in the FINOS Maintainers Cheatsheet.

• All participants in FINOS project meetings are subject to the LF Antitrust Policy, the FINOS Community Code of Conduct and all other FINOS policies.

• FINOS meetings involve participation by industry competitors, and it is the intention of FINOS and the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Please contact legal@finos.org with any questions.

• FINOS project meetings may be recorded for use solely by the FINOS team for administration purposes. In very limited instances, and with explicit approval, recordings may be made more widely available.

• A Discussion Group has no direct decision-making power regarding the FDC3 standard - rather it is intended that anything they propose or work on will result in proposals (via Github issues and PRs) for the Standards Working Group participants to consider and vote on for inclusion in the standard. As such, participation in a Discussion group is not required for contributing to any particular issue or FDC 2.0 as a whole.

Agenda

• Convene & roll call, review meeting notices (5mins)
• Review action items from previous meeting (5mins)
  • Desktop Agent Bridging Discussion group 8th June 2022 #741
• Review draft Desktop Agent -> Bridge connection protocol (handshake, auth, name assignment) (40mins)
  • Current proposal PR: [WIP] 544 desktop agent bridging proposal #634
    • Preview: https://github.com/finos/FDC3/blob/544-Desktop-Agent-Bridging-Proposal/docs/api-bridging/spec.md
• Discuss next steps (5mins)
• AOB & Adjourn (5mins)

Minutes

• @kriswest provided a summary of the proposed connection protocol (see current proposal preview)
  • @Yannick-Symphony suggested a clarification on initial websocket connection to the DAB - update mermaid diagram to show the initial connection event as part of the exchange.
  • @Yannick-Symphony suggested we use 2-way authentication (as was preferred in the initial poll on the top) in which an auth token would be added to the hello message coming from the bridge so that DA can authenticate the bridge
    • All: No strong feelings in favor or against it. It (a suitable JWT token) could be added as an additional field to the hello message in the connection protocol, which would ensure implementation simplicity by making validation of it optional.
      • Whether sending the token should be required (MUST) was not discussed.
  • All - No major concerns about the current connection protocol proposal.
• @Vivek-NatWest request some clarification on channel state synchronization - the relevant section of the proposal was reviewed
  • @nkolba Commented that there is a potential race condition on handling channel state synchronization:
    • On startup, apps might load and start broadcasting state immediately - concurrent with the desktop agent connecting to the bridge and receiving state.
    • @kriswest: I believe this is avoidable, and, as this is an important point we should spell out how to go about doing so in the specification
      • Channels are the only stateful mechanism in the FDC3 that we have to consider
      • Connection handshakes (or more specifically the channel sync portion of the handshake) should be handled serially and atomically by the DAB.
      • Channel state sync messages from the DAB to agents should also be handled atomically (allow no overlap with fdc3.broadcast, channel.broadcast, fdc3.addContextListener or channel.getCurrentContext messages)
        • Note that the synchronisation will only bring in new state, on already known channels, for the agent connecting to the bridge - although existing agents should pick up state for channels they have not yet seen.
      • Future work on message exchanges should provide more clarity on the possible race conditions. This can be one of the main topics for the next meeting agenda.
• Details about channel state synchronization to be discussed on the next session.

Action Items

• @tpina @kriswest Update initial websockect connection mermaid diagram - show the initial connection event as part of the exchange.
• @tpina @kriswest Add optional JWT token to DAB's hello message in the connection protocol. Validation of this token by the agent connecting should be optional but recommended (SHOULD).
• @tpina @kriswest Add clarifications suggested above to channel state synchronisation portion of proposal
• @kriswest Add to next meeting agenda:
  • Review additions and clarifications to connection protocol
  • Review channel synchronisation clarifications added to proposal
  • Review and discuss any other potential race conditions or workflows broken by disconnection

Untracked attendees

Full name	Affiliation	GitHub username

[mistryvinay]

Vinay / Symphony

[kriswest]

Kris / Cosaic 🚀

[tpina]

Tiago Pina / Cosaic

[Julia-Ritter]

Julia / FINOS

[Vivek-NatWest]

Vivek / Natwest

[pierreneu]

Pierre Neu / Symphony

[nkolba]

Nick Kolba / Connectifi

[hughtroeger]

Hugh Troeger / FactSet

[robmoffat]

Rob / FINOS

[dominicgifford]

Dom Gifford / S&P Global

[manishbhutani]

Manish / NWM

[Aaron-Haines]

Aaron / NWM

[dominicgifford]

Out of interest, is there any plan to protect against cross-environment contamination?

Let's say I have:

• The Production version of App A
• The Production version of App B
• The UAT version of App A
• The UAT version of App B

The desktop containers for App A and App B are from two different vendors. I want to ensure that while testing the flow from App A UAT to App B UAT, I don't accidentally connect to App B Production.

[Qiana-Citi]

Qiana / Citi

[kriswest]

Hi @dominicgifford. What do you mean by 'connect', as the answer differs depending on the API calls in use...

If we're talking about channels, then its down to which user channels the user adds the apps to, or for app channels, which ones they join. That said, 2.0 introduces (optional) exposure of originating app metadata passed to the context handler which might allow you to filter which context broadcasts on the channel that you listen to.

For intents, if there's more than one option to resolve an intent then you'll see a resolver UI (usually) pop up requiring the user to pick the app. However, you can specify a target app/instance to avoid the resolver and send it straight there (With the resolver either filtered to instances of the app, or go direct by specifying a particular instance). Hence, if you know the details of the UAT and production apps, you can make sure your messages head to the right one.

As far as I am aware there is no other thought on environments in the FDC3 API nor Desktop Agent Bridging. If we were to add something I think it'd begin in the FDC3 API and then be carried over into bridging. That said a particular desktop agent implementation I know quite well has a feature that solves for exactly this problem via config ;-). A similar standardized solution may be possible through an appD config...

[kriswest]

Apologies for the delay, minutes for the last meeting have now been posted and we'll crack on with updating the proposal again this week hopefully.