Decentralized Identifiers (DIDs)

What are DIDs?

Decentralized Identifiers (DIDs) are globally unique identifiers that enable verifiable, self-sovereign digital identity. Unlike traditional identifiers (email addresses, usernames, government IDs), DIDs are:

Decentralized (no central authority)
Persistent (indefinite existence)
Resolvable (discoverable metadata)
Cryptographically verifiable

Why DIDs Matter

Traditional identifiers are controlled by third parties (email providers, social media companies, governments, domain registrars), creating:

Single points of failure
Censorship risks
Privacy concerns
Vendor lock-in
Siloed identity

DIDs solve these problems by giving entities direct control over their identifiers while enabling cryptographic verification.

DID Architecture

DID Syntax

A DID is a simple text string consisting of three parts, separated by colons:

did:example:123456789abcdefghi

Scheme: Always “did”, identifying the string as a Decentralized Identifier
Method: Specifies which DID method is used (e.g., “example”, “key”, “web”, “eth”)
Method-Specific Identifier: A unique identifier within the namespace of the specific method

Each DID method defines how DIDs are created, resolved, updated, and deactivated on a specific system (such as a distributed ledger, decentralized file system, or secure database).

DID Documents

When resolved, a DID points to a DID document containing metadata: verification methods (public keys), authentication mechanisms (proof of control), and service endpoints (associated services).

{
    "@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": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
        }
    ],
    "service": [
        {
            "id": "did:example:123456789abcdefghi#vcs",
            "type": "VerifiableCredentialService",
            "serviceEndpoint": "https://example.com/vc/"
        }
    ]
}

DID Subject: Entity identified by the DID DID Controller: Entity able to change the DID document Verifier: Entity that receives and verifies credentials

Often the subject and controller are the same entity, but can differ (e.g., parent managing child’s DID).

Benefits

User Control: Direct control over identifiers. Create multiple DIDs for different contexts. Update documents. Manage services and verification methods.

Privacy: Pairwise DIDs prevent correlation. Selective disclosure reveals only necessary information. Minimal data in documents. Cryptographic verification without exposing private keys.

Security: Distributed systems increase resilience. Cryptographic proof via public-key cryptography. Key rotation for compromised keys.

Interoperability: W3C standard enables different methods to work together. Consistent verification across platforms. Portable identity.

Persistence: DIDs don’t depend on specific companies. Can be maintained indefinitely. Resilient to technology changes.

Further Resources

W3C DID Core Specification