MPP Integration

Machine Payments Protocol — LCP fields inside the HMAC-covered request body, the canonical Tempo realization, and proposed first-class extensions.

This section is advisory and non-prescriptive. The illustrations describe current possibilities and limitations rather than canonical shapes. The MPP authors (Tempo Labs and Stripe) are invited to publish authoritative LCP integration guidance for the protocol.

What it is

A specification family. The core HTTP authentication scheme is an IETF Internet-Draft (draft-ryan-httpauth-payment-01). A family of per-method specifications — Card, EVM, Lightning, Solana, Stellar, Stripe, Tempo — together with 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), Visa (cards), Lightspark (Lightning), and Tempo (TIP-20). The core scheme uses HMAC-SHA256 over a fixed seven-slot canonicalization, with method-specific request bodies and method-specific receipt extensions.

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. The host MAC commits the service to the advertised values:

{
  "amount": "...",
  "currency": "...",
  "recipient": "...",
  "methodDetails": {
    "network": "...",
    "atrHash": "0x7f83b165...",
    "legalContextUrl": "https://example.com/.well-known/legal-context.json"
  }
}

Because methodDetails is part of the HMAC-protected request body, the service is cryptographically committed to the advertised atrHash at challenge time.

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 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 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, and on-chain binding requires an Overlay Contract.

Tier B — Forward work

A first-class legalContext parameter in the outer WWW-Authenticate: Payment challenge is permitted today by the spec's extension policy ("Implementations MAY define additional parameters in challenges"; unknown parameters are ignored by clients), but bringing it under the host HMAC requires a coordinated change to the seven-slot canonicalization input. Cross-method standardization of a legalContext receipt field — rather than a single method's extension — likewise requires core-spec coordination.

Limitations

The HMAC canonicalization input is positionally fixed (seven slots, pipe-delimited); ad-hoc outer parameters are visible to clients but are not bound by the host MAC 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 and requires an Overlay Contract or Sidecar Attestation on rails that lack an unconstrained, indexed memo carrier. See the On-Chain Binding Patterns page for the abstract pattern vocabulary; the chain operators publishing LCP profiles for their rails are the right source for concrete binding guidance.

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.