A2A extension: signed-receipts/v1

Draft 0.1 — a did:web key-trust convention for A2A §8.4, plus signed task-outcome receipts.

Extension URI
https://councilof.ai/a2a/extensions/signed-receipts/v1
Status
Draft, for the A2A two-tier extension path (experimental → official)
Specification
SPEC.md
Discussion
a2aproject/A2A#2150
Licence
Apache-2.0
Maintainer
CSOAI Ltd (Council of AI), UK company 16939677

The gap it closes

A2A v1.0 §8.4 standardises the envelope for AgentCard signing but deliberately leaves the trust root unspecified, and attestation of a task's outcome is unstandardised. Two agents can interoperate and still be unable to hand a third party durable evidence of what passed between them. Sigstore signs artifacts, not evaluations; SPIFFE binds workloads, not measurements; §8.4 signs cards, not outcomes.

AgentCard declaration

{ "capabilities": { "extensions": [ {
  "uri": "https://councilof.ai/a2a/extensions/signed-receipts/v1",
  "required": false,
  "params": { "issuer": "did:web:councilof.ai" }
} ] } }

What a receipt is, and is not

A receipt is evidence of what was claimed, and when, by the issuer. It is not a certification, an endorsement, or a conformity mark, and must not be presented as one.

That sentence is normative in the specification. It is why the extension adds an evidence channel without creating an authority.

What verifying a signature does not establish

Verifying establishes that the named key produced these bytes and that the bytes have not changed. It says nothing about the state of that key now. Offline verification is a computation over the parameters you hold; revocation is a property of the present. A consumer must not treat a signature that verifies as evidence that the signing key is still valid. Where a decision depends on revocation state, the key-resolution path and the staleness you accept are operational parameters of your deployment and must be stated by it; the receipt does not carry them. Recorded against our own verification rule as correction C-2026-0902-09.

Running code

interceptor.py — an ADK-style client/server interceptor. Offline card verifier: gspc-verify.mjs, Apache-2.0, zero dependencies, three states rather than two. Our published verification rule: HOW-TO-VERIFY.md.