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

[tomjwxf]

This bilateral pattern is useful. My original framing was single-receipt, but I agree the stronger audit shape is two-sided: pre-execution authorization receipt plus post-execution outcome receipt, each signed by the responsible party.

For TAP specifically, I would keep RFC 9421 for the request/authentication layer and use detached JWS over JCS-canonical receipt payloads for the transaction evidence layer, so the two trust claims do not get conflated.

[arian-gogani]

@tomjwxf agreed on keeping the two layers separate. RFC 9421 for authentication, detached JWS over JCS-canonical for the receipt evidence layer. that's exactly how nobulex structures it today.

the JCS-canonical receipt approach is also converging as the standard across other ecosystems. the x402 compliance spec (x402-foundation/x402#2322) just landed a MUST for JCS canonicalization on all signed receipts, and eight implementations have cross-validated byte-identical output against the CTEF v0.3.1 conformance set.

happy to share a specimen receipt payload so you can see the concrete shape and test it against TAP's existing signature infrastructure.

[tomjwxf]

@arian-gogani yes, that split matches the shape I think TAP should keep: RFC 9421 for request authentication, detached JWS over JCS-canonical payloads for transaction evidence.

I added a narrow TAP specimen fixture here so this can be tested concretely:

ScopeBlind/agent-governance-testvectors#8

It contains:

• tap-request.json: simulated TAP request context with RFC 9421 signature metadata
• authorization-receipt.json: agent-signed pre-execution authorization receipt
• outcome-receipt.json: merchant/proxy-signed post-execution outcome receipt
• keys.json: deterministic Ed25519 public keys
• verify.py: verifies both detached JWS-style signatures, checks both receipts bind to the same TAP request hash, and checks the outcome receipt chains to the authorization receipt

Run:

python3 tap-bilateral-receipts/verify.py

Expected:

PASS authorization receipt signature
PASS outcome receipt signature
PASS request hash links both receipts to the TAP request
PASS outcome receipt chains to authorization receipt

This is intentionally not a TAP-core change proposal. It is a test vector for the evidence layer that can sit after TAP authentication without overloading RFC 9421 with transaction-proof semantics.

If you can share a Nobulex specimen receipt, I can add it as a second fixture or compare it against this one so the thread has a concrete interop target rather than just agreeing at the architecture level.

[arian-gogani]

@tomjwxf specimen receipt is at fixtures/composition/nobulex-cross-validation/ in aeoess/aps-conformance-suite. the shape: Ed25519 detached signature over JCS-canonical JSON payload, bilateral (agent signs pre-execution authorization, counterparty signs post-execution outcome), hash-chained for ordering.

happy to add it as a parallel fixture alongside your TAP bilateral receipt test vectors at ScopeBlind/agent-governance-testvectors#8. same JCS canonicalization, same Ed25519 key material pattern, same bilateral split.

the difference worth testing: nobulex receipts chain over time into Trust Capital -- a composite score that gates the agent's future autonomy. the TAP fixture proves one transaction was authorized and processed. the nobulex chain proves the agent's full behavioral history is tamper-evident, and that history becomes an economic asset (higher score = bigger limits, lower premiums). the interop question is whether both receipt shapes can feed the same downstream trust graph.

will push a TAP-shaped nobulex specimen this weekend.

[tomjwxf]

@arian-gogani sounds good. I will keep ScopeBlind/agent-governance-testvectors#8 as a draft until the Nobulex specimen is available.

Once you push it, I can add it as a parallel fixture beside the TAP bilateral receipt vector and make the comparison explicit:

• TAP fixture: one transaction was authorized and processed
• Nobulex chain: behavioral history accumulates into a trust graph / Trust Capital surface
• Shared invariant: detached Ed25519 over JCS-canonical JSON, request/outcome split, hash-linked evidence

The interop test I would want is narrow: both shapes normalize into the same downstream graph interface without erasing the distinction between single-transaction evidence and longitudinal reputation evidence.

No TAP-core change implied. This stays an evidence-layer conformance fixture unless the TAP maintainers ask for a protocol hook.