Self-Issued OpenID Provider V2 (SIOPv2)

SIOPv2 replaces traditional federated logins (like 'Sign in with Google') with a DID-based authentication flow. The user's wallet generates a self-signed ID Token containing their DID, proving control over the identifier without an intermediary. This relies on the resolution of a DID Document to fetch the public key material required for verification, establishing a direct trust relationship between the user and the relying party.

To bridge the gap between a desktop application and a mobile identity wallet, SIOPv2 defines a cross-device Self-Issued OP flow. The relying party generates a deep link or QR code containing the authentication request URI. The user scans this with their mobile wallet, which then signs the authentication challenge locally. This mechanism ensures private keys never leave the secure enclave of the mobile device.

Beyond simple authentication, SIOPv2 integrates with the Presentation Exchange specification. A relying party can request a Verifiable Presentation containing specific claims from Verifiable Credentials (VCs) directly within the authentication request. The wallet responds with a signed presentation that proves possession of the required credentials, enabling privacy-respecting attribute verification in a single step.

SIOPv2 supports multiple identifier formats through the subject_syntax_types_supported parameter. This allows relying parties to request specific DID methods:

• did:key: A self-contained DID derived directly from a cryptographic key pair.
• did:web: A DID anchored to a domain's TLS certificate, binding identity to web infrastructure.
• did:indy: A DID rooted in a Hyperledger Indy ledger for revocation support. This flexibility ensures interoperability across different decentralized identity ecosystems.

SIOPv2 supports aggregated claims and distributed claims, allowing a wallet to compose a response from multiple credential sources. Using BBS+ Signatures or AnonCreds, the wallet can apply selective disclosure to reveal only the minimum necessary attributes from a credential. For example, proving 'age > 21' without revealing the exact birthdate, preserving user privacy while satisfying the verifier's policy.

The protocol's reliance on Decentralized Public Key Infrastructure (DPKI) allows for agile cryptographic evolution. As NIST standardizes post-quantum cryptography (PQC) algorithms like CRYSTALS-Dilithium, SIOPv2 wallets can update their DID Documents to include quantum-resistant verification methods. This ensures that self-issued identity systems remain secure against future cryptographically relevant quantum computers without a centralized upgrade mandate.

The globally unique, persistent identifier that serves as the subject in a SIOPv2 authentication flow. Unlike email addresses, DIDs require no centralized registration authority. A DID is resolved to a DID Document—a JSON-LD file containing the public keys and service endpoints needed to establish a cryptographically secure peer-to-peer connection with the relying party.

• did:key: A lightweight DID method encoding public keys directly in the identifier
• did:web: A DID method leveraging existing web domain infrastructure
• did:indy: A ledger-based method used in Hyperledger Indy networks

A protocol family extending standard OpenID Connect to support W3C Verifiable Credentials. While SIOPv2 handles the authentication leg—proving control of a DID—OID4VC handles the subsequent credential issuance and presentation flows. Together, they form a complete decentralized identity lifecycle.

• OID4VCI: Issuance protocol for requesting and receiving Verifiable Credentials
• OID4VP: Presentation protocol for sharing credentials with verifiers
• Both reuse OAuth 2.0 authorization servers and token endpoints

A tamper-proof envelope that a holder constructs to share one or more Verifiable Credentials with a relying party. After SIOPv2 authenticates the user's DID, a Verifiable Presentation can be delivered to prove specific claims—such as age, qualifications, or membership—without exposing the raw credential.

• Signed by the holder's private key to prevent replay attacks
• Supports selective disclosure: revealing only required attributes
• Can include zero-knowledge proofs for predicates like 'age > 18'

A secure, asynchronous messaging protocol that operates over the DID-based trust established during a SIOPv2 handshake. Once two parties have mutually authenticated via their DIDs, DIDComm enables encrypted, peer-to-peer communication without relying on centralized message brokers.

• Uses ECDH-1PU authenticated encryption for forward secrecy
• Supports routing through mediators for offline delivery
• Enables rich protocols like credential issuance and chat over a single channel

The overarching architectural philosophy that SIOPv2 implements at the authentication layer. SSI mandates that individuals and organizations hold exclusive control over their identity data, deciding what to share and with whom. SIOPv2 is the technical mechanism that enables an SSI wallet to prove identity without calling a third-party identity provider.

• Ten Principles of SSI: Existence, Control, Access, Transparency, Persistence, Portability, Interoperability, Consent, Minimization, Protection
• Contrasts with federated identity models like SAML or social login

A declarative JSON-based query language that a relying party uses to describe exactly which credentials and claims it requires from a holder. After SIOPv2 establishes the DID session, the verifier sends a Presentation Definition specifying constraints like required issuers, credential schemas, and field predicates.

• Defines input_descriptors for each required credential type
• Supports constraints with JSONPath filtering on claim values
• Enables automated wallet selection of matching credentials