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_1Oit0BF3fsXyvlMbisXp722DC9Kg?e=H2y7fn

Relevant issue tags

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

Meeting Date

Thursday 18 July 2024 - 11am (US eastern timezone EST) / 4pm (London, BST)

Zoom info

• Join Zoom Meeting
• Meeting ID: 969 4029 4948
• Passcode: 636931
• Dial-in:

  Country	International Dial-in	Toll-free Dial-in
  US	+1 929 205 6099 (New York)	877 853 5247
  UK	+44 330 088 5830	0800 031 5717
  France	+33 1 8699 5831	0 800 940 415
  Find your local number	https://zoom.us/u/ad2WVnBzb8

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.

Participation Requirements

Note: Meeting participants are expected to accept the terms of the FDC3 license (Community Specification License), understand the governance process and have a CLA in place.

Please click the following links at the start of the meeting if you have not done so previously.

• View the CSL
• View the GOVERNANCE of the Project
• Click here to start a PR.
  • Edit the page to add your details.
  • Hit the save button.
  • Click "Create Pull Request".
  • Click "Accept" on the EasyCLA dialog in the PR's discussion section.
• Click here to send email to become a voting participant on the FDC3 Project

Tracking Attendance

Note: Meeting participants are expected to add a comment to this GitHub issue in order that we can track attendance of FDC3 project meetings. Please do this at the start of the meeting.

Agenda

• Convene & roll call, review meeting notices (5mins)
• Review action items from previous meeting (5mins)
  • FDC3 for Web Browsers Discussion group 20th June 2024 #1229
