Self-Issued OpenID Connect (SIOP)

A Decentralized Identifier (DID) is the core identifier in a SIOP flow, a URI that points to a DID Document. It is globally unique, persistent, and cryptographically verifiable, and is controlled by the user (the DID Subject) without a central registry. The DID serves as the sub (subject) claim in the ID Token.

• Example DID: did:ethr:0xab... or did:key:z6Mk...
• DID Document: Contains public keys, authentication methods, and service endpoints necessary for verification.

The Self-Issued ID Token is a JSON Web Token (JWT) created and signed directly by the user (the Relying Party is its own OpenID Provider). It contains standard OIDC claims like iss (issuer, set to the user's DID), sub, aud (audience), and exp (expiration), proving the user's control over their DID.

• Key Difference: The iss and sub claims are identical (the user's DID).
• Signing: The token is signed with the private key corresponding to the public key in the user's DID Document.

The SIOP Request is initiated by the Relying Party (RP) to request authentication. It is typically encoded as a JWT or passed as URL parameters, specifying the required claims, response type, and a challenge to prevent replay attacks.

• Core Parameters: response_type=id_token, client_id (RP's DID), scope=openid, nonce, state.
• Challenge: The nonce parameter is crucial for binding the response to this specific request.

The SIOP Response is the user's reply to the RP's request, containing the self-signed ID Token. The user's wallet or agent constructs this response, signs the ID Token, and returns it to the RP's specified redirect URI (redirect_uri).

• Content: Primarily the id_token JWT.
• Verification: The RP must validate the JWT signature using keys from the DID Document, check the nonce, audience, and expiration, and ensure the iss and sub are the same DID.

A Verifiable Presentation is an optional, advanced component where the user presents cryptographically verifiable credentials (VCs) alongside or within the SIOP flow. This enables attribute sharing and zero-knowledge proofs.

• Use Case: Proving age, membership, or accreditation without revealing the underlying credential data.
• Standards: Often implemented using OpenID for Verifiable Credentials (OID4VC) or W3C Verifiable Presentations alongside the core SIOP protocol.

The User Agent or Identity Wallet is the software component under the user's control that manages DIDs, private keys, and credentials. It facilitates the SIOP flow by:

• Storing Keys: Securely holds the private keys for signing.
• Processing Requests: Intercepts SIOP authentication requests (e.g., via QR code or deep link).
• Creating Responses: Generates and signs the Self-Issued ID Token and any Verifiable Presentations.
• User Consent: Presents an interface for the user to review and approve the authentication.

SIOP enables passwordless authentication where users sign in to websites and applications using a cryptographic key pair stored in their own wallet, instead of a traditional username/password or a social login from a centralized provider (e.g., "Sign in with Google"). This eliminates reliance on third-party identity providers and associated data collection.

• User Flow: The service requests a Verifiable Presentation. The user's wallet creates and signs a SIOP Response (a JWT) proving control of a Decentralized Identifier (DID).
• Key Benefit: Reduces phishing risk and gives users a single, portable identity across compatible services.

A core use case is proving specific claims from a Verifiable Credential (VC) without revealing the entire document or the underlying identifier. SIOP acts as the presentation layer for W3C Verifiable Credentials.

• Example: Proving you are over 21 by presenting a cryptographic proof of your birth date from a digital driver's license, without revealing your name, address, or exact birth date.
• Mechanism: The Relying Party requests specific claims. The user's wallet uses BBS+ signatures or Zero-Knowledge Proofs (ZKPs) to generate a Verifiable Presentation that satisfies the request, shared via a SIOP response.

SIOP enables the creation of a user-owned, lifelong learning or career record. Institutions issue Verifiable Credentials (e.g., diplomas, certifications, badges) to a user's DID. The user can then present proof of these credentials to employers, other schools, or platforms anywhere SIOP is supported.

• Interoperability: Breaks down data silos between organizations.
• User Control: Individuals manage their own credential portfolio, deciding when and with whom to share it, reducing verification fraud and administrative overhead.

In DeFi, SIOP can link a cryptographic identity (DID) to a wallet address to enable sybil-resistant governance, credit scoring, and compliant access without KYC'ing the entire wallet history.

• Governance: Prove unique personhood (e.g., via a Proof of Humanity credential) to receive one voting token, preventing whale manipulation.
• Under-Collateralized Lending: Present verifiable, off-chain income or credit history to a lending protocol to secure a loan.
• Compliance: Share a KYC/AML Verifiable Credential from a regulated provider to access advanced features, without the dApp ever seeing the raw personal data.

SIOP provides a framework for devices and software agents to have their own DIDs and authenticate to networks or other machines autonomously and securely. This is critical for scalable Internet of Things (IoT) and autonomous system ecosystems.

• Device Identity: A manufacturing robot can have a DID with credentials attesting to its model, maintenance history, and compliance certifications.
• Secure Communication: Devices can establish mutually authenticated, encrypted channels by proving control of their DIDs via SIOP, replacing brittle certificate management systems.

Governments and international bodies are exploring SIOP and Verifiable Credentials as a standard for issuing digital versions of passports, visas, and tax documents. This gives citizens a sovereign identity they can use globally.

• eIDAS 2.0: The EU's updated electronic identification regulation is built on these principles, aiming for a European Digital Identity Wallet.
• Travel: Present a verifiable digital visa and passport credential at an e-gate, streamlining border control while enhancing privacy and security compared to physical documents.

The core security of SIOP relies on the cryptographic binding between a Decentralized Identifier (DID) and its associated public key. The user proves control of the DID by signing the SIOP request with the corresponding private key. This eliminates reliance on a centralized identity provider and establishes a cryptographically verifiable link between the user and their identity assertion.

SIOP, especially when paired with Verifiable Credentials (VCs), enables privacy-by-design through selective disclosure. Instead of presenting an entire identity document, users can present:

• Cryptographic proofs (e.g., zero-knowledge proofs) that they are over 18 without revealing their birthdate.
• Specific, attested claims from a VC without exposing the credential's full content. This minimizes data exposure and limits correlation across different services.

SIOP implementations incorporate several mechanisms to prevent common attacks:

• Nonce and State Parameters: The Relying Party (RP) provides unique, single-use values (nonce, state) that must be included in the signed response, preventing replay attacks.
• Audience Restriction: The SIOP response is explicitly signed for the intended RP's DID or URL, preventing a malicious site from using a response generated for another.
• User-Agent Guidance: Best practices recommend user-agent-based protections to prevent malicious JavaScript from silently intercepting and signing requests.

Security shifts from the provider to the user, making key management the critical vulnerability. Considerations include:

• Private Key Custody: Loss or compromise of the private key means loss of identity. Users must employ secure storage (hardware wallets, secure enclaves).
• Key Rotation & Recovery: DID methods must support secure key rotation protocols. Recovery mechanisms (e.g., social recovery, backup shards) are essential to prevent permanent lockout.
• Signing Context Awareness: Wallets/SIOP clients must clearly display the RP's identity and the data being signed to prevent unauthorized consent.

When presenting Verifiable Credentials, SIOP ensures the integrity of the entire presentation. The user creates a Verifiable Presentation—a wrapper for one or more VCs—and signs it with their DID key. This signature proves:

• The credentials were presented by their legitimate holder.
• The credentials have not been tampered with since issuance.
• The specific combination of claims disclosed was authorized by the presenter.

The Relying Party's (RP) security duty is to properly verify the SIOP response. This involves:

• DID Resolution: Fetching the user's DID Document from the appropriate decentralized ledger or network to obtain the current public key for signature verification.
• Proof Type Validation: Ensuring the cryptographic proof (e.g., JsonWebSignature2020) in the response is supported and valid.
• Claim Verification: If VCs are presented, the RP must also verify the credentials' signatures against the Issuer's DID and check for revocation status.

In the SIOP model, the Holder is the end-user who controls their identity. The Wallet (or Identity Wallet) is the software component, often a mobile app, that:

• Generates and stores the user's private keys and DIDs.
• Creates and signs the self-issued ID Token during an authentication request.
• Manages the user's Verifiable Credentials. The wallet is the critical user-agent that enables the "self-issued" aspect of the protocol, putting the user in control of their authentication secrets.

JSON Web Tokens (JWTs) are the compact, URL-safe token format used by SIOP to convey claims. The Self-Issued ID Token is a specific type of JWT with required claims like iss (issuer, set to the user's DID), sub (subject, also the DID), and aud (audience, the Relying Party). The token is signed using the JSON Web Signature (JWS) standard with the private key corresponding to the DID, allowing any verifier to check its authenticity using the public key in the DID Document.

The Relying Party (RP), also called the Verifier, is the website or application that requests authentication from a user via SIOP. Its role is to:

• Initiate the flow by presenting an OpenID Connect authentication request.
• Receive and validate the self-issued ID Token.
• Verify the token's cryptographic signature by resolving the user's DID to their DID Document.
• Establish a secure session for the user. The RP does not need to know the user beforehand; it trusts the cryptographic proof provided by the token.