Protocol

Verifiable Intent

Mastercard Verifiable Intent

A Verifiable Intent mandate signs the hash of a checkout that carries the ATR hash. Source: lcp docs: agentic checkouts⁠ (opens in a new tab) The Agentic Transaction Record (ATR) is one record of exactly what was agreed, for one transaction. Its ATR hash, the ATR’s fingerprint, is the proof bound to the transaction: change one byte of the ATR and it no longer matches. Source: lcp docs: the ATR⁠ (opens in a new tab) · Source: lcp docs: the ATR hash⁠ (opens in a new tab)

Verifiable Intent was co-developed by Mastercard and Google and contributed to the FIDO Alliance. Source: LCP §C.7⁠ (opens in a new tab) Integra is not affiliated; we read their published interfaces.

lcp docs: agentic checkouts⁠ (opens in a new tab) · lcp docs: the ATR⁠ (opens in a new tab) · lcp docs: the ATR hash⁠ (opens in a new tab) · LCP §C.7⁠ (opens in a new tab)

The protocol’s own site⁠The standard’s illustration of this protocol (LCP §C.7)⁠

Verifiable Intent

Consumer authorization for agent payments

The merchant’s checkout: The ATR hash, as its legalContext.
The mandate: Signs the hash of that checkout.

What it is

Verifiable Intent is an open-source cryptographic framework for consumer authorization in agent-initiated transactions, designed to work with AP2, in layered credentials: identity, the user’s intent, and the agent’s action. Source: LCP §C.7⁠ (opens in a new tab)

LCP §C.7⁠ (opens in a new tab)

Where the ATR hash rides

The mandate signs a checkout that carries the ATR hash.

Exhibit Where it rides, in the protocol’s and the package’s terms

The standard

A legal-context constraint inside a mandate would need registering: verifiers must reject open mandates carrying a constraint type they do not recognize. Source: LCP §C.7⁠ (opens in a new tab)

The package

The ATR hash rides in the merchant’s checkout_jwt as its legalContext, and a mandate signs that JWT’s SHA-256 as checkout_hash: the user’s mandate in Immediate mode, the agent’s checkout mandate in Autonomous mode. Source: lcp docs: agentic checkouts⁠ (opens in a new tab)

In Autonomous mode the seller verifies the user’s and the agent’s signatures and their links, but not the identity issuer’s; in Immediate mode it checks the values and leaves the user’s signature to the payment network. Each pairing’s record says which. Source: lcp docs: agentic checkouts⁠ (opens in a new tab) · Source: lcp docs: pairings reference⁠ (opens in a new tab)

What a payment through it proves

Each pairing’s record states what a payment through it shows, and what it does not, in the package’s own words. These are read from the package when the site is built. Source: lcp docs: pairings reference⁠ (opens in a new tab)

Of these 2 pairings, 2 have the buyer’s signature cover the ATR hash, 0 leave a public proof of it, and 0 let anyone read it back from the chain alone. Source: lcp docs: pairings reference⁠ (opens in a new tab)

Switch to Technical to see each pairing, and the sentence its record states about what a payment through it proves.

lcp docs: pairings reference⁠ (opens in a new tab)

Exhibit Each pairing’s record

The package

Pattern: id-reuse, the package’s name for it
What a payment through it proves: Before this payment, the buyer signed and paid an agreement transaction carrying this ATR's hash on <network>, recorded in <transaction>. The buyer's agent signed a Verifiable Intent L3b checkout mandate whose checkout_hash is the SHA-256 of a checkout_jwt carrying this ATR's hash, with the key the user's L2 mandate delegates to it. The seller verified both ES256 signatures and the sd_hash links, but not the L1 issuer's signature. The user's own signature does not cover the hash, and the seller did not see the L3a payment mandate the network received, whose transaction_id Verifiable Intent requires to equal this checkout_hash. This does not show that amount, payee or timing match the ATR's content.
LCP profile: card/mastercard-vi⁠ (opens in a new tab)
Pattern: id-reuse, the package’s name for it
What a payment through it proves: Before this payment, the buyer signed and paid an agreement transaction carrying this ATR's hash on <network>, recorded in <transaction>. The user's Verifiable Intent L2 mandate lists a checkout mandate whose checkout_hash is the SHA-256 of a checkout_jwt carrying this ATR's hash, and the payment mandate's transaction_id, where disclosed, equals it. The seller checked those values and did not verify the user's signature, which Verifiable Intent has the payment network validate before authorization. The card authorization itself does not carry the hash. This does not show that amount, payee or timing match the ATR's content.
LCP profile: card/mastercard-vi⁠ (opens in a new tab)

Where a sentence names <network> and <transaction>, the pairing’s record fills them in: they name the agreement payment the buyer made first. Source: lcp docs: pairings reference⁠ (opens in a new tab) · Source: lcp docs: the agreement URL⁠ (opens in a new tab)

The rails it settles on

Card networks

Ready to see your own agreements proved?

Tell us what you sell, buy or carry, and we will show you where the agreement rides in it.

Integra Binder, hosted by Integra, does the seller’s side of each agreement and is free on test networks, with test-network USDC.

Talk to us