OpenID Connect (OIDC) for DIDs

OIDC for DIDs provides a standardized protocol for authentication, enabling any Relying Party (RP) to request and verify a user's identity from an OpenID Provider (OP) that supports DIDs. This flow, based on OAuth 2.0, issues a signed ID Token (a JSON Web Token or JWT) containing verifiable claims about the user, such as their DID. It replaces the need for bespoke authentication systems with an interoperable, well-understood standard.

A core innovation is the ability to request and present Verifiable Credentials (VCs) within the OIDC flow. Instead of (or in addition to) a standard ID Token, the OP can issue a Verifiable Presentation. This allows users to share cryptographically signed credentials (e.g., a proof of age or membership) directly from their digital wallet, providing higher-assurance claims than traditional OIDC attributes.

The user's primary identifier in the authentication process is their Decentralized Identifier (DID), not a traditional username or email. The sub (subject) claim in the issued ID Token is the user's DID (e.g., did:ethr:0x...). This shifts identity control to the user, as the DID is anchored to a verifiable data registry (like a blockchain) and is not owned by the identity provider.

Authentication relies on cryptographic proofs linked to the user's DID. The OP must perform DID Resolution to fetch the user's DID Document from its associated registry. This document contains public keys or other verification methods used to validate signatures on the ID Token or Verifiable Presentation, ensuring the response truly originated from the holder of that DID.

This profile of OIDC enables a user to act as their own OpenID Provider using a self-hosted wallet. In a SIOPv2 flow, the user's wallet (the OP) directly signs and issues the ID Token for the Relying Party, eliminating the need for a centralized intermediary. This is a pure expression of self-sovereign identity (SSI), where the user has full control over the authentication process.

The protocol is designed for selective disclosure and minimal data exposure. Users can approve specific claims to be shared with each Relying Party, rather than providing broad profile access. Mechanisms like presentation exchange and claim formats allow users to share only the necessary proof (e.g., 'over 21' instead of a birthdate), enhancing privacy beyond traditional OIDC.

OIDC for DIDs adapts the standard Relying Party (RP), OpenID Provider (OP), and End-User model. The flow involves:

