Skip to main content
A2A-IDF specification

Agent identity for the A2A protocol

A2A-IDF is the identity-framework layer of the A2A protocol stack. Verification levels 0/1/2, dual-shape keyid resolution, attestation envelopes, and delegation chains. Composes with Envoys wire signatures, CTEF identity claims, and APS delegation envelopes without re-keying or re-signing.

What A2A protocol security covers

Before an agent acts on a request from another agent over the A2A protocol, it has three questions to answer: who sent the request, whether the message is the one they signed, and how much evidence stands behind the sender's identity. Transport encryption and the authentication schemes an AgentCard declares come from the A2A specification itself. A2A-IDF and the layers it composes with answer the three identity questions.

Identity

Which agent sent this request?

The AgentCard declares a keyid. The receiving agent resolves it to a public key, published as a W3C DID Document or in the Envoys §6 compact form, and checks the sender's signatures against that key.

The four-layer identity stack

Message signatures

Is this the message the sender signed?

Each request carries an RFC 9421 HTTP message signature made with Ed25519, covering the method, the path and a digest of the body. The signature also carries a creation time and a nonce, so the verifier can reject a stale or replayed request.

Verify a signed request

Verification levels

How much evidence stands behind that identity?

Level 0 is a signature that verifies against the declared key. Level 1 adds a DNS TXT record that ties the key to a domain. Level 2 adds an attestation from an issuer the verifier trusts, tying the agent to an organization.

The three levels

Verify a signed request

typescript
import { verify, resolveKeyid, ReplayCache } from "@opena2a/a2a-idf";

const { publicKey } = await resolveKeyid(headers["signature-input-keyid"]);
const replay = new ReplayCache();

const result = verify({
  method: req.method,
  path: req.url,
  body: req.body,
  headers: {
    "content-digest": req.headers["content-digest"],
    "signature-input": req.headers["signature-input"],
    signature: req.headers["signature"],
  },
  publicKey,
  checkNonce: replay.check.bind(replay),
});

if (!result.ok) reject(result.reason); // signature-invalid, timestamp-too-old, etc.

The same fixture set runs against a2a-idf-conformance using its built-in Node and Python verifiers, which depend only on platform cryptography primitives.

Four layers
Wire signature, identity framework, claims, delegation
Specified across PR #1496, #1829, #1786, #1575
Dual-shape keyid
W3C DID Document and Envoys §6 compact form
A2A-IDF §6 public-key resolution
Byte-matched
Envoys signature/v1 §13 Vectors 1, 2, 3
RFC 8032 §7.1 Test 1 keypair

Four-layer A2A identity stack

The A2A identity stack split into four orthogonal layers, with each layer owned by a separate specification. A2A-IDF occupies layer two. Implementations can adopt one layer at a time.

LayerConcernSpecificationLayer owner
Wire signaturePer-message RFC 9421 + Ed25519. Survives proxies and intermediaries. Point-in-time integrity.#1829 (Envoys signature/v1)External
Identity frameworkVerification levels 0/1/2, attestation envelopes, trust signals, delegation chain structure, revocation hooks.#1496 (A2A-IDF)OpenA2A
Identity claimsCTEF claim envelopes covering identity, transport, authority, and continuity categories.#1786 (CTEF)External
Delegation and continuityAPS bilateral receipts, delegation chains, commerce preflight, task-scoped identity.#1575 (APS)External

Verification levels

A2A-IDF defines three levels of identity verification. Verifiers report the highest level the evidence supports, plus any warnings the evidence carries (stale DNS TTL, untrusted attestation issuer, expired keyid).

Level 0
Self-asserted

The AgentCard ships a valid Ed25519 signature against the declared keyid. Sufficient when downstream trust is granted by separate mechanisms.

Evidence: RFC 9421 + Ed25519 signature verifies against the resolved key.

Level 1
Domain-verified

Level 0 plus a DNS TXT record at _a2a-identity.<domain> advertising the keyid. Binds the agent to a domain operator.

Evidence: DNS TXT lookup returns the expected token. TTL above 300 seconds produces a stale-key warning.

Level 2
Organization-verified

Level 1 plus a trusted attestation that binds the agent to an organization (domain control, employer of record, or third-party audit).

Evidence: At least one attestation in the array is signed by an issuer the verifier trusts.

Reference artifacts

Three artifacts ship with the specification. The SDK is the consumer library; the conformance suite is the independent oracle; AIM is the production-grade reference implementation.

@opena2a/a2a-idf SDK

Reference TypeScript SDK. Sign and verify per RFC 9421 + Ed25519, resolve keyids in both shapes, validate verification levels, parse attestation arrays, walk delegation chains.

  • Runtime dependencies: @noble/ed25519 and @noble/hashes only
  • Apache 2.0, Node 24+
  • Byte-matches Envoys signature/v1 §13 Vectors 1, 2, 3

Canonical conformance suite

Pinned vectors and composition fixtures. Independent Node and Python reference verifiers. No dependency on any A2A-IDF implementation library.

  • Node verifier uses node:crypto only
  • Python verifier uses the cryptography library only
  • Cross-suite byte-match assertions against the Envoys §13 vectors

AIM reference implementation

OpenA2A Identity Manager. Production agent identity server with Ed25519 message signing, JCS canonicalization, and W3C DID Document resolution.

  • Ships the same primitives the spec describes
  • Validates fixtures from the conformance suite end-to-end
  • No privileged position in the specification

Run the conformance suite

bash
git clone https://github.com/opena2a-org/a2a-idf-conformance.git
cd a2a-idf-conformance
node scripts/verify.mjs fixtures/composition/aim-did-rfc9421/signature-alone.json
# PASS  fixtures/composition/aim-did-rfc9421/signature-alone.json

The same fixture passes in both the Node and Python reference verifiers, and its expected signature byte-matches Envoys signature/v1 §13 Vector 1 by construction. Substituting the Envoys §6 compact-form key document for the W3C DID Document at the keyid URL leaves the wire signature unchanged.

Layered split endorsed across implementers

The four-layer A2A identity stack with A2A-IDF as the identity-framework layer is the consensus of the active implementer chain on a2aproject/A2A.

@aeoessAPS + CTEF author

Crystallized the four-layer split on 2026-05-11 with three peer endorsements.

@jschoemakerEnvoys author (#1829)

Owns the wire-signature layer. Published the §13 reproducible test vectors A2A-IDF byte-matches against.

@kenneivesCTEF v0.3.x release manager

Coordinates the cross-thread release cadence for the four-layer stack.

@lawcontinueHippo author

Ships the reference Ed25519 library against #1829. Contributed the tag parameter and SHA-512 acceptance to A2A-IDF §6.

Specification trajectory

Public roadmap so implementers can plan around the timeline. Versions follow the A2A protocol release cadence.

v1.0
Current proposal

Verification levels 0/1/2, dual-shape keyid resolution, attestation array shape, delegation chain envelopes, RFC 9421 + Ed25519 wire signatures.

v1.1
Vouching attestations

Formalize issuer / vouchee / scope / expiry shape for cross-issuer attestation chains.

v1.2
Federated revocation

Append-only revocation registry design with CT-style transparency. Subset of issuers operate as log witnesses.

v2.0
Post-quantum signatures

Algorithm agility framework. Hybrid Ed25519 plus ML-DSA-65 keying and migration story.

Get involved

The reference SDK and conformance suite are under active development. The npm registry release of @opena2a/a2a-idf follows the composition fixture set landing in the conformance suite and this page going live. See the #1829 coordination thread for the latest cycle status.