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

[rikoe]

This whole thing concerns me a lot. I agree that identity is an important issue and should be looked at/talked about, but I don't buy the use cases so far.

The idea of FDC3 has always been that it is supplementary to what applications are already doing - it is a way to transfer back and forth between applications, or share data between them, but it is not a replacement for (1) applications speaking to their own servers in terms of their own domain and data (2) not tied to any concept of user identity.

User identity is (or was) very deliberately considered outside of the scope of FDC3, and the responsibility of the participating applications in workflows. There are many good reasons for this. One is data privacy concerns, another is the complexity of ensuring security across many different tech stacks/desktop agents once we go there.

Participating applications already should/will have a sense of the logged-in user performing actions, and the assumption is that if an intent or channel is activated, it is all within the same user context (but crucially each application manages its own user login, and may be doing that differently than each other, and holding different data about the user that shouldn't be shared with other applications). Anything else borders on madness in my opinion.

There is of course the case of workflows that span multiple machines or devices, or potentially are linked up to activities in the cloud, but that is not currently within the charter I believe.

At most, I think FDC3 can potentially delegate the concept of user identity to another identity provider, if it is really needed, but I think applications should interface with that provider on their own, not via FDC3, otherwise we open the door to all kinds of security concerns.

[dimiter-georgiev]

heyu Rob is it possible to add @.*** and @.*** in the ticket so they can be in the conversation. Thanks!

On Tue, Jun 21, 2022 at 4:08 AM Rob Moffat @.***> wrote:

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.

1. Those present discussed that Identity could be supplied to applications via the existing FDC3 context / intent mechanism.
2. 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.
3. 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.

— Reply to this email directly, view it on GitHub https://urldefense.com/v3/__https://github.com/finos/FDC3/issues/684*issuecomment-1161406454__;Iw!!JrOaqOcUag!JqPp8NICWKGO9SNrO8C254_mfWF_xoxq2QzEwIl70Ca5XEfMHBzknfZG7_E37YhxWDXEmp3gHmuS8mIiMUPyg1N4nqznRPwH$, or unsubscribe https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANCRIVUNI27IOKETJP4SIHTVQFZ6BANCNFSM5USHIRQQ__;!!JrOaqOcUag!JqPp8NICWKGO9SNrO8C254_mfWF_xoxq2QzEwIl70Ca5XEfMHBzknfZG7_E37YhxWDXEmp3gHmuS8mIiMUPyg1N4npNkfiId$ . You are receiving this because you were mentioned.Message ID: @.***>

[robmoffat]

@dimiter-georgiev I can't see who you're talking about here! Can you @-mention them in a comment on GitHub itself?

[dimiter-georgiev]

@robmoffat, Mario Orphanou and Sin Kim ( [email protected] and [email protected] ). they look after our identity strategy

[robmoffat]

Mario is: @marioo6

Not sure what Sin Kim's GitHub handle is..

is this what you're after me doing?

[robmoffat]

Proposal from @mistryvinay and @robmoffat:

https://static.swimlanes.io/8a505ab9ee7ecddd88f42fd2fee0ea38.png

Edit Here

[kriswest]

some quick feedback on the two designs:

The context listener based approach would either need special handling in a desktop agent (in which case it doesn't make much sense to reuse fdc3.addContextListener, you might as well go the whole hog and add a new API function). Alternatively, you could simply standardize a channel name to retrieve and add the context listener to. That would leave the only challenge as ensuring that the identity app had been started and had added the context to the channel. On first joining the identity channel, an app would need to channel.getCurrentContext (to find out the current identity) then channel.addContextListener to receive any changes (if there is a use case for that).

The intent based option is a little more practical and achievable with FDC3 2.0 intent functionality which can spawn the identity app (if need be) and retrieve the identity.

This is purely feedback on the use of the FDC3 API - I'm still not convinced that its a good idea to break the direct relationship between the IDP and applications it is providing identity to/authorizing nor that the resulting system would meet regulatory requirements involving identity that may arise (/were mentioned in use case discussion). At the least, a JWT auth token needs to be validatable (via the IDP!) and would usually be trackable to a single application (for good reasons!)

Any such proposal should be validated against solid use-cases AND best practice in software security/authentication.

K

On Tue, 25 Oct 2022 at 10:40, Rob Moffat @.***> wrote:

Proposal from @mistryvinay https://github.com/mistryvinay and @robmoffat https://github.com/robmoffat: https://swimlanes.io/#lVTBjtowEL3nK+ZWimikdm8cKlHQSlRUrApSrxh7IFOMndqGwN937CTsdjfQ5RYyM2/ee/NCoKBxCI+T8QNMFZpA4QxjawKeAjw5W1ovdJal+gT9LtgylQUZdPDpKyzO+7Kw5gwzuyUDo7KEIcxLNFmWddR4YmxdaZ0ICNPJEzePC6E1mi1mmbEBh89jSKHgLaVDz8w8CNAJaG1PA7AOFG7QeQgWuA/kBXexmNedOWTZv+uuMV6Mfsxg5D26QNZco37FhiF8c1YoKXyAXreV8/VvlOFjIxGyJRN+hmb6BlijihplM2LTCKyF3LUSX+7PgcVNN/yePFAc/P5ryY07NAOgAL6wB61gjWANcpcIrZ+yJu7BWNg6wc4mN+vHurNDflyhta3IbGHD7TZhJUZc9jl7RkZi4plYeMBTSQ4HNcW9OINBVFELkyrRkVUk89aSfp9h2EZZwOd+f3jNwsgjrtB8Ubb7yAHgg/EOZu/3FEK9QWpKkamis9x/BukwhoAzRD5gPFtUQSG/le5UGSesqLJN9qvXN6MhlGoUzJrFvdVGyYecGoGrtyF5N6GY3BSb25Ctx6+nja2gELWhB87+B05SAzEAYRRIYWKhvqCIIdseuCM+sslVQXwtJYKIvzhwVRvUCNZ12S/xspckN0wEM5EprA7/HOJVY0dLBI4kmAsQCzJhAKufKJGO2OZjld/9tRYsTeM0Afbe4F0+0mWKLXKuur6HirRukFrevo5UA3RfTJwgf4vSnf/A/4PrcqwzXs3s1YT9BQ==

— Reply to this email directly, view it on GitHub https://github.com/finos/FDC3/issues/684#issuecomment-1290272948, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAM7PBE3BOK6WWQGPMVRDFLWE6THXANCNFSM5USHIRQQ . You are receiving this because you commented.Message ID: @.***>

-- Kris West Principal Engineer [image: Finsemble] https://cosaic.io/finsemble +1 (800) 821-8147 @.***

[robmoffat]

Presentation from June FINOS Member Meeting: https://docs.google.com/presentation/d/1fGvWWohd1tji4J7lj3AqHeHNd1BF3cfF0ZarCPC6rcM/edit#slide=id.g2507b26aa95_0_194

[robmoffat]

Yannick's prize winning Proof-of-Concept from the BMO Hackathon: https://drive.google.com/file/d/1N05MeL6IkKhOsG8SqmdVMRJEVUcJL3LK/view

[robmoffat]

Proposal for new group: https://docs.google.com/document/d/1WeMfNVXZ9QsWT2ZDx3Yrm4GQh-yjEbl8rRiIewPZvgc/edit

[kriswest]

New group convened:

• #1078

Closing this issue as superseded