Decentralized Identity in AI Agent Trust Networks: DID Methods, Resolution, and Revocation

The identity crisis in AI agent networks is not metaphorical. It is architectural. Every time an enterprise deploys an AI agent and another agent, system, or organization tries to verify who that agent is, what it is authorized to do, and whether it can be trusted, they encounter a fundamental question: whose word do you trust when establishing identity?

Current answers are mostly inadequate. Agents identify themselves with API keys — which can be stolen, shared, or revoked without notice. They present claims about their capabilities in HTTP headers — which can be forged. They operate under organizational identities — which says something about the deploying organization but nothing specific about the agent's own behavioral history. When something goes wrong, the forensic record is often "agent ID 7a3b4c requested X" — and "agent ID 7a3b4c" is a database row, not an identity that provides any context about what this agent is, where it came from, or what it has previously done.

Decentralized Identifiers (DIDs), developed by the W3C, provide a fundamentally different approach to identity that is well-suited to AI agent networks. Unlike centralized identity systems that depend on a single authority (a company, a government), DIDs are resolvable from the DID itself — the identifier contains or points to the cryptographic material needed to verify it. They are durable (not tied to any single organization's infrastructure), portable (can be presented to any system that supports the DID specification), and revocable (the identifier can be deactivated when the agent is retired or compromised).

This post develops a complete technical guide to DID-based identity for AI agents: method selection, document structure, capability encoding, resolution protocols, and revocation mechanisms. It is written for engineers and architects building production agent identity infrastructure.

TL;DR

• DIDs provide durable, portable, cryptographically verifiable identity for AI agents — superior to API keys, session tokens, or organizational identity alone.
• DID method selection is context-dependent: did:web for organization-anchored agents, did:key for ephemeral agents, did:peer for bilateral relationships, did:ethr for blockchain-anchored agents requiring maximum durability.
• DID Documents for AI agents extend the standard structure with agent-specific metadata: model provenance, capability declarations, behavioral monitoring endpoints, and trust score references.
• DID resolution involves fetching and verifying the DID Document from the method-appropriate resolver — understanding the full resolution pipeline is essential for security.
• Status List 2021 (W3C) and SD-JWT credential status provide the two primary revocation mechanisms; Status List is better for scale and privacy, SD-JWT status for selective disclosure.
• Verification relationships in the DID Document govern which keys can be used for which purposes — critical for preventing key confusion attacks.

Why API Keys and Session Tokens Are Not Enough

Before examining DIDs, it is worth being precise about what existing identity mechanisms fail to provide and why.

The Inadequacy of API Keys

API keys are symmetric shared secrets: the same value is known to both the issuer and the holder. This creates several structural weaknesses:

No proof of provenance. An API key proves that someone has the key; it does not prove who they are, what system they represent, or whether the key is being used appropriately. If API key "sk-armalo-7f4a9b" is leaked, anyone with the key can impersonate the legitimate agent.

No behavioral context. An API key is a static credential. It carries no information about the agent presenting it — what model it uses, what its behavioral track record is, what constraints it operates under. Every API key presentation is context-free.

Revocation requires coordination. Revoking an API key requires that all systems accepting the key receive the revocation notification. In distributed multi-agent systems, key revocation propagation is a reliability engineering challenge — some systems will continue accepting a revoked key during the propagation window.

Cannot support delegation. API keys do not natively support delegation: giving an agent the ability to act on behalf of another agent with a scoped subset of the original agent's permissions. This pattern is essential for multi-agent architectures but cannot be expressed cleanly with API keys.

The Inadequacy of Session Tokens

Session tokens (JWTs, OAuth access tokens) improve on API keys by adding claims about the token holder: who issued the token, what permissions it grants, when it expires. But session tokens have significant limitations as permanent agent identifiers:

Ephemeral identity. A session token is typically valid for minutes to hours. There is no stable, long-lived identity for the agent — each session is, from the token's perspective, a new agent. This makes longitudinal behavioral tracking impossible without additional infrastructure.

Centralized trust anchor. Session tokens derive their validity from the issuing authorization server. If the authorization server is unavailable, token verification fails. If the authorization server's signing key is compromised, all tokens signed by that key are compromised.

No self-describing identity. A JWT's subject claim (sub) is typically an opaque identifier. To learn anything about the agent represented by this identifier, you must query the issuing organization's infrastructure.

DID Fundamentals for AI Agent Engineers

A DID is a URI with the form did:<method>:<method-specific-identifier>. The DID resolves to a DID Document — a JSON-LD document containing cryptographic material and service endpoints.

The critical property is self-description: the DID method specification tells you how to resolve the DID to its Document, and the Document contains everything needed to verify claims made by the DID controller. No third-party query is required during verification (though some DID methods involve external infrastructure for resolution).

DID Document Structure

A complete DID Document for an AI agent:

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1",
    "https://armalo.ai/ns/agent-did/v1"
  ],
  "id": "did:web:agents.acme-corp.com:billing-agent-v2",
  "alsoKnownAs": [
    "https://agents.acme-corp.com/billing-agent-v2"
  ],
  "controller": "did:web:acme-corp.com",
  
  "verificationMethod": [
    {
      "id": "did:web:agents.acme-corp.com:billing-agent-v2#key-1",
      "type": "Ed25519VerificationKey2020",
      "controller": "did:web:agents.acme-corp.com:billing-agent-v2",
      "publicKeyMultibase": "z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9y84QgmqearFHWkTpt"
    },
    {
      "id": "did:web:agents.acme-corp.com:billing-agent-v2#key-2",
      "type": "JsonWebKey2020",
      "controller": "did:web:agents.acme-corp.com:billing-agent-v2",
      "publicKeyJwk": {
        "kty": "EC",
        "crv": "P-256",
        "x": "lCvOy8Ua23NTl_Z8Dg...",
        "y": "2RQjOKMr4Ts3lH_vf1..."
      }
    }
  ],
  
  "authentication": [
    "did:web:agents.acme-corp.com:billing-agent-v2#key-1"
  ],
  "assertionMethod": [
    "did:web:agents.acme-corp.com:billing-agent-v2#key-2"
  ],
  "capabilityInvocation": [
    "did:web:agents.acme-corp.com:billing-agent-v2#key-1"
  ],
  "keyAgreement": [
    {
      "id": "did:web:agents.acme-corp.com:billing-agent-v2#key-exchange-1",
      "type": "X25519KeyAgreementKey2020",
      "controller": "did:web:agents.acme-corp.com:billing-agent-v2",
      "publicKeyMultibase": "z6LSkg9bHHgT6VPzMZfnF..."
    }
  ],
  
  "service": [
    {
      "id": "did:web:agents.acme-corp.com:billing-agent-v2#trust-oracle",
      "type": "ArmaloTrustOracleEndpoint",
      "serviceEndpoint": "https://api.armalo.ai/v1/trust/did:web:agents.acme-corp.com:billing-agent-v2"
    },
    {
      "id": "did:web:agents.acme-corp.com:billing-agent-v2#behavioral-monitoring",
      "type": "BehavioralMonitoringEndpoint",
      "serviceEndpoint": "https://monitor.acme-corp.com/agents/billing-agent-v2"
    }
  ],
  
  "agentProfile": {
    "modelProvider": "anthropic",
    "modelFamily": "claude-3-5-sonnet",
    "modelVersion": "20241022",
    "deployingOrganization": "did:web:acme-corp.com",
    "deploymentDate": "2026-01-15T00:00:00Z",
    "primaryFunction": "invoice-processing-and-billing-queries",
    "dataClassificationCeiling": "confidential",
    "scopeConstraints": [
      "no-financial-transactions-over-10000-USD",
      "no-external-api-access",
      "requires-human-approval-for-refunds"
    ],
    "compositeTrustScoreRef": "https://api.armalo.ai/v1/trust/did:web:agents.acme-corp.com:billing-agent-v2",
    "pactRegistry": "https://api.armalo.ai/v1/pacts?agent=did:web:agents.acme-corp.com:billing-agent-v2"
  }
}

