Proposal: Content Integrity Profile for A2A artifacts (hash + signature + schemaRef)
- Dominant language
- Shell
- Stars
- 25.7k
- Forks
- 2.6k
- Avg merge
- 3d 6h
- Merged PRs (30d)
- 16
Description
## Problem
A2A secures transport (HTTPS/SSE) and RPC, but artifact content itself (produced by tasks and streamed via SSE) lacks a portable integrity/provenance standard. Cross-hop verification, archival checks, and cache safety become vendor-specific.
## Proposal (optional → SHOULD)
Add OPTIONAL fields to Task artifacts and streamed artifact updates:
- `hash`: `sha256:<64-hex>` of canonical JSON (keys sorted ASC)
- `signature`: `{ alg: "ECDSA-secp256k1", value: "" }` over the 64-hex hash
- `schemaRef`: URI for JSON Schema of the artifact
- `links`: array of related artifact hashes for provenance chains
Backwards-compatible: existing clients/servers may ignore these fields.
## Benefits
- Portable verification across org boundaries and archives
- Safer caching and replay detection (content-addressed)
- Enterprise provenance & audit support without exposing internals
- Aligns with A2A’s opaque execution goal (verifiable, not inspectable)
## Deliverables I can contribute
- Spec PR: small edits to artifact sections + appendix “Content Integrity Profile v1”
- JS SDK helpers: `computeHash`, `signHash`, `verifySignature` + a tiny example
- Samples PR: minimal server/client showing signed artifact verification
## Prior art
This mirrors content-integrity rules we use in an independent protocol (Cube): canonical JSON → SHA-256 → ECDSA, with optional `links[]` for provenance. No dependency on Cube is required; this is a neutral A2A extension.
## Questions
- Preferred placement: fields on the artifact object vs. event wrapper?
- OK to reference W3C Trace Context for cross-service correlation?
- Any key-format guidance you want recommended (PEM/SPKI/PKCS8)?
Repo reference for prior art: https://github.com/Phil-Hills/cube-protocol-spec
Contributor guide
Assessment
This issue has not been assessed yet.