a2aproject / a2aproject/A2A

[Feat]: Specify a Payment Evidence Frame for payment lifecycle receipts in task artifacts

Open
#2,070 4 comments 0 reactions 0 assignees View on GitHub
Dominant language
Shell
Stars
25.7k
Forks
2.6k
Avg merge
3d 6h
Merged PRs (30d)
16

Description

### Is your feature request related to a problem? Please describe.

When a payment agent returns a receipt as a task artifact, an orchestrator has no documented, transport-agnostic way to do three things without parsing the inner domain format:

- identify what kind of payment receipt the artifact carries
- hold a stable reference identifier that survives re-serialisation and late signing
- detect tampering of the wrapped receipt

The docs specify Artifacts and Parts, but there is no page describing an envelope for payment lifecycle evidence carried inside them. Implementations are inventing their own wrappers, which do not interoperate.

### Describe the solution you'd like

Add a docs/topics page specifying a Payment Evidence Frame: a JSON envelope with a closed claim_type enum covering the payment lifecycle, a deterministic frame_id derived as SHA-256 over a JCS (RFC 8785) canonical preimage that excludes frame_id and signature, and an annotated example conforming to the Artifact and Part schema in a2a.proto.

Excluding the signature from the preimage is the load-bearing detail: it keeps a recorded frame_id valid when a frame is signed after the identifier has already been referenced elsewhere.

### Describe alternatives you have considered

Leaving the envelope to each implementation. That is the current state, and it is what produces the incompatible wrappers described above.

Putting payment receipt fields directly into the Agent Card or a registry record. That places lifecycle evidence in standing identity fields, which is the wrong lifetime for per-transaction data.

### Additional context

This is scoped strictly to payment lifecycle evidence. It is deliberately not a general admission or attenuation frame. The broader question of where verifier-side trust, permit, and receipt artifacts should live relative to A2A is #1769 and is not resolved by this.

Normative references: RFC 8785 (JCS), RFC 9421 (HTTP Message Signatures), and the Internet-Draft draft-hopley-x402-payment-evidence-frame.

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.