Mastercard Verifiable Intent Integration
SD-JWT credential with up to three layers — LCP integrates as a custom Layer 2 constraint via URN naming.
This section is advisory and non-prescriptive. The illustrations describe current possibilities and limitations rather than canonical shapes. The Verifiable Intent stewards are invited to publish authoritative LCP integration guidance for the framework.
What it is
An open-source cryptographic framework for consumer authorization in agent-initiated transactions, co-developed by Mastercard and Google and designed to work with AP2. Mastercard contributed it to the FIDO Alliance for community governance in April 2026 — the same announcement in which Google donated AP2 (see AP2 Integration) — with standardization continuing in the FIDO Alliance Payments Technical Working Group. Uses an SD-JWT credential format with up to three layers: Layer 1 (Identity), Layer 2 (Intent — user-signed authorization with constraints), Layer 3 (Action — agent-signed execution record). It defines two modes: Immediate mode uses two layers (L1 + L2, with no agent delegation); Autonomous mode adds Layer 3, which itself splits into L3a (network-facing payment mandate) and L3b (merchant-facing checkout mandate). Layer 2 registers eight constraint types that verifiers MUST support — mandate.checkout.allowed_merchants, mandate.checkout.line_items, mandate.payment.allowed_payees, mandate.payment.amount_range, mandate.payment.budget, mandate.payment.recurrence, mandate.payment.agent_recurrence, and mandate.payment.reference — and explicitly permits implementations to define custom types using URN or reverse-domain naming.
Tier A — Available today
LCP can register a custom Layer 2 constraint carrying atrHash, jurisdiction, and dispute method. The custom constraint is included in the consumer's Layer 2 credential alongside the registered constraints, signed by the user's device key, and carried through the mandate chain:
{
"layer": 2,
"constraints": [
{ "type": "mandate.payment.amount_range", "value": "..." },
{ "type": "<reverse-domain>.lcp-terms-hash", "value": "0x7f83b165..." },
{ "type": "<reverse-domain>.lcp-jurisdiction", "value": "USA" },
{ "type": "<reverse-domain>.lcp-dispute-method", "value": "Dispute Resolution Service Rules" }
]
}The custom constraint inherits Layer 2's signature, integrating LCP into the consumer authorization chain without upstream protocol change.
Tier B — Forward work
Standardizing LCP-aware constraint types as registered Layer 2 types (rather than custom URN-named types) would give parsers standardized handling across implementations.
Conceptual relationship
Verifiable Intent captures the consumer's authorization chain — who authorized, under what constraints, whether the agent stayed within scope. LCP captures the merchant's terms — what was offered, under what conditions, with what recourse. The combined evidence package — consumer authorization chain + LCP terms record + LCP signed acceptance — provides a complete evidentiary foundation for dispute resolution.
| What | Source |
|---|---|
| Consumer authorized this agent | Verifiable Intent Layer 1-2 |
| Agent stayed within constraints | Verifiable Intent Layer 2-3 |
| Merchant offered these terms | LCP atrHash |
| Both parties agreed | LCP Level 3+ signed acceptance record |
| Dispute resolution available | LCP Level 4 (disputeResolution) |
Steward invitation
The Verifiable Intent stewards — now the FIDO Alliance Payments Technical Working Group — are invited to register LCP-aware constraint types in Layer 2 and to publish guidance on the relationship between consumer-side constraints and merchant-side LCP records.
AP2 Integration
Agent Payments Protocol — LCP travels alongside SD-JWT mandates in transport metadata; embedded mandate fields as forward work.
Relationship to Authorization Protocols
LCP captures the merchant's side of a transaction. Authorization protocols capture the consumer's side. Together they form a complete agreement.