Decentralized Identifier (DID)

A Decentralized Identifier (DID) is controlled solely by its subject (e.g., a person, organization, or device), not by a central registry, identity provider, or certificate authority. This shifts control from centralized entities to the user, enabling self-sovereign identity. The DID's creation, usage, and revocation do not require permission from a third party.

DIDs are designed to be persistent—they remain stable over time without relying on a continuously available service. Their authenticity is established through cryptographic proof, typically using public-key infrastructure. A DID Document contains public keys and service endpoints, allowing any party to cryptographically verify interactions with the DID's controller.

Every DID resolves to a unique DID Document, a JSON-LD document describing the subject. This document is the core of the DID system and contains:

• Public keys for authentication and encryption
• Service endpoints for interacting with the subject (e.g., a messaging service)
• Protocols and other metadata Resolution is performed by a DID method, a mechanism for creating, reading, updating, and deactivating DIDs on a specific verifiable data registry (like a blockchain).

The DID specification is method-agnostic. The core did: scheme (e.g., did:ethr:..., did:key:...) is separated from the DID method, which defines the operations for a specific underlying ledger or network. This allows the same principles to be implemented across diverse systems:

• Blockchain-based: did:ethr (Ethereum), did:sov (Sovrin)
• Peer-to-Peer: did:peer (direct connections)
• Web-based: did:web (HTTPS URLs)

DIDs support privacy-preserving interactions through several mechanisms. Users can generate different, unlinkable DIDs for different contexts (pairwise pseudonymous DIDs) to prevent correlation. Zero-knowledge proofs can be used with verifiable credentials to prove claims (e.g., age > 21) without revealing the underlying DID or additional personal data. Control over disclosure is held by the user.

The primary use case for DIDs. A Verifiable Credential is a tamper-evident, cryptographically signed claim (like a diploma or license) issued by one DID holder to another. Zero-Knowledge Proofs can enable selective disclosure.

• Standard: W3C Verifiable Credentials Data Model.
• Flow: Issuer → Holder → Verifier, with DIDs providing the trust anchor.
• Example: A digital driver's license issued by a DMV (did:web:dmv.gov).

A Decentralized Identifier (DID) is a URI that points to a DID Document, a JSON-LD file stored on a verifiable data registry like a blockchain. This document contains public keys, authentication protocols, and service endpoints that allow the DID controller to prove ownership and interact with services. The blockchain provides a tamper-proof anchor for the document's location and integrity, without storing personal data on-chain.

DIDs enable cryptographic authentication for blockchain transactions and smart contract interactions. Instead of using a raw wallet address, a user can sign a message or transaction with the private key linked to their DID. This allows dApps to verify:

• The signer's persistent, reusable identity.
• Selective disclosure of attributes via Verifiable Credentials.
• Compliance with sign-in with Ethereum (SIWE) and other emerging standards for web3 login.

In decentralized finance, DIDs anchor soulbound tokens (SBTs) and Verifiable Credentials that represent credit history, KYC status, or proof of income. This enables:

• Under-collateralized lending: Protocols can assess borrower risk based on attested, on-chain reputation.
• Sybil resistance: DIDs help prove unique personhood, preventing manipulation of governance or airdrop systems.
• Portable credit scores: Users can build a reusable financial identity across multiple protocols without re-submitting personal data.

DIDs are critical for managing identity and permissions within DAOs. They enable:

• Verified membership: Linking a unique human identity to a governance wallet to prevent sybil attacks.
• Role-based access: Assigning permissions (e.g., treasurer, contributor) via verifiable credentials tied to a DID.
• Reputation systems: Building transparent, portable reputation scores that travel with the member's DID across different DAOs and platforms.

DIDs provide verifiable identities for entities in a supply chain (manufacturers, shippers, certifiers). Each participant can issue tamper-evident Verifiable Credentials about a product's origin, handling, or quality. These credentials are linked to the physical asset via a digital twin (e.g., an NFT), creating an immutable, auditable history from source to consumer, all verifiable through the participants' DIDs.

Interoperability is driven by W3C standards and blockchain-specific methods:

• W3C DID Core: The foundational standard defining the DID syntax and data model.
• Verifiable Credentials (VCs): The standard for cryptographically signed attestations linked to a DID.
• did:ethr & did:pkh: Common DID methods for Ethereum and blockchain public key hashes.
• EIP-4361 (Sign-In with Ethereum): A specification using DIDs for secure, self-custodied authentication.