• Enhancements to messages defined in BrowserTypes #1268
• Support for Multiple Application Scopes (Agents) within a single window process #1250
  • Tear down patterns (Question: Disposal/Teardown patterns in FDC3 #1263)
• @robmoffat's questions about the GetAgentParams
• (if time) Mono-repo refactor (related to Don't bundle CSL license file into FDC3 NPM module #1209)
• AOB & Adjourn (5mins)

Minutes

• Enhancements to messages defined in BrowserTypes #1268
  • @Roaders introduced the issue which suggests that we provide type that is a union of all messages and a set of type predicates that can differentiate the different messages
  • @kriswest provided some detail on the code generation from schemas used to generate BrowserTypes.ts, the base message types which are structurally compatible with all derived message types and generated enumerations of the message type values.
    • @kriswest to deal with type generation script generating a commandline command that is too long.
    • @Roaders to explore generating type predicates automatically etc. using TSMorph
  • @openfin-johans requested clarification on whether any of the proposed changes are breaking or would be required for confromance with FDC3 (for an existing container product, rather than a browser-absed product)
    • @kriswest confirmed that the main proposal does not create new requirements for containers and is non-breaking.
      • There is a second proposal (Support for Multiple Application Scopes (Agents) within a single window process #1250) which does add a new API call for retrieving a sub-agent, that would place new requirements on a container implementation if it was required (MUST). That has not been determined yet.
• Support for Multiple Application Scopes (Agents) within a single window process #1250
  • @kriswest provided an introduction to the Multiple app scopes in one window issue (Micro-frontend Containers) and the existing proposal to resolve it, which is based on the same techniques as the main FDC3 for Web Browsers proposal (passing some Id details)
    • non-breaking, but may be an additional requirement for containers to implement in 2.2
    • @Lecss asked if a parent-child relationship is implied by the name of the proposed function getSubAgent, which mirrors getAgent used in the main proposal.
      • @kriswest answered that to a certain extent that is true as you need to establish an FDC3 connection/API instance for the window first (fdc3) and then use that to retrieve a sub-agent
        const anotherFdc3 = await fdc3.getSubAgent(...) however once retrieved there is no implied functional link between them (in a browser it would likely communicate with the same 'parent' as the window-level agent, while container implementations can implement however they prefer.
  • Tear down patterns (Question: Disposal/Teardown patterns in FDC3 #1263)
    • @Davidhanson90 introduced this additional issue - cleaning up FDC3 connections when a widget or window has gone away
    • @kriswest explained how this is handled in containers at the window level - they are able to track and observe the status of windows and clean-up automatically on close, hence, FDC3 currently contians very little in this area. Thought on this topic will be more necessary in web-based agents as the HTML Standard APIs do not provide an event (As far as we know) that you can listen to to catch the window closing - we believe the best you can do is poll a particular value on a MessagePort that tells you if the other end is still active...
    • With sub-agents something explicit would also be needed (as the scope/DOM may remain without the widget). In both cases, widgets or apps that have closed need to be cleaned up or they will turn up in intent resolvers and APIs that return instance details such as findIntent and findInstances
    • @robmoffat said he was using websockets in the POC and could detect when these went away - but this is not relevant to the MessagePorts approach used to interface with frames/windows proposed for standardisation.
    • @novavi mentioned finalisation registries in javascript as perhaps relevant to this problem
    • @robmoffat took an action item to look at cleaning up resources for windows and iframes that have gone away under the main proposal.
    • @Davidhanson90 took an action item to look into the issue with tear-down of subagents.
    • @kriswest summarized the fact that there are two separate proposals for the group to be raised to the SWG for consideration: FDC3 for Web and SubAgents and there was consensus that they could / should be raised separately and may end up in different FDC3 versions. The group has a goal of trying to get the first proposal raised an adopted in time for OSFF 24 in NY.
• @robmoffat's questions about the GetAgentParams
  • @robmoffat @kriswest and @novavi provided details of some discussion they'd had since the last meeting about the arguments to the getAgent function and deviations from them in the POC work.
  • Identity of apps: As proposed apps would point to a appD record providing their identity and metadata via a fully0qualified appId or appDUrl
    • @robmoffat Proposed to switch to sending the app's URL instead, which the DA would then need to look up in its own DA.
      • @kriswest gave an overview of how appD's have been used (hosted by adoptors putting apps into their own desktops) vs. how they were intended (to be published by vendors and then linked to by adoptors) - and how they were proposed for use in FDC3 for the Web: apps provide details of a record that their identity would be validated against (by comparing message origin to allowed origins in the appD record) - optional for DAs to compare to their own records. Essentially relying on the DNS system to validate app identity via domain ownership.
      • It is further proposed that deeper identity validation is adopted later, based on recommendations of the Identity & Security group, which is likely to propose the addition of asymmetric encryption keys (public key) to appD records for other purposes and could be used to create a cryptographic identity validation system (which would be easier to apply to other languages in which FDC3 maybe implemented). Hence, we do want appD records involved in identity validation.
      • We also propose to support use cases where users independently enter URLs in a browsers - which might result in an an FDC3 enabled app being present that the DA is not aware of in advance - if the app identifies an appD record its possible to know something about it... This is supported by the 'failover' function specified in getAgent.
        • This was not explicitly decided in the meeting - but there was consensus that we should switch to using the URL for identity with the DA looking up the record, which implies that the DA must know about the application in advance.
      • @Roaders asked whether URL validation would include the has and search parameters... These can make the URL represent a different logical application.
        • Others had assumed that these would be ignored, but there was consensus that this would not work in all cases. There were also concerns that it would be hard to identify what parameters matters and what did not.
        • @kriswest proposed that what is in the appD record could decide what is required. If the appD record contains only the origin and path then the search and hash are ignored in the comparison. If either parameters or a hash are present then they must be present in the URL being validated to match. The JavaScript URL class can be used to implement the comparison easily enough based on its parsing of URLs. There was consensus that this would work.
          • It was agreed to defer to later any additions to the appD record for multiple possible app URLs (different environments or deployments) - this would be a premature optimisation.
          • It was further clarified that connection to an appD by a DA is recommend but not required. Hence, DAs that don't use an appD will need to have an equivalent form of configuration that they can compare to.
        • @kriswest to update the proposal doc and PR to base identity arguments on URLs as described, with responsibility for the DA to look up the appD record (or equivalent config).
    • There was consensus that we can switch the proposal to use URLs for identity management
      • @robmoffat to update the POC to work on URLs for identity - if not specified the current window.location.href should be used by default

Action Items

• @kriswest to deal with type generation script generating a command line command that is too long
• @Roaders to explore generating type predicates automatically etc. using TSMorph
• @robmoffat to look at cleaning up resources for windows and iframes that have gone away under the main proposal.
• @Davidhanson90 to look into tear-down patterns for subagents.
• @kriswest to update the proposal doc and PR to base identity arguments on URLs as described with a defined comparison procedure.
• @robmoffat to update the POC to work on URLs for identity - if not specified the current window.location.href should be used by default, and window.location.href should always have a matching origin to the specified URL.

Rolled over and/or still in progress:

• @kriswest to apply changes to deal with as many of the comments on the docs PR (FDC3 for Web specification #1191) as possible.
• @kriswest to ensure that a README and screencast video is provided on maintaining schemas and code generation.
• @robmoffat to seek out and recruit other potential POC collaborators
• @robmoffat to continue work on getting the conformance framework to run over the POC codebase and to connect with @kriswest to confirm race conditions and resolutions needed in the framework.

Untracked attendees