Using OpenID Connect with Decentralized Identifiers
The DID Auth WG had its kick-off meeting on April 25th. As DID Auth has different interpretations, the group agreed that DID Auth should be scoped as follows:
- Disclosure of a Decentralized Identifier
- Proof of control of the disclosed Decentralized Identifier
- Focus on authentication (AuthN)
- Authorization is out of scope
DID AuthN Flavors
DID AuthN allows two parties to connect by exchanging DIDs, resolve their DID Documents, and use the Service Endpoints within them to interact with each other.
We agreed to work towards specifications and recommendations on how to use DID AuthN in a specific context. This means, rather than having one particular DID AuthN protocol, we believe it makes sense to specify how to integrate DID AuthN in existing, open and standardized protocols and create so-called DID AuthN flavors. We hope to drive adoption of the DID specification by describing how these protocols could work together with DID AuthN.
We chose OpenID Connect (OIDC) and more specifically the Self-Issued OpenID Connect Provider (SIOP) first, but we won’t rule out working on other flavors of DID AuthN such as Webauthn, or Message Layer Security (MLS) in the future.
OIDC Flavor
An everyday use case that the SSI community identified is the sign-up or login with web applications. Nowadays, this is often achieved through social login schemes such as Google Sign-In. While the SSI community has serious concerns about social login, the underlying protocol, OIDC, does not have these flaws by design. DID AuthN provides great potential by leveraging an SSI wallet, e.g., as a smartphone app, on the web. This will increase and preserve the user’s privacy by preventing third-parties from having the ability to track which web applications a user is interacting with.
This first DID AuthN Flavour aims to define a DIF-approved recommendation on how to use OIDC together with the strong privacy and security guarantees of DID for everyone who wants to have a generic way to integrate SSI wallets into their web applications.
Here is a summary of why we have chosen OIDC first:
- Well-known and mature
- Widely used, and has a big community
- Enterprises are familiar with OIDC
- Simple and light-weight
- Flexible and extensible through profiles
- Additional (optional) support for credentials/ claims exchange
- Based on work incubated at RWOT, and IIW
The outcome will be a dedicated DID AuthN profile for SIOP. The profile has two goals:
- Staying backward compatible with existing OIDC clients that implement the SIOP specification which is part of the OIDC core specification.
- Adding validation rules for OIDC clients that have DID AuthN support to make full use of DIDs.
The following is an overview of how the W3C Verifiable Credentials terminology could map onto the work of the DID AuthN profile for SIOP.
We work in coordination with editors of the OpenID Connect specification to combine the knowledge from the DIF community and the OpenID Foundation.
Next Steps
The DID Auth WG will publish their official WG page soon where you will find information about their working documents. We will work on the DID AuthN profile for SIOP and keep the community posted.
