Decentralized Identifiers (DIDs):
Self-Sovereign Identity Explained

Digital identity is broken. Every time you create an account on a new platform, you hand over personal data to yet another centralized custodian. These custodians become honeypots for attackers, single points of failure, and gatekeepers who can revoke your identity at will. Decentralized Identifiers, or DIDs, represent a fundamental rethinking of this model. Rather than receiving an identity from a provider, you generate one yourself, anchor it to a verifiable data registry, and remain in full control of who can read your credentials and for how long.

What Is a DID?

A DID is a globally unique URI that resolves to a DID Document, a small JSON-LD object containing the public keys, authentication methods, and service endpoints associated with the identifier's subject. The W3C finalized the DID Core specification as a Recommendation in July 2022, establishing the canonical syntax:

did:method-name:method-specific-id

// Example DIDs
did:web:example.com:users:alice
did:key:z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP
did:ion:EiClkZMDxPKqC9c-umQfTkR8vvZ9JPhl_xLDI9Nfk38w5w
did:sol:devnet:3Js1pvbcQqRobfMf5jBnKEWPjmpd9G7TTFxhCmwp5gFB

The critical property is that no central registry assigns DIDs. The subject generates a cryptographic key pair, derives the identifier deterministically, and optionally anchors it to a blockchain or other verifiable data registry. Resolution is method-specific: did:web uses DNS and HTTPS, did:ion reads from the Bitcoin network via the Sidetree protocol, and did:key requires no network at all since the entire public key is encoded directly in the identifier.

DID Methods Compared

Choosing the right DID method depends on your trust model, latency requirements, and infrastructure constraints. The following table summarizes the most widely adopted methods:

For high-throughput authentication systems, resolution latency matters enormously. A did:key resolves in microseconds because the key material is literally embedded in the identifier string, while a did:ion resolution can take hundreds of milliseconds as it traverses the Sidetree overlay. When you need to verify millions of identities per second, even small resolution overheads compound into unacceptable delays.

The DID Document

Every DID resolves to a DID Document that acts as the subject's cryptographic passport. A minimal document includes a verification method (public key) and an authentication relationship:

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:web:auth.example.com:users:alice",
  "verificationMethod": [{
    "id": "#key-1",
    "type": "JsonWebKey2020",
    "publicKeyJwk": {
      "kty": "OKP",
      "crv": "Ed25519",
      "x": "d75a980182b10ab..."
    }
  }],
  "authentication": ["#key-1"],
  "service": [{
    "id": "#auth-endpoint",
    "type": "H33AuthService",
    "serviceEndpoint": "https://api.h33.ai/v1/verify"
  }]
}

Richer documents can include key agreement methods for encrypted communication, delegation and capability invocation relationships, and multiple service endpoints for different protocols. The document is entirely under the subject's control: they can rotate keys, add new verification methods, or deactivate the DID without asking anyone's permission.

DIDs and Verifiable Credentials

DIDs become truly powerful when combined with Verifiable Credentials (VCs). A VC is a tamper-evident claim about a subject, signed by an issuer, and presented by a holder. The flow works like this:

• Issuance: An issuer (university, government, employer) creates a credential asserting something about the holder's DID, then signs it with their own DID's private key.
• Storage: The holder stores the credential in a personal wallet. No central database holds the credential.
• Presentation: When a verifier requests proof, the holder constructs a Verifiable Presentation, optionally using zero-knowledge proofs to disclose only the minimum required attributes.
• Verification: The verifier resolves both the issuer's DID and the holder's DID, checks the cryptographic signatures, and confirms the credential has not been revoked.

This selective disclosure is where ZKP-based systems shine. Rather than revealing your full date of birth, you can prove "I am over 21" without disclosing the actual date. H33's ZKP verification layer, backed by an in-process DashMap cache achieving 0.085 microsecond lookups, makes these proof checks practical at scale.

The Quantum Threat to DIDs

