Legal Context ProtocolVisa TAP Integration
Trusted Agent Protocol — RFC 9421 HTTP Message Signatures with three signed body objects; LCP integration via signed body objects or covered HTTP headers.
This section is advisory and non-prescriptive. The illustrations describe current possibilities and limitations rather than canonical shapes. The TAP stewards are invited to publish authoritative LCP integration guidance for the protocol.
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. Body objects (Consumer Recognition, Payment Container) are independently signed with the same private key as the HTTP signature.
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. 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. 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.
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.