A2A Signed Agent Card verification chain

--- title: "A2A's Signed Agent Cards bind a card to a key. They don't bind the key to anyone." date: 2026-05-19 summary: "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." slug: a2a-signed-cards-key-not-identity author: "Sebastiaan Hilbers" hero_glyph: nodes --- The [A2A 1.0 release announcement](https://a2a-protocol.org/latest/announcing-1.0/) 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](https://a2a-protocol.org/v0.3.0/specification/) 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](https://a2a-protocol.org/v0.3.0/specification/) 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 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](https://github.com/a2aproject/A2A/issues/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](https://agenstry.com/blog/erc-8004-three-registries-honesty) gives an on-chain Identity Registry that could anchor an A2A signer key to a portable agent identifier. [The MCP server card registry](https://github.com/modelcontextprotocol/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](https://agenstry.com/blog/mcp-spec-vs-probe-evidence) 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](https://github.com/a2aproject/A2A/issues/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 - [Announcing A2A v1.0](https://a2a-protocol.org/latest/announcing-1.0/) — A2A Protocol Project, 2026. - [Agent2Agent (A2A) Protocol Specification v0.3.0](https://a2a-protocol.org/v0.3.0/specification/) — A2A Protocol Project, accessed May 2026. - [Agent2Agent (A2A) Protocol Specification — current](https://a2a-protocol.org/latest/specification/) — A2A Protocol Project, accessed May 2026. - [Proposal: Agent Identity Verification for Agent Cards — issue #1672](https://github.com/a2aproject/A2A/issues/1672) — a2aproject/A2A on GitHub, March 22, 2026. - [ERC-8004: Trustless Agents](https://eips.ethereum.org/EIPS/eip-8004) — Marco De Rossi, Davide Crapis, Jordan Ellis, Erik Reppel, Ethereum Improvement Proposals, August 13, 2025. - [Model Context Protocol Registry repository](https://github.com/modelcontextprotocol/registry) — modelcontextprotocol/registry, accessed May 2026.