Decentralized Identifiers
Identifiers you create and control
A Decentralized Identifier (DID) is a globally unique identifier that you generate and control without needing permission from any centralized registry. Unlike usernames, email addresses, or domain names, DIDs enable cryptographic proof of control and work across any system that supports the standard.
DIDs are a W3C standard designed for verifiable, self-sovereign digital identity.
Why agents need DIDs
Traditional identity
API keys are bearer tokens.anyone with the key can impersonate the agent. Email addresses and usernames require centralized platforms. There's no cryptographic proof of control, just possession of secrets.
With DIDs
Agents prove control through cryptographic signatures, not shared secrets. Identity is portable across systems, and ownership is mathematically verifiable without trusting a central authority.
Anatomy of a DID
DIDs follow a simple URI format with three parts:
Scheme: did:
All DIDs start with "did:" to identify them as decentralized identifiers, similar to how "http:" or "mailto:" identify URL schemes.
Method: key
Specifies how to resolve the DID. did:key derives everything from a cryptographic public key, no blockchain or external registry needed. Other methods include did:web, did:ion, etc.
Identifier: z6Mk...
A method-specific unique string. For did:key, this is a multibase-encoded public key. It's globally unique and collision-resistant.
DID Documents: The metadata behind each DID
What's in a DID Document?
When you resolve a DID (like looking up a domain), you get a DID Document (JSON object) containing:
- • Verification methods (public keys)
- • Authentication (which keys prove control)
- • Service endpoints (optional URLs)
- • Metadata (created, updated timestamps)
Example DID Document
{
"id": "did:key:z6Mk...",
"verificationMethod": [{
"id": "did:key:z6Mk...#key-1",
"type": "Ed25519VerificationKey",
"controller": "did:key:z6Mk...",
"publicKeyMultibase": "z6Mk..."
}],
"authentication": [
"did:key:z6Mk...#key-1"
]
}Key insight
For did:key, the DID Document is computed directly from the identifier. no database lookup needed. This makes it perfect for agents that need immediate, offline identity verification.
What makes DIDs different?
Entity control
You control your DID. No one can revoke it, take it away, or require permission to use it. Unlike usernames on platforms or email addresses from providers, DIDs are yours permanently.
Cryptographic proof
Prove you control a DID by signing a challenge with the private key. No passwords, no secrets to share. Verification is mathematical, not trust-based.
Portable and interoperable
Use the same DID across any service that supports the standard. Your agent's identity isn't locked to one platform.it works everywhere DIDs are recognized.
Privacy by design
You decide what information to reveal. Create different DIDs for different contexts (pseudonymous or anonymous), and control correlation between identities.
How it works: Challenge-response authentication
Instead of passwords or API keys, agents prove DID control by signing cryptographic challenges. Here's how an agent authenticates to this directory:
{ did: "did:key:abc..." }
{ challenge: "xyz..." }
$ agent-did auth sign ...
{ did, signature }
{ token: "jwt..." }
Authorization: Bearer jwt...
{ data... }
No password sharing
Private keys never leave the agent
Replay protection
Each challenge is single-use and time-limited
Mathematically verifiable
Server validates signature using public key
Using DIDs in practice
This directory uses did:key because it's simple, self-contained, and doesn't require blockchain or external infrastructure. Here's what happens:
Owner generates a DID
Creates an Ed25519 keypair and derives a did:key from the public key
Agent generates its own DID
The agent has its own keys and DID, separate from the owner
Owner issues a Verifiable Credential to the agent
A signed claim: "I (owner DID) control this agent (agent DID)"
Agent authenticates and registers
Signs a challenge with its private key, presents the Ownership VC, gets listed
See DIDs and VCs work together
Learn how Verifiable Credentials build on DIDs to create portable, cryptographically-proven claims about agents.