RFC: Transaction receipt signing for post-authentication audit trail

[tomjwxf]

TAP solves the "is this agent legitimate?" question with RFC 9421 signatures. Once the agent is authenticated and the merchant processes the transaction, though, neither party has a cryptographic record of what actually happened.

For regulated commerce this creates a gap: the agent proved its identity at request time, but there is no tamper-evident receipt of the transaction itself. In a chargeback dispute or compliance audit, the merchant has logs, but logs are mutable. The agent has nothing.

Proposed extension: a lightweight receipt that the merchant (or a TAP-aware proxy) signs after processing a verified agent request.

The receipt would contain:

• The original TAP signature (binding it to the authenticated request)
• A hash of the transaction payload (what was actually processed)
• Merchant signature over both (proving the merchant saw and processed this specific request)
• Timestamp and sequence number (ordering guarantee)

This creates a two-sided audit trail: the agent proves it was authorized (via TAP signature), and the merchant proves what it processed (via receipt signature). Either party can verify the other's claims offline.

I built a working implementation of this receipt pattern for a different context (MCP tool-call signing): examples/deerflow-receipts. The core is Ed25519 signing with JCS canonicalization (RFC 8785), which would map cleanly onto TAP's existing signature infrastructure.

Two design questions worth considering:

1. Who signs the receipt? The CDN proxy is the natural candidate since it already intercepts and verifies TAP signatures. Alternatively, the merchant backend could sign after processing.

2. Receipt format: TAP already uses RFC 9421 for request signatures. Should receipts reuse the same signature format (keeping everything in the HTTP Message Signatures family), or use a simpler detached JWS envelope?

Happy to prototype a receipt-signing extension for the CDN proxy if there is interest.

[arian-gogani]

This is exactly the pattern we've built and validated across multiple implementations. Nobulex (@nobulex/crypto) produces bilateral Ed25519 receipts with JCS canonicalization (RFC 8785) — one signature before execution binding the authorized scope, one after binding the actual outcome, hash-chained for ordering.

On your two design questions:

1. Who signs the receipt? Both parties. The bilateral pattern is stronger than single-signer because it creates two independent evidence trails. The agent's pre-execution signature proves what was authorized. The merchant's (or proxy's) post-execution signature proves what was processed. Neither can forge the other's. In a chargeback dispute, both signatures are independently verifiable without contacting either party.

2. Receipt format: Detached JWS over JCS-canonical JSON. We tested both paths — reusing RFC 9421 for receipts (your option A) adds unnecessary HTTP-binding semantics to a payload that doesn't need them. A detached JWS envelope with JCS-canonical content is simpler, produces byte-stable hashes across implementations, and composes cleanly with TAP's existing RFC 9421 request signatures without conflating the two layers.

The receipts also chain: each receipt carries the hash of the previous one, so the full history is tamper-evident. Over time, this chain forms what we call Trust Capital — a verifiable reputation that can gate future transaction limits, insurance eligibility, and access controls.

We've cross-validated the canonicalization across four independent implementations (Python + TypeScript), and the bilateral receipt primitive is merged into Microsoft's Agent Governance Toolkit (PRs #1302, #1333). The CTEF v0.3.2 spec (publishing May 19-22) defines the envelope shape for this exact use case.

Happy to coordinate on aligning the receipt format with TAP's existing signature infrastructure. The composition should be natural — TAP handles authentication at request time, the receipt layer handles evidence at execution time.

Repo: https://github.com/arian-gogani/nobulex
Cross-validation: a2aproject/A2A#1734

— Arian