FDC3 Desktop Agent Bridging Discussion group 27th July 2022

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: #544

Meeting Date

Wednesday 27July 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 [email protected]
- 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: 2558 920 8729

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 [email protected] 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

[x] Convene & roll call, review meeting notices (5mins)
[x] Review action items from previous meeting (5mins)
- #772
[x] Review updates to the proposal (40 mins)
- Current proposal #634
  - Preview: https://github.com/finos/FDC3/blob/544-Desktop-Agent-Bridging-Proposal/docs/api-bridging/spec.md
  - Changes
    - Connection protocol updated
      - Added initial connection step to connection protocol diagram
      - Renumbered connection protocol steps to better map to diagram
      - Improvements to connection protocol steps titles
      - Added optional auth token to hello message from bridge to DA (allows 2-way authentication)
      - Added description of atomicity requirements for handling of handshake and connectedAgentsUpdate messages by both DAB and DAs
      - Channel State Synchronization
        
        Added details necessary to avoid race conditions (e.g. if a DA is connecting and another is broadcasting context concurrently)
      - Recommended port range for bridge - (4470 - 4480)
    - Interaction/Messaging protocol
      - Added WIP draft
      - Added section on GUID generation (with reference to external standard) used in requestGuid and responseGuid fields in messages.
      - Added missing field comments for message formats
      - Handling of slow responding DAs?
        
        Recommended timeout of 1500ms/3000ms
  - Open questions / TODO list
    - Add details of how to handle:
      - workflows broken by disconnection
      - An agent that is repeatedly timing out should be disconnected?
    - Advise on whether other agents report to users on connect/disconnect events?
    - Add new terms and acronyms to FDC3 glossary and ensure they are defined in this spec's introduction
    - Add RFC 4122 - https://datatracker.ietf.org/doc/html/rfc4122 to FDC3 references page
[x] Discuss next steps (5mins)
[x] AOB & Adjourn (5mins)

Minutes

@kriswest
- We are not quite ready to discuss the workflows broken by disconnection - that may be a good topic for our next discussion.
- The next 4 to 8 weeks are critical to get DAB into FDC3 2.1 Draft
- Summarized latest changes to draft proposal:
  - Highlighted bridge responsibility on filling/assigning the Desktop Name to prevent spoofing
  - Highlighted the importance of steps 3 - 6 and ensuring that they happen atomically
  - No initial questions about current changes nor additional items to add to the agenda
  - Proposal should expand on how the DAB should create the JWT token (and its claims, which must change to avoid replay attacks) which it sends out in the hello message for DAs to validate
    - Keep it similar to the one generated by DAs to send back to DAB in handshake
- @Aaron-Haines - We'll need to review offline - a lot to take in
@kriswest
- Highlighted the importance of other participants (DA vendors and potential Bridge providers) needing to validate the current proposal, particularly the approach to steps3-6 in the connection protocol
- Generic message format:
  - type: string identifier for message type
  - meta: portion that relates to source, destination and handling by the by the bridge
  - payload: portion that relates to data that needs to be processed by Desktop Agents (either request or response content)
- Response messages
  - ...should be collated by the bridge (after all responses received or timeout hit) and payloads merged for transmission to requestor
  - Questioned whether we actually need a destination field on responses as the bridge must track requests (to apply timeouts).
    - We could instead use only the requestGuid
    - Requested feedback from participants that have built bridging solutions
      - @Vivek-Natwest - NWM uses requestGuid but recognizes that having the destination would be more readable for debug and troubleshooting purposes
    - Noted that the source field for a reply/response can present an issue for responses that come directly from a Desktop Agent (e.g. data for findIntent.
    - AppIdentifier might have to be adjusted so that appId is optional or some other way to identify a Desktop Agent. (e.g use-case for fdc3.findIntent response)
      - Modifying AppIdentifier this way will be problematic for the rest of the API, hence, better to create a new type (DesktopAgentIdentifier, which is just { "desktopAgent": string} and make source a union of AppIdentifier and DesktopAgentIdentifier )
@kriswest - Any questions or comments on what was presented?
- All - No questions for now
- Highlighted once again the importance of feedback, review and suggestions on the current proposal from all participants as a collective action point

Action Items

[ ] @kris add to meeting agenda for 24th August:
- workflows broken by disconnection
- response collation example
@tpina @kriswest Update proposal:
- [ ] Expand on how the DAB should create the JWT token (and its claims, which must change to avoid replay attacks) which it sends out in the hello message for DAs to validate
- [ ] Update generic message format such that meta.source may be an AppIdentifier or DesktopAgentIdentifier ( { "desktopAgent": string})
- [ ] Add notes on destination field vs. requestGuid. Recommend use of requestGuid but include destination for debugging purposes
- [ ] Add a response collation example to generic messaging protocol
All: provide feedback on generic parts of proposal (connection and messaging) as we are about to move to specific workflows...
- See proposal draft at: https://github.com/finos/FDC3/blob/544-Desktop-Agent-Bridging-Proposal/docs/api-bridging/spec.md