Authentication Request

Self-Issued OpenID Connect Provider v2 (SIOPv2) is a core standard for decentralized identity. It defines how a Relying Party (RP) requests a Verifiable Presentation from a user's wallet. The request is a JSON object specifying:

• client_id: The identifier of the requesting service.
• response_type: Typically id_token.
• scope: Requested claims (e.g., openid, did_authn).
• nonce: A cryptographic challenge for replay protection. This standard extends traditional OAuth 2.0/OpenID Connect for a user-centric, wallet-based model.

A Presentation Definition is a format created by the Decentralized Identity Foundation (DIF) to specify the exact Verifiable Credentials a verifier requires. It's a JSON schema that defines:

• Input Descriptors: The types of credentials needed.
• Constraints: Specific fields, schema URIs, or issuers.
• Format Requirements: Supported proof types (e.g., jwt_vc, ldp_vc). This allows a Holder (user wallet) to selectively disclose credentials that satisfy the verifier's policy, enabling complex, conditional authentication requests.

The W3C Verifiable Credentials specification implies a request format where a Verifier asks a Holder for a credential presentation. While less rigidly defined, the request typically includes:

• challenge: A nonce to prevent replay attacks.
• domain: The verifier's context.
• presentation_definition: A reference to or embedding of a DIF Presentation Definition. The holder responds with a Verifiable Presentation, a wrapper for one or more credentials containing proofs that satisfy the request's constraints.

The primary function is to establish a secure, verifiable link between a user and an application. The standard flow is:

• dApp Generates: Creates a structured message (e.g., "Sign in to example.com at 12:00 UTC").
• Wallet Presents: Displays the request to the user for review and approval.
• User Signs: The user cryptographically signs the message with their private key.
• dApp Verifies: The application verifies the signature against the user's public address to authenticate the session.

Authentication Requests are a critical defense against phishing. Key security features include:

• Domain Binding: The signed message is explicitly tied to a specific domain (example.com). A signature cannot be replayed on evil-site.com.
• User Visibility: Wallets clearly display the full request, allowing users to verify the domain, statement, and requested permissions before signing.
• Nonce Management: Servers track used nonces to ensure a single signature cannot be reused, preventing replay attacks.
• Expiration: Time-bound validity limits the window for potential misuse.

While foundational for login, the pattern extends to other consent-driven actions:

• Session Keys: Authorizing a temporary key with limited permissions for gasless transactions.
• Delegated Authority: Granting a smart contract or another address the right to act on behalf of the user.
• Proof of Ownership: Verifying control of an asset (like an NFT) or a specific account without exposing private keys.
• Commitment Signatures: Signing an agreement or a hash of data to be revealed later, forming the basis for systems like anonymous credentials.

Wallets like MetaMask, Rainbow, and Coinbase Wallet implement handlers for Authentication Requests. Their role is to:

• Parse the Standard: Recognize requests formatted under SIWE or similar specs.
• Present UI: Render a clear, secure interface showing the request's critical details.
• Manage Signing: Use the wallet's secure signing mechanism (e.g., a hardware wallet, biometrics) to produce the signature.
• Return Result: Send the signature back to the requesting dApp to complete the authentication flow.

Several major protocols utilize authentication requests as a foundational layer:

• OpenSea: Uses SIWE for logging into its marketplace and verifying NFT ownership for listings.
• Uniswap: Integrates wallet authentication for accessing portfolio data and interacting with the protocol interface.
• Ceramic Network: Uses decentralized identity (DID) signatures, a form of authentication request, to manage user data streams.
• Lens Protocol: Social graph interactions and post publications are gated by signatures that authenticate the user's profile NFT.

The fundamental principle is explicit user consent. A well-formed request must clearly disclose:

• The action being requested (e.g., 'Sign this message').
• The scope of access (e.g., 'Read your balance', 'Approve token spend').
• The requesting party (dApp domain or service). Without this, users cannot make informed security decisions, leading to phishing and unauthorized access.

Attackers craft deceptive authentication requests to trick users into signing malicious transactions. Key threats include:

• Address poisoning: Requests that appear benign but contain hidden recipient addresses.
• Permission escalation: Requests for excessive token allowances or blanket smart contract approvals.
• Fake domain spoofing: Requests originating from impersonated dApp frontends. Users must always verify the request origin and payload details.

The request-response process can expose sensitive user data:

• Network metadata: The fact of the request reveals wallet activity and dApp interaction to network observers.
• Public signature correlation: Signing a message with a wallet key can link a user's identity across different services if the signed data is unique.
• Request origin tracking: Centralized relay services that process requests can build profiles of user behavior.

The user's wallet (or agent) is the final gatekeeper. Secure wallets implement:

• Request visualization: Clearly rendering the request's intent, domain, and data before prompting for a signature.
• Domain binding: Validating that the request originates from the domain it claims (e.g., using CORS or Origin headers).
• Transaction simulation: Previewing the outcome of a transaction request to detect unexpected state changes or asset transfers.

Before approving any authentication request, users and developers should verify:

• ✅ Domain: Does the browser URL match the request's domain field?
• ✅ Action: Is the requested action (sign, send, approve) expected?
• ✅ Data: Are all addresses, amounts, and parameters correct and intended?
• ✅ Expiry: Does the request have a valid nonce and expiration to prevent replay?
• ✅ Standard: Is the request using a known, audited standard like SIWE?