Visa TAP Integration

This section is advisory and non-prescriptive. It describes what the host protocol permits, read from its own primary artifact. Where this page and the host protocol disagree, the host is correct — build from its schema, not from an example here.

---

What it is. A framework for agent-initiated transactions, built on HTTP Message Signatures [RFC 9421]. Uses a three-signature model establishing agent identity, consumer identity, and payment authorization. Two body objects — the Agentic Consumer Recognition Object and the Agentic Payment Container — each carry their own signature made with the same private key as the HTTP message signature and signing the same nonce present in that signature; a nonce mismatch invalidates the binding even when the object's own signature verifies.

Tier B — Forward work. A clean integration point for an LCP reference is either (a) inside one of the existing signed body objects (which the spec's extension clause permits), or (b) as a sibling object with its own nonce/keyid/alg/signature quartet that mirrors the existing objects' signature pattern — note keyid, not kid, per [RFC 9421]. Both paths require coordination. A bare { type, value } sibling without its own signature quartet does not inherit the signature chain and would be silently replaceable.

Tier A — Available today. A custom HTTP header (e.g. X-LCP-Hash) carrying atrHash is available without coordination. It is unbound: TAP's covered components are the request authority and path ("@authority" "@path"), so a custom header sits outside the signature and any party in the path may alter it undetectably. A deployment relying on the header alone SHOULD describe it as advisory (§8.3.7), never as bound. To be cryptographically bound to the agent's identity, the header must be added to the Signature-Input covered components — itself a coordinated extension.

Limitations. TAP's signature chain is structurally binding; ad-hoc additions outside the chain provide no integrity protection. Integration must respect the signature topology. TAP publishes no extension registry and no change-management process — its only extensibility language contemplates an agent or a payment scheme optionally defining additional fields within the signature — so any integrity-bearing LCP placement is a coordinated arrangement rather than a specification filing.

Steward invitation. The TAP stewards are invited to publish guidance on a registered LCP integration point — either inside an existing body object or as a new signed body object — and on the covered components a deployment should add to the signature scope.