This DID Document provides a receiving agent with:

• The cryptographic keys needed to verify the agent's assertions and authenticate it
• Service endpoints for querying the agent's trust oracle and behavioral monitoring
• Structured metadata about the agent's deployment context and constraints
• References to the agent's pact registry

Verification Relationships in Depth

The verification relationship fields in a DID Document — authentication, assertionMethod, capabilityInvocation, keyAgreement — are not interchangeable. Each governs a specific cryptographic purpose, and confusing them introduces security vulnerabilities.

Authentication. Keys listed under authentication can be used to prove control of the DID. When an agent is challenged to prove its identity (the challenge-response protocol in trust negotiation), it signs the challenge with a key whose ID is listed under authentication. Verification: the challenger resolves the DID Document, finds the key listed under authentication, and verifies the signature against that key.

AssertionMethod. Keys listed under assertionMethod can be used to sign credentials and other assertions. When an agent issues a Verifiable Credential about its capabilities, it signs with an assertion key. This is distinct from authentication — an agent might use different keys (with different security properties and rotation schedules) for authentication and for signing long-lived credentials.

CapabilityInvocation. Keys listed under capabilityInvocation can be used to invoke capabilities — essentially, to authorize actions. In ZCAP-LD (Authorization Capabilities for Linked Data) systems, capability invocations require the invoker to sign the request with a capabilityInvocation key. This allows fine-grained authorization at the cryptographic layer.

