FDC3 for Web Browsers Discussion group - 18th May 2023

kriswest commented 1 year ago

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: https://github.com/finos/FDC3/issues/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 18 May 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

[x] Convene & roll call, review meeting notices (5mins)
[x] Review action items from previous meeting (5mins)
- 976
- Recap requirements and design goals agreed so far. Google doc link
[x] Continue requirements and design goal discussion (30mins)
[ ] Explore how a solution might be used in an app via code examples (10-20mins)
[ ] Discuss implementation options (if time)
[x] AOB & Adjourn

Minutes

The meeting continued the discussion of requirements and design goals for a solution. The current draft is:

Definitions:

Use cases (ways a Desktop Agent might be used)

An installer library will need to allow for several different formats of FDC3-enabled environments built with web technologies. Terminology for these is defined below:

Container or Browser Extension: A web app running in the context of a container or browser extension that provides an implementation of the FDC3 API (the traditional FDC3 use-case).
Web container/Child Web App (window.open / window.opener / iframe): A web app running in a window opened by a web app running in another browser window with a Desktop Agent running in it or otherwise associated with it. OR A web app running in an iframe inside another window with a Desktop Agent associated with it.
Independently opened web app: A web app running in an independent window (for example user typed in a web address in a browser), not opened or embedded in any other window.
Micro-frontend Container (Single DOM): Multiple separate 'apps' running in the same DOM, that could communicate with each other and other windows through the desktop agent.

FDC3 Installer / Bootstrapper / Discover library

A library that enables an app to retrieve a FDC3 Desktop Agent Implementation (and will generally be independent of it) - allowing app developer to avoid tying their implementation to a specific implementation of FDC3.

Requirements:

(Note 'this solution' / 'any solution' refers to the overall proposal not just an installer library of API changes etc. as different things may be needed to solve for each case) \

Don't break FDC3 for existing applications (use case 1 apps).
Any solution should aim to support all 4 proposed use cases
It should be possible to write applications that can run under any of the first 3 4 use cases without code modifications (preserve WORA).
It should be possible to write use case 4 applications (micro frontend containers) where the FDC3 implementation for the window (the root Desktop Agent Instance?) is retrieved via any of the first 3 use cases.
An app developer should be able to control / limit what implementations of an FDC3 Desktop Agent it will accept, by:
1. Version
2. Owner of implementation?
  1. Note: Implies a requirement for being able to authenticate a Desktop Agent…
3. Vendor of implementation?
  1. Note: Implies a requirement for being able to authenticate a Desktop Agent…
4. Security / type of implementation?
Apps using an installer that are started by a particular Desktop Agent (use case 2) should prefer retrieving that implementation (unless prevented by configuration as per requirement 4).
Any solution should not force the addition of security holes into applications.
If no configuration is or preference for a Desktop Agent is provided by an independently launched (use case 3) then no agent should be loaded.
A Desktop Agent vendor/owner should be able to decide whether to accept the application. \

Design Goals:

A solution to 'install' or 'retrieve' an FDC3 implementation should work across different versions of FDC3 / be independent of the FDC3 Desktop Agent version - particularly on the same major version. I.e. An app should not have to update its installer library version to retrieve / work with a different FDC3 Desktop Agent version.
There SHOULD be feedback to the end user and the app developer if the loading of an FDC3 implementation is blocked (e.g. by configuration) - particularly for container and child web apps (use case 1 or 2).
Any solution should be lightweight (don't increase bundle size unnecessarily and doesn't create make it harder to adopt FDC3)
Any solution should avoid FDC3/FINOS/the library etc. having to maintain a list of all Desktop Agent implementations? However specific applications might supply such info as part of a configuration (e.g. allow or deny list).
Should enable, rather than limit innovation in the design and build of Desktop Agents as much as possible.
Use of the installer library should be as simple as possible - i.e. avoid developers needing to add too many additional lines of code for bootstrapping or waiting for the implementation to be ready.
The installer process should be async and not blocking, by design. (can be awaited as needed)
The installer should be quiet on failure: don't spam the console endlessly
The installer should continue to retry on failure to retrieve an implementation.
- Implementation might be started later
- Might fail and restart
It should be possible to know the status of the retrieval of an implementation (if promise based this might just be the promise resolving).
User input should not be required to select an agent.
Two independently started web apps which have overlapping allowed implementations should be able to discover that overlap and pick the same implementation?