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)

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.

Sources (1)

lcp docs: agentic checkouts⁠ (opens in a new tab)

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

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)

Sources (1)

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

Where the ATR hash rides

The mandate signs a checkout that carries the ATR hash.

The standard

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)

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)

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.

Sources (1)

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

The standard

card/mastercard-vi/autonomousId-ReuseBuyer signs H: yesH on chain: noPublic proof: noRecoverable from chain: no
Pattern: Id-Reuse (LCP §8.3.5)⁠ (opens in a new tab)
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)
card/mastercard-vi/immediateId-ReuseBuyer signs H: yesH on chain: noPublic proof: noRecoverable from chain: no
Pattern: Id-Reuse (LCP §8.3.5)⁠ (opens in a new tab)
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