KeyAgreement. Keys listed under keyAgreement are used for encrypted communication — establishing shared secrets for encrypted agent-to-agent channels. These are typically Diffie-Hellman keys (X25519) rather than signature keys.

The key confusion attack vector: if an agent uses the same key for both authentication and assertionMethod, a replay attack is possible — a legitimate authentication proof could be replicated as an assertion proof. Using separate keys for each relationship prevents this.

DID Method Selection Guide

Different DID methods are appropriate for different deployment contexts. The choice of DID method is a deployment architecture decision with significant security and operational implications.

did:web — Organization-Anchored Agent Identity

did:web anchors agent identity to an organization's web infrastructure. The DID did:web:agents.acme-corp.com:billing-agent-v2 resolves to the document at https://agents.acme-corp.com/billing-agent-v2/did.json.

Security properties: Trust derives from HTTPS certificate chain and DNS security. The agent's DID Document is as trustworthy as the organization's web infrastructure.

Resolution: Standard HTTPS GET to the method-specific URL. Fast (< 100ms for nearby infrastructure), no special resolver required. Works with standard HTTP libraries.

Update mechanism: The deploying organization updates the DID Document by replacing the document at the canonical URL. No external coordination required.

Revocation: Revoke by deactivating the DID Document (returning a 410 Gone response or replacing with a deactivation notice).

Appropriate for: Enterprise AI agent deployments where the agent's identity is anchored to an organizational domain. The most common enterprise DID method for 2026 deployments.

Limitations: Dependent on domain stability. If the organization loses the domain or changes domain infrastructure, DID Documents may become unresolvable. Not suitable for agents that need identity independent of any organization's infrastructure.

did:key — Ephemeral and Self-Sovereign Identity

did:key derives a DID Document directly from the public key itself. The DID did:key:z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9y84QgmqearFHWkTpt can be resolved by any conformant resolver without querying any external infrastructure — the public key is encoded in the DID identifier.

Security properties: Cryptographic security only — trust derives entirely from the private key. No organizational anchor. Theoretically, anyone could create a did:key — the key's trustworthiness depends entirely on how it was created and managed.

Resolution: Purely local computation — the resolver decodes the public key from the DID identifier. No network round-trip. Near-zero latency.

Update mechanism: did:key DIDs are immutable. The public key is baked into the identifier; there is no mechanism for key rotation. A new key requires a new DID.

Revocation: Not natively supported. Cannot revoke a did:key DID without revoking all credentials that reference it.

Appropriate for: Short-lived agents (single sessions, temporary workers), testing and development, scenarios where agent identity is not expected to persist beyond a single interaction.

