FDC3 for Web Browsers Discussion group 19th October 2023

kriswest commented 1 year ago

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: 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.

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 19 October 2023 - 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
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.

Agenda

[x] Convene & roll call, review meeting notices (5mins)
[x] Review action items from previous meeting (5mins)
- 1084
[x] Review (final?) API proposal widget and sub-apps to receive their own FDC3 API instances: getSubInstance() function (20mins)
[x] Revisit fdc3Ready proposal (10mins):
- App identity validation by desktop agent
- Keeping consistent instanceIds
- Handling channel selection and IntentResolver UIs (15mins)
[ ] Next steps
[x] AOB & Adjourn (5mins)

Minutes

The meeting initially focused on reviewing the getSubInstance() API proposal and its re-use of concepts fro the main browser access proposal,
- particularly the self-identification of app via an appD record (indicated by a fully qualified appId or URL to an appD record)
- This is particularly necessary for a set of widgets or apps that share the same URL as they need to be differentiated.
- A participant suggested that the name for this API and other parts of the proposal could be improved
Updates, suggested at the previous meeting, to the proposal were reviewed - particularly to the section on identity validation procedure, and further refined:
- The proposal was divided into a 'FDC3 Web Connection protocol', and 'FDC3 Access function' that implements that protocol and an 'FDC3 Browser Communication protocol' that is used to communicate with a desktop agent running elsewhere in the browser that was accessed via the Web Connection protocol, and implemented as a 'DesktopAgentProxy' that conforms to the Desktop Agent interface.
- The 'FDC3 Browser Communication protocol' is yet to be defined, but should be bi-directional and relatively easy to derive based on the existing FDC3 API interface. It is simpler than the bridging protocol but will be similar, requiring a set of standard JSON messages.
- There was consensus that the proposed method of identity validation (comparison of app origin to that of a start url/new array of allowed origins) is sufficient for a first version and can be extended later to use any more detailed identity mechanism introduced across FDC3 - for example a mechanism based on a signed token, validatable via a public key provided in the appD record.
- It was noted that this requires that an app developer publish their appD record - although this is currently rarely the case (consuming firms publish records for those apps they use in their desktop currently - this was not intended, but is whats evolved and would likely need to change - this in turn might revive conversations about federating app directories.
- @kriswest noted that the fact that identity verification goes through the a vendor's appD (as their code needs to point at it) doesn't prevent a different record being used to incorporate an app into a desktop (as long as the vendor record can be used to verify identity).
- Re: Connection protocol
- It was agreed that if references to multiple parent windows or frames are found, messages should be sent to all and the first to reply (with a messaging confirming the existence of a Desktop Agent) acted on.
  - This is compatible with the agreed requirement that an app spawned by a Deksotp Agent should connect back to that agent only.
- @novavi noted that the proposed 'failover' function argument might lead to a situation where an app connects to the Desktop Agent that spawned it on first launch, but if that agent goes away (e.g. launcher/parent window is closed), may connect post-navigation or refresh to a different agent - which may be undesirable and may conflict with the agreed requirement that apps always connect to the agents that spawned them
It was agreed that apps should be able to retain consistent instanceIds post navigation or refresh and that the proposal needs to address how this may be achieved - further research and discussion is needed on this topic.
The meeting did not fully address handling UIs for Channel Selection and Intent resolution, which should be discussed at the next meeting

Action Items

[x] @kriswest apply agreed updates and clarifications to the proposal
[ ] @novavi confirm if WindowProxy objects are comparable, allowing them to be used as a mechanism for assigning consistent instanceIds to apps (that still validate as having the same identity) - comparison needs to be backed by the HTML Standard to be trustworthy, otherwise an alternative mechanism will be needed.
[x] @kriswest Add assigning consistent instance ids, revisiting the failover function and handling UIs for Channel Selection and Intent resolution to the next meeting agenda.