← Articles A2A Identity Security

A2A DID-Based Agent Identity: Decentralized Verification via AIP

February 25, 2026 · The-Nexus-Guard · View proposal →

A new Agent Improvement Proposal (AIP) arrives at A2A with potentially significant implications: using Decentralized Identifiers (DIDs) to establish cryptographic agent identity. The proposal builds on the W3C DID specification to give autonomous agents verifiable, self-sovereign identity credentials.

About the Author

The-Nexus-Guard brings decentralized identity expertise to the agent ecosystem. This proposal follows earlier A2A identity discussions from abdelsfane and imran-siddique, consolidating around the DID standard.

The Identity Problem in Agent-to-Agent Communication

When two autonomous agents communicate, how does each verify the other's identity? Traditional approaches have limitations:

API keys — Prove you're authorized to use a service, not who you are
OAuth tokens — Tied to a centralized identity provider
TLS certificates — Prove server identity, but agents are often clients
Shared secrets — Don't scale, require pre-arrangement

For enterprise multi-agent systems where agents from different organizations collaborate, none of these cleanly solve the "who are you, and who do you work for?" question.

DIDs as Agent Identity

Decentralized Identifiers provide a foundation for self-sovereign identity. A DID looks like:

did:web:agents.example.com:finance-assistant

The proposal extends A2A's agent card with DID-based identity:

{
  "name": "Finance Assistant",
  "url": "https://agents.example.com/finance",
  "identity": {
    "did": "did:web:agents.example.com:finance-assistant",
    "verificationMethod": "did:web:agents.example.com:finance-assistant#key-1",
    "proofFormat": "JsonWebSignature2020"
  },
  "skills": [...]
}

Why did:web? The proposal recommends the web-based DID method for initial adoption — it maps naturally to existing DNS infrastructure. More exotic methods (did:ion, did:ethr) can be added as extensions.

Verification Flow

When Agent A wants to verify Agent B's identity:

Agent A receives Agent B's agent card with DID
Agent A resolves the DID document from the well-known endpoint
Agent A extracts the public key from the verification method
Agent B signs messages with its private key
Agent A verifies signatures against the resolved public key

This creates cryptographic proof that messages actually come from the claimed agent, without requiring a centralized authority.

Trust Delegation

The proposal also addresses delegation chains — when Agent C acts on behalf of Agent B, which acts on behalf of Organization A:

{
  "delegationChain": [
    {
      "delegator": "did:web:org-a.com:root",
      "delegate": "did:web:org-a.com:dept-finance",
      "scope": ["financial-queries", "budget-reports"],
      "proof": "eyJhbGciOiJFZERTQSIsInR5cCI6IkpXVCJ9..."
    },
    {
      "delegator": "did:web:org-a.com:dept-finance",
      "delegate": "did:web:agents.example.com:finance-assistant",
      "scope": ["budget-reports"],
      "proof": "eyJhbGciOiJFZERTQSIsInR5cCI6IkpXVCJ9..."
    }
  ]
}

Each link in the chain is cryptographically signed, creating a verifiable trail from the acting agent back to the authorizing organization.

Relation to Earlier Proposals

This AIP builds on previous A2A identity work:

A2A Agent Identity and Trust Framework (abdelsfane, Feb 18) — Proposed verification levels and trust signals
A2A Cryptographic Identity Verification (imran-siddique, Feb 13) — Initial exploration of cryptographic identity

The DID-based approach consolidates these discussions around an existing W3C standard rather than inventing A2A-specific identity primitives.

Implementation Considerations

Several practical challenges the proposal acknowledges:

Key management — Agents need secure key storage, rotation procedures, and revocation mechanisms
Resolution latency — DID resolution adds network calls to the verification path
Offline scenarios — Cached DID documents create freshness vs. availability tradeoffs
Bootstrap problem — How do agents get their initial DIDs and keys?

Why This Matters

As agent ecosystems grow beyond single-organization deployments, identity becomes critical. Consider:

Multi-vendor agent orchestration — A user's personal assistant delegates to specialized agents from different providers
Enterprise compliance — Audit trails require knowing which agent did what, on whose authority
Trust boundaries — Agents need to verify they're talking to legitimate counterparties before sharing sensitive data

DIDs provide a foundation that doesn't require a single identity provider to rule them all. Each organization can issue and manage its own agent identities while still enabling cross-organization verification.

Next Steps

The proposal is in early discussion phase. Key questions for the community:

Should DID support be required for A2A compliance, or an optional extension?
Which DID methods should be supported initially?
How should delegation scope be defined and enforced?
What's the migration path for existing A2A deployments?

Watch GitHub issue #1511 for community discussion.

← Back to Repo Pulse