FDC3 for Web Browsers meeting this week

[Kris West]

Hi All,

The next meeting of the FDC3 for Web Browsers discussion group is tomorrow (Thursday 1st June). This week we'll be continuing to discuss requirements and design goals, moving on to how a solution might be used in an app and perhaps implementation options. 

Please find the agenda and joining details below and at https://github.com/finos/FDC3/issues/1009. I also include the latest draft of the requirements and design goals below for any that is interested in getting up to speed with the discussion.

WebEx info

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

Agenda

• Convene & roll call, review meeting notices (5mins)
• Review action items from previous meeting (15mins)
• FDC3 for Web Browsers Discussion group - 18th May 2023 #991
• Recap requirements and design goals agreed so far.
• Continue requirements and design goal discussion (15mins)
• Explore how a solution might be used in an app via code examples (20-25mins)
  
• Discuss implementation options (if time)
• AOB & Adjourn

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:

1. 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).
2. 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.
   
3. 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.
4. 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) \

1. Don't break FDC3 for existing applications (use case 1 apps).
2. Any solution should aim to support all 4 proposed use cases
3. It should be possible to write applications that can run under any of the first 3 4 use cases without code modifications (preserve WORA).
4. 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.
5. 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?
      2. Note: Implies a requirement for being able to authenticate a Desktop Agent…
   4. Security / type of implementation?
6. 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).
7. Any solution should not force the addition of security holes into applications.
8. 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.
9. 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?

K

--

Kris West he • him
Principal Engineer

kr...@finsemble.com finsemble.com