Glossary

Decentralized Identity (DID)

Decentralized identity is a self-sovereign framework where individuals control their own digital identity without relying on centralized authorities.

Key Takeaways

  • Decentralized identifiers (DIDs) are globally unique, self-owned identifiers standardized by the W3C. Unlike usernames or email addresses, DIDs are not issued or controlled by any central authority: the subject generates their own private key and registers the identifier directly.
  • The DID stack includes DID documents (which map identifiers to public keys and service endpoints) and verifiable credentials (digital attestations that can be cryptographically proven without contacting the issuer). Together they enable portable, privacy-preserving identity across services.
  • In crypto, decentralized identity powers KYC credential reuse across exchanges, reputation systems in DeFi, and passwordless login using passkeys or blockchain key pairs: reducing friction while keeping users in control of their data.

What Is Decentralized Identity?

Decentralized identity (sometimes called self-sovereign identity or SSI) is a framework that lets individuals and organizations create, own, and manage their digital identities without depending on a centralized registry or certificate authority. The core building block is the decentralized identifier (DID): a string that resolves to a DID document containing public keys, authentication methods, and service endpoints.

The W3C finalized the DID Core 1.0 specification as a formal Recommendation in July 2022, establishing a universal syntax and data model. A DID looks like this:

did:method:method-specific-identifier

// Examples:
did:web:example.com
did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK
did:ion:EiClkZMDxPKqC9c-umQfTkR8vvZ9JPhl_xLDI9Nfk38w5w
did:pkh:eip155:1:0xab16a96D359eC26a11e2C2b3d8f8B8942d5Bfcdb

The format follows the pattern did:method:identifier, where the method specifies how the DID is created, resolved, and updated. Each method defines its own rules for anchoring identifiers: some use blockchains, others use web infrastructure, and some require no external system at all.

Traditional digital identity relies on centralized providers. Your Google account, your government ID number, your bank login: all are issued and controlled by institutions that can revoke access, change terms, or suffer data breaches. Decentralized identity inverts this model. You generate a cryptographic key pair, derive your identifier from it, and selectively disclose credentials to verifiers without exposing underlying data.

How It Works

The decentralized identity stack has three layers: identifiers (DIDs), documents (DID documents), and attestations (verifiable credentials). Each layer builds on the one below it.

DID Documents

When a DID is resolved, it returns a DID document: a JSON-LD structure describing the subject's public keys, authentication mechanisms, and service endpoints. This is the digital equivalent of a phone book entry, except the subject controls it.

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:example:123456789abcdefghi",
  "authentication": [{
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "Ed25519VerificationKey2020",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyMultibase": "z6Mkf5rGMoatrSj1f..."
  }],
  "service": [{
    "id": "did:example:123456789abcdefghi#messaging",
    "type": "MessagingService",
    "serviceEndpoint": "https://example.com/messages"
  }]
}

The document declares what keys can authenticate as the DID subject, what keys can sign assertions, and where to reach the subject's services. Crucially, the document itself contains no private data: it is a public directory of capabilities.

Verifiable Credentials

A verifiable credential (VC) is a tamper-evident digital attestation issued by one party about another. The W3C finalized the Verifiable Credentials Data Model 2.0 as a Recommendation in May 2025, alongside specifications for data integrity cryptosuites, JOSE/COSE securing, and status lists.

The VC model involves three roles:

  1. Issuer: the entity that creates and signs the credential (a university, a government agency, a KYC provider)
  2. Holder: the subject who stores the credential in their digital wallet and decides when to present it
  3. Verifier: the entity that checks the credential's signature and validity without contacting the issuer

This triangle eliminates the need for real-time lookups against a central database. A verifier can confirm a credential is authentic by checking the issuer's DID and validating the digital signature: no API call, no data sharing with the issuer.

DID Methods

