DID AuthN

Users create and control their own Decentralized Identifiers (DIDs) without relying on a central registry, certificate authority, or identity provider. This shifts control from institutions to the individual, enabling self-sovereign identity.

• No Central Point of Failure: Identity verification isn't dependent on a single company's servers.
• User-Centric Control: Individuals manage their keys and decide with whom to share credentials.

Authentication is achieved by cryptographically proving control of the private key associated with a DID. This is typically done by signing a challenge (a random nonce) with the private key, which can be verified by the public key listed in the DID's DID Document.

• Method-Agnostic: Works with various cryptographic suites (e.g., Ed25519, secp256k1).
• Verifiable Proof: The verifier can independently confirm the signature without querying a third party.

DID AuthN is the foundation for presenting Verifiable Credentials (VCs). A user can authenticate and then share a Verifiable Presentation—a cryptographically signed package of credentials—proving attributes like age or membership.

• Selective Disclosure: Users can reveal only specific claims from a credential.
• Tamper-Evident: Any alteration to the presented data invalidates the cryptographic proof.

DID AuthN is built on W3C standards (DID Core, Verifiable Credentials), ensuring interoperability across different networks and systems. Protocols like DIDComm and SIOPv2 (Self-Issued OpenID Connect Provider) define how authentication messages are structured and exchanged.

• Vendor-Neutral: Avoids lock-in to specific platforms or blockchains.
• Universal Framework: Provides a common language for decentralized identity across the web.

The architecture minimizes data exposure. Pairwise DIDs allow a user to use a unique DID for each relationship, preventing correlation across different services. Zero-Knowledge Proofs (ZKPs) can be integrated to prove a claim (e.g., 'over 21') without revealing the underlying data.

• Minimal Disclosure: Share only what is necessary for the transaction.
• Unlinkability: Different interactions cannot be easily linked back to the same identity.

While not all DIDs are on a blockchain, many implementations use decentralized ledgers (e.g., Ethereum, Sovrin, ION) as a verifiable data registry to anchor DID Documents. The ledger provides a global, immutable root of trust for resolving a DID to its public keys and service endpoints.

• Immutable Anchoring: The DID Document's fingerprint is recorded on-chain.
• Permissionless Resolution: Anyone can resolve the DID without special access.

Two simple, widely implemented DID methods for AuthN.

• did:key: A lightweight method where the DID itself is a direct encoding of a public key (e.g., did:key:z6Mk...). Perfect for ephemeral sessions or simple key-based authentication without a registry.
• did:web: Allows a DID to be resolved via a HTTPS endpoint you control (e.g., did:web:example.com). The DID Document is hosted as a JSON file at a well-known URL. This is commonly used for early prototyping and organizational DIDs.

Advanced AuthN using Zero-Knowledge Proofs (ZKPs) or BBS+ Signatures. A user can prove a claim from a Verifiable Credential without revealing the entire credential. Example: Proving you are over 21 from a driver's license credential, without revealing your name, address, or exact birth date.

• Cryptographic Suite: BbsBlsSignature2020 enables this selective disclosure.
• Use Case: Privacy-preserving access to age-gated services or KYC checks where minimal data disclosure is required.

Authentication within secure, encrypted peer-to-peer messaging channels established using DIDs. Used in mobile agent-to-agent frameworks. Flow:

1. Two agents exchange their DID Documents to establish a peer DID and an encrypted channel using DIDComm.
2. Authentication happens through challenge-response protocols sent over this private channel.
3. This is foundational for decentralized web of trust models and secure IoT device handshakes, where there is no central server.

The foundation of DID AuthN's privacy. Users present Verifiable Credentials (VCs) issued by trusted entities, but can use Zero-Knowledge Proofs (ZKPs) or BBS+ signatures to prove specific claims (e.g., 'over 21') without revealing the underlying credential data. This minimizes data exposure and prevents correlation across services.

DID AuthN replaces traditional Certificate Authorities with DPKI. A user's public keys are anchored to their DID on a verifiable data registry (like a blockchain). Security relies on:

