Upgrade exposure of originating app identity to a requirement (MUST) from recommended (SHOULD)

[kriswest]

Enhancement Request

The below issue, disucssion and PR added the optional ability for the desktop agent to expose the identity of the application that originated each context or intent message sent via FDC3 APIs.

• Require propagation of originating application identity on context/intent handlers #520
  • Support propagation of originating application identity #569
  • 520 expose originating app identity #725

This issue seeks to upgrade this from an optional, recommended feature (SHOULD) to a required feature (MUST).

Use Case:

See the original issue and discussion linked above.
Created in response to two of the PR reviews (1, 2)

[openfin-johans]

I would argue it's too early to make this a MUST. To make sure FDC3 is easy to use and thus gain adoption - it must be possible to implement basic functionality like broadcasting context without having to consider these more long term, eco system like ideas. Sure, you can just add some random value for your app but that's just add complexity for no real value.

A lot of functionality around App Directory has been added in 2.0 - let's now use the community and verify uptake of this and whether it provides the functionality requested (trust the incoming context) and if the bi-lateral discussions regarding app identity happens.

[novavi]

@kriswest In the simplest case, when an app listens for intents or contexts it can treat the data within them at face value - on the basis that although the app doesn't know where the the intent / context originated from, it must have been raised / broadcast from some app within the user's desktop container (with that app ensuring AuthN/AuthZ for the user as it sees fit).

By contrast, when the originating app identity is propagated then the target app will be capable of using the originating app identity in its intent or context listeners in order to determine the legitimacy of the data and help make decisions about participation in user workflows.

I guess this must have been touched on elsewhere previously, but with the upgrade of this ability to a requirement (MUST) from recommended (SHOULD), where do we stand on the issue of intent and context spoofing at the moment? I mean because if an FDC3 desktop agent cannot provide an app with full confidence that the originating app identity is genuine, then it would be difficult for the app to rely on this information.

I can see there was some discussion in #569 about reducing the scope for spoofing by having the DesktopAgent add the app identity rather than relying on apps to self report their identity correctly, and also the potential problem of someone writing their own DesktopAgent to maliciously spoof sender details.

However, as per this discussion I started recently in FDC3 API window.fdc3 installation and overwriting #881 where I showed an example in a current desktop container of a method on window.fdc3 being replaced at runtime by code at the application level, it seems like there are things to be concerned about in this area even with existing desktop containers.

I'm not sure how the FDC3 spec should address originating app identity when there are outstanding questions about spoofing. This is even before one considers the issue raised in #569 about people writing their own DesktopAgent for spoofing purposes, or the wider issue of potential browser-based implementations where preventing spoofing would seem to be quite difficult.

I note that the FDC3 Conformance Framework aims to provide compliance badges for certified desktop agents. I gather the main driver was in order to confirm adherence with the FDC3 spec in terms of the behaviours of FDC3 API methods. But to what extent should a big focus on security / spoofing become part of this?

On a related note, if an app vendor was concerned about intent / context spoofing in an old version of a desktop agent, then theoretically that app could be coded to restrict some or all of the functionality of the app. This would be analogous to a web site or web app having an open-to-all philosophy but still being within its rights to prevent its usage on an older, unsupported web browser (whether for security reasons, unsupported APIs or UX, or otherwise). However, if intents / contexts can be spoofed, then as per my example in FDC3 API window.fdc3 installation and overwriting #881 getInfo can also be spoofed. This would leave an application unable to verify the authenticity of not just intent / context data and originating app identity, but also about the desktop agent provider itself.

I'm not sure what else has been discussed on this area in the past, but would be very interested to know.

[kriswest]

@novavi The issue of someone writing their own Desktop Agent is likely to be very hard for us to solve, the same would apply to a custom web-browser (I imagine) and, say, the enforcement of a Content-Security-Policy.

At some point I suspect we have to assume that the end-user trusts their Desktop Agent / Browser as a custom implementation could effectively circumvent almost any mechanism we put in place (including overriding Object.freeze(), spoofing user agent strings, hacking checksum calculations etc., etc.). Hence, when this issue was originally discussed we opted to move forward with the change, with the Destop Agent providing the details to avoid trivial spoofing, despite the fact that you could write your own Desktop Agent to so so. There was just no good way to prevent that with a custom implementation. Hence, we are currently relying on the user's/licensors trust in the FDC3 Desktop Agent implementation - as web applications do with web browser implementations when they use mechanisms such as CSPs and Content-Type headers to prevent XSS attacks.

The FDC3 conformance framework/testing program, intended to promote that trust in the Standard and compliant implementations, could go as far as confirming that originating app details are reported and reported faithfully if the above change was made. The existence of the program and its T&Cs including mandatory re-testing (to retain your compliance badge), on reports of non-compliance with the FDC3 Standard, maybe the best we can reasonably do.

We could/should certainly strengthen the language in the Standard around accurate reporting if we were to make the proposed change (actually that's worth doing whether or not we make this mandatory).

Finally, see #881 (comment) for thoughts on runtime replacement/hacking of window.fdc3 (odd thing for an app to do to itself - but also a strong reason why vendor libs providing an FDC3 implementation, particularly for use in a browser, are not FDC3 compliant or something that should be used/promoted at the current time).

However, if intents / contexts can be spoofed, then as per my example in #881 getInfo can also be spoofed. This would leave an application unable to verify the authenticity of not just intent / context data and originating app identity, but also about the desktop agent provider itself.

My contention is that, without certain assumptions/trust in the (Desktop Agent/Browser) implementation, this is the case for most if not all security mechanisms we might put in place. Hence, this issue is about whether we require Desktop Agents to provide this information for compliance with the Standard - rather than whether the Desktop Agent implementation itself can be trusted.

[novavi]

Hi @kriswest

Yes, you make a good point about this issue being whether we require DAs to provide this info rather than whether the DA can be trusted.

Glad to hear you support the idea of strengthening the language in the FDC3 spec around accurate reporting of originating app identity in any case.

I also note your point about FDC3 implementations in the browser being non-compliant at present, unless or until current known issues around security and installation (and arguably the network effect problem too, notwithstanding the DA bridge proposal) can be solved - if that is even possible.

Assuming that an end-user trusts their DA seems sensible on the face of it, but it still feels to me that the value in propagating originating app identity is massively reduced for apps that really care about this, when we know how relatively easy it is to spoof.

In the old world of browser-based solutions, an app could attempt to limit its usage in older unsupported, untrusted browsers. And an app could attempt to prevent itself from being used as a component in a larger app (in browser terms, embedding) by means of response headers like content-security-policy (frame-ancestors) and x-frame-options. Of course, your point about a custom web browser bypassing CSP stands.

In the world of desktop containers and FDC3, we're essentially saying that FDC3-enabled apps are unable to restrict their usage to known, verified, safe, compliance-badged FDC3 DAs. On this basis, when the language is strengthened in the FDC3 spec around accurate reporting of originating app identity, I would suggest that it is made very clear that the target app really needs to trust its DA if it is relying on originating app identity as part of its security policy.

[robmoffat]

Hi @bingenito - do you think you could comment on this? I believe you have some strong opinions you've expressed before. We're hoping this might make it into FDC3 2.1

cheers!

[bingenito]

I'm fine with either way. If it remains SHOULD and I required it on the handler I would simply ignore if undefined | null.