Managing SSI (A relying party perspective)

Managing SSI (A Relying Party Perspective)

Wednesday 10F

Convener: George Fletcher

Notes-taker(s): George Fletcher & Aaron Parecki

Tags for the session - technology discussed/ideas considered:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

1. Notes received from George Fletcher:

We discussed a quick overview of the SSI Model. Basically that the goal is to provide a similar experience that users have today with their physical wallets where in they can present credentials from their wallet to entities of their choosing without the credential issuer knowing about the action.

We then discussed that relying parties (or service providers) all have an identity life-cycle to manage even if they are using an external service for identity management. The key aspects of the RP Identity life-cycle we discussed are:

• Onboarding / Registration
• Authentication
• Account Recovery

Onboarding Registration

The key differences between existing methods and SSI is that the expectation with SSI is that the user will have all the credentials they need in their wallet and the RP will ask the wallet for the credentials that it needs. The big issue for the RP is that they don’t have any idea what credentials a user might have in their wallet. Especially as the model gets adopted, the credentials in wallets are going to be very varied and this is an issue for relying parties. Additionally, the claims a relying party requires at registration time vary widely based on the service the relying party offers. This can range from just needing self-asserted data to very robust verified credentials (for say opening a bank account).

Authentication

The biggest issues here is that DID Authentication (as currently defined) just provides some flows that can be used but the specifics of those flows are unique to the DID Method used by the SSI platform. This is problematic for relying parties as they have to have different code for each integration. Otherwise, the UX flow can be made pretty similar to existing flows and that’s good for users.

Account Recovery

The SSI view of account recovery is “don’t lose your private keys”. From a relying party perspective this isn’t a viable solution. Additional recovery methods need to be defined because real users will lose their private keys and need to get back into their accounts.

Other topics discussed

1. Fraud - there are new attack vectors with the SSI model and just normal registration fraud needs to be handled (it’s easy to create a pub/priv key pair and self-assert data). Many relying parties don’t need verified credentials and won’t want to pay for them as a way to limit fraud.

2. Account Linking - there is a strong likelihood relying parties will need to support account linking as they will have both an SSI wallet and an existing identity at the relying party. It’s unclear what the user experience is, or security impacts are, of supporting such linking.

3. Opportunities - there are some benefits of the SSI model due to the fact that the DID provides a discovery mechanism of services supported by the holder of the DID. This means its possible to discover a way to query for updated user information without involving the user which would be an improvement over the current practice of asking users to update their data when they sign in.

********************* *********************** ***********************

2. Notes received from Aaron Parecki:

Notes: Relying Party Lifecycle Management

• someone shows up to use your thing
• then they come back and you need to authenticate them
• users are going to lose their credentials and you'll need some sort of recovery mechanism
• under GDPR etc users will say you need to forget me and you need to deprovision them

we have these lifecycle events regardless of which authentication mechanism exists

from a RP perspective, SSI is an authentication mechanism

The RP has to separate the user's credentials from the identity storage where user info is stored. 

Onboarding

common patterns are to ask the user for a bunch of information. any RP has to deal with fraud, even if all your service is is leave comments on blog posts. in many cases today, fraud at an RP is done by asking the user for a mobile number. 

Eve - do you really mean relying party, or are you a service provider?

George - whether we use an internal component to authenticate users, or ask an external idp, it's the same for us so we are a relying party

Possible SSI Registration Flow

one of the issues is as an RP, how do I know what's in your wallet? how do I know what I can ask for? 

I might need to know whether you're over 13, but do I trust a random bank in a country I don't know to issue a credential that says you're over 13? so I need some way to say which providers I trust to verify your age. it's unclear how to do this well.

when can I ask for a zero knowledge proof? 

Lessons learned from OpenID Connect: what RPs always needed has been a way to communicate to the user, usually an email address. This won't change for a very long time.

Do I ask for an email address, and how do I know it's verified? If I get an email address from gmail.com, do I only trust google to issue that claim? or do I do my own email verification?

In practice I don't see a way to actually get all the information needed for registration in a verified way, so more likely we'd end up collecting what we can from the user to prefill the registration form.

Protocol Challenges

Right now, each DID method defines its own syntax for the JWT claims, so it becomes really hard to actually support all the methods.

Common Pattern: Authentication

• enter your username
• open a yahoo app 
• app prompts is this you trying to sign in
• confirmed and you're signed in

Possible SSI Authentication Flow

If you did ask the user for a unique (to your system) username, then you could prompt the user to enter their unique username for that RP and it would know how to generate the appropriate JWT challenge.

Question - if you ask the user to enter a username, then this discloses which DID methods that username uses, so it's a slight leak.

Yes, just like any identifier-first flow right now, like currently happens with Google or Yahoo.

This keeps the user experience flow the same. 

DID-Auth - proves ownership of a private key. Should other mechanisms also be allowed?

Account Recovery

Normal account recovery process - put in the email address, tell the user the phone number on file and verify it somehow. 

Possible SSI Account Recovery Flow - don't lose your keys, back them up, etc. there is none. I don't think this is viable from an RP perspective.

if a person logs in to a paid service with DID-Auth, then they come in and say I lost my keys, what do I do? Maybe if it's a paid service they have a credit card and I can prove ownership of the credit card and then assign a new DID?

The existing account recovery problems that RPs have don't change with SSIs. Hopefully the one change is that it will reduce the number of recovery flows since it will be easier to log in without a password. But it won't eliminate them completely.

So then the question is if I have a really strong method like DID-Auth, then how many recovery methods do I need in order to get a strong enough verification of the user in order to recover their account? And then how much data do I need to collect about the user in order to do this?

What are the security implications of allowing a recovery method?

Question - what about letting the user upload verifiable credentials?

For us, as an email provider, we're not going to ask the user for a utility bill to recover their email account.

Other issues

Account linking - I already have a Yahoo account and now I want to connect my wallet to it. Is it good or bad? It's an easy technical problem to just add a DID to the account.

Fraud / anti-abuse

It's not hard to generate public/private keypairs. How do I do fraud detection to avoid bot networks registering? What do I do in the registration flow to know whether I should accept this registration.

Our fraud person said no you won't directly create an identity from the claim. Instead you'll present that to the user and have them click it, because that gives us many more signals to detect fraud.

At that point SSI becomes a form fill for the registration page.

It ends up being like SSI is just another social provider. But with social providers, we have the signal that we know an IDP is actively working towards eliminating fraud accounts so we have a higher assurance that a registration from that IDP is good. But with SSI everyone is their own IDP so we are missing that signal.

Data Hygiene

One thing DIDs do provide is the ability to update the user's data since the DID can be queried to find updated info about the user. The RP could use this to update the user's phone number which would be a much better experience than what we currently do which is to ask the user to update their information occasionally.

Relying parties will need to

- support both identity models in parallel

- minimize infrastructure impact

- will need to be involved in the community to know when things are changing

- deal with lack of standardization in the near term

Eve - in order to solve the challenges you identified... do you think that the goals for the current architecture would be compromised by doing this? Even just account linking or account recovery are kind of counter to the goals.

George - I just don't see this right now being practical to have just one DID method for a user account with no recovery plan.