1 of 12

FDC3 Identity

Symphony: Yannick Malins, Vinay Mistry

FINOS: Rob Moffat

Fintech Open Source Foundation

finos.org

2 of 12

Agenda

Introduction to the Problem

User identity
App Identity
Desktop Agent Identity
Overview of Yannick’s Identity POC

Discussion of Pain Points / Potential Use Cases
Decision on whether we need an FDC3 Workstream for Identity

Fintech Open Source Foundation

finos.org

3 of 12

Introduction To The Problem

User Identity Hell

Who's using this app?
Who’s using the other apps?
Who are we interacting with?

App Identity

Who are we interoperating with?

Desktop Agent Identity

Can apps trust the platform provider (mediate identity)?

Validate Identity

How do we validate identity?

FDC3 has limited identity features:

Fintech Open Source Foundation

finos.org

Opening

FDC3 - is a standard that enables desktop interoperability. It provides a standardised way to represent information so that it can be shared between different applications.
As the standard has evolved, use-cases have been raised where identity would be useful
FDC3 API returns metadata on Intent resolutions, telling you what appId resolved a raised intent
There also the optional originating app metadata feature, which can tell you who raised an Intent or sent a Context message.

But they both return an appId which is not an easily validatable identity

User Identity

When a new application is started by an FDC3 container/agent, should the app should be given the details of the user who is using it.
If an intent gets raised from one app to another, should the apps be aware of the user that raised the intent?

App Identity

Application interoperability is a key part of FDC3, the ability to send information between applications, developed by different providers.
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.

Desktop Identity

We can get some basic details of the desktop agent via fdc3.getInfo(), this provides information about the provider name and version. But does this information need to be validated?
Can apps trust the platform provider? DA are responsible for routing and broadcasting messages.
Desktop agent sends a message - if you trust the DA then the app trusts this message

Validate Identity

So how should we validate identity across these different areas.

Introduction

The recent BMO Hackathon in May was focused around FDC3 use-cases, one of which was how to enable Identity
Take this opportunity to introduce Yannick Malins from Symphony, who is the Director of Software Engineering who led the Symphony team in building a PoC around managing user user-identity.

4 of 12

Identity Proof-Of-Concept

BMO Hackathon Demo

“Login With FDC3”��Identity provider: Symphony

Identity consumer: Mockup apps: portfolio app, transaction app�

Fintech Open Source Foundation

finos.org

5 of 12

How It Works

CONTEXT

User

Desktop

Agent

Portfolio

App

Login

App

clicks

login

GetIdentity

INTENT

GetIdentity

INTENT

Login

App

User

handle

Login process

Desktop

Agent

CONTEXT

Portfolio

App

1

2

Validation

Login

App Backend

Portfolio

App Backend

SIGNATURE

FDC3

JWT

Fintech Open Source Foundation

finos.org

6 of 12

Discussion

Pain Points - are these genuine problems?
Potential Use Cases - please tell us yours!

Fintech Open Source Foundation

finos.org

Thank you Yannick for that great presentation and demo on “Login with FDC3”

So out in the field the maintainers have come across scenarios where identity would be useful,

User onboarding for example, the ability to simplify application provisioning and enablement
Cross-firm workflows, where apps are deployed outside your organization. Do you need to know who is logged in?
App Directory, can anyone list an application. Do you trust the publisher of the app?

So this is a great time to kick off our discussion around identity.
Is identity a genuine problem that needs to be solved across FDC3?

Remember this not trying to figure out what technology to use, but rather is there a need to validate the identity of a user, an application or platform provider?

This is a great time to open for a discussion.

7 of 12

Question

Do we need to kick-off a workstream for adding Identity & Auth features to FDC3?

Fintech Open Source Foundation

finos.org

8 of 12

User Identity - Use Cases

Password Hell

Too many start-of-day logins
Logging in during a workflow slows you down

Onboarding Hell

Pre sign-up validation of 'suitable persons'
Lengthy on-boarding –> drop-off
Too many passwords!

Licensing and security

There's often a need to reconcile identity across apps
Cross-firm/Cross-vendor SSO

Sharing an Identity

Capital Markets workflows often involve other parties
Their Identity may need to be shared AND validated

Fintech Open Source Foundation

finos.org

9 of 12

App Identity - Use Cases

Who are you interoperating with?

Both Vendors & Banks may not be able to take actions or share data without confirming the identity of the other App & it's User.�

Licensing issues
Logging and/or regulatory requirements
Commercial reasons�

This reduces uptake of the Standard/Interop

Fintech Open Source Foundation

finos.org

10 of 12

Identity

A lack of identity & authentication features causes multiple problems for adopters of FDC3

Desktop agents may know/trust the identity of Users and Apps, and Apps their own Users but…

Apps can't validate the DA
Apps can't validate each other's users
Apps can't validate each other
Onboarding users can be tough as is hell on the Desktop

Whats are your personal pain points about identity?

Fintech Open Source Foundation

finos.org

App Identity: App wants to validate the identity of another app thats asked it to do something (display data, return data, change data etc.), or apps that they might share data with.

Vendors/Banks have spoken publicly about not wanting to take actions or share data without being able to confirm who (the user) and what (the app) is sending the request or receiving the data.

Logging
Regulatory rules / Compliance and rules around automation (by connecting two applications) - passing structured messages between applications can be seen as automation which may be regulated.
Is this app who the desktop agent says it is? Could it have navigated elsewhere? Or the identity been spoofed?
FDC3 was not designed with this in mind, instead it targeted 'open' (often anonymous) interop.

Commercial reasons

We might disagree with this philosophically, but…
This slow uptake of FDC3, which is a bad for the community as a whole.

User Identity: Apps wants to provide services to a user before onboarding them

High drop-off at sign up forms
But regulator needs them to confirm they are suitable person to retrieve

Desktop Agent identity:

If the Desktop Agent is trusted to mediate interactions (and possibly identities) then it too needs to have its identity authenticated

11 of 12

Desktop Agent Identity - Use Case

Use Case

How do apps trust a message that is coming through the desktop agent?

Do we sign the message or trust the FDC3 channel?
What about replay attacks and spoofing?

Fintech Open Source Foundation

finos.org

12 of 12

Identity Proof-Of-Concept

Fintech Open Source Foundation

finos.org