FDC3 for Web Browsers Discussion group 27th 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 27th 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 [email protected]
  • 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 [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 review of 'Questions to answer to set Implementation Details' - in shared document, items marked in red (30 mins)
  • Options to pass to Desktop Agents
  • App Identity
  • API to retrieve additional API instances (Use case 4)
  • Security issues
  • FDC3 versions
  • NPM module(s) and naming
• Review 'Summary of discussions ' in shared document (15mins)
• AOB & Adjourn (5mins)

Minutes

• The meeting briefly revised the question of how configuration options should be provided to Desktop Agents, through the installer
  • The use of an App Directory Record was reconfirmed as the preferred route (as this is how such config is currently provided - both for intents and DA implementation-specific options in hostManifests)
• The rest of the meeting focused on the discussion of use cases 2 & 4 and the provision of identity details for apps
  • It was noted that current FDC3 versions/implementations tend ignore the fact that web pages can be navigated and become other apps
    • This is rare in containers which tend not to display an address bar, however, in web browsers this will always be present and users will expect to be able to use it
    • @kriswest confirmed that the window.opener reference remains in place and can be used for postMessage communication (albeit originating from the new origin) with a parent window - meaning apps that have navigated and become new apps can still use postMessage to communicate with a parent DA window - although they should not have an assumed identity and should supply a new identity that can be validated.
  • postMessage communications will always include the origin of the window that sent the message - hence this may be used to help establish/validate the app's identity.
  • @kriswest suggested that this group may need to start working on issues of app and desktop agent identity (rather than deferring to the discussion group starting up) in order to produce an MVP
    • @pbaize indicated a reluctance to trust app-provided info without a way to validate it - a position on which there was general consensus
    • It was further suggested that by @kriswest that public/private key system might work for this with public keys provided in appD records, and the requirement for a signed token to be passed by an app to confirm its identity.
    • @pbaize made the further suggestion that app-provided info might be more trustworthy if it can be validated or scoped via brower-api provided info
      • Further discussion established that this is a viable approach!
        • AppD records already contain start URLs and could be augmented with allowed origins as needed.
        • Containers can establish the current URL of windows they host
        • child windows that communicate with a parent via postMessage reveal their origin in every message
        • independent web windows may need another procedure, but are currently out of scope for an MVP, beyond providing an escape hatch to run custom code if other use-cases do not apply.
        • Micro-front-end-container windows with multiple widgets can use the same procedure as long as appD records for the widgets contain the details of their host window, whose identity / origin should be established via one of the other use-cases

Action Items

• @kriswest to update the summary at the bottom of the shared doc with details of the identity establishment procedures (based on window origin)

Untracked attendees

Full name	Affiliation	GitHub username

[rfinter13]

Rose Finter - FactSet

[mistryvinay]

Vinay Mistry / Symphony 🎵

[hughtroeger]

Hugh Troeger / FactSet

[pbaize]

Pierre Baize / OpenFin