Summary

  • OpenA2A AIP verifies a challenge response in two distinct stages: the signature proves possession of the presented key; a verifier registration or resolved DID document must prove that this key is bound to the claimed agentDid.
  • Revision 03 assigns different authority surfaces to provider-scoped did:web and ecosystem-scoped did:opena2a identities. Neither a self-declared purpose nor a capability claim supplies authorization or evidence of an external result.

The response looked exemplary. Its nonce had not been seen before. Its timestamp fell inside the five-minute window. The signature verified under the public key carried in the same JSON object. A dashboard could have turned green at that point.

The verifier rejected it.

The key was real, and the signature was valid. But the verifier's registration record did not bind that key to the agent identity named in the challenge. The cryptography had answered one question precisely: the responder possessed the private key corresponding to the presented public key. It had not answered a second question: was this the key that the claimed agent was entitled to use?

That distinction is the most consequential part of revision 03 of OpenA2A Agent Identity Protocol (AIP). The draft was posted on 2 October 2026 as an active individual Internet-Draft. It is not an RFC, an IETF working-group product, IETF consensus or evidence of a production deployment. The text requests Standards Track treatment, but intended status is an author declaration, not achieved standing. Revision 03 expires on 3 April 2027.

What the signature covers

The protocol begins with a verifier-generated challenge. The structure includes a 32-byte random challenge, the claimed agentDid, a 16-byte nonce, issuedAt, expiresAt, and issuerDid. Timestamps use UTC RFC 3339 form; the validity window is five minutes.

The agent signs a pipe-delimited UTF-8 string:

<challenge>|<agentDid>|<nonce>|<issuedAt>|<expiresAt>

The response then carries the signature alongside publicKey, keyId, signedAt and algorithm. Those four response fields are not part of the signed string. This is not automatically a defect: a verifier can still use a presented key to test possession. It becomes a trust failure only when an implementation treats that presented key as proof of its own authority.

Consider the circular rule: “accept the agent because the signature verifies under the key the agent supplied.” Any party capable of generating a key pair can satisfy it. The signature can be genuine while the identity claim remains ungrounded. A green cryptographic check therefore needs a provenance label: valid under presented key. It must not silently become valid for claimed agent.

Rule one and rule two

AIP's verification procedure keeps the questions separate. First, verify the signature under the response's public key. That establishes proof of possession for this challenge. Second, compare the presented key with the key already bound to agentDid in the verifier's registration data or in a resolved DID document. The draft explicitly says that the embedded publicKey must not be trusted alone.

Freshness and replay controls form additional gates. The response must remain inside the permitted time window, the nonce must be single-use, and issuerDid must belong to a trusted issuer set. None of them repairs a missing identity binding. A fresh, non-replayed signature from an unbound key is still a fresh, non-replayed signature from an unbound key.

The operating consequence is that a signature service and an identity resolver have different failure modes. Signature verification may be perfectly available while the resolver is stale, unreachable or compromised. Conversely, a correct DID document cannot rescue a malformed signature. Collapsing the two checks into one status erases the diagnostic evidence needed during an incident.

Revision 03 allocates naming authority

Revision 03 is a method-scoping change. Provider-scoped agent identities use did:web. In that model, the provider serves the DID document through the web resolution path. Control of the provider's domain, publication system, TLS termination and document lifecycle therefore becomes part of identity authority.

The draft reserves did:opena2a for ecosystem-scoped identities. The identity provider does not serve those documents. The older did:aip:aim_ form is described as a deprecated alias. Verification is expected to treat the identifier as opaque and send it to the applicable resolver rather than deriving trust from a familiar-looking prefix.

This is a governance decision disguised as a small namespace change. A provider-scoped identity can inherit the provider's availability and recovery procedures. An ecosystem-scoped identity needs a different resolution authority, update path and dispute mechanism. Silent fallback between them would let one trust domain speak for another.

The draft also notes that, as of 8 September 2026, its reference implementation's resolver answered only the deprecated alias form. That is an implementation note inside the draft, not evidence of current production behaviour. It does, however, expose a migration risk: a document can specify one identity scope while deployed resolvers recognise another. Leaders should ask which method actually resolved at decision time, not merely which identifier was printed in a log.

Attributes are not authority

AIP permits an agent to carry a type and an optional declaredPurpose. The draft draws a useful hard line. Type is informational and must not drive security decisions. Declared purpose may support identity or attestation context, but a verifier must not reject an agent merely because purpose is absent and must not use the declaration as an authorization input.

That restraint matters. “Procurement agent”, “research assistant” or “acts only for invoice review” can sound like policy. Unless independently attested and connected to an authorization decision, they remain assertions. The same applies to trust scores: inputs should be independently verifiable, not self-reported.

Identity binding is also not authorization. A correctly resolved key may belong to the named agent, while the requested action still exceeds its scope, budget or current mandate. Capability declaration is not capability exercise. Authorization is not execution. Execution is not proof that a bank, network, registry or delivery system reached the intended external state.

The disciplined evidence chain therefore has several receipts: challenge issuance, signature result, bound-key resolution, trusted-issuer decision, authorization decision, execution record and external outcome. Each receipt should say which question it answers. A single “verified” badge cannot carry them all.