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.