Limitations: No key rotation, no organizational anchor, no revocation. Not suitable for production agents with persistent behavioral records.

did:peer — Bilateral Peer-to-Peer Identity

did:peer is designed for bilateral relationships — two agents that want to establish a private, persistent identifier for their relationship without registering with any external registry.

Security properties: Each party in the relationship holds a copy of the peer DID Document. Updates require coordination between peers. Security derives from the private keys held by each party.

Resolution: Each peer resolves the other's DID from their local copy of the DID Document. No external resolution required.

Update mechanism: Both peers maintain synchronized copies of each other's DID Documents. Key rotation requires notifying the peer.

Revocation: Either party can revoke by ceasing to recognize the peer DID. The other party cannot verify the revocation independently.

Appropriate for: Long-term bilateral relationships between agents that have established a prior trust relationship — agent-to-agent integration partners, agents within the same organizational deployment.

Limitations: Does not scale beyond bilateral relationships. Cannot be verified by third parties who are not part of the relationship.

did:ethr — Blockchain-Anchored Durable Identity

did:ethr anchors DID Documents to the Ethereum blockchain (and EVM-compatible chains). The DID did:ethr:0x7f4a9b2c1e3d5f6a7b8c9d0e1f2a3b4c5d6e7f80 resolves to a DID Document derived from the Ethereum address, with updates recorded as on-chain transactions.

Security properties: Blockchain-anchored — updates are immutable, timestamped, and publicly verifiable. The security of the identity is backed by the blockchain's security properties.

Resolution: Queries an Ethereum node for the DID Document. Requires either running a node or using a trusted node provider. Higher resolution latency (100–500ms) than other methods.

Update mechanism: DID Document updates are recorded as on-chain transactions. Updates are permanent and publicly auditable. Key rotation requires an on-chain transaction.

Revocation: Recorded as on-chain transactions — publicly verifiable and immutable. Maximum credential revocation transparency.

Appropriate for: Agents that require maximum identity durability and verifiability — agents involved in financial transactions, cross-border operations, or regulatory compliance scenarios where third-party audit of identity records is required.

Limitations: Higher latency, gas costs for updates, dependency on blockchain availability. Not appropriate for high-frequency low-stakes agent interactions.

Method Selection Decision Framework

DID Resolution Security

Understanding the DID resolution pipeline is essential for security. Resolution vulnerabilities can allow attackers to substitute malicious DID Documents, defeating the entire identity framework.

The Full Resolution Pipeline

For did:web:agents.acme-corp.com:billing-agent-v2:

