Proposal For Identity Discussion Group / Work Stream

[robmoffat]

NB: I am keeping the below for posterity, since the commenters below have responded to it. However, this is more clearly laid out in this comment here

Use Case:

FDC3 needs a way for apps to send the details of the user between them. If an intent gets raised from one app to another, the apps should be aware of the user that raised the intent.

For example:

• When a user asks to start a chat, the identity of the user initiating the chat should match the user logged into the chat platform. (this also applies to sending emails)
• When a user asks to begin a trading process, the trading application needs to know that the user that is going to make the trade (or make sure that it is the same logged in user)
• Many operations will need to be audited. it's important that the audit log is aware of who the user is
• We don't want users to have to authenticate with multiple different mechanisms
• When a new application is started by the FDC3 container/agent, the app should be given the details of the user who is using it. (In a corporate environment, this can be solved with SSO... maybe that forms part of the solution)
• Desktop Agents: where multiple agents are running on the same desktop, there will need to be some coordination of identity between them

Workflow Description

• Probably, raising intents will need to be augmented to store some kind of user token? I have literally no idea of how best to implement this yet

Workflow Examples

I think we can work on workflow examples as part of the Discussion Group.

Additional Information

• Symphony have shown an interest in running this piece of work, but as yet no-one has stepped forward

[kriswest]

I think the use case for this issue needs work. As at present FDC3 assumes the same user is in each app, which is a foundational assumption for us: FDC3 is about a user being able to make their apps work together. We have yet to hear of anyone actually complaining that they need their chat app to know that they are the same person operating the OMS on the same computer (first example).

Nearly every use case example below it is about a single app needing to know the user's identity, which doesn't actually come under our (current) charter:

The mission of the Financial Desktop Connectivity and Collaboration Consortium (FDC3) is to develop specific protocols and taxonomies to advance the ability of desktop applications in financial workflows to interoperate in a plug-and-play fashion, without prior bi-lateral agreements.

(multiple applications connected together in a workflow)

That's my feedback as an FDC3 maintainer. As an engineer working for a container vendor, this is absolutely something we're interested in talking about as SSO is a common challenge when integrating multiple applications into a desktop platform. However, it is a challenge that's also directly addressed by a number of other standards (e.g. OAuth).

However, I suspect (and have heard faint rumblings) that the true use case for this issue is validating identity in cross-user and cross-firm workflows, where applications are deployed by one firm for use by another, and enabling simpler sign-up/entitlements/permissioning. In that situation there may by a role for FDC3 (perhaps a remote user identity will be received into the desktop by an app and shared out to other apps as part of a workflow), however the FDC3 context use case still seems secondary to the primary identity validation use case (although you might need to revalidate an identity after receiving it from another app).

Hence, to move the discussion of this issue forward I would like to see more detail on the problems that need to be solved (use cases) and some thinking on why the FDC3 standard is the a suitable place to handle them.

@robmoffat @jgavronsky @dimiter-georgiev @bertrand-s @mistryvinay

[lspiro-Tick42]

I see this issue more in terms of authenticated user id's.
Kris as you say, from a desktop agent point of view, there is a single windows login (ignoring Citrix servers) and so at that level there is a single user id across all applications.
But almost all desktop applications, log into back end services with a user id, which is usually not the logged in window user.
Rob's description of this issue, expresses the need to share id's across an Intent, and I think this is an important use case, when the relevant id is the id the user logged into the app with, accepting that this is often different to the desktop login.
In my head this is also related to having the ability to provide a shared authentication mechanism across applications running on a desktop.
So in summary I think there are important issues to discuss identity and authentication.

[kriswest]

But almost all desktop applications, log into back end services with a user id, which is usually not the logged in window user.

True - but they are on a single desktop, within the context of a single desktop agent. They may/will have different user accounts in different apps, but they remain a single person operating the UIs on a single desktop at present. FDC3 does not currently handle cross-user/cross-firm workflows (as they pass out of the domain of desktop agent through an application whose domain it becomes).

In my head this is also related to having the ability to provide a shared authentication mechanism across applications running on a desktop.

