All posts
· 10 min read ·

A2A's Signed Agent Cards bind a card to a key. They don't bind the key to anyone.

A2A 1.0 named cryptographic identity verification as a headline feature. The spec text standardizes the JWS signature format and leaves the trust decision about the signing key to the verifier. The two are not the same thing.

The A2A 1.0 release announcement describes Signed Agent Cards in one sentence: "Signed Agent Cards provide cryptographic verification of agent identity and metadata, establishing trust before interaction." That sentence is technically true and operationally misleading. The specification it points to (section 5.5.6 of the A2A v0.3 spec and its successors) defines AgentCardSignature as a JWS (RFC 7515) signature over the card. What the JWS proves is that the holder of a private key signed this card. What the JWS does not prove, and what the spec does not specify, is who the holder of the private key is.

The distinction matters because a verifier reading "Signed Agent Card" in a press release will reasonably assume the second property. The spec text confirms only the first. Until something else in the stack closes the gap, the signature is a useful integrity check and not an identity guarantee.

What the spec actually standardizes

Section 5.5.6 of A2A v0.3.0, carried forward into 1.0 and 1.2, defines the signature object:

AgentCardSignature represents a JWS signature of an AgentCard. This follows the JSON format of an RFC 7515 JSON Web Signature (JWS).

The signature object has three fields: protected (Base64url-encoded JWS header), signature (the signature bytes), and header (optional unprotected JWS header values). The example in section 5.7 includes a jku header (a URL where the signer's public key set lives), but the specification does not normatively require jku and does not specify how a verifier should resolve, validate, or trust that URL.

What this means in practice: a verifier handed a Signed Agent Card can do three things mechanically. It can confirm the JWS is well-formed. It can fetch the public key (if jku is present) and confirm the signature verifies. It cannot, from the spec alone, answer the question "should I trust the key I just fetched?"

The verification chain, drawn out

A2A Signed Agent Card verification chain A vertical flow showing the steps a verifier walks through when validating a Signed Agent Card. Step 1: parse the JWS. Step 2: fetch the signer's key (if a jku header is present). Step 3: verify the signature against the card content. Step 4 is rendered with a dashed pink outline to indicate "out of scope" — the trust decision about whether the key actually represents the claimed agent identity. Annotations note that the first three steps are spec-defined; the fourth is not. A2A SIGNED AGENT CARD · VERIFICATION CHAIN 1. Parse the JWS protected · signature · header are well-formed (RFC 7515) spec §5.5.6 2. Resolve the signer's public key fetch from jku URL (if present); spec does not require jku spec example only 3. Verify the signature against the card confirms the holder of this key signed this card spec §5.5.6 4. Decide whether to trust the key is this key actually controlled by the claimed agent operator? is the operator who they say they are? OUT OF SCOPE

STEPS 1–3: SPEC-DEFINED · STEP 4: VERIFIER'S PROBLEM

The first three rows are what the spec actually buys. The fourth row is the trust decision, and the spec is explicit only in its silence about it. A verifier that has completed steps 1–3 has learned that the card they hold was signed by some key. They have not learned anything about the agent the card describes.

What the community already noticed

This is not a contrarian read. The A2A project's own issue #1672, filed on March 22, 2026, names the gap in the proposer's own words: "identity verification is currently left to external mechanisms" and "there is no standardized way for a receiving agent to cryptographically verify who it is communicating with." The proposal (adding an optional verifiedIdentity field with an embedded certificate and a real-time verification endpoint) is a concrete acknowledgment that the Signed Agent Card alone does not do what the announcement copy says it does.

The referenced implementation in that issue uses ECDSA P-256 certificates and a separate AgentID registry to bind the key to a human-readable identity. That is the architecture that closes the loop. It is also not part of the A2A specification today.

Why the gap was always going to be here

The omission isn't sloppy spec drafting. JWS as a primitive is correct for what it does: it standardizes how to express a signature in a JSON-friendly format. The trust model around the key is a separate concern, the same way TLS standardizes the handshake but defers root trust to a certificate authority ecosystem governed elsewhere. A2A inherited the same architectural decomposition. The difference is that TLS arrived with a mature CA ecosystem already in place; A2A arrived with the CA equivalent still being prototyped.

The candidates for the missing layer are by now familiar from earlier in this blog. ERC-8004's three-registry design gives an on-chain Identity Registry that could anchor an A2A signer key to a portable agent identifier. The MCP server card registry operated by the Agentic AI Foundation gives a hosted publication surface for the same kind of binding. The AgentID approach proposed in A2A #1672 gives a PKI-style certificate layer with a verification endpoint. None of them is canonical yet. Until one is, an A2A verifier that wants more than JWS-correctness has to choose its own trust model.

What this means for the registry layer

A registry that publishes Signed Agent Cards faces a clean editorial choice. It can publish the signature and call the agent "verified," which is what the JWS allows it to do narrowly. Or it can publish what it actually probed: the signature verified, the jku URL resolved to this key set, the key matches an Identity Registry entry at this address, the agent at the card's stated endpoint responded today. The first is faster. The second is the trust statement a downstream consumer can act on.

The split we've described before between "the card claims compliance" and "the probe confirmed behavior" applies identically here. A Signed Agent Card is an integrity claim about a single JSON document. A registry that treats it as more than that is making a trust claim the underlying signature does not carry. A registry that treats it as exactly that, and pairs it with probe data about the agent's actual behavior, is doing the work the spec leaves out.

What we're watching

Three things, observable within the next two quarters:

  1. Whether A2A 1.3 or later promotes a key-resolution mechanism to normative MUST. A specified mapping from jku URL to an agent identity registry (whether the AAIF's hosted one, ERC-8004's on-chain one, or both) would let a verifier complete Step 4 mechanically rather than as a per-deployment policy choice.
  2. Whether the verifiedIdentity field proposed in #1672 lands in the spec. The proposal is concrete, backward-compatible, and points at a reference implementation. Its trajectory through the working group will indicate how much appetite exists for closing the identity gap within A2A itself rather than deferring to a different layer.
  3. Whether enterprise A2A deployments start publishing the probe of their own Signed Agent Cards alongside the cards themselves. A server that publishes "the jku URL for our signing key is X, verified by Y at time T" gives consumers a starting point for verification that the JWS alone does not.

A2A 1.0 was the first agent-protocol release to make identity verification a headline feature. The headline was correct as a direction and incomplete as a specification. The gap between marketing claim and spec text is now the working surface area for the next revision.

Sources

← Back to blog Agenstry