Support propagation of originating application identity

[bingenito]

Enhancement Request

Extend the FDC3 API to provide support for propagation of originating application identity on context/intent handlers.

Use Case

Use of container message brokers are currently restricted at many financials to require verifying identity of sender when receiving messages. The FDC3 API sits on top and prevents an agnostic approach to enforce this security requirement resulting in a showstopper to using FDC3 in production for some. Analogous of this for w3c would be checking origin and source on addEventListener of postMessage.

While the establishment of common schema and the spirit of interoperability seems to be opposed to this request at first glance, it should be up to the receiver to decide and verify sender. They might want to work closer with the other parties for certification before adding the application to an allow list of senders.

Additional Information

Identity propagation would also need to be a consideration as part of #544.

[lspiro-Tick42]

I strongly support this proposal. I view it as saying that there are some applications, that may need to know who the calling application is, and that we should extend the FDC3 specification so that an Intent request can optionally include an identity of the caller.

Further I would propose that we have a readable/loggable name that might contain some mix of the following identifiers; Platform Type, Platform Instance, App Name, App Instance and that this id could also include (as a set of optional fields) a user identification which includes user name and / or then also allow an authentication cookie to be provided.

There is no agreement that these two fields (app and logged on user) will work or are required, but it would allow the kind of use case that Brian is describing to be supported within standard FDC3 fields, and in a way that can work independently of the container an app may be running or the authentication mechanism being used.

It may be that we assume these fields are auto-inserted by the FDC3 Implementation (aka the Container) and so are only visible in the Intent request, which reduces the scope for spoofing.

[bingenito]

Agreed on the specification detailing it being inserted as opposed to not allowing it to be spoofed by having it as a parameter from sender. For broader use I would expect it be available on ContextHandler which covers context listeners and intent listeners.

[bingenito]

Another common use case would be adding FDC3 support for interop of our own web properties. When used internally within our vetted scenarios and container(s) of choice we verify and allow use of our own applications as senders. When an external user attempts to create a manifest using their own container to host our web property our handlers would not accept those messages and mitigate risk of scenarios that can cause issues.

[kriswest]

FDC3 has addressed this question in the past (when I raised it maybe a year and a half to two years ago), opting not to expose information about the sending application, citing the spirit of interoperability and the fact that individual Desktop Agent implementations can provide their own mechanisms for achieving this filtering (both allowing them to differentiate themselves and keeping control of who can talk to whom in the hands of the desktop owner). Further, an application can of course already use user-agent information and [`fdc3.getInfo()`](https://fdc3.finos.org/docs/api/ref/DesktopAgent#getinfo) to determine what container it is running in and whether it wishes to behave differently. It just can't validate the sender of messages from other applications. I offer no particular opinion on this topic, but expect views to be divided particularly as apps deciding for themselves who they will and won't respond to may add some significant complexity to the ecosystem of FDC3-enabled apps. Were the working group to change its position on this topic, the obvious way to handle this through the API this would be to add an `AppMetadata` parameter to `ContextHandler` and the proposed `IntentHandler` (#495): ```typescript type ContextHandler = (context: Context, originator: AppMetadata) => void; type IntentHandler = (context: Context, originator: AppMetadata) => Promise<Context> | void; ``` `AppMetadata` already carries the details of the application, can be populated by the Desktop Agent, is proposed to carry details of app instances (#509) and early discussions in desktop agent bridging would also see it carrying details of the originating platform/instance.

Identity propagation would also need to be a consideration as part of #544.

#544 (Desktop Agent bridging) could handle identity propagation differently, in that it relates to Desktop Agents exchanging messages through a different interface to the one used by applications. Hence, if it is decided NOT to expose this information to applications, we can still expose the information to Desktop Agents (which may be necessary to allow the implementation of security/authorization restrictions: one of the requirements under discussion).

[bingenito]

in the hands of the desktop owner

an application can of course already use user-agent information and fdc3.getInfo() to determine what container it is running in and whether it wishes to behave differently.

We have a public property in which we could have FDC3 usage. Internally within our own hosting of that web application within container A, we can use the container's proprietary methods of restricting or make use of getInfo in the app. The problem is a public web application can be loaded into a container externally. They then can join any channel and listen to any message or send any message. There can't be an assumption that the desktop owner is a party that is in a position to make these decisions on your behalf as an application provider. This is just the surface level. Things can quickly become more difficult if we look to address someone writing their own DesktopAgent and maliciously spoofing sender details (if implemented) or ignoring targeted intents and context messages.

[kriswest]

This issue was also raised recently as #520

[bingenito]

Do you want me to close this one as duplicate of the pre-existing?

[kriswest]

This one is a discussion currently, after we've addressed it in a meeting we can either convert it back to an issue and close the other or just pick up on the other issue and close this, makes no difference to me ;-)

[kriswest]

This topic (issue #520) was discussed at the last SWG meeting (#597). Here is a quick summary of what was discussed:

• Participating in context sharing and intent workflows is only possible for some apps if they know where messages were sent from (see comments from @bingenito)

  • Workflows can also be streamlined in some situations if the app raising the intent is known, e.g. starting a chat or sending a chat message would require a confirmation pop-up, however, if the sending app is know config in the chat app could allow it to be sent without confirmation

• Putting details of the sending app inside a context and relying on apps to self report their identity correctly is unreliable/can be spoofed

  • Hence, it should be the DesktopAgent implementation that should be responsible for doing so.
  • This is most cleanly done buy extending the ContextHandler and IntentHandler signatures to include AppMetadata, which would be added by the desktop agent (preventing spoofing by an app implementation):

  type ContextHandler = (context: Context, originator?: AppMetadata) => void;
  type IntentHandler = (context: Context, originator?: AppMetadata) => Promise<IntentResult> | void;

• In the past, FDC3 has shied away from providing this information as some feel it is antithetical to open interop as it allows apps, rather than desktop owners, to decide which apps will interoperate with which other apps.

  • However, if apps cannot participate in interop without knowing where messages came from for governance/audit logging reasons, or their workflows become less elegant (e.g. requiring confirmation dialogs) that also hurts the app interop ecosystem.

• It was suggested that this feature should be considered optional for compliance (e.g. tagged with the SHOULD or MAY keyword, rather than MUST).

  • If the originator argument is optional, app implementations can handle it if present and ignore or refuse to participate in interop if not present
  • Additional arguments at the end of a function signature are non-breaking for typescript, but are breaking for other languages (e.g. .Net/Java) - hence this change needs to be handled in a major revision of the standard (i.e. FDC3 2.0).
  • Configuration could be used to enable/disable sharing of originating metadata by the desktop agent

  There are 3 paths ahead on this issue:

  1. Add it to the standard as required for compliance (MUST)
  2. Add it to the standard as an optional feature (SHOULD or MAY)
  3. Reject it

The issue will be added to the next SWG meeting agenda for further discussion