[Feat]: Specify a Payment Evidence Frame for payment lifecycle receipts in task artifacts
- 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
Assessment
This issue has not been assessed yet.