There are existing solutions and standards for such problems and it is unlikely that something we provide in FDC3 will replace OAuth or SAML as part of an organisation's infrastructure - nor is it likely that every organisation and vendor will use the same auth mechanisms making it hard for us to define a standard mechanism for passing an identity that can be validated on each end. Without being able to validate an identity there seems little point in being able to pass it (an illusion of auth being worse than no auth).

FDC3 is currently a client-side integration API. Adding some form of auth support to it would necessitate plumbing into back-end identity providers to (at least) validate identities. That plumbing will require the selection of an auth solution or solutions, which will be limiting.

There may be a whole separate conversation to have about validating the identity of an application - but that's a different use case (which I think easier to support in FDC3).

[robmoffat]

Following our meeting on 2022-06-17, I've extracted the following use-cases for further discussion:

Use Cases

1. Buy Side Identity / Sell Side Using App

• A sell-side Order Management System is being used by a buy-side trader.
• They connect to the sell-side app.
• The trader will then have to authenticate as themselves with the sell-side app.
• The sell-side app will therefore have to manage the identity of all of the users.
• If we are using OAuth, then there may need to be extra steps to complete the handshake within the client

2. Pushing Axes

• An axe is pushed to a client (say, via Symphony)
• The client wants to see the price of the axe.
• Can we take them to a protected, read-only screen with the price on the pricing platform?
• To show them a price and "tiptoe" them into the single-dealer platform.
• NB, further authorisation / verification steps may be needed before a trade can be booked (e.g. 2FA). i.e "Further Onward Authorisation"

3. Matt's Mother

• You can't just show prices to anyone - you need to verify who you're showing them to. i.e. Matt's mother shouldn't just be able to come and see prices on anything.
• However, we want as little friction as possible for the right users to see prices.
• So, you don't want to have to burden the user with logins unnecessarily.

4. On-boarding

• We need to make it simple to onboard users into FDC3 Apps.
• It's no good having to have a different onboarding process for every single app, this would really increase the friction of getting started.
• Therefore, if we can provide a simple story around onboarding a new user across the board, this would be nice.

5. Off-boarding (Identity vs. Authorisation)

• Similarly, sometimes users will get off boarded from a system. Although their identity might still be correct within the FDC3 ecosystem, it might be that their permissions have been restricted / revoked.
• Again, it would be necessary to make sure we can get an up-to-date view on this before a trade is made (say).

6. OAuth Hell

• If the user has n different apps that require login, are they going to have to go through the OAuth process n times?
• Are there any ways to speed up this exchange?
• Is the user going to end up with a different identity on each app?
• Would there be a way to "reconcile" identity between apps? i.e. avoid the issue where "Rob Moffat" on App A is not he same as "Robert Moffat" on app B.

7. App Identity

• We might need apps to be able to call other apps
• In this case, we would need some way for apps to say who they are, and for this to be validated.

Other Notes / Points

1. The existing assumption in FDC3 is that login is handled by the OS - maybe using SSO (as done in Finsemble). SSO is great if you are logging in
2. App Identities - already some work around this in FDC3 to have a Public/Private key pair for the apps. Nb. Symphony also handles this in a different way with a "circle of trust" and passing tokens between app front-ends and back-ends.
3. Symphony talked about:
   • Self-Sovereign Identity: the user holds proof of their identity, and this doesn't need to be vouched by a 3rd party.
   • Federated Identity: based on top of OAuth, where they are federating identity from other sources, e.g. clients of symphony.
4. Those present discussed that Identity could be supplied to applications via the existing FDC3 context / intent mechanism.
5. Use of Tokens: sometimes, a token might grant you a permission to do something (i.e. the token says who is logged in, and that they can retrieve a price, say). Other times, a token might just assert an identity (e.g. the token identifies the sender of a messsge). Clearly, you shouldn't be able to take the 2nd token and use it for the 1st case.
6. Security is hard. We should not be trying to roll-our-own. We should be using standard off-the-shelf security functionality in ways that are common.

[nkolba]

LGTM @robmoffat - though I missed the first 1/2 of the meeting.

Would it be useful to take a couple of the use cases and map out how it would be implemented today using existing FDC3, OAuth, etc? Might help elucidate gaps to address...