Visa TAP

This section is advisory.

Visa TAP is an open framework built on RFC 9421 HTTP Message Signatures, co-developed with Cloudflare. It uses a three-signature model to establish agent identity, consumer identity, and payment authorization in every transaction. The protocol, its specifications, and a reference implementation are publicly available on the Visa Developer Center and GitHub.

Three-Signature Model

TAP applies signatures during two interaction types: browsing (agent-browser-auth tag) and payment (agent-payer-auth tag). Each interaction can include three signed components:

1. Agent Recognition Signature — HTTP header signature proving the agent is Visa-trusted, domain-bound, time-bounded (max 8 minutes), and replay-protected via nonce
2. Agentic Consumer Recognition Object — request body containing consumer identity (JWT idToken with obfuscated email/phone) and contextual data (country, postal code, device), signed with the same private key and nonce as the agent signature
3. Agentic Payment Container — request body containing payment data (credential hash, encrypted payload, or browsing IOU), also signed with the same key and nonce

Primary Integration — Request Body with Linked Signature

TAP's body objects (Consumer Recognition, Payment Container) are each independently signed with the same private key and nonce used for the HTTP Message Signature, creating a cryptographic chain linking all components. The recommended integration follows this same pattern — include the LCP reference in the TAP request body and sign it with the same key and nonce:

{
  "consumerRecognition": { ... },
  "paymentContainer": { ... },
  "legalContext": {
    "type": "sha256",
    "value": "0x7f83b165..."
  }
}

The shared key and nonce cryptographically bind the legal context to the agent identity, consumer identity, and payment data — proving not only who initiated the transaction and that they were authorized, but also what terms governed it. This follows the same signature-linking pattern TAP uses for its existing body objects.

Alternative — Custom Header in Covered Components

Include X-LCP-Hash as a custom header. If added to the TAP signature's covered components in the Signature-Input header, it would be cryptographically bound to the agent's identity. This is simpler but carries only the hash, not structured legal context.

Note: Adding custom headers to TAP's covered components would require a coordinated extension to the TAP specification.

Browsing IOU Integration

TAP's Browsing IOU mechanism (HTTP 402 deferred payment) creates a credit relationship — the merchant grants access with the expectation of later settlement. This deferred obligation is precisely the kind of temporal commitment that benefits from LCP: the IOU should reference specific terms governing the deferred payment, including what happens if settlement fails.