How We Built Cryptographic Identity for AI Agents with DIDs
Updated 2026-07: Anima’s DID method migrated from a customWhen an AI agent sends an email, makes a purchase, or calls an API, the receiving party has a reasonable question: who is this, and should I trust it? Today, most agents authenticate with API keys or OAuth tokens. These prove authorization, not identity. They say “this request is allowed” but not “this is agent X, operated by company Y, with these specific capabilities and constraints.” That distinction matters as agents start interacting with each other, with vendors, and with compliance systems. We use the W3C-standarddid:anima:method to the standarddid:web:method, and this post has been updated to match what is shipped today. Where a capability is still on the roadmap (automatic credential issuance), it says so.
did:web method to solve this.
Why Agents Need Verifiable Identity
There are three forces pushing agents toward cryptographic identity:1. Agent-to-Agent Trust
When agent A contacts agent B to negotiate a contract or request a service, B needs to verify that A is who it claims to be. API keys do not help here — they authenticate a request to a specific service, not an identity across services. DIDs provide a portable, verifiable identity that works across any protocol.2. Compliance and Accountability
Regulators are catching up to agentic systems. SOC 2 auditors want to know which agent performed which action and under whose authority. AML rules require knowing the identity behind financial transactions. A DID ties every action to a verifiable identity with a clear chain of custody.3. Discovery and Interoperability
As the agent ecosystem grows, services need to discover agent capabilities and verify their legitimacy. The combination of DIDs and Agent Cards gives every agent a machine-readable, cryptographically verifiable profile that other systems can query.Standard did:web, not a custom method
Every agent created on Anima is automatically assigned a DID following the W3C Decentralized Identifiers specification, using the registered did:web method:
did:web over inventing a custom method: did:web resolution is plain HTTPS, already supported by standard resolver tooling, with nothing bespoke to implement on the verifier side.
The DID resolves to a DID Document containing the agent’s public key and authentication methods:
Key Design Decisions
Ed25519 keys: We use Ed25519 for signing because it is fast, produces compact signatures, and is widely supported across platforms. Each agent gets a dedicated key pair at creation time — and the private key is stored encrypted at rest. World-readable documents: DID documents must be verifiable by parties who cannot authenticate to Anima, so they are served publicly with open CORS. Automatic provisioning: You do not need to manage keys or DID documents manually. Creating an agent automatically provisions the DID, generates keys, and publishes the document.Resolving and Verifying DIDs
Any system can fetch an Anima agent’s DID document — no API key required:application/did+json. Authenticated callers can also fetch it through the API:
Verifiable Credentials
DIDs establish identity. Verifiable Credentials (VCs) establish attributes of that identity — “this agent’s email is verified”, “this org passed billing verification”. Anima’s identity layer verifies and revokes W3C VCs today (POST /v1/identity/verify checks signature, expiry, and revocation of a JWT VC). Automatic credential issuance has not shipped yet — agents don’t accumulate credentials on real events (email verified, phone provisioned) until that lands, and Agent Cards honestly report verification.level: "basic" in the meantime. See Verifiable Credentials for the current status.
Agent Cards: machine-readable agent profiles
Every Anima agent has an Agent Card — a machine-readable JSON profile generated from its live state:capabilities block is derived from what the agent actually has provisioned — not self-declared.
Agent Registry
For discovery across your organization, Anima runs an Agent Registry — register your agent, and other agents can find it by capability or DID:Putting It All Together
Here is the flow when Agent A wants to hand a task to Agent B: Every step is verifiable. Every identity is cryptographic. No shared secrets between agents.What This Enables
- Signature-verified agent-to-agent tasks: recipients verify the sender’s signature against its published DID document before accepting work
- Compliance reporting: every action is tied to an identity with a clear audit trail
- Standards-based portability:
did:webis a registered W3C method — verifiers need no Anima-specific code - Key rotation and revocation: rotate an agent’s keypair (
POST /v1/agents/{agentId}/did/rotate) or revoke credentials at any time
