MPP 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 specification family. The core HTTP authentication scheme carries two published identities: draft-httpauth-payment-00 at paymentauth.org and in the family's repository, and draft-ryan-httpauth-payment on the IETF datatracker (latest revision -01, March 2026). It is an individual submission — not a working-group document and not endorsed by the IETF. A family of per-method specifications — Card, EVM, Hedera, Lightning, NEAR Intents, Solana, Stellar, Stripe, Tempo and USDC — together with a parent draft-payment-intent-charge-00, a service-discovery draft (draft-payment-discovery-00), and a JSON-RPC + MCP transport binding are published at paymentauth.org. MPP is in production via Stripe (PaymentIntents API, currently a preview-gated API version), Visa (cards), Lightspark (Lightning), and Tempo (TIP-20). The core scheme binds each challenge id to the challenge's own parameters, with method-specific request bodies and method-specific receipt extensions. How that binding is computed is implementation-defined: servers MAY use stateful storage such as a database lookup, or stateless verification such as an HMAC or authenticated encryption. The draft recommends HMAC-SHA256 over a canonicalization of seven fixed positional slots — realm, method, intent, request, expires, digest, opaque — with an eighth appended when the header parameter is present. The request slot is serialized with JCS [RFC 8785] first, so different JSON orderings cannot produce different values.

Tier A — Available today. LCP fields ride inside the HMAC-protected request body — typically inside methodDetails — that accompanies the 402 challenge. Each method specification defines its own methodDetails schema, so the exact placement is method-specific:

{
  "amount": "...",
  "currency": "...",
  "recipient": "...",
  "methodDetails": {
    "network": "...",
    "atrHash": "0x7f83b165...",
    "legalContextUrl": "https://example.com/terms/v3.md"
  }
}

What the binding does and does not commit. MPP requires the server to bind the challenge id to realm, method, intent and request, and to expires, digest, opaque and header when present — so tampering with an advertised atrHash inside request is detectable. But the binding is computed under a key, or against a store, that the server holds. It lets that server detect tampering in a challenge returned to it; it is not a signature over the seller's advertised terms, and it commits the seller to nobody who lacks the key. A deployment that needs the advertised atrHash provable to a third party must place it where the buyer's own authorization signature reaches, or bind it on-chain per §8.3.

A method-specific legalContext receipt field is also Tier A: the core spec explicitly permits methods to define additional receipt fields, so a single method's spec can register a legalContext receipt extension without core-spec coordination.

Canonical realization on Tempo (illustrative). Tempo's TIP-20 token standard exposes transferWithMemo(to, amount, bytes32 memo) and emits TransferWithMemo(...indexed memo) — a chain-level property independent of any payment protocol. Under MPP, a seller advertising methodDetails.memo = atrHash causes the buyer to call transferWithMemo(recipient, amount, atrHash), emitting atrHash as an indexed event topic. The binding is zero-party-recoverable from the settlement transaction hash and forward-indexable via topic filter — the strongest Native Field realization (see §8.3.1 and Appendix B.1) currently demonstrated on any rail. The same chain-level property would also support direct-TIP-20 LCP bindings outside MPP. On MPP-EVM, by contrast, methodDetails is constrained, the EIP-3009 (ERC-3009) nonce is a derivation MUST (keccak(challenge.id ‖ challenge.realm)), and the Permit2 witness type string is hardcoded; LCP fields ride alongside the method-defined fields without committing to the settlement transaction. An Id-Reuse binding per §8.3.5 remains available — the seller sets challenge.id = atrHash, satisfying the challenge-uniqueness requirement by making each ATR unique per transaction (§8.3.5) — which yields an on-chain commitment that verifies a candidate atrHash but does not recover it; zero-party-recoverable on-chain binding requires an Overlay Contract per §8.3.2.

Tier B — Forward work. A first-class legal-context parameter in the outer WWW-Authenticate: Payment challenge is permitted today by the spec's extension policy — "Implementations MAY define additional parameters in challenges", with unknown parameters MUST-ignored by clients — but that same policy states that parameters MUST use lowercase names, so the parameter is legalcontext, not legalContext. Bringing it under the challenge binding requires a coordinated change to the canonicalization input. Cross-method standardization of a legalContext receipt field — rather than a single method's extension — likewise requires core-spec coordination.

Limitations. Where the recommended HMAC binding is used, its input is positionally fixed — seven slots, or eight when header is present — so ad-hoc outer parameters are visible to clients but are not covered unless the canonicalization is extended. The receipt structure is method-specific, so cross-method uniformity is a registry-level concern. The strength of any on-chain LCP binding is determined by the host chain's primitive — the same MPP wire format produces a Native Field binding on Tempo, while rails that lack an unconstrained, indexed memo carrier offer only an Id-Reuse commitment (candidate verification, not recovery) and require an Overlay Contract for zero-party-recoverable binding (or Sidecar Attestation where the forum accepts a trusted indexer).

Steward invitation. The MPP authors (Tempo Labs and Stripe) are invited to publish authoritative guidance for LCP integration — including standard placement of atrHash inside methodDetails per method, the structure of any legalContext receipt field, and whether the canonicalization input should be extended to cover an outer legalContext parameter. Stewards of adjacent MPP drafts (draft-payment-discovery-00, the JSON-RPC + MCP transport binding) are similarly invited to clarify the relationship between MPP service discovery and LCP discovery.