finos
FDC3 For Web browsers
Enhancement Request
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.
Hence, I strongly encourage any vendors or firms working on API implementations that would fall outside current compliance requirements to work with the FDC3 maintainers and community, in general, to help move the Standard forward! The first step will be to raise an issue to bring to the Standards Working Group, which might then move to a Discussion Group to develop a proposal for additions to the Standard and its software. The maintainers meet again next week and will discuss getting such an issue on the books.
This is therefore a placeholder issue where we can begin to discuss how to solve this problem and potentially open up FDC3 to a wider audience.
This is a problem with some prior art:
- @ggeorgievx @ksgeorgieva @flashd2n from Tick42 have already implemented "Glue 42 Core" which provides a vendor-implementation of "FDC3 over the web"
- @nkolba has been working on Connectifi, which is adjacent to this.
- @nkolba has also been working on FDC3-Sail, which contains some of the parts to solve this problem (I think)
- I have been thinking about for several months as part of project planning for FINOS for 2023 - I will share my thoughts in the comment below.
As @kriswest says in the quote above, he thinks there is interest within the community. I have personally talked to a number of App vendors who are confused as to why this isn't a thing already.
I am hoping we can have a discussion on this at the next maintainers' meeting and move this forwards
Here is my thinking so far on the subject (more to seed a debate rather than anything else).
-
Glue Core uses PostMessage to allow FDC3 to communicate within-browser but across tabs. This is a promising line of inquiry and I'm hoping we can learn more from that team about how this works. There are security concerns here that I would like us to think through.
-
In discussing this with @kriswest yesterday, we agreed that it would be nice to rally around a well-written Use Case. Perhaps this is where we should start?
-
A further point we discussed is the need for what I am calling an FDC3 "wire protocol":
- FDC3 Sail implements a bus for FDC3 messages between apps, with the agent acting as router (and converting between FDC3 versions as needed).
- Desktop Bridging is also essentially the same thing - providing a sockets-based messaging protocol between different desktop agents.
- At some level, Connectifi must be implementing a bus also.
Hi @robmoffat thanks for raising this issue.
Related this this, on the point @kriswest raised (which you cited) about the possibility of using a 'vendor-agnostic FDC3 NPM module to detect and connect to API implementation(s)', I have something to share.
I have implemented this fdc3-installer library:
https://github.com/novavi/fdc3-installer
over the last few weeks. It aims to provide a solution to the problem in browser-based environments of tight coupling between FDC3-enabled apps and FDC3 Desktop Agents, by providing a mechanism to dynamically discover and install an agent within an app at runtime. This approach allows an app to run both in a desktop container (using the container's built-in agent) and also in a browser-based micro-frontend container (using a dynamically-installed agent) with zero code changes to the app. The library supports multiple strategies for the areas of agent discovery, creation and bootstrapping - with the ability to easily add and try out additional strategies based on any subsequent discussion / ideas.
The library does not claim to have all the answers by any means, but demonstrates some of the options that could potentially be used for a solution in this area. I hope this will help in the wider discussion that needs to be had within the FDC3 community about how we can best overcome the tight-coupling problem for browser-based FDC3 Desktop Agent implementations - and help move us towards standardized approach in the future.
I was originally aiming to publish this library more like sometime next month rather than now but after seeing that you'd raised the issue, I brought this forward in the interest of the discussion and just published what I have now. Because of this, I haven't actually even proof-read the stream-of-consciousness that I turned into a README yet, so parts of the description might still be a bit rough round the edges.
@novavi many thanks for sharing your work on this issue.
While I suspect/hope we'll end up adopting a subset of what you propose, it nevertheless represents a tour-de-force in exploring the options and related issues. I look forward to reviewing (and hunting for the strategies I intend(ed) to propose within your implemented set).
K
On Mon, 23 Jan 2023, 10:08 Derek Novavi, @.***> wrote:
Hi @robmoffat https://github.com/robmoffat thanks for raising this issue.
Related this this, on the point @kriswest https://github.com/kriswest raised (which you cited) about the possibility of using a 'vendor-agnostic FDC3 NPM module to detect and connect to API implementation(s)', I have something to share.
I have implemented this fdc3-installer library:
https://github.com/novavi/fdc3-installer
over the last few weeks. It aims to provide a solution to the problem in browser-based environments of tight coupling between FDC3-enabled apps and FDC3 Desktop Agents, by providing a mechanism to dynamically discover and install an agent within an app at runtime. This approach allows an app to run both in a desktop container (using the container's built-in agent) and also in a browser-based micro-frontend container (using a dynamically-installed agent) with zero code changes to the app. The library supports multiple strategies for the areas of agent discovery, creation and bootstrapping - with the ability to easily add and try out additional strategies based on any subsequent discussion / ideas.
The library does not claim to have all the answers by any means, but demonstrates some of the options that could potentially be used for a solution in this area. I hope this will help in the wider discussion that needs to be had within the FDC3 community about how we can best overcome the tight-coupling problem for browser-based FDC3 Desktop Agent implementations - and help move us towards standardized approach in the future.
I was originally aiming to publish this library more like sometime next month rather than now but after seeing that you'd raised the issue, I brought this forward in the interest of the discussion and just published what I have now. Because of this, I haven't actually even proof-read the stream-of-consciousness that I turned into a README yet, so parts of the description might still be a bit rough round the edges.
— Reply to this email directly, view it on GitHub https://github.com/finos/FDC3/issues/896#issuecomment-1400091717, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAM7PBGQKMDQ7S3S72MXK53WTZKALANCNFSM6AAAAAAUAFXPPQ . You are receiving this because you were mentioned.Message ID: @.***>
@kriswest no probs.
Yes tbh I'd be very much in favour of narrowing down to a subset of the options if this type of approach was to be standardized. The strategies you intend(ed) to propose might not even be amongst the ones I came up with actually! I'm sort of hoping that there might be more options on the table to choose from when standardizing this.
The main constraint I applied when listing out and implementing those discovery strategies was that the container-based ones must work on a cross-origin basis. I think it's sensible to make any standardized solution work for the more restrictive cross-origin scenario, and then it will automatically work for the (simpler) same-origin scenario. From my experience of large organisations who hope to provide a more unified customer experience for their existing brownfield apps, those apps are typically built by separate teams on separate tech stacks in separate repos with separate release schedules and deployed on separate subdomains. That is to say, if an organisation has apps that are commonly on the same subdomain as their container (and as each other) then they are quite probably heavily down the road towards a module federation approach, and may have less requirement for FDC3 interop in their apps in any case (except perhaps for third-party app integration).
There's more freedom on the app-based discovery strategies of course, because you don't have to worry about the cross-origin issue e.g. even reading from a previously-defined global variable would be possible. I did avoid a few other things like reading from meta tags e.g. that requires SSR of the host page in order to prevent it just being a pointless exercise in moving hard-coding from one place to another. That said, the general risk with app-based discovery strategies (as opposed to container-based ones) is that it could be quite easy to misuse them if one did not fully understand their purpose (e.g. again using an installer, but simply moving hard-coding from the app's code into the app's config).
In terms of the range of strategies supported, the whole concept certainly becomes less usable by casual FDC3 app devs and less supportable as a library if it aims too wide (indeed, supporting corner cases sometimes encourages requests to support further corner cases). Laying out the options in this library was partly intended as a mechanism to help test them and discuss them - because without a concrete implementation it can sometimes be hard to see the relative merits and pitfalls of different approaches.
Having said that, it's worth pointing out that we should really distinguish between a generic installer library that can load pretty much any arbitrary browser-based FDC3 Desktop Agent today (which is sort of what I just about implemented) and a future standardized installer that only needs to load a future FDC3 Desktop Agent adhering to a future spec version (2.1 or above?) which is clear about how agents are to be provided. For example, if a future version of the FDC3 spec mandated that an agent must be provided by a factory function and exported via an ES Module with a specific name, then one should be able to easily dispense with the different creation strategies - although one would still need to offer support to pass args to that function in a config of some sort (whether to provide a WebSockets url for a cloud-based approach, or simply just more mundane options applying to all browser-based implementations e.g. whether fdc3.open() should open apps in tabs / windows / iframes). The issue of bootstrapping is more involved than that of creation because as I alluded to in the README for this repo there is (currently at least) a relationship between agent bootstrapping and window.fdc3 installation in terms of the overall agent lifecycle... which is a subject for another email thread I think!
- Derek
On Mon, Jan 23, 2023 at 12:42 PM Kris West @.***> wrote:
@novavi many thanks for sharing your work on this issue.
While I suspect/hope we'll end up adopting a subset of what you propose, it nevertheless represents a tour-de-force in exploring the options and related issues. I look forward to reviewing (and hunting for the strategies I intend(ed) to propose within your implemented set).
K
On Mon, 23 Jan 2023, 10:08 Derek Novavi, @.***> wrote:
Hi @robmoffat https://github.com/robmoffat thanks for raising this issue.
Related this this, on the point @kriswest https://github.com/kriswest raised (which you cited) about the possibility of using a 'vendor-agnostic FDC3 NPM module to detect and connect to API implementation(s)', I have something to share.
I have implemented this fdc3-installer library:
https://github.com/novavi/fdc3-installer
over the last few weeks. It aims to provide a solution to the problem in browser-based environments of tight coupling between FDC3-enabled apps and FDC3 Desktop Agents, by providing a mechanism to dynamically discover and install an agent within an app at runtime. This approach allows an app to run both in a desktop container (using the container's built-in agent) and also in a browser-based micro-frontend container (using a dynamically-installed agent) with zero code changes to the app. The library supports multiple strategies for the areas of agent discovery, creation and bootstrapping - with the ability to easily add and try out additional strategies based on any subsequent discussion / ideas.
The library does not claim to have all the answers by any means, but demonstrates some of the options that could potentially be used for a solution in this area. I hope this will help in the wider discussion that needs to be had within the FDC3 community about how we can best overcome the tight-coupling problem for browser-based FDC3 Desktop Agent implementations - and help move us towards standardized approach in the future.
I was originally aiming to publish this library more like sometime next month rather than now but after seeing that you'd raised the issue, I brought this forward in the interest of the discussion and just published what I have now. Because of this, I haven't actually even proof-read the stream-of-consciousness that I turned into a README yet, so parts of the description might still be a bit rough round the edges.
— Reply to this email directly, view it on GitHub https://github.com/finos/FDC3/issues/896#issuecomment-1400091717, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAM7PBGQKMDQ7S3S72MXK53WTZKALANCNFSM6AAAAAAUAFXPPQ
. You are receiving this because you were mentioned.Message ID: @.***>
— Reply to this email directly, view it on GitHub https://github.com/finos/FDC3/issues/896#issuecomment-1400279240, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA2PIF2NEGCEAVBWP7JUIXDWTZ4B3ANCNFSM6AAAAAAUAFXPPQ . You are receiving this because you were mentioned.Message ID: @.***>
@novavi - this is great work! Thanks for sharing.
Just want to note that this is a code project and exactly the kind of work that is vital to the ecosystem. It also underscores that there isn't anything missing from the standard to solve this problem. In fact, as @robmoffat alludes to, Connectifi already provides secure and seamless support across all environments including web and cross-origin in full conformance with the 1.2 spec.
Keeping the standard simple, accessible, and focused only on those problems that truly address interoperability is the best way to continue to drive adoption as well as the innovation of FDC3.
It also underscores that there isn't anything missing from the standard to solve this problem.
That is not the case @nkolba - it demonstrates that the problem, of establishing standardized ways of retrieving a reference to an API implementation, is solvable. It absolutely doesn't eliminate the need to adopt a standard for how to do so that app developers can write a single way of doing so/single version of their apps. Further, @novavi's write-up on it clearly indicates several areas that would specifically benefit from standardization, or already do, in order to reduce complexity for the app developer. These include the installation of the API reference into window.fdc3, all 3 of the discovery, creation and bootstrapping strategies and the use of internal & external provider directories.
If we don't provide a clear standardized approach we are not keeping the Standard simple or accessible - quite the opposite as application vendors will still have to choose approaches, configure for individual providers, test widely etc. and hence we again encourage the ecosystem to become fragmented and factional. Whereas, with a little work we can likely reduce complexity for app developers significantly, aiming for as close to zero configuration and variation in code as possible. That is quite obviously addressing problems that affect interoperability and ease of adoption, where attempting to block the community from doing so is not.
As discussed in the standards meeting last week, it may helpful to split this (and the previous email thread) into three separate topics:
- Whether 1.2 Conformance tests should require FDC3 to be exposed as a global or if this should be optional (as the 1.2 spec states)
- Whether the global requirement should be continued going forward in 2.x
- What additional standards (if any) are needed for Web.
Note: while points 2 & 3 are somewhat related, the global issue doesn't just impact web. It is a blocker for conformance support on other tech stacks such as Java, .NET, Python, and many others and forces FDC3 conformance into a very specific type of implementation.
As discussed in the standards meeting last week, it may helpful to split this (and the previous email thread) into three separate topics:
- Whether 1.2 Conformance tests should require FDC3 to be exposed as a global or if this should be optional (as the 1.2 spec states https://fdc3.finos.org/docs/1.2/api/spec#api-access)
As discussed at the meeting (and minuted), I agree that the 1.2 spec allows for the FDC3 API reference to be provided by other means (MAY), but does recommend (SHOULD) that it is provided as a global. The SWG voted to change this in 2.0 such that the global is required (MUST) as it was widely agreed that a standard way to retrieve the FDC3 API reference was essential to the Standard as a whole and its uptake with the industry.
Further, it is somewhat awkward that, in order to run the tests on a 1.2 implementation without the API being provided via window.fdc3, the test framework has to be modified with proprietary dependencies and bootstrapping code for each implementation that needs testing - providing an example of the type of challenge that this creates.
- Whether the global requirement should be continued going forward in 2.x
- What additional standards (if any) are needed for Web.
I think it an odd suggestion that these two items should be dealt with separately as both relate to the code an app developer must write in order to get at a copy of the FDC3 API. If we don't provide an answer that spans both the web and containers, then this fractures the ecosystem and is likely to result in app developers having to provide different implementations, deployments and appD records not just for browser/container deployments, but also for working with different FDC3 implementations. Whereas, if we work to move the standard forward we can provide a standardized approach that works for all cases. The value in doing so for app vendors, desktop agent vendors and FDC3 adopters is obvious - so I'll refrain from restating it here again. I have, however, yet to hear a decent argument for why not moving the Standard forward on this issue would benefit the community in any way.
Note: while points 2 & 3 are somewhat related, the global issue doesn't just impact web. It is a blocker for conformance support on other tech stacks such as Java, .NET, Python, and many others and forces FDC3 conformance into a very specific type of implementation.
This is not the case as those global requirement has always been scoped to web applications:
API access in 2.0 https://fdc3.finos.org/docs/api/spec#api-access:
The FDC3 API can be made available to an application through a number of different methods. In the case of web applications, a Desktop Agent MUST provide the FDC3 API via a global accessible as window.fdc3.
API Access in 1.2 https://fdc3.finos.org/docs/1.2/api/spec#api-access
The FDC3 API can be made available to an application through a number of different methods. In the case of web applications, a Desktop Agent SHOULD provide the FDC3 API via a global accessible as window.fdc3.
This is expanded on in the supported platforms section in both versions, e.g. in 1.2 https://fdc3.finos.org/docs/1.2/supported-platforms#native:
The FDC3 standard does not define wire formats for communication. Hence, for native applications to be FDC3-enabled, they need to make use of a library (e.g. a DLL in .Net or JAR file in Java) that provides them with an implementation of the FDC3 API. FDC3-enabled native applications are therefore specific to particular desktop container frameworks (or other suitable environments) that provide the necessary libraries.
Despite this limitation, implementing support for FDC3 in a native application can allow it to interact with a wide variety of FDC3-enabled web applications.
I.e. the Standard's documentation acknowledges that the lack of a standardized approach to getting an API reference in other languages is a significant limitation, linking the value that can still be provided without one to interop with web (in this case container apps built with web technologies) where there is an answer. We also lack interface definitions in other languages - although I'm aware of at least a couple of community members working on that problem.
Again, it's rather obvious that the lack of standardisation is what's limiting native implementations and making it difficult to test them for conformance. The assertion that it is the requirements placed on web (which enable its conformance testing) that limit native, is daft.
K
P.S. I'm back in the office tomorrow and will work on arranging the proposed meeting to further the discussion.
Just on the issue of the provision of the window.fdc3 global going forward, for the benefit of anyone reading this who didn't already see the separate (longer) 'FDC3 Desktop Agents vs. API implementations and using FDC3 on the Web' thread, I would like to reiterate here a few key points that I made as part of that discussion:
- Regardless of one's views on making APIs available in the global scope in the general sense, providing the FDC3 API on the
window.fdc3object has the clear benefit of making all DAs consistent in terms of how they provide the API. Additionally, it's not too difficult to draw a distinction between an API that an application always imports for itself (e.g. like a grid or a utility library where it is always better to use the more modern module mechanism than to use a global) and an API which may well in a number of circumstances be pre-installed on behalf of the app by the container environment (e.g. in the case where an FDC3-enabled app optionally runs in a desktop container which provides a DA). - The
fdc3Ready()function implementation in@finos/fdc3uses the availability or non-availability ofwindow.fdc3when deciding whether to resolve or reject (https://github.com/finos/FDC3/blob/master/src/api/Methods.ts), so I believe changing the requirement aroundwindow.fdc3would also imply a change to the behaviour offdc3Ready(). window.fdc3has a dual use. The first use is simply as a mechanism for an app to obtain a reference to the DA's FDC3 API. The second use, although less obvious, is actually very important – this is the use of the global as a mechanism for a standardized installer library (or even just app-level conditional logic) to determine whether a DA is already provided/pre-installed. If the FDC3 standard did move away from requiring DAs to be installed inwindow.fdc3then there would probably need to be an agreed, standardized, new mechanism for desktop containers to provide a reference to their built-in DAs (and of course if that mechanism ended up just using a different global to provide a factory function or factory class, then the proposed change wouldn't be eliminating globals in the general sense - it would simply be removing one specific global).- Requiring a new way to discover whether a DA is already installed in an environment (in a newer version of the FDC3 standard) is further complicated by the fact that ISV apps would then need to worry about handling both the old (window.fdc3) and the new (as yet unspecified) mechanisms to test for a DA. This is because an app might need to run in existing versions of desktop containers (which support window.fdc3) and newer versions of those same desktop containers (which might support a different mechanism) and also have the ability to run in a browser by installing a browser-based DA.
Of course, there may be some valid counter-arguments to the ones I made above which could make a compelling case for the removal of the global from the standard (and which actually outweigh the disruption caused by the removal). I'd be interested to hear of any. The main one I can think of off the top of my head is if there was a requirement to install more than one DA in a given environment (although I believe this would go beyond what the current FDC3 spec provides for, and I would also have thought that any potential need to do that would likely be significantly undercut by the availability of a Desktop Agent bridge a.k.a. Backplane solution for interop between apps running in different ecosystems / containers that used different DAs).
For reference, the full 'FDC3 Desktop Agents vs. API implementations and using FDC3 on the Web' discussion thread I was referring to is here: https://groups.google.com/a/finos.org/g/fdc3/c/jCvlLjokBLs
At the last FDC3 Standards Working Group meeting (#899) it was resolved that a discussion group should be set up to discuss what changes need to be made to how the FDC3 API is accessed, to enable its use in a Web browser (rather than a container or browser extension that makes the API available at window.fdc3).
This is currently only possible through the import of an implementation from a proprietary module (allowed, but not recommended in standard version <=1.2, but not in 2.0), which has significant downsides for the FDC3 ecosystem as it requires an application to be adapted for each desktop agent that it may be used with (which is not the case when working with an injected window.fdc3). A lively discussion of possible ways forwards, and their impacts on the FDC3 ecosystem has already started over email, which should continue in the discussion group.
- Email thread: https://groups.google.com/a/finos.org/g/fdc3/c/jCvlLjokBLs/m/TBoK6lZYAQAJ
To help us organise the discussion group at a time suitable for all those who wish to participate, please indicate your interest and dates you could attend below (by clicking on the relevant emojis):
- 😄 Monday 13th Feb 11:30AM EST / 4:30PM GMT
- 🎉 Wednesday 15th Feb 10AM EST / 3PM GMT
- ❤️ Thursday 16th Feb 11AM EST / 4PM GMT
- 👎 Nothing works I need other options!
Poll Closed: result:
Kris mentioned in the 'FDC3 for Web Browsers Discussion group' meeting today (https://github.com/finos/FDC3/issues/908) that people could raise here discussion points about the use of FDC3 in web browsers and/or points for the next meeting relating to any potential evolution of the standard.
I don't actually have any specific issues for the next meeting at this stage (I'm sure I'll think of something nearer to the time). But just to pick up on one point raised today about the alleged inability to use the postMessage API for native browser local cross-origin comms (sorry, I can't remember who mentioned it now). To be clear, postMessage API can in fact be used successfully for native browser local cross-origin cross-window interop.
The restriction in this case is that (unlike the same-origin-only Broadcast Channel API) postMessage API requires a target window reference and also (assuming you sensibly want to avoid reliance on asterisk wildcards for security purposes) a target window origin when posting messages. In the case of an iframe, it can perform limited discovery of sibling iframes because even though it can't access its container's DOM on a cross-origin basis, it can still use the container's window.frames collection on a cross-origin basis. However, even with those sibling window references, it cannot (to my knowledge) read the original or current location hrefs for those windows - or indeed discover the appIds of the apps currently running in those windows. Moreover, there's also the wider problem of interop with external tabs/windows - only the iframe which originally spawned the external tab/window would be able to directly interop with it (i.e. via the window reference returned by window.open() or by window.opener depending on the direction you're messaging) and anything that involved indirect interop by means of republishing messages across a chain of windows would obviously be too brittle to be worth considering - not least because one or more of the windows in the chain could be closed by the user at any time.
This all means that postMessage API can be used for cross-origin cross-window local interop, but that you simply need a solution to the above routing problem. One solution is to use some sort of lightweight 'hub' or 'router' in the original container window to help orchestrate things for the DAs in the app windows (e.g. route interop/channel messages, and open external windows on behalf of the iframe apps and track the references to those opened windows). One consequence of this approach (which is broadly what I used in a limited FDC3 DA implementation myself) is that it matters where a window is opened from. For example, if you opened an external window via the original container (i.e. an fdc3.open() invocation within an app window which delegated the actual window.open() to the parent container), then interop with the external window would work fine. But if you bookmarked that external window, closed it, and later reopened it - then you would have no interop because you'd have no window reference on either side.
In practice, I don't believe the extra hop via a 'hub' or 'router' in the container presents any problems for most real-world scenarios. Now, there might be some limited alternative solutions for peer-to-peer style iframe interop, perhaps involving some sort of handshaking to overcome the initial lack of visibility around the window hrefs (although I'm honestly not sure how you'd do this securely in a manner that would allow you to ever trust the other iframe window). The issue of peer-to-peer local interop with external windows seems intractable to me though - at least based on current browser APIs that I'm aware of . I'd actually be interested if anyone had any different patterns for cross-origin local messaging in general.
Anyway, the end result of all this is that for most real-world scenarios you could potentially use postMessage API for native browser local cross-origin interop - as long as you use a sensible approach for message routing. However, in the specific theoretical situation where FDC3 apps / windows were opened completely independently of each other (a so-called containerless scenario) you would then have to use a cloud-messaging WebSocket API approach, instead of being able to use a local-messaging postMessage API approach. And of course there are a few other scenarios where a cloud-based approach could achieve things that a local-based approach could not support e.g. direct interop with an app on a another device, without using a bridge.
thanks @novavi - this an excellent summary of what is feasible as well as the challenges with the client only approach to interop in the browser. The reproducibility of a URL and the controls around cross-origin trust are fundamental building blocks of the web and not wanting to break these patterns lead us (at Connectifi) to the cloud approach.
My thoughts post the meeting are pretty brief:
- the window.fdc3 requirement is the only clearly identified issue with the spec relating to FDC3 in browser
- removing the window.fdc3 as a MUST has no clear downside. In fact, this was just changed in 2.0, so all of the growth and interest we've seen in FDC3 for the past 5 years has happened without this being mandated. If the community prefers the global pattern, they are free to continue to use that pattern, while requiring the global clearly inhibits standard implementation options in browser and any other technology stacks.
- open source code projects can definitely help here, but a mandate for a specific implementation/library as part of the standard would not be consistent with the principles of FDC3.
Looking forward to hearing from the rest of the community on this.
thanks @nkolba - you raise a valid point about the reproducibility of a URL. It's certainly true that if a window with a given url behaved differently depending on where it was opened, this could cause confusion to end users. And I agree that a cloud-based approach certainly has the potential to eliminate that particular (undesirable) difference. Having said that - playing devil's advocate for a moment - one could argue that although ensuring reproducibility of a URL would be a good thing to aim for, it's possible that the cost might be paid in greater friction in non-federated identity scenarios, if a cloud-based approach ended up forcing an (undesirable) additional logon for the agent in the given app. This is something the user wouldn't see when opening the same app in either a desktop container or in a MFE container that used local interop. So it's possible that there could be trade-offs, depending on the specific setup of the institution and the ISVs involved. Of course, every setup is different - which is why I think a good result for the community would be to have a standard which encompassed all the common scenarios, and a range of solutions from agent providers to cater for those different scenarios.
I have to say that - based on my current knowledge of the FDC3 standard at least - I don't really agree with the assertion that removing the window.fdc3 as a MUST has no clear downside. I believe the downsides of removal would be the inability to use window.fdc3 to directly detect the presence of a pre-existing agent (in the case where a container-agnostic app could be run both in desktop containers and browser-based MFE containers) and also the fact that window.fdc3 is currently closely intertwined with the agent bootstrapping process and the standard fdc3Ready() behaviour. For these reasons, it seems to me that any removal would require (a) a new standardized mechanism for desktop containers to provide their FDC3 DAs (I've not yet heard anyone suggest what this could/should be); and (b) a change to the behaviour of fdc3Ready(). Point (b) in particular seems problematic for ISVs because an app that is expected to work across different FDC3 versions (e.g. where it only uses basic FDC3 functionality) could not easily adjust its usage of fdc3Ready() based on the version of the agent or version of FDC3. This is because the app shouldn't even be invoking fdc3.getInfo() to determine the version until after it has awaited fdc3Ready(). But the app also couldn't rely on fdc3Ready() if the behaviour depended on the version of FDC3. This feels like a chicken and egg situation - perhaps there's a way around it that's not clear to me at the time I write this. For reference, I also listed some of these points above (https://github.com/finos/FDC3/issues/896#issuecomment-1411280183)
Now that I think about it, I've yet to actually see a convincing upside for any proposed removal of window.fdc3.
Firstly, I don't particularly buy into the argument that static import declarations are necessarily better in every circumstance just because they are the more modern ES way. To me, a DA feels like a different category of import than something like a UI component (where an import declaration would always definitely be better) in that it's an API that can be injected into the environment in the case of a desktop container. For me, this makes it more analogous to a polyfill for a new browser API which hasn't yet been made available in all browsers. Additionally, it's not clear to me that a static import declaration is a good method for loading an agent in any case (since import declarations can't be used in conditional blocks, this would imply either fixing to a single specific agent at build-time or alternatively including multiple agents in the resulting script bundle even though only one was required at runtime). That's actually what caused me to look at the idea of an installer library in the first place.
Secondly, I think I'd probably need some convincing that there's any significant downside to having the agent installed in a global (instead of inside part of the main app module) from a security perspective. In particular, having the agent hidden in the revealing module pattern or similar doesn't seem to offer any meaningful protection from being tampered with by malicious code. For example, if someone wanted to write malicious code to use as part of a XSS attack to read all inbound and outbound interop messages, it would actually be far easier to directly target the native browser APIs that the FDC3 DA relied upon (postMessage or WebSocket, to attack local or cloud interop approaches respectively) than to target the layer on top i.e. the multiple intent/channel methods of the FDC3 DA itself.
However, I can believe there could be some genuine upsides which I'm not fully aware of - so I'm definitely interested in hearing any other arguments on the matter.
As for the question of open source vs FDC3 standard in terms of the strategy for an installer library or similar, my main concern with an open source approach would be the risk of untested/unmaintained implementations and unnecessary duplication/fragmentation. To this I would also add the possibility of confusion in the case of smaller ISVs where the developer knowledge of FDC3 may not initially extend much further than their boss having mandated some work with a deadline and a simplistic "Get FDC3 done" slogan. More specifically, if you think about the combination of multiple open source agent installer implementations with (over time) different versions of the FDC3 spec and (as the market grows larger) multiple competing desktop containers and web-based agent providers, it could easily lead to smaller ISVs building apps that don't do a good job of installing an FDC3 DA. At best, this might mean the app not working reliably or consistently across different containers. At worst, this might risk an approach containing security flaws that would not be limited to that particular app i.e. which could potentially compromise the interop of the whole ecosystem / MFE container that the app was loaded into (even when all the other apps in the ecosystem had done the right thing). This is why I would argue in favour of having some form of installer library or equivalent mechanism as part of the FDC3 standard itself - where it can be agreed, designed, implemented, tested and maintained in a manner that promotes confidence in FDC3 as an open interop standard and enables growth in FDC3 adoption amongst ISVs and institutions. I appreciate that others might take a different view on this, so I'd also be interested to hear from the rest of the community.
Hi,
- the window.fdc3 requirement is the only clearly identified issue with the spec relating to FDC3 in browser
Like @novavi, I heard no clearly articulated advantage to this proposal, nor much support for it at the meeting. We did however hear from a number of speakers with concerns about such a proposal, particularly with no clearly defined successor to the global. Many of us want to avoid creating a situation where:
- App developers have to target particular vendor implementations or deal with excess complexity when needing to acquire an API handle (making it harder to get started),
- Apps can only interoperate with other applications that included the same library at development time (making the ecosystem factional).
- These challenges impede the uptake & growth of FDC3.
As such, I continue to believe that it is in fact the inclusion and bootstrapping of proprietary libraries, without a standardized pattern or open/cross-vendor library support, that is the greatest issue facing FDC3 on the web. This is particularly the case as it will take away the ability for an app to be (Desktop Agent) vendor agnostic if it wishes to be (highlighted as an important property of FDC3 at the meeting multiple times).
Other interesting points that we heard at the meeting:
- There are multiple approaches to FDC3 on the web, including apps launched (windows opened) within the scope of a Desktop Agent (iframes and windows opened with window.open) and those launched independently have different needs/approaches that might apply.
- These should be carefully considered as the client-side communication that FDC3 generally provides, is harder to implement in the independent launch scenario and there is a fair chance that when (up to) any 3 financial services firms are engaged in communication (e.g 2 app vendors and user) at least one may not be keen on communication passing through the servers of a 4th firm.
- Applications might want to work with different Desktop Agents, but could talk to each other through Desktop Agent Bridging.
- It might make sense to further sub-divide the Standard into:
- API interface and methods of retrieving access to it.
- Desktop Agents and Browser Agents with different requirements (at the least scoping for 'web' may need dividing into Web containers and Web browsers).
Hence, the overly simplistic proposal of dropping the requirement for the fdc3 global is a distraction from the real issues we need to work on. A solution to those may see the global superseded - but its existence does not block the use of FDC3 on the web.
@api-forever
Note that the client-side integration with an IFRAME requires the ability of the application to communicate its content height to the parent window which hosts the IFRAME, so the protocol for this should be added to the FDC3 spec, too.
A good point (as most solutions to that I've seen use postMessage between the parent window and the iframe). However, not every layout will require that (iframes might internally scroll, or you might use full windows via window.open only). Nevertheless, it seems worth considering a solution.
Both patterns must continue to work if there is an injected window.fdc3, therefore a fail-fast algorithm for determining whether to wait for the fdc3Ready event should be added to the FDC3 spec. One possibility is to inject window.fdc3 = null as soon as this becomes possible during page loading and then replace it with the full implementation before firing fdc3Ready, or removing it before firing fdc3Ready or another event if the agent decides not to trust the application web page after additional security checks.
Also a good point. This advice on API Access in the Standard will almost certainly need adjusting to facilitate testing for the (impending) availability of an implementation:
The global window.fdc3 must only be available after the API is ready to use.
https://fdc3.finos.org/docs/api/spec#api-access
FWIW I don't we're that far apart in what we're saying and I think we all agree that producing a common library is the best way forward. Perhaps the best course is to put the larger questions on the standard to the side for now and focus on that.
Thanks Nick. That seems like a reasonable focus for the next meeting's agenda, see you there.
I assume we're talking about a common installer library here? If so, this sounds positive. I think to move forward it would be worth first defining clearly what should be in and out of scope for the initial focus on an installer library. Based on the discussion so far, there are many wider issues raised by the use of FDC3 in a browser-based environment which can probably be kept in mind but largely parked for discussion purposes (this includes the idea of running different agents in different apps, which was floated in the last meeting). So the idea of sub-dividing the standard as @kriswest suggested to allow an initial focus on API interface and methods of retrieving access to it seems sensible to me.
Clearly everyone will have their own views - and I'll be very interested to hear everyone else's - but in the meantime some of the things that spring to mind when I think about a common installer library now include:
- Standardization of agent provision - the may be a common ground where a balance can be struck between allowing a few different approaches (and indeed enabling innovation) by agent vendors, and disallowing too much variation in how an agent can be provided. In particular, whilst it would theoretically be possible to support almost any agent delivery mechanism, I believe it would be better if there could be a degree of standardization around agent provision in the FDC3 spec (e.g. requirement for factory function, etc.) in order to reduce the need to support the relatively large number of approaches I laid out in the
fdc3-installerlibrary I put together previously. - Whether the installer library could/should be part of the existing npm package or a separate (new) package. There are pros and cons to both approaches. If it was part of the existing npm package, ISVs would potentially be including baggage they didn't need if all they required was the type defs (e.g. where they were only targeting a desktop container, and not browsers). The baggage would be mitigated by modern script bundlers, but this could still be suboptimal. Unless of course the future FDC3 standard actually required the use of a (lightweight) installer to obtain an agent in all circumstances (e.g. both for browsers and for desktop containers), in which case the answer here could be different.
- Version handling. Specifically, should a given version of an installer be expected to handle installation of FDC3 DAs supporting different versions of the FDC3 spec (e.g. v1.2, v2.0, etc.) or should an installer be linked to a specific version of the standard? ISVs would benefit from the ability to write apps which run on different versions of an FDC3 DA (where they use API methods that are common across those versions). This would be consistent with how apps have historically been run on different browser versions using common APIs, and using graceful degradation where necessary. Additionally, the existing npm package includes the
compareVersionNumbersandversionIsAtLeastfunctions, which implies the original intention was to allow an app to target more than one FDC3 DA version - allowing the app to make it's own decision on whether the DA provided at runtime is sufficient for the app or not. To achieve this, the installer library would presumably need to be a separate package. window.fdc3installation. I'm very conscious that there are different views on this, but for reasons mentioned previously (not just by me) it's inextricably linking with agent bootstrapping - which itself has to be considered by any installer. Therefore I'm not sure it's realistic to avoid or park this subject. Again, going back to the issues I looked at when I worked on thefdc3-installeridea, I somewhat sidestepped this area at the time. That library'sinstallAgent()method actually returns thefdc3object directly - which theoretically allows the app to use thatfdc3object (if the app wasn't using the wrapper functions from the@finos/fdc3npm package, which ultimately delegates to the globalwindow.fdc3object). The main reason I sidestepped the issue was that I didn't believe an installer library could perform thewindow.fdc3installation itself unless it was dealing with an an explicitly-bootstrapped DA (which goes beyond what the FDC3 spec provides for). Hence, the installer made the assumption that all agents (whether implicitly or explicitly bootstrapped) would be responsible for their ownwindow.fdc3installation, and that the installer library should not get involved. Clearly, if the discussion and design of any future common installer library meant that a different approach to globalwindow.fdc3installation was ultimately decided upon (with the backward compatibility support that any change implies) then whatever this new/different approach was would need to be factored into the design of the installer library (and of course also into thefdc3Readyfunction).- Detection of any existing FDC3 DA. Clearly this is related to the issue of
window.fdc3installation above. Clearly, any change to the requirement forwindow.fdc3installation implies a new/different mechanism would need to be specified to allow an installer to detect any existing DA (and this mechanism would ultimately need to be provided in desktop containers also, as I have alluded to previously). - Passing config to agents. Unless an installer returned an
fdc3object which required an app to manually bootstrap it, then config would need to be provided at the installer level to use at agent construction/bootstrap time. Again with thefdc3-installeridea, I supported the concept of static config which could be defined in the JSON installer config file. This made sense to me at the time, because config options like window/tab preference forfdc3.open()behaviour or WebSockets urls or the like could be defined in a config file - and indeed would be better defined centrally at container-level config (where a container exists) for consistency and to reduce duplication across individual apps. However, I can now see that only having support for passing static values could be a severe limitation. In particular, if an agent allowed apps to pass callback functions to customise the behaviour e.g. for logging, Resolver UI, or anything else then limiting config to static values only would be unacceptable. To solve this, any method provided by an installer might need to also support the ability to accept a JS config object argument which would be passed through to the agent at construction/bootstrap time (e.g. passed straight through as a factory function argument or similar). There might even be a case for supporting both static installer-config-file-defined values and non-static JS objects that can be passed through - so perhaps this should be on the table for discussion? - Agent discovery. This relates to the so-called discovery strategies I defined in the
fdc3-installerlibrary. Some of the ones I laid out are problematic and potentially brittle (i.e. couldn't be used across all agents) and therefore could probably be ruled out after any serious discussion. Conversely, there could well be some better ideas for how an app can discover an agent at runtime. In any case, ISVs would benefit from having several different options available to them in order to support different MFE container scenarios - but by the same token, supporting too many different strategies could risk confusing ISVs and making an installer library harder to test and maintain. - CSP for DA module import. This should be designed-in. The safest, most restrictive option would presumably be to require apps to host agent implementations alongside the app's own script bundles (though this would place a burden on the deployment process for individual apps). This type of approach ought to mean that - from a security perspective - dynamic loading of a DA was not all that much different from lazy loading an app script bundle at runtime in a module federation scenario. But there any many different implementation options in this area, and therefore there is plenty to discuss and POC. Clearly for any common installer library to be used in a production environment, it would need to either only support the most secure method for obtaining a DA, or at the very least it would need to default to that option (and provide very clear console warnings if an app strayed from that recommended path).
I could go on further, but will just put the above thoughts forward for now. Look forward to discussing more in the next meeting.
For the record, I should correct something that I mentioned in one of my recent posts about browser-based local interop above (https://github.com/finos/FDC3/issues/896#issuecomment-1433771266) where I stated that postMessage API requires a target window reference - and that this always imposes limitations around app launching and requires a common 'hub' or 'router' window for messaging.
I had originally ruled out Broadcast Channel API completely on the basis of the same-origin policy restriction it imposes. And since postMessage API is (as far as I am aware) the only native browser local messaging API that works for the cross-origin scenario (which is necessary in most real-world situations) I had thought that one would just have to live with the requirement for window references. In practice, that would mean apps delegating interop and window opening functionality to a 'hub' or 'router' running at the micro-frontend container level. Moreover, it would mean that if a user launched an app independently (i.e. in manually opening a separate window or tab, and navigating to the app's url) then that app could not participate in local interop.
However, with a bit of lateral thinking, I can now see that there is a fairly simple mechanism to overcome the above problem. This mechanism effectively provides for cross-origin interop between isolated independently-launched windows. The solution I came up with uses postMessage API in conjunction with Broadcast Channel API, and it works along the following lines:
- app1 and app2 are both launched independently from each other in a containerless manner (i.e. neither of them spawn each other, and neither of them are spawned from a common container or launcher window).
- app1's DA (let's say this is on port 3100) dynamically creates a hidden iframe pointing to a page containing some simple 'ancestor bridge' logic (let's say this iframe is on port 4000).
- app2's DA (let's say this is on port 3200) also dynamically creates a hidden iframe pointing to another 'ancestor bridge' instance.
- app1 (port 3100) can publish an interop message to app2 (port 3200) as follows - app1's DA uses postMessage API to publish the message to it's (child) ancestor bridge (port 4000) using the easily-obtained window reference to the hidden iframe, then app1's DA's ancestor bridge republishes the message to app2's DA's ancestor bridge using Broadcast Channel API (note that the two ancestor bridge instances are both running on port 4000, so the same-origin policy restriction imposed by Broadcast Channel API is satisfied).
- app2's DA's ancestor bridge receives the message and uses postMessage API to republish the message to its (parent) app window (port 3200) using the easily-obtained window reference to provide the interop message to app2.
This goes further than I previously thought was possible with browser-based local interop. To be clear, based on a spike I just created, the above solution appears to work - but I have to confess I haven't (yet) tried it in anything beyond that limited spike.
Of course it's worth noting that for a local browser-based app to interop with a local desktop container or a remote (e.g. Citrix-based) container, then cloud-based interop is still absolutely necessary.
Of course it's worth noting that for a local browser-based app to interop with a local desktop container or a remote (e.g. Citrix-based) container, then cloud-based interop is still absolutely necessary.
@novavi This is a case a Desktop Agent Bridge could/would solve for (as a browser page could connect to local websocket).
Clearly everyone will have their own views - and I'll be very interested to hear everyone else's - but in the meantime some of the things that spring to mind when I think about a common installer library now include:
Standardization of agent provision - the may be a common ground where a balance can be struck between allowing
A couple of other things came into my mind since I posted that comment (https://github.com/finos/FDC3/issues/896#issuecomment-1439144348) above. This is because those thoughts were largely based on the experience of the fdc3-installer library I put together previously - which at the time I had only ever tested on a dummy DA implementation with a single getInfo() method. However, thinking a bit further about the requirements for an installer library in the context of a real DA implementation raises a few more considerations:
- App-specific DA arguments. One limitation of
fdc3-installeris that DA construction arguments are provided increationStrategyorbootstrapStrategyconfig objects which exist under theproviderImplementationentry in theproviderDirectoryarray of the installer config. Whilst this allows for app-specific DA arguments to be passed when the installer config is at the app-level, it could present a problem if the installer config was at the container-level (or in all cases if an external provider directory was used). In practice, although some of the DA constructor arguments might well be best provided at container level (e.g. settings governing the DA's behaviour, or a WebSockets service url to use for all the apps), it is possible that other arguments could be app-specific (passing an appId would be the most obvious example). This issue could possibly be mitigated if a DA used some sort of app-specific DA manifest file to obtain app-specific values such as appId, etc. - but unless all DAs followed this pattern (unlikely unless it was mandated in the FDC3 standard) then there would still be a need to provide app-specific arguments even when it was desirable to use a container-level installer config. - Fallback. It might be worth considering whether any support for fallback would be desirable. The question really concerns how rigid an installer library should be e.g. whether a given app has to use something along the lines of either container-level or app-level config / discovery strategy... or whether it makes any sense to allow an app to use container-level if available, but fallback to some sort of app-level default if running in a so-called containerless scenario. It may be that this behaviour muddies the waters too much and isn't worth implementing - but it should probably at least be put on the table initially for discussion.
I'm a bit confused about how @novavi's Desktop Agents would know about each other in the scenario above.
But I think there is probably some value in establishing a common wire format for FDC3 messages to suit both postMessage and Sockets.
I think @kriswest said in the meeting that his team were working on a JSON Schema for this. I would imaging that it could be reused by our postMessage-transport from DA to app and back as well as the DA-to-bridge WebSocket-transport.
Thanks @robmoffat.
I should have been clearer in the point I was trying to make about interop between isolated independently-launched browser windows. The Desktop Agents would know about each other because in my example they were from the same vendor, and would connect on a peer-to-peer basis (publishing intent and channel messages, along with details of currently-running apps, etc. to each other as and when each app's DA instance bootstrapped). So this was all specifically about the example of a single DA provider. In terms of bridging though, I do agree that there is probably value in establishing a common wire format for FDC3 messages. That would certainly open up opportunities for communication between different desktop agent providers (which goes beyond what I was talking about).
What I was trying to get across was that there is another pattern for comms that could potentially be used by a browser-based DA. This is irrespective of any future common wire format because - until you introduce bridging across different DA vendors into the equation - a given DA only needs to concern itself with its own comms pattern. On this basis, there are potentially three different approaches for implementing a DA in a browser-based environment (I mean a vanilla browser, not leveraging any browser extension) to route FDC3 interop messages between different windows:
Pattern 1 - via the cloud, utilising a WebSockets connection. This is the approach Connectifi takes. Crucially, this pattern works for isolated independently-launched browser windows.
Pattern 2 - via a main window. I used this pattern previously in a fairly-extensive-but-incomplete DA implementation to support intent and channel FDC3 interop. I suspect this is also broadly the approach taken by the browser-based Glue42 Core solution - but someone from Glue42 would need to confirm or refute that. This patern does not work for isolated independently-launched browser windows - it only works if all the app windows are spawned from the main window (either directly, or by the app's DA delegating window opening to the main window in order to allow tracking of window references for subsequent use in message routing).
Pattern 3 - via a local browser messaging cross-window cross-origin bridge (not using WebSockets, and not relying on a main window). In the example below, App 1 runs on port 3100 and App 2 runs on port 3200. Most importantly, the Isolated Window Bridge hidden iframe within both app windows runs on port 4000 (to satisfy the same-origin policy restriction imposed by Broadcast Channel API). My test used ports on localhost, but in a real-world scenario clearly the windows would use different domains / subdomains. The approach works for isolated independently-launched browser windows on a cross-origin basis (despite the fact that it relies purely on local browser messaging).
The main point is that it's technically possible to bridge between two isolated independently-launched browser windows using local browser messaging only. I was actually kind of amazed to find that a third pattern was technically possible - I only thought about it and created a successful spike on it a few days ago. Prior to last week, I was labouring under the illusion that cross-origin interop in a browser environment was only possible using Pattern 1 or Pattern 2. Hence in the interest of the overall discussion on FDC3 For Web browsers, I thought it was at least worth calling this out for the benefit of anyone else who also hadn't realised this was possible.
I was always very conscious that:
- Broadcast Channel API works across isolated independently-launched windows, but does not support cross-origin messaging
- postMessage API supports cross-origin messaging, but does not work across isolated independently-launched windows
But what I hadn't tried until last week was using postMessage API in conjunction with Broadcast Channel API - together with judicious use of iframes on a common 'bridge' origin.
Note that in many (most?) circumstances there is still good reason to have some sort of main window or launcher window in any browser-based micro-frontend ecosystem for the purposes of discovering and launching apps and workspaces/layouts. The point is that for cross-window interop in a pure browser scenario, a single DA implementation used within individual app windows does not necessarily need to use a main window for interop message routing (this has the consequence that the main window could be closable by the user without breaking interop between the remaining app windows) and does not necessarily need to use WebSockets.
To be completely clear, none of this has any direct bearing on a common wire format or on the use of WebSockets. The common wire format idea makes sense to me. And there will always be a need for WebSockets for cloud-based DA vendor solutions and also for bridging across different DA tech stacks (e.g. into desktop containers and legacy native apps) and across different environments (e.g. Citrix or mobile devices). The above Pattern 3 DA does not preclude the use of a cloud-based bridge between a Pattern 3 DA and any other flavour of DA (all it does is provide the internal comms for itself).
One further thought.
Interestingly, the use of a hidden iframe might also have other potential usages in DAs - beyond the postMessage API <-> Broadcast Channel API <-> postMessage API pattern I floated above for a local-browser-messaging DA.
For example, it might be possible to use a postMessage API <-> WebSocket API <-> postMessage API pattern in a cloud-bassed messaging DA. One potential challenge for cloud-based DAs concerns AuthN/AuthZ across multiple apps from different ISVs in non-federated customer scenarios. In those scenarios there could be some friction involved in getting individual apps onto a service bus (this is on top of the existing requirement to get the user logged into each individual app). However, if a cloud-based DA library proxied each app window to a 'Service Client' hidden iframe for WebSockets interaction with its cloud-based service bus, this would have the potential to reduce that friction. In particular, the scenario would no longer require getting each individual app onto the service bus. Instead, it would require auth for the service bus on the basis of the user session instead of on a per-app basis (with the user <-> app auth continuing to happen as normal). Friction could potentially be reduced even further if the 'Service Client' hidden iframe could be configured to run on the same iframe as the ecosystem's container / launcher / entry point (meaning the auth for the service bus could happen at initial launch of the first component in the ecosystem, rather than on each subsequent app opening). This is all if the DA actually supported such a security model.
Overall this type of approach could make a cloud-based FDC3 DA browser app ecosystem operate more along the lines of the experience a user enjoys in a traditional desktop container (where each app does not have to separately auth onto the container's DA - and where trust is established firstly for user <-> desktop container DA, and secondly for user <-> app(s)).
Clearly there are many trade-offs in this area, so there's possibly a case for both patterns (i.e. direct WebSockets, and also 'Service Client' hidden iframe WebSockets). It's also the case that although this is something that could (optionally) be supported directly by a cloud-based DA if it was considered useful / appropriate, it would be a bad idea for an app to randomly attempt to use a cloud-based DA in a manner like this that was not intended / expected / supported by the DA and its associated service bus. Ultimately, a cloud-based DA might have a single security model which always required each each app to auth separately onto its service bus (i.e. requiring trust in the app at runtime, rather than just trust in the app within the appD and trust in the user).
I should also say that whilst the above patterns might not directly effect the use of all installer library proposals, it's probably worth at least keeping some of these possible DA implementation patterns in the back of one's mind when thinking about what things a standardized installer library might end up having to contend with (e.g. a DA that already used iframe proxying even before any potential additional proxying caused by some dynamic installer library solutions which themselves required an iframe to run the DA inside).
Additionally, it is also worth noting that the proposed common wire format could well be the most important part of an eventual DA bridging specification. This is because although many DA bridging scenarios will involve two different tech stacks or environments (which therefore require a cloud-based WebSockets solution), it looks like it's possible that a simple DA bridging scenario involving only browser windows with different DAs might be solvable with an implementation that relied on a postMessage API <-> Broadcast Channel API <-> postMessage API pattern (instead of requiring a full cloud-based WebSockets solution).
@novavi just one item to pick up here:
This is because although many DA bridging scenarios will involve two different tech stacks or environments (which therefore require a cloud-based WebSockets solution)
Bridging as currently proposed uses websockets, but provided by a locally running executable (the bridge), with bridges themselves being able to cluster for multiple devices. It is therefore not exactly 'cloud-based' - some of those involved initially were keen to ensure that comms stayed on device or at least on the local network. I suspect that may be an important distinction for some InfoSec teams.
I'm really looking forward to tomorrow's discussion. A lot of technology has been uncovered.
From my perspective, I think we should aim for a bootstrapper that is as small and simple as possible, with the prime objective of (1) identifying the desktop agent and (2) loading the desktop agent's proprietary JavaScript (in order to instantiate the fdc3 object).
To that end, I would like to suggest utilizing web manifests. A dedicated fdc3 section can contain instructions for the bootstrapper (this is similar to @novavi 's suggestion of using a file in the root but leverages an existing standard).
Instructions might then be one or more of the following (perhaps specifying precedence):
a) use global fdc3 object (preload style)
b) given <queryString value> load
P.S. @novavi, for the hidden iframe trick, a sharedWorker is another possibility, with the advantage that it is a singleton by design. A second possibility is simply to use localStorage. A running desktop agent could simply drop its url into a well-known slot in local storage where it can be picked up by any window wishing to connect. This last one has the advantage that the desktop agent need not even be running.
Ah, many thanks for clarifying @kriswest, that's an important distinction.
This makes sense - keeping the comms on the local environment (i.e. the same model that desktop containers follow) could be important for some institutions. The use of local comms could also reduce potential friction around auth, and perhaps also questions over which ISV / ecosystem / institution owned/operated the bridge service bus.
From an ISV's operational perspective, I imagine the trade-offs with using a local executable include potential challenges around reliability (e.g. handling bridge installation / runtime / shutdowns / restarts / updates and any associated corner cases across range of different end-user environments) and difficulty for operations / support teams in easily inspecting log files if a problem requires diagnosis. Those are issues that ISVs / institutions likely wouldn't face if using a cloud-based solution (whether for bridging purposes, or using a cloud-based DA vendor). I'll be very interested to see how this area develops (the operational aspect as much as the technical specification and solution really). And I wonder whether for some customers, the option of running a self-hosted bridge (e.g. on their own cloud infra) as an alternative to installing a local executable on end-user machines might be attractive. I mean in the same way that for a cloud-based DA vendor, providing customers with different options (in that market, SaaS and self-hosted infra models) is likely to be important to satisfy diverse technical, operational and legal requirements.