1. Method parsing: Extract the method (web) and method-specific identifier (agents.acme-corp.com:billing-agent-v2).
2. URL construction: Convert to HTTPS URL: https://agents.acme-corp.com/billing-agent-v2/did.json.
3. DNS resolution: Resolve agents.acme-corp.com via DNS. DNS security is the first attack surface — DNS cache poisoning or DNS hijacking attacks can redirect resolution to a malicious document server.
4. TLS handshake: Establish a TLS connection to the resolved IP. Verify the TLS certificate against the expected hostname. Certificate authority compromise is the second attack surface.
5. Document fetch: HTTP GET to the constructed URL. HTTP redirect handling requires care — an attacker who can inject a redirect can substitute a document.
6. Document validation: Verify that the fetched document is valid JSON-LD, that its id field matches the DID being resolved (prevents substitution of a different agent's document), and that it contains required fields.
7. Freshness check: Verify the document's freshness by checking the DID Document's updated timestamp against the resolver's cache TTL policy.

Security requirements for each stage:

• DNS: use DNSSEC where available; monitor for unexpected DNS changes
• TLS: enforce TLS 1.2+, reject self-signed certificates, implement certificate pinning for critical agents
• HTTP: do not follow redirects to different domains; validate id field matches DID
• Document: implement JSON-LD validation before accepting any claims in the document

Resolver Selection

The choice of DID resolver is a trust decision. Some organizations run their own universal DID resolvers; others use public resolver services (uniresolver.io, cloudflare's resolver). Public resolvers introduce a centralization point — if the public resolver is compromised or unavailable, resolution fails.

For enterprise AI agent deployments, running an organization-internal DID resolver that handles the DID methods your organization uses provides independence from public infrastructure. The universal resolver codebase (from Decentralized Identity Foundation) is open-source and deployable on standard infrastructure.

Caching and Staleness

DID Documents should be cached by resolvers to avoid repeated resolution overhead. Caching parameters:

• Maximum TTL: 15 minutes for authentication decisions, 60 minutes for read-only capability queries
• Minimum refresh: resolve afresh when the cached document approaches TTL, not only when it expires
• Invalidation: implement DID Document update notifications (if the method supports them) to invalidate caches proactively when documents are updated
• Revocation: always check credential status in real time; do not cache revocation status

Revocation Mechanisms

Revocation is the mechanism by which an identity is invalidated. For AI agents, revocation is needed when: the agent's private key is compromised, the agent is retired, the agent has been found to behave outside acceptable bounds, or the deploying organization is terminating operations.

Status List 2021

The W3C Verifiable Credentials Working Group has published Status List 2021 as the recommended revocation mechanism for VCs. It is well-suited to large-scale deployments.

The mechanism: the issuer maintains a bitstring (list of bits) where each bit position corresponds to a credential. When a credential is issued, it is assigned a position in the bitstring. When it is revoked, the corresponding bit is flipped to 1. Verifiers download the bitstring and check whether their credential's position bit is 0 (valid) or 1 (revoked).

Implementation for AI agent trust credentials:

{
  "credentialStatus": {
    "id": "https://api.armalo.ai/v1/status/list-2026-q2#position-7834",
    "type": "StatusList2021Entry",
    "statusPurpose": "revocation",
    "statusListIndex": "7834",
    "statusListCredential": "https://api.armalo.ai/v1/status/list-2026-q2"
  }
}

The status list credential is itself a Verifiable Credential, signed by the issuer, containing the compressed bitstring. The entire bitstring can be downloaded once and used to verify revocation status for all credentials issued against that list — reducing the per-credential revocation check to a local bit lookup.

Privacy properties: Verifiers learn the credential's position in the list, which could in principle be correlated with issuance timing to reveal when a credential was issued. For AI agent trust credentials, where privacy is less sensitive than for human identity credentials, this is generally acceptable. For implementations with stronger privacy requirements, privacy-preserving extensions (mixing position assignments, using multiple status lists) reduce correlation.

Scale properties: Status List 2021 scales to millions of credentials per list. The compressed bitstring for 1 million credential positions is approximately 125KB — easily cacheable by all verifiers. Revocation propagation time is the list's cache TTL.

OCSP for Real-Time Revocation

For the highest-stakes interactions where status list caching introduces unacceptable risk, Online Certificate Status Protocol (OCSP, RFC 6960) provides real-time revocation checking. The verifier queries the issuer's OCSP endpoint for each credential, receiving a signed response indicating current revocation status.

OCSP has higher latency than Status List 2021 (requires a network round-trip per credential check) and introduces a privacy issue (the issuer learns which verifiers are checking which credentials). For AI agent trust credentials, these tradeoffs favor Status List 2021 for routine interactions and OCSP for critical one-time verifications (initial trust negotiation for high-stakes deployments).

Key Rotation and Agent Lifecycle Management

An AI agent's DID must be managed across its operational lifecycle: key rotation, capability updates, behavioral baseline changes, and eventual retirement.

Key Rotation Protocol

Key rotation — replacing a cryptographic key with a new one — is a security hygiene requirement. For Ed25519 keys (the recommended signature algorithm), rotation frequency depends on risk: critical agents should rotate every 90 days; lower-stakes agents can extend to 6–12 months.

DID key rotation procedure:

1. Generate new keypair
2. Update DID Document to add new key to verificationMethod
3. Add new key to appropriate verification relationship arrays
4. Issue a "key rotation" Verifiable Credential signed by the old key, attesting that the new key is authorized
5. After a transition period (recommended: 48 hours), remove the old key from the DID Document
6. Revoke credentials signed by the old key that have not been renewed
7. Reissue time-sensitive credentials signed by the new key

The transition period is important: verifiers that have cached the old DID Document (and thus only know the old key) need time to refresh before the old key is removed.

Agent Versioning

When an agent's model, system prompt, or configuration changes materially, the behavioral profile changes. The question is: does this constitute a new agent (requiring a new DID) or an update to the existing agent (requiring a DID Document update)?

New DID appropriate when: Model provider or family changes, major system prompt redesign, fundamental change in authorized capabilities, new deploying organization.

DID Document update appropriate when: Model version increment within the same family, minor system prompt tuning, capability additions within the existing scope, tool set expansion.

This distinction matters for behavioral continuity: an agent inheriting a DID from a substantially different prior agent is representing continuity of identity that may not reflect continuity of behavior. Trust scores and behavioral attestations should be re-evaluated when the agent's behavioral baseline changes substantially.

How Armalo Addresses This

Armalo's identity infrastructure provides turnkey DID management for AI agent deployments, eliminating the need for deploying organizations to build and maintain DID resolution infrastructure from scratch.

Agent registration with Armalo automatically provisions a did:armalo DID — a custom DID method using Armalo's trust-anchored resolution infrastructure. The did:armalo method provides the durability of blockchain-anchored identity with the performance of cached resolution, by anchoring identity roots to Base L2 (Armalo's blockchain infrastructure) while caching DID Documents in a globally distributed CDN.

The DID Document for each registered agent is automatically populated with Armalo trust oracle service endpoints, behavioral monitoring endpoints, and references to the agent's pact registry. This means that any entity that resolves an Armalo-registered agent's DID immediately has the information needed to query the agent's trust standing — without needing to know anything about Armalo's infrastructure in advance.

Credential issuance uses Armalo's signing keys (themselves anchored to did:web:armalo.ai) and includes Status List 2021 credential status entries in all issued credentials. Revocation can be executed through the Armalo dashboard or API and takes effect within the credential status list's cache TTL (maximum 15 minutes).

Key rotation is managed automatically: Armalo generates new keypairs on the configured rotation schedule, updates DID Documents atomically, and handles the transition period gracefully by briefly accepting both old and new keys.

Memory attestations — Armalo's behavioral history credentials — are issued as VCDM 2.0 credentials anchored to the agent's DID, making them portable to any VCDM-compliant relying party. An agent can present its full behavioral history, signed by Armalo's issuing keys, to any counterparty in a trust negotiation.

Conclusion: DID Infrastructure as the Foundation Layer

Decentralized Identifiers provide the foundational identity layer that AI agent trust networks require. The alternative — relying on API keys, session tokens, and organizational identity alone — produces systems where identity is ephemeral, behavioral history is not portable, and revocation is operationally fragile.

The DID specification is mature and production-ready. Multiple DID methods cover the full range of AI agent deployment contexts, from ephemeral worker agents (did:key) to enterprise deployments (did:web) to regulated financial deployments (did:ethr). W3C VCDM 2.0 provides the credential layer; Status List 2021 provides revocation; IETF RFC 9421 provides transport security.

The engineering investment required to implement DID-based identity for AI agents is real but bounded. Organizations that make this investment will find that trust negotiation, credential verification, and behavioral accountability all become substantially more tractable — because they have a stable, verifiable, revocable foundation to build on.

Key Takeaways:

• DIDs provide durable, portable, cryptographically verifiable AI agent identity — API keys and session tokens are insufficient for production trust infrastructure.
• Method selection: did:web for enterprise, did:key for ephemeral, did:peer for bilateral, did:ethr for regulated/financial.
• Verification relationships (authentication, assertionMethod, capabilityInvocation, keyAgreement) must use separate keys to prevent confusion attacks.
• Resolution security requires: DNSSEC monitoring, TLS certificate validation, redirect protection, and document ID validation.
• Status List 2021 is the recommended revocation mechanism for scale; OCSP for real-time high-stakes checks.
• Armalo's did:armalo method provides enterprise-grade DID management with automatic provisioning, trust oracle integration, and behavioral monitoring endpoints.