FDC3 for Web Browsers Discussion group 16th November 2023

[kriswest]

Group overview

Group convened to discuss how to enable FDC3 use in a web browser, without the use of a browser extension (such as fdc3-desktop-agent or a container).

Issue: #896
Mailing list discussion: https://groups.google.com/a/finos.org/g/fdc3/c/jCvlLjokBLs

In a recent email on the FDC3 mailing list, @kriswest wrote:

... I also want to add that there is clearly significant interest in the community in enabling FDC3 use on the web. There is a strong use case in that it would enable better onboarding journeys with less drop-off (where you use an app on the web with others before adopting a desktop container or similar).

and:

But there are also additional challenges such as how to make the API available reliably without importing a proprietary module from a particular vendor into every app, how to deal with more than one implementation of API/Desktop Agent in the browser at once, how to do this reliably and securely within the browser sandbox etc.. Work needs to be done in the Standard to solve these issues and to make web browser use possible in a future FDC3 Standard version - which I believe is possible (and likely to involve using a vendor-agnostic FDC3 NPM module to detect and connect to API implementation(s)). However, we're going to need to do that work to enable the aforementioned API implementations to be compliant and if we fail to hold the line now on compliance with the current version of the FDC3 Standard, that may never happen.

Shared doc with current draft: https://tick42-my.sharepoint.com/:w:/g/personal/finsemble_datastore_interop_io/EZ0dfTCdRlJCnIF3C_1Oit0B7xK0OOJ0nAvC73dwad53AA?e=x2zlge

Relevant issue tags

Current open issues that relate to the above concepts with the label:

Meeting Date

Thursday 16 Nov 2023 - 11am (US eastern timezone EST) / 4pm (London, GMT)

Zoom info

• Join Zoom Meeting
• Meeting ID: 969 4029 4948
• Passcode: 636931
• Dial-in:

  Country	International Dial-in	Toll-free Dial-in
  US	+1 929 205 6099 (New York)	877 853 5247
  UK	+44 330 088 5830	0800 031 5717
  France	+33 1 8699 5831	0 800 940 415
  Find your local number	https://zoom.us/u/ad2WVnBzb8

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.

Agenda

• Convene & roll call, review meeting notices (5mins)
• Review action items from previous meeting (5mins)
  • FDC3 for Web Browsers Discussion group 19th October 2023 #1091
• Discuss necessary proposal refinements (50 mins)
  • Refine naming used in the proposal
  • Clarify the discovery race
    • Message all parents simultaneously
    • Set reasonable default timeout for discovery race
    • (maybe) shorten timeout if no references to message to
  • Revisit the failover function:
    • use case & justification,
    • ensuring that it does not inadvertently switch an app to another agent on refresh/navigation
  • Consistent behavior post navigation/refresh
    • Assigning consistent instance ids for the same app,
    • Changing the instance id if the app identity changes,
    • Persisting URLs provided for the hidden iframe procedure
  • Handling UIs for Channel Selection and Intent resolution
    • Channel selector UIs:
      • Do we need a new event on channel change,
      • How to indicate a UI is already provided by DA or App
      • Providing a default opensource implementation, with the option to replace or disable (if app includes its own)
    • Intent resolver UIs:
      • window.open is blocked everywhere unless connected to a user gesture (and one window.open per gesture) - that is a problem for a hidden iframe which will never have a gesture associated.
      • Either an iframe has to show itself and render the intent resolver...
        • or A new temporary iframe may need to be created and shown (perhaps using a URL delivered by the DA),
        • or The app window will have to open the window inside handling of whatever user gesture triggered the raiseIntent,
        • or Intent resolution will need to be handled elsewhere by a launcher window.
  • Do we need connection status or other lifecycle events
• Next steps (if time)
• Adjourn

Minutes

