FDC3 for Web Browsers Discussion group 13th July 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 13 July 2023 - 11am EST / 4pm BST

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 25521733304@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: 255 217 33304

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.

Agenda

• Convene & roll call, review meeting notices (5mins)
• Review action items from previous meeting (5mins)
  • FDC3 for Web Browsers Discussion group - 29th June 2023 #1017
  • Shared doc link
• Review and discuss 'Questions to answer to set Implementation Details' (30 mins)
• Discuss next steps for the group (15 mins)
• Adjourn

Minutes

The meeting largely focused on the questions table added to the document:

• Questions to answer to set Implementation Details
  • What use cases need to be addressed?
    • All 4, but with limitations on use case 3 (independently launched apps) as its complicating things.
  • Can we make a breaking change to FDC3 to do this?
    • No
  • Do we need to preserve WORA – to now work across containers and browsers?
    • Yes!
  • What should the app developer be able to control?
    • FDC3 version - apps will generally be written to a particular FDC3 version - where desktop agents already support multiple versions. Hence, give this control to app developer.
    • Provider(s) they will accept? Or Owner (whitelabel)? Provider versions?
      • This is far more complex in use case 3. Its a much simpler filter in use-case 1 & 2.
      • Consider just not loading one or load a single default option in use case 3.
      • Authentication mechanisms are critical...
    • There was much further discussion on methods of discovering a default implementation and integration types (post Message proxy/dynamic script load)
      • Both have potential security issues... solutions will need careful design
    • How is the Desktop Agent delivered or connected to by the installer? Proxy? Dynamic Script import?
      • Notes added but no clear decision on whether to to do one, the other or both.
  • If an app is started by an FDC3 Desktop Agent should it always pick up that Desktop Agent?
    • Yes, that or nothing - it wouldn't make sense to be started by one agent but then load a different one.
  • Where / how should configuration options be provided to the library
    • Options (may be combined):
      • in code
      • web app manifest
      • AppD record
      • Container manifest/config
    • No clear decision, but it was noted that FDC3 already requires an appD record in order to read metadata on the app and intents supported.
      • However, in Use cases 3 and 4 we need a way to indicate the appD record location.
  • Should there be options to pass through to the Desktop Agent – if so what and how?
    • appD records already support this through hostManifests, so if we solve linking to an appD we get this for free.
  • Handling different versions of FDC3
    • In previous meetings we've discussed the idea that you shouldn't have to change the loader in order to change FDC3 versions (with some thought going into using generics to allow the output type to change).
      • However, when revisited it was determined that this would rarely make sense!
      • An app will generally be written to a particular FDC3 version and currently just import types for that version.
      • Whereas Desktop Agents are already supporting multiple FDC3 versions (e.g. 1.2 and 2.0)
      • Hence, it would make more sense for this change to be made such that an app can continue to just import a particular FDC3 version, for that to serve as the configuration/option for FDC3 version and for Desktop Agents to support multiple versions if they wish to.
      • Further, this would make the existing FDC3 module the ideal place to put 'the loader' - perhaps co-opting/replacing the fdc3Ready function from methods.ts
• Next steps
  • There was consensus that:
    • discussion regularly gets stuck on the independently launched web app use case and that we've already agreed that we don't need to expend too much effort on it - mainly we should be ensuring that supporting it does not break the other use cases
    • we should focus on defining an MVP scope next and move to implementation proposals/attempts (some of which are already underway)
  • MVP scope is likely to include:
    • Support for use case 1 (ensuring that we don't break existing apps built to run in containers)
    • Support for use case 2a (child web apps spawned into their own windows, with desktop agent as parent)
    • (maybe) Support for use case 2b (child web apps that are iframes in another window) - we need to determine how important this use case is and if the parent is a desktop agent or other app that is itself communicating with a DA (two-hop proxy needed?)
    • Minimal support for use case 3: Either loading no agent or a default agent indicated by the application
      • postMessage proxy methods are not supportable unless the app spawns the desktop agent window or hidden iframes are used, which is additional complexity.
      • this leaves dynamic script load or somehow indicating / bootstrapping an agent that's already loaded, without that conflicting with use case 1 or 2.
    • Support for use case 4: API addition for retrieving a 'sub-agent' and indicating the appropriate appD record to read for it
  • The next meeting agenda should focus on the MVP spec and implementation efforts

Action Items

• ...

Untracked attendees

Full name	Affiliation	GitHub username

[novavi]

Derek Novavi / S&P Global

[WatsonCIQ]

Chris Watson / Interop.io 👋

[openfin-johans]

Johan Sandersson / OpenFin

[hughtroeger]

Hugh Troeger / FactSet

[kriswest]

Kris West / Interop.io 🚀

[kziemski]

Kryspin Ziemski / QCOMPUTE