• Key Rotation: Ability to revoke compromised keys and add new ones to the DID Document.
• Proof of Control: Authentication proves control of the private key corresponding to the public key listed in the DID Document.

Robust DID AuthN protocols defend against common attacks:

• Challenge-Response: Relying parties send a unique, time-bound nonce to sign, preventing replay.
• DID Method-Specific Risks: Some DID methods (e.g., did:web) may be vulnerable to DNS hijacking, while others (e.g., did:ethr) inherit blockchain security.
• Presentation Binding: VCs are cryptographically bound to the specific DID session.

Decentralization does not guarantee anonymity. Key privacy challenges include:

• DID as a Correlation Handle: Reusing the same DID across contexts creates a persistent identifier.
• On-Chain Metadata: For blockchain-anchored DIDs, transaction patterns and timing can leak identity.
• Solution: Use pairwise-unique DIDs (a unique DID for each relationship) and private credential presentations to break linkability.

User-controlled identity shifts security burdens. Critical considerations are:

• Revocation Mechanisms: Status lists, cryptographic accumulators, or smart contracts must be checked by verifiers.
• Private Key Custody: Loss of keys means loss of identity. Decentralized Key Management Systems (DKMS) and social recovery models are essential.
• Accountability: Decentralized revocation can be slower than centralized invalidation.

Security depends on standardized, audited protocols. The core standards are:

• W3C DID Core: Defines the DID data model and operations.
• OIDC SIOPv2: Enables DID-based login for existing OAuth2/OpenID Connect ecosystems.
• W3C Verifiable Credentials Data Model: Ensures credential integrity and proof formats.
• Implementation Flaws: Ad-hoc implementations risk vulnerabilities; adherence to specs is critical.

DID AuthN is the first step in presenting Verifiable Credentials (VCs). A user authenticates with their DID, then selectively discloses cryptographically signed claims (like a KYC attestation or diploma) to a verifier. This enables:

• Trust minimization: Verifiers check proofs against the issuer's DID on a ledger.
• User sovereignty: Individuals control what data is shared and with whom.
• Composable identity: Credentials from multiple issuers can be combined for complex proofs.

DAOs use DID AuthN for granular, Sybil-resistant governance. By linking a unique, proven identity to voting power, it prevents ballot-stuffing and enables:

• One-person-one-vote systems: Based on proven unique humanity (e.g., via proof-of-personhood credentials).
• Delegated voting: Trusted delegates can be authorized to vote on a user's behalf.
• Transparent participation: All actions are auditably linked to a persistent, non-transferable identity.

DID AuthN enables fine-grained access control for smart contracts, APIs, and cloud resources. Using capability-based security models, a DID can grant temporary, revocable permissions. Examples include:

• Smart contract functions: Authorizing a specific wallet to execute a privileged function.
• API gateways: Using a DID-signed token instead of an API key.
• Delegated asset management: Granting a trading bot limited rights to a wallet without exposing private keys.

A single DID can be used to authenticate across different blockchains and traditional web platforms, creating a unified digital identity layer. This interoperability is achieved through:

• Universal Resolvers: Systems that can resolve DIDs from different methods (e.g., did:ethr, did:key).
• Bridge Protocols: Services that translate authentication proofs between ecosystems.
• Standardized Protocols: Adherence to W3C DID Core and Decentralized Web Node (DWN) specifications.

DID AuthN provides a foundational layer for compliant interactions in regulated industries like DeFi and gaming. It enables services to implement Know Your Customer (KYC) and Anti-Money Laundering (AML) checks without central data silos. Key mechanisms:

• Zero-Knowledge Proofs: Proving regulatory compliance (e.g., citizenship, accreditation) without revealing underlying data.
• Audit Trails: All authentication events are immutably linked to a DID, creating a non-repudiable log.
• Travel Rule Compliance: VCs can attest to sender/receiver identity for cross-border transactions.