A Decentralized Identifier (DID) enables self-sovereign identity, where the user holds the cryptographic keys and controls what personal data is shared. This is a fundamental shift from centralized models where third-party providers (like social media platforms) own and manage identity data. Users present verifiable credentials (VCs) directly from their digital wallet, sharing only the specific, necessary claims (e.g., "over 21") without revealing the underlying DID or other personal information.

Security is rooted in public-key cryptography. A DID document, resolved from the DID's URI, contains the public keys and service endpoints. Authentication and data integrity are proven via digital signatures, eliminating reliance on vulnerable password databases. Verifiers can cryptographically check that a credential: 1) was issued by a trusted entity, 2) is bound to the presenter's DID, and 3) has not been tampered with, all without contacting the issuer after initial setup.

DID ecosystems employ advanced techniques to prevent correlation and protect user privacy. Zero-Knowledge Proofs (ZKPs) allow a user to prove a claim (e.g., citizenship) without revealing the specific credential or identifier. Pairwise Pseudonymous DIDs enable creating unique, unlinkable DIDs for different relationships, preventing service providers from colluding to build a profile. Selective disclosure lets users reveal only subsets of information from a credential.

The primary security risk shifts from server breaches to private key management. Loss of keys means permanent loss of the DID and associated credentials. Solutions include:

• Social Recovery: Using a trusted group to restore access.
• Hardware Security Modules (HSMs): Storing keys in secure, tamper-resistant hardware.
• Decentralized Key Management Services (DKMS): Using blockchain smart contracts for recovery logic. The trade-off between security, usability, and decentralization is a critical design challenge.

By anchoring DIDs on decentralized systems like blockchains or peer-to-peer networks, they resist unilateral control or censorship by any single entity. No central authority can arbitrarily revoke or disable a globally valid DID. However, the chosen Verifiable Data Registry (e.g., a specific blockchain) introduces its own considerations: transaction costs, network uptime, governance models, and the permanence of the DID document's on-chain footprint, which may conflict with "right to be forgotten" regulations.

A Verifiable Credential is a tamper-evident digital claim, such as a driver's license or university degree, issued by an authority. It is cryptographically signed and can be presented by the holder to a verifier. VCs are the primary data format exchanged using DIDs, enabling trustless proof of attributes.

• Structure: Follows the W3C VC Data Model.
• Key Property: The credential is cryptographically bound to the DID of the holder.

A DID Method is a specification defining how a specific type of DID is created, resolved, updated, and deactivated on a particular verifiable data registry (like a blockchain). It's the implementation layer of the DID standard.

• Examples: did:ethr: (Ethereum), did:key: (public key), did:web: (web domains).
• Role: Each method specifies the precise operations for its underlying ledger or system.

A Verifiable Data Registry is the decentralized system that acts as the trusted root for DIDs and their associated public keys. It provides the necessary data for DID resolution. Blockchains (e.g., Ethereum, Bitcoin) are the most common type, but other systems like distributed file systems can also serve this role.

• Core Function: Stores the DID Document and its updates.
• Key Property: Ensures the integrity and availability of the DID's control proofs.

Self-Sovereign Identity is the overarching philosophy and architecture where individuals and organizations have exclusive ownership and control over their digital identities without relying on centralized authorities. DIDs and VCs are the fundamental technical components that make SSI possible.

• Core Principles: User control, portability, interoperability, and consent.
• Contrast: Moves away from siloed, platform-specific logins (e.g., "Login with Google").

A DID Document is a JSON-LD document containing the public keys, authentication protocols, and service endpoints associated with a specific DID. It is the machine-readable resource returned when a DID is resolved from a verifiable data registry.

• Contents: Includes publicKey, authentication, assertionMethod, and service entries.
• Purpose: Enables cryptographic verification of interactions with the DID subject.

A Decentralized Web Node is a personal data store protocol, often associated with DIDs, that allows entities to store and message encrypted data. It acts as a user-controlled endpoint referenced in a DID Document's service section, enabling decentralized communication and data exchange.

• Function: Hosts private data and facilitates secure, peer-to-peer messages.
• Example: Used in protocols like the Identity Overlay Network (ION) for Bitcoin.