FDC3 for Web Browsers Discussion group - 30th March 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.

Relevant issue tags

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

Meeting Date

Thursday 30 Mar 2023 - 11am EST / 4pm BST (note both US and UK now on daylight savings time)

WebEx info

• Meeting link: https://finos.webex.com/finos/j.php?MTID=mc297e9962d73ad18f6539745ce79abf9
• Meeting number: 2552 173 3304

More ways to join

• Join by video system:
  • Dial ########@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 [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)
• Continue discussion of proposals for a library (standard) to provide access to a Desktop Agent API interface (45 mins)
  • Proposals posted on FDC3 For Web browsers #896
    • Detailed proposal with options: FDC3 For Web browsers #896 (comment)
    • The proposal was reviewed up to the beginning of step 2 in the previous meeting.
    • Start discussing technology options for the implementation of the steps
      • At two attempts have been made at implementation of multiple steps have been made by participants already
• AOB & Adjourn (5mins)

Minutes

• A recap of the conversation so far was provided, focused around the proposal draft:
  • Expand the Standard to cover 4 FDC3/Desktop Agent API use-cases:
    • Container or Browser Extension (* the existing use case)
    • Web container
    • Independent Web App
    • Micro-frontend Container (Single DOM)
  • These need to be handled in order in the standard:
    • Step 1: Discover implementations injected by container/browser extension
      • Some changes to the spec are needed:
        • use the proposed installer library instead of going straight for the window.fdc3 global,
        • containers/browser extensions should set the global ASAP and use queuing if not ready to answer calls yet
        • can set the global yourself once you have an instance for backwards compatibility/to support the newer user cases with older code
    • Step 2: Handle web containers that indicate the library that should be loaded or otherwise communicated with
    • Step 3: Handle independent web app cases
    • Step 4: Handle single DOM micro frontends (sharding)
  • Theres a strong feeling that changes introduced should be non-breaking for existing FDC3 apps.
  • You shouldn't have to tie an app implementation to a specific desktop agent implementation (defeats the object of standardization)
  • The Desktop Agent will generally be running outside of any HTML page (in a container or web browser) and we are working out how it would retrieve a client (fdc3 API instance) to communicate with the Desktop agent - in Step 1 and 2 information or an implementation is provided from outside the app that it can use to load the right thing. Step 3 will involve loading without such information.
  • Some form of configuration (provided by an app) may be needed to control what implementations can be loaded by an installer library, possibly also a link to an appD record - the web application manifest may be suited to this.
  • Step 2 (web containers) proposal needs detail on how the web container details are passed to client/it is communicated with.
  • Step 3 (independent web apps) and Step 4 proposals (Micro-frontend Container (Single DOM)) are yet to be discussed
    • Step 4 is likely to be based on the FDC3 implementation retrieved in the previous steps and an API function to split off a separate instance
• @nkolba offered to run through his attempt to implement a solution
  • deferred to a future meeting
• Options for implementing Step 2 were discussed
  • URL parameters are not going to work in every app (framework).
  • Postmessage:
    • Communication via post message could either be direct or via a hidden iframe on well known domain (e.g fdc3.finos.org)
      • In the direct case:
        • the opener (window.open cases) or embedded (iframe cases) should know the origin of what they've opened and can securely listen for messages from it.
        • the opened app should be able to communicate to its window.opener (window.open) or window.parent (iframe) - but initially without filtering responses by origin (as it may not know it until after a message is received).
      • In the indirect case, the shared domain acts as a proxy - giving the appearance of more security, but not really any more in practice (anything could be on the other side) - whilst also creating a single point of failure for the whole FDC3 eco-system.
    • Some form of handshake will need to be defined and the web manifest might be a good way to express config that might be used to control the communication/filter allowed parents.
    • Use a whitelist, which might be open by default, allowing vendors to put out integrations that work with any agent.
      • FDC3 APIs are all 'opt-in' - no info is shared without the apps cooperation - hence, this is not inherently insecure.
    • Postmessage could be used just to pass details of what client lib to load OR as a full proxy for communicating with a remote desktop agent
      • Full proxy approach is restrictive (for example what if the agent is on a server and not in the browser at all, or has optional features implemented that others do not). An implementation might use postMessage through a hidden iframe anyway - we might not want to proliferate (and end up debugging) too many of these.

Decisions made

• We should prefer a step 2 solution that indicates what client library to load (rather than using a full proxy implementation of the the FDC3 API)
  • A postmessage solution for passing details of what agent client lib should be loaded is preferable (to URL parameters)
  • We should avoid a dependency on a single (FINOS) domain and define communication that doesn't require it - hence communication should be direct between the child application and 'parent' (Desktop Agent)
  • A handshake protocol will need to be defined
• We should complete the discussion of requirements and approaches before reviewing competing implementations of the approaches
  • Hence, the next meeting agenda should focus on Step 3 and 4 requirements, perhaps more detail on Step 2, before we do more run-throughs of proposed implementations.

Action Items

• Arrange next meeting agenda: Step 3 and 4 requirements.

Untracked attendees

Full name	Affiliation	GitHub username

[tpina]

Tiago Pina / Finsemble

[novavi]

Derek Novavi / S&P Global

[pierreneu]

Pierre Neu / Symphony

[Julia-Ritter]

Julia / FINOS

[robmoffat]

Rob / FINOS 🥔

[kriswest]

Kris West / Finsemble 🚀

[bingenito]

Brian Ingenito / Morgan Stanley

[thorsent]

Terry Thorsen / Finsemble

[kziemski]

Kryspin Ziemski/ QCOMPUTE

[psmulovics]

Peter Smulovics / Morgan Stanley

[hughtroeger]

Hugh Troeger / FactSet

[WatsonCIQ]

Chris Watson / Finsemble 👋

[Julia-Ritter]

Untracked attendees:

• Alexandru Dumitru / Citi
• Maria Krupl / MS
• Pavlo Vozniuk
• Srikanth Tanniru / Red Hat
• Vinay Mistry / Symphony
• nick k / Connectifi
• Rob M / FINOS