Self-Issued OpenID Provider (SIOP)

SIOP acts as the secure conduit for presenting Verifiable Credentials (VCs). A user (the holder) can present cryptographically signed credentials from an issuer (e.g., a university diploma) directly to a verifier (e.g., an employer). The SIOP flow ensures:

• The presenter is the legitimate credential holder.
• Credentials are not tampered with (data integrity).
• The interaction minimizes unnecessary personal data exposure.

SIOP enables a portable identity that is not locked to a specific platform or corporation. A user can use the same core decentralized identity across:

• Different websites and services.
• Government e-services and Know Your Customer (KYC) platforms.
• Enterprise and supply chain authentication systems. The identity is anchored by the user's private keys and verifiable credentials, making it resilient to single provider failure.

A core use case is enabling privacy-preserving interactions. SIOP, combined with Zero-Knowledge Proofs (ZKPs) or Selective Disclosure, allows users to prove specific claims (e.g., 'I am over 18') without revealing their full identity or credential details. This supports principles of:

• Data minimization.
• Unlinkability across different service providers.
• User-controlled consent for data sharing.

SIOP is the primary authentication mechanism for Self-Sovereign Identity (SSI) wallets. The wallet software (acting as the SIOP) manages the user's DIDs, private keys, and verifiable credentials. It handles the entire SIOP protocol flow, providing a unified interface for users to:

• Authenticate to relying parties.
• Store and organize credentials.
• Authorize data sharing transactions. Examples include Trinsic, Lissi, and MATTR VII wallets.

For SIOP to function, a user must possess a compatible identity wallet. This wallet:

• Stores the user's private keys and manages their DIDs.
• Securely holds received Verifiable Credentials.
• Implements the SIOP protocol to respond to authentication requests from websites or apps (Relying Parties).
• Presents a consent screen, allowing the user to select which credentials to share, enabling selective disclosure.

A Relying Party (e.g., a dApp or website) integrates SIOP to request user authentication. The flow is:

1. RP redirects the user to a siopv2:// URI containing an authentication request.
2. The user's wallet opens, processes the request, and constructs a Verifiable Presentation.
3. The user consents and signs the response with their DID's private key.
4. The wallet redirects back to the RP with a JWT (JSON Web Token) containing the signed presentation.
5. The RP verifies the JWT's signature against the user's public DID on a ledger.

SIOP is a profile of the OpenID Connect (OIDC) protocol, which itself is an identity layer on top of OAuth 2.0. The key difference is the Provider. In traditional OIDC, a central server (like Google) is the Identity Provider. In SIOP, the user's wallet becomes the Self-Issued OpenID Provider. This maintains the familiar authorization code flow for developers while radically decentralizing the source of identity.

A primary application is passwordless, phishing-resistant login for decentralized applications. Instead of "Connect Wallet" just for signing transactions, SIOP enables "Login with your Wallet" for user authentication. The dApp (the RP) can request specific claims (e.g., "over 18" or "has NFT X") from the user's credentials. This creates a portable, user-centric identity layer across the Web3 ecosystem without new usernames or passwords.

The user's Decentralized Identifier (DID) and associated private keys are the sole credentials. Security depends entirely on the user's ability to store them securely, typically in a digital wallet. Loss or compromise of the private key means permanent, irrecoverable loss of the identity. This shifts the burden of key management from centralized servers to end-users.

SIOP relies on cryptographic proofs (e.g., signed JWTs). A malicious Relying Party (RP) could:

• Trick a user into signing a Verifiable Presentation for unintended data.
• Impersonate a legitimate RP to steal credentials.
• Use a replay attack with a captured presentation. Mitigations include using DID Auth, challenge nonces, and verifying the RP's own DID.

A core SIOP goal is minimizing data exposure. However, a user's persistent DID can become a correlation handle if used across multiple RPs. Techniques to prevent this include:

• Using pairwise pseudonymous DIDs (a unique DID for each RP).
• Employing zero-knowledge proofs (ZKPs) to disclose only necessary claims.
• Selective disclosure of Verifiable Credentials.