A DID method defines how identifiers are created, resolved, updated, and deactivated on a specific infrastructure. The W3C maintains a registry of methods, and a draft charter for a dedicated DID Methods Working Group proposes standardizing methods across three categories:

  • Ephemeral methods: did:key encodes a public key directly in the identifier. No registration or blockchain needed. Useful for temporary sessions and testing.
  • Web-based methods: did:web resolves DIDs through standard HTTPS endpoints, using DNS as the trust anchor. did:webvh adds verifiable history to web-based DIDs.
  • Blockchain-anchored methods: did:ion (Microsoft's Sidetree protocol on Bitcoin), did:ethr (Ethereum), and did:pkh (derives DIDs from any blockchain address) anchor identifiers to distributed ledgers for maximum censorship resistance.

The choice of method involves tradeoffs between decentralization, cost, speed, and privacy. Blockchain-anchored methods provide the strongest guarantees against censorship but incur transaction fees for updates. Web-based methods are free and fast but inherit DNS's centralization risks.

DID Resolution

Resolution is the process of taking a DID string and returning its DID document. The W3C is actively developing the DID Resolution specification (v0.3 as a Working Draft published in June 2026), which defines standard algorithms for resolving DIDs and dereferencing DID URLs.

Resolution works differently for each method. For did:web, the resolver fetches a JSON document from a well-known HTTPS endpoint. For did:ion, the resolver reads Bitcoin transactions and reconstructs the DID's state from Sidetree operations anchored in the chain. For did:key, the resolver simply decodes the public key embedded in the identifier itself: no network request required.

Use Cases in Crypto

KYC Credential Reuse

Today, every exchange and financial service runs its own KYC process. Users submit passports, selfies, and proof of address repeatedly. Decentralized identity enables a different model: complete KYC once with a trusted provider, receive a verifiable credential, then present that credential to any service that accepts it.

The verifier checks the credential's cryptographic signature against the issuer's DID without seeing the raw identity documents. This reduces data exposure (fewer copies of your passport floating around) while meeting regulatory requirements. Several jurisdictions are exploring frameworks for portable KYC credentials, including the EU's eIDAS 2.0 regulation which mandates European Digital Identity Wallets for all EU citizens.

Reputation in DeFi

DeFi protocols currently treat every wallet as anonymous and interchangeable, requiring full overcollateralization because there is no way to assess creditworthiness. Decentralized identity changes this by linking on-chain history to verifiable credentials.

A DeFi borrower could present credentials proving a history of successful loan repayments, verified asset holdings, or even traditional credit scores: all without revealing their real-world identity. Soulbound tokens (non- transferable NFTs bound to a wallet) represent an early on-chain approach to reputation, but verifiable credentials offer richer data and selective disclosure through zero-knowledge proofs.

Passwordless Authentication

DIDs enable login without passwords or centralized OAuth providers. Instead of "Sign in with Google," a user presents a DID and proves control of the associated private key. The service verifies the signature and grants access without ever seeing a password, and without Google acting as an intermediary.

This model pairs naturally with WebAuthn passkeys, where biometric authentication on a device produces a cryptographic proof. Combined with DIDs, passkeys can provide both device-level security and portable, cross-service identity.

Bitcoin and Nostr Implementations

Bitcoin-adjacent ecosystems have developed their own approaches to decentralized identity. The did:ion method, developed by Microsoft, anchors DID operations to the Bitcoin blockchain using the Sidetree protocol. It batches thousands of DID operations into a single Bitcoin transaction, keeping costs low while inheriting Bitcoin's censorship resistance.

Nostr, the decentralized social protocol, uses secp256k1 key pairs (the same curve as Bitcoin) for identity. Every Nostr user is identified by their public key (displayed as an npub address), and NIP-05 provides human-readable verification by linking keys to domain names. While not formally a W3C DID method, Nostr's identity model shares the same principles: self-custody of keys, no central registry, and cryptographic proof of ownership. Proposals for a did:nostr method have been discussed in the community to bridge Nostr identity with the broader DID ecosystem. For more on how Nostr intersects with Bitcoin identity, see the Nostr, Bitcoin identity, and payments research article.

Comparison with Traditional Identity

FeatureTraditional (OAuth, Government ID)Decentralized Identity (DID)
IssuerCentral authority (government, corporation)Self-issued or any trusted entity
ControlProvider can revoke or modifySubject holds keys and controls access
PortabilityLocked to issuing platformWorks across any service that supports DIDs
PrivacyProvider sees all authentication eventsSelective disclosure via ZK proofs
Single point of failureYes (provider outage or breach)No (keys are self-managed)
RecoveryPassword reset via providerKey recovery (social recovery, backups)
Verification costAPI call to identity provider per requestCryptographic check (offline capable)

The key tradeoff is responsibility. Traditional identity offloads key management to providers (who can be hacked, censored, or shut down). Decentralized identity puts the user in control but requires them to manage cryptographic keys securely: a challenge that wallet infrastructure like MPC wallets and social recovery aim to solve.

Risks and Considerations

Key Management Burden

Without a central password reset mechanism, losing control of a DID's private key means losing the identity. Key rotation (updating the DID document with new keys) mitigates compromise but requires the old key to still be accessible. This shifts the security burden from institutions to individuals, which improves sovereignty but introduces new failure modes.

Method Fragmentation

Over 150 DID methods have been registered, but most see little adoption. Interoperability between methods is limited: a verifier that supports did:web may not support did:ion. The W3C's proposed DID Methods Working Group aims to standardize a smaller set of methods (including did:key, did:web, and did:webvh), but consensus on which methods to endorse remains an open challenge. Google and Mozilla raised formal objections when DID Core 1.0 advanced without standardized methods, and that gap persists.

Adoption Chicken-and-Egg

Decentralized identity delivers the most value when many services accept the same credentials. But services have little incentive to support DIDs until users carry them, and users have little reason to obtain DID-based credentials until services accept them. Government mandates (like the EU's eIDAS 2.0) may help break this cycle by requiring support for digital identity wallets.

Privacy Tradeoffs

Blockchain-anchored DIDs create a permanent public record of identity operations. While the DID document itself may not contain personal data, correlation across services remains possible if the same DID is reused everywhere. Best practices recommend using different DIDs for different contexts (pairwise DIDs) and leveraging zero-knowledge proofs for selective credential disclosure: proving you are over 18 without revealing your birthdate, for example.

Regulatory Uncertainty

Identity regulation varies dramatically across jurisdictions. A verifiable credential issued in one country may not satisfy compliance requirements in another. The interaction between decentralized identity and existing KYC/AML frameworks is still being worked out, with regulators cautious about accepting credentials they do not control.

Why It Matters for Bitcoin and Payments

As self-custodial Bitcoin and stablecoin payments grow, decentralized identity becomes critical infrastructure. Platforms building on Bitcoin layers need ways to verify users for compliance without centralizing sensitive data. Decentralized identity offers a path: users prove attributes through verifiable credentials while keeping their keys and data under their own control.

For payment networks, DID-based identity can streamline onboarding, reduce duplicative KYC processes, and enable reputation-based trust: all while preserving the self-sovereign ethos that Bitcoin was built on. The convergence of elliptic curve cryptography, verifiable credentials, and blockchain infrastructure makes decentralized identity a natural complement to decentralized finance.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.