A2A extension https://fractalai.net.co/a2a/ext/pqc-receipt/v1: payment-bound delivery receipts on Artifacts

[johnInarti]

Author: John Edward Romo Sanchez (FractalAI, KPITAPP SAS). Drafted with AI assistance (Claude).

What it does

When an agent delivers an Artifact for a paid task, it attaches a receipt:

artifact.extensions += ["https://fractalai.net.co/a2a/ext/pqc-receipt/v1"]
artifact.metadata["https://fractalai.net.co/a2a/ext/pqc-receipt/v1"] = <agent-commerce-receipt>

• delivery.sha256 = sha256(JCS(artifact.parts)). The receipt binds exactly the parts the client received; metadata
  is excluded.
• payment and bindings carry the identifiers and hashes of the payment protocol in use. The first profile is AP2
  v0.2: the hashes of the ES256 Payment/Checkout Receipts, their reference, payment_id and order_id.
• Agents advertise support in AgentCard.capabilities.extensions[] (required: false). Clients activate it with
  A2A-Extensions.
• The signature is ML-DSA-65 (FIPS 204). Verification uses an open kernel (spec, JS and Python implementations,
  217-vector corpus).

Why an extension

A2A has no delivery receipt. AgentCard.signatures covers the card, not what was delivered. Following the A2A
guidance, the extension only uses metadata and extensions. No core field changes.

Evidence

src/a2a.ts, test/ap2-a2a.test.ts: 9/9 tests with real AP2 artifacts generated by the official AP2 SDK. A tampered
artifact, a substituted payment receipt, a forged payment_id and the wrong key use are all detected.

Limits

• The extension URI is FractalAI's own, and the page that documents it still has to be published.
• No production signing key with use commerce-receipt is published yet.
• The receipt does not judge the quality of the work.

Code, tests and examples: https://github.com/johnInarti/pqc-receipts-colosseum/blob/main/integrations/universal-proof/
Open verifier and spec (Trust Kernel v2, spec 2.2): https://github.com/johnInarti/pqc-receipts-colosseum

[kaspermuutra-dotcom]

Nice. Binding the receipt to sha256(JCS(artifact.parts)) with the payment hashes closes a real gap: A2A has no delivery receipt, and AgentCard.signatures only covers the card. Your stated limit, "the receipt does not judge the quality of the work", points at the complementary piece: a separately signed check of whether the agent's skills behave as its card declares, which a buyer could consult before paying, while your receipt proves what was delivered after. Have you considered an optional field in the receipt for referencing such an external attestation by digest?

Kasper

[johnInarti]

Thanks, Kasper. Yes, that is a useful addition. We are considering an optional capability_attestation reference containing the attestation digest, issuer, key identifier, resolution URI, algorithm, issuance time and expiry. The delivery receipt would remain evidence of the artifact delivered and payment binding; the external attestation would remain a separate capability and conformance claim. This keeps receipt verification independent from quality endorsement while allowing buyers to verify capabilities before payment.