• User presents a DID to the Relying Party (e.g., a dApp).
• The RP redirects to an OpenID Provider (which manages the DID's keys).
• The user authenticates (e.g., via a wallet) and consents.
• The OP issues a signed ID Token (a JWT) containing verifiable claims about the DID, which the RP can cryptographically verify.

The central artifact is the ID Token, a JSON Web Token (JWT). For DIDs, this token is enhanced to convey Verifiable Credentials or proofs. Key elements include:

• iss: The issuer, typically the DID of the OpenID Provider.
• sub: The subject identifier, the user's DID.
• vc: An optional claim embedding a W3C Verifiable Credential.
• A cryptographic signature from the OP, verifiable using the OP's public key listed in its DID Document.

OIDC relies on discovery of the OpenID Provider's configuration. With DIDs, this is achieved via the DID Document. The Relying Party:

1. Resolves the user's DID to find their linked service endpoint for the OP.
2. Resolves the OP's own DID to fetch its public keys and OIDC configuration. This creates a trust chain rooted in decentralized identifiers rather than centralized domain names, aligning with Web3 principles.

Self-Issued OpenID Provider v2 (SIOPv2) is a critical profile where the user's wallet acts as its own OP, eliminating the need for a third-party provider. The flow involves:

• The user's wallet generates a DID specifically for the interaction.
• The wallet directly creates and signs the ID Token.
• The RP verifies the signature against the public key in the newly created DID Document. This enables truly decentralized, peer-to-peer authentication without pre-registration.

It's crucial to distinguish the layers:

• OAuth 2.0 is an authorization framework for granting access to resources ("can this app act on my behalf?").
• OIDC is an authentication layer on top of OAuth that provides identity information ("who is this user?"). For DIDs, OIDC uses OAuth 2.0 flows (like Authorization Code) to securely obtain the ID Token, which proves the user controls the DID.

Allows users to carry verifiable attributes (claims) across different services without relying on a central database. OIDC's standardized claim structure (like email, name) can be populated with data from W3C Verifiable Credentials.

• Key Benefit: A university-issued VC proving graduation can be presented via OIDC to access job portals or professional networks.
• Interoperability: This creates a portable identity layer where credentials issued in one ecosystem (e.g., education) are usable in another (e.g., employment).

Enables DID-based authentication for internal systems, customer portals, and government services, complying with existing Identity and Access Management (IAM) frameworks. Enterprises can act as issuers of VCs (e.g., employee badges) and also as relying parties that accept them.

• Use Case: An employee uses a company-issued VC to log into internal HR systems, cloud services, and partner networks via a standardized OIDC interface.
• Compliance: Facilitates audit trails and meets regulatory requirements for identity assurance by leveraging cryptographic proof.

Replaces or supplements traditional Web2 social logins with direct authentication from a user's cryptographic wallet. The website (RP) redirects the user to their wallet (OIDC Provider), which signs an authentication response.

• User Flow: "Sign in with Ethereum" or "Sign in with Polygon ID" are implementations of this pattern.
• Advantage: Reduces phishing risks and data breaches by removing centralized credential stores, tying authentication directly to the user's private key or biometric wallet unlock.

Extends secure, automated authentication to devices and machines using DIDs. A device can have its own DID and present VCs (e.g., a manufacturer certificate) via OIDC to access networks or APIs.

• Example: A sensor in a supply chain authenticating to a logistics API to submit tamper-proof data.
• Standardization: Leverages the OIDC Client Credentials Grant flow for machine-to-machine (M2M) communication, where the client ID is a DID.

OIDC for DIDs extends the standard OIDC flow by replacing the centralized Identity Provider (IdP) with a Self-Issued OpenID Provider (SIOP). This allows users to authenticate directly using their own Decentralized Identifier (DID) and cryptographic keys, without relying on a traditional third-party issuer.

• SIOP v2 is the key specification enabling this, where the user's wallet acts as the OpenID Provider.
• The ID Token is replaced or supplemented by a Verifiable Presentation (VP) containing Verifiable Credentials (VCs).

Interoperability is governed by formal specifications from the OpenID Foundation and W3C. Key standards include:

• OpenID Connect for Verifiable Presentations (OIDC4VP): Defines how a Relying Party (RP) requests and receives VPs within an OIDC flow.
• OpenID Connect for Verifiable Credential Issuance (OIDC4VCI): Standardizes how credentials are issued to a wallet via OIDC.
• Self-Issued OpenID Provider v2 (SIOPv2): The core protocol for DID-based authentication.

This architecture enables new authentication patterns for decentralized applications:

• Passwordless Login: Users sign in to websites and apps using their crypto wallet (e.g., for DAOs, DeFi, gaming).
• Selective Disclosure: Users can present specific claims from their VCs (like being over 18) without revealing their full identity.
• Cross-Platform Portability: Identity and credentials are user-controlled, moving seamlessly across different services and ecosystems.

The flow involves several key actors and artifacts:

• Holder/Wallet: The user's agent that holds DIDs, keys, and VCs, and acts as the Self-Issued OP.
• Relying Party (RP): The application or service requesting authentication.
• Verifiable Presentation (VP): The cryptographically verifiable package of credentials presented to the RP.
• Authorization Server: May still be used in hybrid models to manage session and access tokens.

Integrating DIDs introduces fundamental shifts:

• User Sovereignty: Eliminates dependency on a centralized identity provider; the user is the issuer.
• Enhanced Privacy: Enables zero-knowledge proofs and minimal disclosure via Verifiable Credentials.
• Interoperability: Built on open W3C standards (DIDs, VCs) rather than proprietary corporate directories.
• Reduced Liability: RPs no longer store sensitive PII; they verify cryptographic proofs.

OIDC for DIDs replaces the standard ID Token with a Verifiable Presentation (VP). This is a cryptographically signed package containing one or more Verifiable Credentials (VCs). The key security shift is from a centralized issuer's signature (e.g., Google) to a user-held signature from their DID, enabling selective disclosure and proof of control without revealing the underlying credential data.

A core privacy benefit. Users can prove specific claims (e.g., "I am over 21") from a credential without exposing the entire document (e.g., birth date, name). This is achieved through zero-knowledge proofs (ZKPs) or BBS+ signatures in advanced implementations, moving beyond the all-or-nothing data sharing of standard OAuth 2.0.

Trust is not placed in a central Identity Provider (IdP) but in verifiable data registries (like blockchains) and the cryptographic proofs themselves. The Relying Party must:

• Resolve the user's DID to a DID Document.
• Verify the signature on the VP using keys from that document.
• Validate the status of any VCs (e.g., against a revocation registry). This reduces dependency on any single service's availability or integrity.

The protocol mandates nonce and state parameters in the authorization request, which must be included in the signed VP response. This prevents:

• Replay Attacks: An intercepted VP cannot be reused.
• Phishing: A malicious Relying Party cannot successfully submit a VP to a different, legitimate RP. The signature binds the response to the specific authorization request.

Security depends on the DID method's underlying ledger and the user's key management. Risks include:

• Key Loss: Losing the private key means irrevocable loss of the DID and all linked credentials.
• Ledger Risks: The security and decentralization of the verifiable data registry (e.g., blockchain finality, governance).
• Sybil Resistance: Some DID methods lack inherent cost, making fake identity creation trivial unless paired with attested VCs.

While VPs enable minimal disclosure, the persistent nature of a DID can become a correlation handle across different Relying Parties. Techniques to mitigate this include:

• Using pairwise-pseudonymous DIDs (a unique DID for each RP).
• Credential revocation schemes that don't reveal which credential was revoked.
• Blind signatures for credential issuance. Without these, the system can offer less privacy than some centralized pseudonymous systems.

DID Auth is a broader, informal term for authentication patterns where a entity proves control of a Decentralized Identifier. OIDC for DIDs is a standardized, interoperable implementation of DID Auth.

• Scope: Encompasses any method of authentication using DIDs, not limited to the OIDC protocol.
• Comparison: While DID Auth defines the goal, OIDC for DIDs provides a specific, widely-understood protocol stack to achieve it, leveraging existing OAuth 2.0 libraries and infrastructure.