The signatures anchoring DID Documents to verifiable registries are the system's root of trust. If an attacker can forge an Ed25519 signature, they can replace a subject's public key in their DID Document and assume their identity entirely. This is not a theoretical concern: NIST finalized its post-quantum signature standards (ML-DSA, formerly CRYSTALS-Dilithium) in 2024 precisely because the timeline for cryptographically relevant quantum computers is measured in years, not decades.

Migrating DIDs to post-quantum signatures requires updating three layers simultaneously: the verification methods listed in DID Documents, the signature algorithms used by credential issuers, and the verification logic in every relying party. This is a coordination problem of enormous scale.

Post-Quantum DIDs with H33

H33's authentication stack is built to handle this transition natively. Every authentication event passes through a fully post-quantum pipeline: biometric templates encrypted under BFV fully homomorphic encryption, verified via ZKP STARK lookups, and attested with Dilithium (ML-DSA) signatures. The entire chain completes in approximately 42 microseconds per authentication, sustaining 1.595 million authentications per second on production hardware.

For DID-based systems, this means you can anchor your DID Documents with Dilithium signatures today, ensuring that even a future quantum adversary cannot forge your identity. The DID Document's verification method simply references a Dilithium public key instead of Ed25519:

{
  "verificationMethod": [{
    "id": "#pq-key-1",
    "type": "Multikey",
    "publicKeyMultibase": "z6LSb...dilithium5...publickey"
  }],
  "authentication": ["#pq-key-1"]
}

Because H33's Dilithium sign-and-verify cycle completes in roughly 244 microseconds for an entire 32-user batch, the overhead of post-quantum signatures is negligible compared to the security guarantee. Batch attestation means that a single Dilithium signature covers 32 concurrent verifications, amortizing the cost to under 8 microseconds of signature overhead per user.

Encrypted Identity Resolution

H33 goes further than simply replacing signature algorithms. Using BFV fully homomorphic encryption, identity resolution can happen on encrypted data. A verifier submits an encrypted query, the system performs the lookup without ever seeing the plaintext identifier, and returns an encrypted result that only the verifier can decrypt. This eliminates a class of privacy leaks inherent in traditional DID resolution, where the resolver learns which identifiers a verifier is interested in.

The combination of FHE-encrypted resolution, ZKP selective disclosure, and post-quantum attestation creates identity infrastructure that is simultaneously private, minimal, and quantum-resistant. This is the architecture self-sovereign identity always needed but never had the cryptographic tooling to build.

Implementation Considerations

If you are building a system that incorporates DIDs, keep these practical concerns in mind:

• Key rotation strategy: Plan for regular key rotation and publish rotation events to your verifiable data registry. Post-quantum key sizes are larger (Dilithium-5 public keys are 2,592 bytes versus 32 bytes for Ed25519), so factor this into your DID Document storage.
• Method portability: Design your architecture to be method-agnostic. Use a DID resolver library that supports multiple methods, so you can migrate from did:web to a blockchain-anchored method without rewriting your verification stack.
• Revocation: Implement a revocation registry. Status List 2021 is the most widely supported approach, encoding revocation status as a compressed bitstring that verifiers can check without contacting the issuer.
• Latency budget: If your system requires sub-millisecond verification, pre-resolve and cache DID Documents locally. H33's DashMap-based caching pattern, with lookups at 0.085 microseconds, demonstrates that in-process caching eliminates network resolution as a bottleneck entirely.
• Hybrid signatures: During the transition period, consider issuing credentials with both a classical and a post-quantum signature. If one algorithm is broken, the other still provides assurance.

Decentralized identifiers represent the most significant shift in digital identity architecture since the introduction of public-key infrastructure. Combined with post-quantum cryptography and homomorphic encryption, they offer a path toward identity systems that no government can revoke, no breach can compromise, and no quantum computer can forge. The building blocks exist today. The question is whether your infrastructure is ready to use them.