1 of 11

DID chooser�for SIOP

How can a user get a meaningful choice about which identifier to use on a website?

2 of 11

Use Case: a user goes to a Relying Party

  • The user has not been to this website on this device’s browser
  • The user wants to register for return visits
  • The Relying Party gives the user a choice
  • One choice is to use a self-issued identifier
  • There are too many choices for RP to display all
  • The user needs a way to select the ID to use
  • Let’s look at some options

3 of 11

User choice at the Relying Party

Google

Personal

Healthcare

Register

Prefered identification providers.

These providers all can authenticate the user as the owner of the user information stored on this site using the user identifier provided by your choice from the buttons below.

​

The “Personal” provider requires a Wallet you have installed for Self-Issued IDs

The “Healthcare” provider is the trust registry for that community.

4 of 11

What are the options for Self-issued

The user has selected the “Personal” button above, what next?

1 The user has a single wallet available at openid://

2 The user has a wallet chooser available at openid://

The above can be improved if there is trust of apps using openid://

3 The user has a wallet chooser in the web (access by Registry)

4 The user agent (brower) has a registry for SIOPs

5 The user agent has extensions selected and installed by the user

6 The user selected Password Manager is woke to DIDs

5 of 11

1 The user has a single wallet for all DID

  • Required - a standards organization that can create a spec
  • Wallets will handle (nearly) all methods for ID and AuthN
  • The various methods all adopt the wallet requirements
  • The wallet can determine if the methods meet the requirements

​

No solution proposed for web apps.

6 of 11

2 The user has a single chooser for all IDs

This solution, like the password manager, has a default and override

  • The User’s wallets are all registered with the chooser
  • The chooser should use the previous choice for each RP
  • A registry of trusted choosers is still required
  • That chooser should be able to access web app just like native
  • The chooser can select apps, or optionally identifiers w/i apps

7 of 11

3 Registry Chooser (just shows /Authorize?)

8 of 11

4+5+6 The user agent (brower) has control

Similar to option 3 - some W3C options exist on implementation

The RP will needs to install javascript that sorts through the options

  • Registered like the payment handler today
  • Added methods to W3C Credential Manager (e.g. for CHAPI)
  • User selects and installs a browser extensions on device
  • The user can already install a password manager that does it all

Caveats

  • Javascript needs to be installed by RP which controls the flow
  • If an attacker can run code, it’s not your computer any more
  • Security model needs to ensure user data is not leaked

9 of 11

Post Conditions

  • A Relying Party has presented a set of data requests to a holder
  • Holder has chosen the identifier that they want to use with an RP
  • Holder is provisioned with some sort of association at the RP
  • Holder stored information about this association
  • Holder goes to the site later and the identifier is retrieved
  • Holder is given a receipt showing exactly what the RP knows
  • Holder has the means to tell the RP to discontinue use of that ID
  • Holder is happy about the outcome and understands what happened

10 of 11

Useful links

11 of 11

​

  • How does the user select choices for the chooser?
  • Orie: Cookie blocking not an issue Oliver’s post: “Now ITP has aligned the remaining script-writable storage forms with the existing client-side cookie restriction, deleting all of a website’s script-writable storage after seven days of Safari use without user interaction on the site. ”
  • O - Issue on CHAPI - browsers do not plan any support (but might improve CredMAN?)
  • Orie thinks (Tom disagrees) End of the day, one thing everyone will agree is that the RP will install or assume some client side javascript.
  • QR codes will solve {everything or nothing} major split on when users will be comfortable with QR
  • URL’s can work for {everything, nothing} another spilt
  • Mike believes we need to create a standard for a single wallet that will handle all creds a user might have
  • Orie believes we can have choices so long as they are interoperable (some disagreement)
  • Question about how many choices a user can have / can tolerate / would want
  • What user sees and consents to is a big issue for UX - needs careful analysis early in process
  • Vittorio - From the user experience perspective, choosing many wallets seems as inconvenient as having multiple password managers. It happens on IOS and it's not great
  • Joe Andrieu - privacy demands choice
  • Troy Ronda wishes Wallets would become more like Browsers - can create presentations and create authorizations.
  • Joe Andrieu - wallet interoperability and substitutability is the real unaddressed standard
  • Troy Ronda - prefer an API to get the registered wallet
  • DW - put wallet choice in a wallet (ie wallet spec needs to mandate a chooser)
  • Orie - I think SIOP needs to work with PWA, Native and Backend Services- Or its dead on arrival
  • K - to go back to SIOP, for wallets that can be part of the trust framework, I see universal URL + sharesheet solution work (both for PWA, native apps), other wallets would have to negotiate their own custom schema (works also with backend - usual OIDC registration) with the RPs (NASCAR there) is what I see now as a viable solution

​