1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. connect

Wiki

Clone wiki

connect / SIOP Use-cases

View History

This is a wiki page to collect the use-cases that require SIOP, as a guidance when making architectural decisions related to SIOP V2 draft. Please copy fields from a "Template" section and add your use-case to the "List of the use-cases" with a use-case number and a title. Feel free to add any additional information. Please focus on problems rather than on the solutions.

Template

  1. Description : what problem SIOP solves
  2. Deployment model : [SIOP on the user device (native app, PWA, browser wallet), SIOP on a server (personal data store)]
  3. Subject Identifier type : [JWK thumbprint, DID]
  4. Claims format : [claims directly in id_token, Verifiable Presentation]
  5. Verifiable Presentation signature (if VPs are used) : [JWT, LD-proofs]
  6. A person who entered a use-case
  7. Implementations

List of Use-cases

Use-case 1 (WIP) : user authentication using DIDs and VCs

  1. Description : User authentication for 1/ remote on-boarding (for employees, contractors, customers), 2/ access to high value apps and resources, and 3/ Self-service Account Activation and Recovery. Service uses DIDs and VCs to enable the End-users to authenticate themselves while controlling their identity data. SIOP needed a) to lower the barrier for adoption for the Relying Parties, majority of whom already use OpenID Connect, and b) to preserve user privacy by eliminating a need to call the issuer/IdP during user authentication.
  2. Deployment model : SIOP on the user device as a native app
  3. Subject Identifier type : DID
  4. Claims format : Verifiable Presentation with Verifiable Credential
  5. Verifiable Presentation signature :JWT
  6. A person who entered a use-case : Kristina Yasuda
  7. Implementations: Microsoft

Use-case 2 (WIP) : mDL (mobile Driving License) ISO/IEC 18013-5

  1. Description : SIOP is used to share information from mdoc held by the user (SIOP) to mdoc reader (RP) in a privacy-preserving way without mdoc reader having to call the issuer. When 'usual' OpenID Connect is used, mdoc shares a token with mdoc reader, which can take that token to the issuer to retrieve information about the End-User.
  2. Deployment model : SIOP on the user device as a native app
  3. Subject Identifier type : JWK thumbprint
  4. Claims format : claims directly in id_token (mdoc data as defined in ISO specification)
  5. Verifiable Presentation signature : NA (VPs not used)
  6. A person who entered a use-case: Kristina Yasuda, Tony Nadalin
  7. Implementations: coming

Use-case 3 (WIP) : authenticate the end-user after a business stopped existing

  1. Description : being able to authenticate the End-user after a business that initially asserted identity of that End-user stopped existing.
  2. Deployment model : SIOP on the user device (native app, PWA, browser wallet)
  3. Subject Identifier type : either [JWK thumbprint, DID]
  4. Claims format : Verifiable Presentation
  5. Verifiable Presentation signature (if VPs are used) : either [JWT, LD-proofs]
  6. A person who entered a use-case: Kristina, based on the comments from David Waite and Nat Sakimura
  7. Implementations: none?

Use-case 4 :

  1. Description :
  2. Deployment model : [SIOP on the user device (native app, PWA, browser wallet), SIOP on a server (personal data store)]
  3. Subject Identifier type : [JWK thumbprint, DID]
  4. Claims format : [claims directly in id_token, Verifiable Presentation]
  5. Verifiable Presentation signature (if VPs are used) : [JWT, LD-proofs]
  6. A person who entered a use-case
  7. Implementations

Updated