• Revised naming proposals reviewed and accepted (including naming the functions proposed getAgent(...) and getSubAgent(...).
• The meeting re-reviewed the discovery race, with recent clarifications (e.g. contacting all possible DAs in parent frames/windows simultaneously) and there was consensus that this approach is the best available.
  • Default timeout to be reviewed once implemented - it was noted that the timeout needs to be set appropriately for cases where the machine/browser is under load during a market event or restoration of a large number of windows in a layout and hence will likely need to be longer than the fastest that could be achieved (but no longer than a second ideally - initial setting proposed at 750ms - can be overridden by app developers via an argument to getAgent).
  • It may be possible to shorten the timeout if no parent windows or frames are found (then only needed for implementations injected at window.fdc3 - which may be able to achieve injection via preloads faster in future).
• The meeting revisited the failover function and discussed ensuring consistent behaviour/connection to a Desktop Agent post navigation or refresh.
  • Adding some small amount of data persistence via SessionStorage (persists data by origin and as long as the window or tab exists - doesn't affect other windows or tabs), will allow us to:
  • Continue to connect to a DA via the inframe/URL approach, even if the parent window has gone away (store the URL)
  • Prevent the failover function switching the app to a different Desktop Agent on a subsequent connection
    • This is likely to be confusing to the user and the meeting agreed that it is undesirable.
• The meeting addressed handling of UIs for Channel Selection and Intent resolution
  • The proposed solution for Channel Selector UIs (adding a developer-supplied callback function to start a channel selector UI if needed) was accepted.
    • App developer can indicate that they do not need a UI for channel selection by not passing a function
    • DA vendor can indicate that they already supply a UI for channel selection (e.g. by rendering apps in an iframe with a sector over the top) in the handshake messages on connection - which should cause getAgent to NOT call the callback passed
    • Open-source and vendor implementations of a channel selector may be made available for use or an application can enable a built-in UI by setting the callback in the arguments
      • A number of participants stated that this optionality was very important, including one participant whose firm uses specialized hardware to allow traders to set channels.
    • The fdc3 API already provides functions necessary to set and check channels - but doesn't include events that can tell an app/UI if the channel was set externally.
      • Such events need to be proposed to the SWG. Theres no need to wait for this proposal, lets raise this request now.
  • Further lifecycle type events (e.g. connection lost/resumed) may be needed at some point, e.g. to support remote desktop agents and an indication of connectivity. Any required can be raised as part of this proposal or a later refinement (rather than raising with SWG now).
  • The meeting briefly discussed Intent Resolver UIs, which are more complex to handle than a Channel Selector
    • Intent resolvers are usually pop-up windows in containers. However, in a browser its not possible to open a window without a user gesture and as the raiseIntent API call goes to the Desktop Agent in a different window/DOM the link to the user gesture is probably lost, making opening a window hard.
    • Alternatives include having a hidden iframe, which reveals itself to act as an intent resolver - this could be rendering a URL that was sent from the Desktop Agent on connection or in response to a raiseIntent call
    • Ideally a similar approach to channel selectors would be used...
    • More thought on solutions is required.
      • It was noted that the API does provide all the data on resolution options necessary to render a resolver.

Action Items

• @kriswest Move all parameters (i.e. failover function) into params object in API proposal
• @kriswest update default timeout to proposed value in proposal
• @kriswest add a note to proposal about refining timeout in later version, situations timeout must deal with and shortening timeout if no parents found.
• @kriswest complete details of data persistence in proposal
• @novavi confirm if WindowProxy objects are comparable, allowing them to be used as a mechanism for assigning consistent instanceIds to apps (that still validate as having the same identity) - comparison needs to be backed by the HTML Standard to be trustworthy, otherwise an alternative mechanism will be needed.
• @kriswest Add details of assigning consistent instanceIds to apps and how spoofing is prevented
  • If WindowProxy objects are not comparable, add a one-time key (nonce) to data persisted to support reassignment of consistent instanceID and to prevent spoofing
• @kriswest raise an issue for the additional of channel changed events to the FDC3 API.
• @kriswest include Intent resolver UIs on next meeting agenda.

Untracked attendees

Full name	Affiliation	GitHub username

[novavi]

Derek Novavi / S&P Global

[lspiro-Tick42]

Leslie Spiro / Interop.io

[robmoffat]

Rob / FINOS 🎳

[psmulovics]

Peter Smulovics / Morgan Stanley

[hughtroeger]

Hugh Troeger / FactSet