did:key vs did:web: Portable Key vs Domain-Verified DID

No external dependencies: No web server, domain, or registry is required for creation or verification. This reduces operational overhead and eliminates a central point of failure, making it perfect for decentralized applications where uptime of a web host cannot be guaranteed.

Resolves to a hosted DID Document: The identity's public keys and service endpoints can be updated by the domain controller. This supports key rotation, service endpoint changes, and protocol upgrades without changing the core DID identifier, crucial for long-lived, managed identities.

Choose did:key when:

• You need maximum decentralization and offline capability.
• Your system is peer-to-peer or operates without internet.
• You are issuing long-term, static identities for devices or data.
• Examples: IoT device IDs, static Verifiable Credentials, DIDComm agents.

Choose did:web when:

• You need a simple, web-integrated identity for your organization.
• You already manage a domain with TLS and can host a JSON file.
• You require the ability to update keys and service endpoints over time.
• Examples: Company-issued employee credentials, university diplomas, OIDC integration.

Self-contained identifier: The DID document is derived directly from the cryptographic key pair, requiring no external resolution. This is critical for offline-first applications and embedded device credentials where network access isn't guaranteed.

No server or domain required: Eliminates the operational overhead and cost of maintaining a web server or DNS record. Ideal for prototyping, client-side wallets, and ephemeral identities where simplicity and speed are paramount.

No key rotation or revocation: The DID is permanently bound to its initial key pair. This is a critical security flaw for long-lived identities, as a compromised key cannot be changed without creating a wholly new DID.

Domain-based verification: Proves control over a specific internet domain (e.g., did:web:example.com). This is essential for organizational identities (like a company issuing verifiable credentials) and establishing trusted, recognizable endpoints.

Supports key rotation & service endpoints: The DID document is hosted at a well-known URL, allowing the controller to update keys and add services (like linked data registries or communication endpoints). Necessary for production systems and evolving user profiles.

Relies on traditional web infrastructure: Depends on DNS and HTTPS, reintroducing points of central failure. The DID becomes unavailable if the domain expires or the server goes down, making it unsuitable for fully decentralized, resilient systems.

Self-contained DID: The entire DID Document is encoded within the DID itself (e.g., did:key:z6Mk...). This eliminates external resolution dependencies, making it perfect for offline-first applications, secure local key generation, and embedding credentials in QR codes. No server or domain required.

Zero-resolution overhead: Since the public key is in the identifier, there's no HTTP fetch to resolve the DID Document. This results in sub-millisecond verification times, ideal for high-throughput, low-latency scenarios like IoT device handshakes or in-memory cryptographic operations within wallets.

No key rotation or service endpoints: A did:key is cryptographically bound to a single key pair. You cannot rotate keys or attach service endpoints (e.g., messaging, storage) without creating a new DID. This makes it unsuitable for long-lived, mutable identities in complex systems.

Leverages existing web trust: The DID is derived from a domain you control (e.g., did:web:example.com). This provides a verifiable link to a real-world entity, making it the standard for organizations, enterprises, and protocols (like the W3C itself) issuing verifiable credentials from a known source.

Full W3C DID Core compliance: Host a complete, mutable DID Document at a well-known URL (/.well-known/did.json). This enables key rotation, service endpoint definitions (for auth, messaging, storage), and integration with the broader Verifiable Credentials ecosystem (e.g., signing with Ed25519Signature2018).

Depends on web infrastructure: The DID's validity is tied to domain ownership and HTTPS availability. It introduces a central point of failure—if the domain expires or the server is down, the DID cannot be resolved. Requires active DNS and web server maintenance.