A signature is not trust: three silent questions in the agent protocol stack

Sources cited in this piece · A2A official specification a2aproject/A2A · W3C AI Agent Protocol Community Group technical report (2026-09-24) · Sister pillars: rttp:// (CRI 27) · iqa:// (CRI 28)

In 2026, signatures are everywhere. A2A added JWS signatures to Agent Cards; AP2 — Google together with dozens of payment institutions — wraps every transaction into verifiable mandates; MCP delegates authorization to OAuth. The signature has become the default answer of the agent world — and a default answer deserves to be read carefully against the full list of questions.

Our verdict, given up front: a signature answers two questions, while the complete list has three. The mainstream stack answers the first two, leaves the third to the deployment environment, and never even asks the second.

1. What a signature answers

The A2A official specification is candid: Agent Cards "MAY be digitally signed using JSON Web Signature (JWS) ... to ensure authenticity and integrity. Signatures allow clients to verify that an Agent Card has not been tampered with and originates from the claimed provider." Two gains: integrity — the content was not altered; attribution — the signer is indeed the claimed signer. That is the respect cryptographic signatures deserve, and we discount none of it.

But pause on that word: "claimed" provider. What a signature verifies is never "who it is," only "it is who it claims to be." The distance between the claim and the fact is a distance the signature cannot walk by itself.

2. The three silent questions

First: what makes the claimant trustworthy? Where does the signing key's authority come from? A2A's default answer is TLS — clients "SHOULD verify the A2A Server's identity by validating its TLS certificate against trusted certificate authorities." And the W3C September report already named this layer's ceiling: certificates verify domain ownership, not individual agent identity; multiple agents on the same domain share a single certificate. The key's authority is entrusted to the inherited Web trust system — not an error, an inheritance.

Second: does trust expire? Is a card verified today still valid tomorrow? TLS certificates expire, OAuth tokens lapse — but the state of "whether an agent is still trustworthy right now" has no carrier in the protocol stack. Trust got signed into permanence, and the world is not permanent.

Third: can the verifier verify independently? Verifying a signed card requires reaching certificate authorities, DNS, OAuth servers — the whole trust chain must be online. With the network cut, censored, or isolated, can verification still complete? Does the power to verify rest with the infrastructure, or with the verifier?

3. Three questions, our paper

Identity Quality Assurance (IQA) is the second pillar, and it was designed for the three silent questions.

On the first, we open no new bank and claim no identity: address derivation (the WHERE of the Resonant Time Transfer Protocol) and identity are two different things — a self-consistent fresh keypair fools no one. What iqa:// does is write "who vouches for this statement" into the envelope itself: the vouching subject, the organ, the scope — all fields verifiable inside the envelope, not hearsay outside it. The verifier needs to trust no registry, only a key.

On the second, trust holds a lease: every envelope carries a 120-second freshness window (standing), a closed set of four states — ghost / probation / radiant / genesis. Fail to renew and you lapse into ghost — trust is not signed into permanence; it is re-earned every 120 seconds.

On the third, the three offline tests: verifiable with the network cut, verifiable in survival scenarios, and reproducible by any third party under their own interpretation. Zero network, zero third parties, fail-closed — malformed input quietly stops verifying; REJECT is a conclusion, not an exception. Verify a piece of evidence with your own hands in thirty seconds — see the previous tooling piece.

4. Not an indictment — a relay

To be clear: A2A's signing is a "MAY," not a "MUST" — the door is left open; the W3C report listed verification among its requirements and conceded that the current stack carries no trust in content. The three silent questions are not our accusation against anyone; they are the industry's shared next exam. A signature is a necessary condition, not a sufficient one — just as the wax seal on a letter proves it was never opened, but does not prove the writer is still alive, still at the same address, and still standing behind every word.

rttp and iqa are provisionally registered at IANA (2026-09-22 / 2026-10-13). The exam paper is here: prov/iqa; the specification is draft-li-rttp-iqa-addressing-00. Word-by-word review is welcome.

Sources　[1] A2A official specification (a2aproject/A2A · docs/specification.md), §8.4 signature clauses and TLS verification clause; quotations taken verbatim from the archived copy　[2] W3C AI Agent Protocol Community Group technical report, 2026-09-24 (TLS domain-vs-entity, OAuth O(N²) passages)　[3] AP2 (Google, announced 2025-09): the mandate mechanism is described here from consistent public secondary accounts; no official AP2 specification text is quoted, and this is labeled as such　[4] IANA URI Schemes registry, verified 2026-10-17.

One line: the seal proves the letter was never opened — what we add is the verifier's ability to conclude, owing nobody anything, that the writer is still standing behind every word, right now.