The RP must perform critical validation steps on the incoming ID Token or Verifiable Presentation:

• Verify the cryptographic signature against the user's DID Document.
• Resolve the DID to its public key material (risks: unreachable DID resolver, poisoned methods).
• Validate the issuer (iss) matches the user's DID.
• Check the audience (aud) matches the RP's own DID.
• Ensure the nonce matches the one issued in the challenge.

Traditional OAuth uses centralized revocation lists. In SIOP, revocation is more complex:

• Key Rotation: Users can update their DID Document with new keys, but RPs must fetch the latest version.
• Credential Status: Revocation of underlying Verifiable Credentials (e.g., a driver's license) depends on the issuer's status mechanism (e.g., a revocation list, status registry).
• Lack of a global, real-time revocation mechanism is a known challenge.

Security flaws often arise from implementation errors:

• Insecure Randomness: Weak nonce generation for challenges.
• JWT Validation Bugs: Failing to validate all required claims or signatures correctly.
• DID Method Vulnerabilities: The security of the user's DID depends on the specific DID method (e.g., did:key, did:ethr) and its resolver.
• Man-in-the-Middle Attacks: Requires strict use of TLS (HTTPS) for all communications.

A Decentralized Identifier (DID) is a globally unique, cryptographically verifiable identifier that is controlled by its subject, not a central registry. DIDs are the foundational identifier type used by a Self-Issued OpenID Provider (SIOP) to represent the user.

• Key Properties: Decentralized, persistent, resolvable to a DID Document.
• Example: did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK
• Role in SIOP: The sub (subject) claim in a SIOP ID Token is a DID, proving self-sovereign identity.

Verifiable Credentials are tamper-evident digital claims that are cryptographically signed by an issuer. They are a core data format in decentralized identity ecosystems that often integrate with SIOP for authentication.

• Structure: Composed of metadata, claims, and proofs (e.g., digital signatures).
• Standard: Defined by the W3C Verifiable Credentials Data Model.
• Integration: A SIOP-based wallet can present VCs (like a driver's license) during an OpenID Connect flow to provide verified attributes.

OpenID Connect is an identity layer built on top of the OAuth 2.0 protocol. It enables clients to verify the identity of an end-user based on authentication performed by an Authorization Server.

• Core Flow: Relies on ID Tokens (JWTs) and UserInfo endpoints.
• SIOP's Role: SIOP is a specific OIDC profile where the user acts as their own OpenID Provider, removing the need for a centralized Authorization Server.
• Key Difference: Standard OIDC uses a third-party IdP; SIOP uses a user-held DID.

A JSON Web Token is a compact, URL-safe token format defined in RFC 7519, used to securely transmit claims between parties. It is the fundamental container for SIOP's authentication assertions.

• Structure: Header (algorithm), Payload (claims like sub, iss), and Signature.
• Use in SIOP: The ID Token issued by a SIOP is a JWT, where the iss (issuer) and sub (subject) claims are both the user's DID.
• Verification: Relies on public key cryptography, with keys discoverable via the DID's DID Document.

DID Auth is an umbrella term for authentication patterns where a entity proves control of a Decentralized Identifier. SIOPv2 is the formalization of this pattern within the OpenID Connect working group.

• Evolution: SIOPv2 refines the original SIOP draft, improving interoperability and security.
• Core Mechanism: The RP sends an authentication request; the user's wallet signs a response JWT with the key associated with their DID.
• Standardization: Defined in the OpenID Connect for Verifiable Presentations (OIDC4VP) suite.

In the OpenID Connect and SIOP model, the Relying Party (RP) is the application or service that requests and relies on authentication of an end-user. It is synonymous with the OAuth 2.0 Client.

• Role: Initiates the authentication flow by presenting a request to the user's SIOP (wallet).
• Action: Receives and validates the ID Token/JWT returned by the SIOP.
• Trust Model: The RP trusts the cryptographic proof in the JWT signature, not a central authority.