A Server-Side Model for Gating Agent-Initiated Human-Sourced Asynchronous HTTP Tasks on Payment or Entitlement
draft-king-yew-choo-agentic-payments-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Author | King Yew Choo | ||
| Last updated | 2026-07-23 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-king-yew-choo-agentic-payments-00
Network Working Group King Yew Choo
Internet-Draft True Primary
Intended status: Informational 23 July 2026
Expires: 24 January 2027
A Server-Side Model for Gating Agent-Initiated Human-Sourced
Asynchronous HTTP Tasks on Payment or Entitlement
draft-king-yew-choo-agentic-payments-00
Abstract
This document presents a server-side model for paid, human-sourced
asynchronous HTTP tasks initiated by software agents acting on behalf
of a principal. Clients may retry after uncertain outcomes and act
under authority delegated in advance, while fulfilment incurs cost
and may not be freely reversible.
The model places a payment or entitlement gate before fulfilment,
maps that gate to adjacent protocols, and defines a task state
machine. Under stated well-formedness constraints and operating
assumptions, it yields gate-before-fulfilment safety, at most one
task per retained idempotency key, at most one gate acceptance per
payment requirement, and an operator-checkable record linking a
delivered artefact to operator-controlled records. It defines no
protocol, wire format, or conformance requirements.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 24 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
King Yew Choo Expires 24 January 2027 [Page 1]
Internet-Draft Agent-Initiated Payment Gating July 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Document Status and Maturity of the Cited Protocols . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Layered Architecture . . . . . . . . . . . . . . . . . . . . 8
3.1. The Layer Map . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Protocol Placement . . . . . . . . . . . . . . . . . . . 10
3.3. Scope of the Gate . . . . . . . . . . . . . . . . . . . . 11
3.4. The Gated Exchange . . . . . . . . . . . . . . . . . . . 12
4. Formal Objects and the Validation Predicate . . . . . . . . . 14
4.1. Quotes and Pricing . . . . . . . . . . . . . . . . . . . 14
4.2. Mandates and Authority . . . . . . . . . . . . . . . . . 14
4.3. Payment Requirement, Settlement, and Validation . . . . . 15
4.4. Fulfilment, Ledger, and Receipt . . . . . . . . . . . . . 16
5. The Task State Machine . . . . . . . . . . . . . . . . . . . 16
5.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2. Level Function, Gate, and Fulfilment Region . . . . . . . 18
5.3. Transitions . . . . . . . . . . . . . . . . . . . . . . . 18
5.4. Activation Requests, Keys, and Nonces . . . . . . . . . . 24
6. Well-Formedness Constraints and Operating Assumptions . . . . 25
6.1. Constraints . . . . . . . . . . . . . . . . . . . . . . . 25
6.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 26
7. The Four Properties . . . . . . . . . . . . . . . . . . . . . 27
7.1. Property 1: Gate-before-Fulfilment Safety . . . . . . . . 28
7.2. Property 2: Idempotency under an Idempotency Key . . . . 29
7.3. Property 3: Single Acceptance per Payment Requirement . . 29
7.4. Property 4: Operator-Checkable Audit Record . . . . . . . 30
7.5. Composition . . . . . . . . . . . . . . . . . . . . . . . 30
8. Operational Considerations . . . . . . . . . . . . . . . . . 31
9. Security Considerations . . . . . . . . . . . . . . . . . . . 32
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
11. Informative References . . . . . . . . . . . . . . . . . . . 35
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 37
King Yew Choo Expires 24 January 2027 [Page 2]
Internet-Draft Agent-Initiated Payment Gating July 2026
1. Introduction
Some paid HTTP requests are initiated by software agents acting on
behalf of a human or organisational principal. Industry material
commonly discusses this class of transaction under the term "agentic
payments"; this document uses "agent-initiated transactions". This
document considers the subset with three architecturally significant
properties. First, the transport is unreliable in the ordinary
distributed-systems sense: requests can be lost, retried, duplicated,
or observed out of order, so any state-changing exchange is exposed
to duplication, and a retry that creates a second task or captures a
second charge is a correctness failure even though every individual
message was well-formed. Second, the principal is not present:
authority to spend was delegated in advance, with limits (a budget,
an authorised scope, an expiry, and conditions under which a human is
brought back into the loop), so the server evaluates delegated
authority as data presented with the request rather than inferring it
from an interactive session. Third, the server commits real cost
when it fulfils a request: for request types whose fulfilment
involves sourcing human work, generating an artefact, or consuming
metered capacity, fulfilment side effects are expensive and not
freely reversible, and a server that begins fulfilment before payment
is validated can have cost extracted from it by a non-paying or
unauthorised caller.
RFC 9110 reserves status code 402 (Payment Required) for future use
[RFC9110]; recent protocol work proposes wire mechanics for machine
payment using that code. The "Payment" HTTP authentication scheme
[I-D.ryan-httpauth-payment] defines an HTTP 402 challenge that a
client satisfies by paying out of band and retrying with a
credential; the Machine Payments Protocol (MPP) [MPP-STRIPE]
[MPP-SPECS] is a vendor-maintained protocol built over that scheme;
x402 [X402] demonstrated the same 402 pattern bound to stablecoin
settlement; and the Agent Payments Protocol (AP2) [AP2] supplies a
mandate object for delegated payment authority. These specifications
do not collectively define the complete server-side task model
considered here. A wire scheme specifies how a challenge and
credential travel, and the scheme cited here also constrains side
effects on unpaid requests, retry handling under an idempotency key,
and concurrent use of one credential [I-D.ryan-httpauth-payment]. It
does not define the asynchronous task lifecycle, delegated mandate
evaluation, entitlement handling, the post-gate compensation paths,
or the artefact-bound operator record considered here. Those are
properties of the server's own task architecture.
This document describes an architectural model that addresses those
concerns by placing a gate in the task lifecycle. The model places
one gate state, written g*, at which a settlement-method-neutral
King Yew Choo Expires 24 January 2027 [Page 3]
Internet-Draft Agent-Initiated Payment Gating July 2026
payment requirement is validated together with delegated authority;
every path into the fulfilment region of the state machine passes
through that gate, and no fulfilment side effect occurs before it.
The model also uses an idempotency key to associate retries with one
task, a single-use nonce to reject credential replay, and a receipt
linking the task to operator-controlled authority and settlement
records.
A fuller formal treatment of this model appears in [ARCH].
1.1. Document Status and Maturity of the Cited Protocols
The intended status of this document is Informational. It is an
analytical description of a model, and it deliberately contains no
requirements language; BCP 14 key words are not used, and nothing in
this document is a conformance target. It defines no new protocol
elements and requests no registrations.
The cited mechanisms have different maturity and governance models
that affect implementation risk:
* [I-D.ryan-httpauth-payment] is an individual-submission Internet-
Draft. As of July 2026 it stands at revision -01 (published 18
March 2026), expires on 19 September 2026, and has no IETF
working-group adoption; it is not an IETF standard.
* [I-D.ietf-httpapi-idempotency-key-header] was adopted by the IETF
HTTPAPI Working Group and has expired: its latest revision, -07,
was published on 15 October 2025 and expired in April 2026. It is
cited in this document as provenance for an established pattern,
not as a settled standard.
* MPP [MPP-STRIPE] [MPP-SPECS] is vendor documentation and a vendor-
maintained specification (maintained by Tempo Labs and Stripe,
launched 18 March 2026). Its maintainers describe it as an open
standard; it is not the product of a standards body.
* x402 [X402] is an independent protocol created by Coinbase. The
Linux Foundation's 14 July 2026 release [X402-LF] announced the
operational launch of the x402 Foundation and the completed
contribution of the x402 protocol by Coinbase, and records that
the Foundation's formation had been announced on 2 April 2026.
* AP2 was announced by Google on 16 September 2025 [AP2]; its
specification stands at v0.2, a pre-1.0 document [AP2-SPEC].
King Yew Choo Expires 24 January 2027 [Page 4]
Internet-Draft Agent-Initiated Payment Gating July 2026
* The Model Context Protocol (MCP) [MCP] is an application-layer
tool-invocation specification, cited here only for product
discovery and invocation context and not as part of the settlement
layer. This document cites protocol version 2025-11-25; it is not
an IETF standard.
2. Terminology
The following terms name the objects of the model. Angle brackets
denote tuples. The literals true and false represent Boolean values;
Greek symbols are transliterated as Phi, eta, chi, epsilon, sigma,
sigma_auth, rho, rho_pay, and Omega.
Quote (q): The tuple q = <a, p, rho, m, sigma, d, R> recording the
requesting agent a, product p, request parameters rho, frozen
price m, scope descriptor sigma, deadline d, and payment
requirement R. A quote states a fixed amount and currency;
acceptance, authorisation, and settlement are separate events.
Mandate (M): The delegated-authority object M = <c, a, aud, b,
sigma_auth, d_lim, chi, epsilon>: issuer (principal) c, holder
(agent) a, audience (intended-payee set) aud, cumulative budget
cap b in a single currency, authorised scope set sigma_auth,
authority expiry d_lim, contributor-criteria predicate chi, and
escalation predicate epsilon. In capability terms the mandate is
an attenuated capability: it represents the authority recorded in
its signed fields, subject to signature validation, authenticated-
holder binding, audience checks, expiry, and current mandate
status.
Payment requirement (R): The settlement-method-neutral requirement R
= <amt, cur, payee, eta, scheme, t_exp> issued with the quote:
amount and currency equal to the quoted price, the operator as
payee, a server-minted nonce eta, the scheme name "Payment", and a
requirement expiry t_exp. Exactly one R is issued per quote;
where a fresh machine payment is needed, a method-specific
challenge derived from R is carried by an HTTP 402 response.
Settlement method (S), Settle: How the gate is satisfied. Settle
contains payment methods (card, wallet, stablecoin), entitlements
(account_balance, package_drawdown, subscription_allowance), and
approved credit accounts. The model does not treat an unpaid
invoice as validated payment. Settlement remains separate from
the gate.
Credential, realise(S, R): The proof a settlement method produces to
King Yew Choo Expires 24 January 2027 [Page 5]
Internet-Draft Agent-Initiated Payment Gating July 2026
satisfy a requirement: presented on retry in an "Authorization:
Payment" header after a 402 challenge, or recorded directly at the
gate on the entitlement path.
Nonce (eta): A server-minted value, generated with negligible
collision probability, bound into R and re-presented in the
credential; it is consumed as part of a successful gate commit and
never becomes fresh again.
Idempotency key (k): A client-supplied key, stable across retries of
the same logical request and namespaced per client. The key
identifies the logical request; the nonce identifies the issued
challenge; the gate transition consumes the nonce and binds the
key to the task, and that binding remains available for later
retries.
Request fingerprint: The collision-resistant digest of the canonical
request representation of C8, recorded with k before the gate and
confirmed at the gate commit. The canonical-request digest of
Section 5.4 is the same object.
Activation request: The call that presents (R, S, M) for validation
at the gate, carrying an idempotency key k.
Gate (g*): The task state pending_payment_or_plan_check: the locus
of the validation predicate and the unique crossing into the
fulfilment region.
Fulfilment region (Phi): The set of post-gate states
{pending_expert_match, awaiting_expert_input,
needs_client_clarification, in_review, ready, delivered}. All
expensive, not freely reversible fulfilment side effects occur on
transitions entering or internal to Phi.
Entitlement: The non-machine-payment way to satisfy the same gate:
an existing entitlement (package drawdown, subscription allowance,
account balance), presented as the settlement method whose
credential realises the same R, recorded in place of a fresh
machine payment.
Contributor (e): A human contributor whose input is recorded in L
and who satisfies chi_M.
Ledger (L): An append-only record of discrete fulfilment
contributions; entries are <taskId, e, inputRef, t>, where taskId
identifies the task, e is the contributor, inputRef identifies the
recorded contribution, and t is its timestamp.
King Yew Choo Expires 24 January 2027 [Page 6]
Internet-Draft Agent-Initiated Payment Gating July 2026
Delivery receipt (Omega): The operator-issued object Omega = <M,
rho_pay, taskId, hashAlg, artefactHash, t, mode>. hashAlg
identifies the collision-resistant hash algorithm, and
artefactHash is computed over the exact delivered bytes; the other
fields record the mandate, the settlement reference rho_pay, the
task identifier, the timestamp, and the settlement mode. In a
delivery receipt rho_pay binds the task to the payment, credit, or
entitlement record accepted at the gate; the same settlement
reference is reused by a compensating receipt to reconcile a
capture recorded without gate acceptance.
verify_Omega: The consistency check of a receipt against operator-
controlled records: resolve taskId to the final receipt stored for
that task and require the supplied Omega to equal it; recompute
artefactHash over the exact delivered bytes using hashAlg and
compare; resolve rho_pay against the method-specific payment,
credit, or entitlement record; resolve M against the mandate
registry; check the taskId binding.
F, ValidatedReq: The partial fulfilment function F: ValidatedReq ->
Artefact, with side effects recorded in L; ValidatedReq is the set
of (q, S, M) triples whose requirement passed the gate. F is
defined on the validated requests that reach delivered; a
validated request that reaches credited_or_refunded before
delivery yields no artefact, while an upheld dispute may move a
task to credited_or_refunded after F has yielded its artefact.
The model treats invocation of F only after the gate transition as
an implementation invariant; the type notation does not enforce
that ordering.
Operator: The server-side entity that issues quotes and
requirements, controls the gate, task engine, and stores, and
fulfils or delivers the task.
Client: The authenticated party that submits activation requests and
holds the idempotency-key namespace. The agent acts as client on
behalf of the principal.
Money: Non-negative integer minor units paired with a currency tag.
currency(x) reads the currency tag of a Money value x; the frozen
price m(q) and a mandate's cap are Money values, so the budget
test of authorises compares their currency tags before comparing
amounts. Comparison is defined only within one currency; cross-
currency comparison is undefined and is resolved by conversion at
quote time, since a quote fixes one currency.
Predicates: credentialValid(cred, R) checks the credential
King Yew Choo Expires 24 January 2027 [Page 7]
Internet-Draft Agent-Initiated Payment Gating July 2026
cryptographically and confirms payment assurance sufficient for
the expected fulfilment period, or validates entitlement or credit
evidence that the gate commit can reserve atomically and that
resolves to an account the authenticated client may draw on under
M, rather than to a client-supplied identifier alone;
authorises(M, q) checks delegated authority (Section 4.2);
fresh(eta) holds while the nonce is unconsumed; current(R, q)
holds while R remains the in-force requirement issued for quote q;
expired(R) holds when current_time is at or after t_exp(R); dl(q)
is expired when current_time is at or after dl(q); consume(eta)
atomically spends a nonce; active(M, t) holds when M is in force
and has not been revoked at time t; the guard "capture recorded"
holds when the task's settlement record shows funds transferred or
captured out of band, as distinct from an authorisation held for
later capture; validate(R, S, M) is the gate predicate conjoining
these (Section 4.3).
CAS(k: bottom -> taskId): The atomic compare-and-set by which the
task store binds an unbound idempotency key to a task record;
bottom denotes the unbound value. It succeeds at most once per
key and is performed as part of the gate commit.
Term: The terminal states {cancelled, failed, credited_or_refunded}.
3. Layered Architecture
This section arranges the transaction path as a layered stack, places
each cited mechanism on it, and states what the gate does and does
not replace.
3.1. The Layer Map
The stack runs top to bottom (Figure 1). The access layer can expose
Representational State Transfer (REST) APIs. A request descends
through access, decision, and payment/settlement layers before
crossing the gate. The artefact and delivery receipt return to the
caller; the operator retains the audit record. Throughout this
document, the operator-controlled audit record comprises L and Omega;
verify_Omega checks Omega only and does not verify or bind L.
King Yew Choo Expires 24 January 2027 [Page 8]
Internet-Draft Agent-Initiated Payment Gating July 2026
+---------------------------------------------------------------+
| Client / client agent |
| holds mandate M = <c, a, aud, b, sigma_auth, d_lim, chi, |
| epsilon> for delegated spend |
+------------------------------+--------------------------------+
v
+---------------------------------------------------------------+
| Product interface (access layer) |
| tool-invocation surface (agent-facing) . REST/domain APIs |
| (system of record) |
| carries no money, decides no price; routes request inward |
+------------------------------+--------------------------------+
v
+---------------------------------------------------------------+
| Decision layer |
| pricing price(p, rho) -> Money, frozen at quote time . |
| authority check authorises(M, q) . entitlement resolution |
| . attaches R to every quote; derives the 402 challenge |
| from R only where a fresh machine payment is needed |
+------------------------------+--------------------------------+
v
+---------------------------------------------------------------+
| Payment/settlement abstraction |
| one payment-or-entitlement gate, many settlement methods: |
| 402 challenge-credential-receipt on top; the settlement |
| method S in Settle selected beneath |
+------------------------------+--------------------------------+
v
+===============================================================+
| THE GATE g* (task state pending_payment_or_plan_check) |
| validate(R, S, M) <=> credentialValid AND authorises |
| AND current AND fresh AND NOT expired |
| true => enter region Phi false => refuse |
+==============================+================================+
v
+---------------------------------------------------------------+
| Fulfilment system (region Phi) |
| async task engine (state machine) . contributor sourcing |
| against chi . append-only ledger L . |
| partial F: ValidatedReq -> Artefact |
+------------------------------+--------------------------------+
v
+---------------------------------------------------------------+
| Result + receipt + audit |
| delivered artefact . receipt Omega (verify_Omega checkable) |
| . audit record . contributor payment outside this model |
+---------------------------------------------------------------+
King Yew Choo Expires 24 January 2027 [Page 9]
Internet-Draft Agent-Initiated Payment Gating July 2026
Figure 1: The layered model. A request descends through access,
decision, and settlement layers, crosses the gate g*, and is
fulfilled in region Phi.
The gate g* is the point after which the modelled fulfilment side
effects may begin. Everything above it prepares quotation,
authorisation, and settlement evidence; everything below it is the
fulfilment region Phi.
3.2. Protocol Placement
The layer map assigns each cited mechanism to the function it
provides. A tool-invocation protocol such as MCP [MCP] makes a
product discoverable and callable by an agent; AP2-style mandates
record who authorised what; an asynchronous task engine fulfils;
receipts and audit make the outcome checkable against operator-
controlled records. In this model, none of these layers is treated
as the settlement layer. Between an agent-readable product surface
and paid access sits the payment/settlement layer that the access,
authority, and fulfilment layers do not themselves provide: the point
at which a machine presents a valid payment, the server validates it,
and only then does fulfilment begin.
The model places the cited protocols as follows:
The "Payment" HTTP authentication scheme and MPP. The wire mechanism
is the "Payment" HTTP authentication scheme of
[I-D.ryan-httpauth-payment]: the server returns 402 Payment
Required carrying a "WWW-Authenticate: Payment" challenge; the
client pays out of band and retries with an "Authorization:
Payment" credential; on success the response can carry the
scheme's "Payment-Receipt" header, a payment receipt distinct from
the delivery receipt Omega; the scheme pairs that header with
"Cache-Control: private". MPP is the protocol built over that
scheme [MPP-STRIPE]. In the model this pair occupies exactly one
tier: the machine-payment requirement inside the decision layer,
realised over a settlement-flexible abstraction. It replaces none
of the other tiers. The wire challenge is derived from and bound
to the payment requirement R, supplying the parameters that the
scheme requires, and the credential it elicits is what the gate
validates.
x402. x402 [X402] demonstrated the 402 paid-resource pattern in
practice: its settlement is crypto-native, using stablecoin
transfers settled on-chain. Verification and settlement are
performed either directly by the resource server or through an
optional facilitator service, which may be managed, self-hosted,
or run in process. In the model that binding makes x402 one
King Yew Choo Expires 24 January 2027 [Page 10]
Internet-Draft Agent-Initiated Payment Gating July 2026
settlement path among several (a stablecoin settlement method in
Settle), rather than the shape of the gate itself. Its governance
transition to the x402 Foundation under the Linux Foundation,
announced 2 April 2026, completed with the x402 Foundation's
operational launch on 14 July 2026 [X402-LF].
AP2. AP2 [AP2] [AP2-SPEC] supplies the delegated-authority layer:
signed Checkout and Payment Mandates intended to provide tamper-
evident evidence of recorded user instructions within AP2's trust
model, with a human-not-present form carrying price limits,
timing, and conditions, and a human-present form binding exact
items and price. (The 2025 announcement named these Intent and
Cart Mandates; the v0.2 specification restructures them as
Checkout and Payment Mandates. This document uses the human-not-
present versus human-present distinction without asserting term-
for-term equivalence with the current specification.) In the
model the mandate M is one input to the gate, alongside R.
Authority is necessary but not sufficient: a validated mandate
provides evidence of the authority represented in its signed
fields, but does not price the work, move money, source a
contributor, or deliver a result.
Adjacent layers. The access layer (tool invocation plus REST and
domain APIs backed by the system of record) standardises how an
agent calls the product and carries no semantics for payment,
delegated authority, pricing, or settlement. Inter-agent
protocols and commerce-channel wrappers sit at the edges, relevant
only where a coordinating agent or an external commerce surface is
operated. These layers are named here only to fix what the gate
does not replace.
3.3. Scope of the Gate
Table 1 separates the gate from the access, authority, pricing,
settlement, and fulfilment responsibilities around it.
King Yew Choo Expires 24 January 2027 [Page 11]
Internet-Draft Agent-Initiated Payment Gating July 2026
+============================+======================+
| Requirement | Layer that owns it |
+============================+======================+
| Agent can call the product | Access layer (tool |
| | invocation / REST) |
+----------------------------+----------------------+
| Client can buy a product | The payment gate |
| | (this model) |
+----------------------------+----------------------+
| Principal authorises | Mandate M (AP2-style |
| delegated spend | authority) |
+----------------------------+----------------------+
| Price is calculated and | Pricing engine in |
| frozen | the decision layer |
+----------------------------+----------------------+
| Entitlement already covers | Account/entitlement |
| the request | resolution |
+----------------------------+----------------------+
| Money actually moves | Settlement method in |
| | Settle |
+----------------------------+----------------------+
| Task is fulfilled | Task engine (state |
| | machine, region Phi) |
+----------------------------+----------------------+
| Contributor inputs are | Fulfilment workflow |
| managed | + ledger L |
+----------------------------+----------------------+
| Result is delivered | Artefact generation |
| | F |
+----------------------------+----------------------+
| Transaction is auditable | Receipt Omega + |
| | audit record |
+----------------------------+----------------------+
Table 1: Responsibility placement across the
model's layers.
3.4. The Gated Exchange
On the wire, the model's transaction is a seven-step exchange gated
on a single validation.
1. Request. The agent calls a product or quote endpoint, presenting
M and an idempotency key k that remains stable for every retry of
this logical request. On the machine-payment path the server
records only the challenge state for that request: k, the
authenticated client, a collision-resistant digest of a canonical
encoding of all processing-relevant request fields, and the
King Yew Choo Expires 24 January 2027 [Page 12]
Internet-Draft Agent-Initiated Payment Gating July 2026
resulting quote. That record is not a task record, and no task
identifier exists before the gate commit; reuse of k with
different data is rejected.
2. Quote plus requirement. The pricing engine freezes the price and
the decision layer emits the quote q with its requirement R. If
a fresh machine payment is needed, the server returns 402 Payment
Required carrying a method-specific "WWW-Authenticate: Payment"
challenge derived from and bound to R, which supplies the
parameters that the scheme requires; R itself remains the model's
internal, settlement-method-neutral requirement. If an
entitlement may cover q, the server returns no 402, and the
client presents entitlement evidence in step 3 for validation and
atomic reservation at the gate in step 5.
3. Obtain payment evidence. The agent obtains evidence accepted by
the selected payment path. The task record distinguishes
transfer, capture, authorisation for later capture, and
entitlement coverage; these states are not interchangeable.
4. Retry with credential. The agent retries the original request,
carrying the credential in an "Authorization: Payment" header and
its idempotency key.
5. Validate (the gate g*). The server evaluates validate(R, S, M);
the nonce binds the credential to this specific challenge, and a
stale or expired challenge fails closed.
6. Activate and return a handle. On true, and only on true, the
task engine enters Phi; the server returns a task identifier.
7. Receipt and audit. The gate commit of step 6 durably recorded
the settlement reference rho_pay before entry to Phi; the server
returns that reference, and constructs and returns the artefact-
bound Omega at delivery.
Steps 2, 4, and 5 establish the challenge, retry, and validation
sequence: the challenge in step 2 names the price and the nonce, the
retry in step 4 satisfies exactly that challenge, and the gate in
step 5 admits the request to Phi only on full validation. Because
eta is bound into R and re-presented in the credential, a credential
cannot be replayed against a different challenge; the separate
idempotency-key binding supports server-side idempotency
(Section 7.2).
King Yew Choo Expires 24 January 2027 [Page 13]
Internet-Draft Agent-Initiated Payment Gating July 2026
4. Formal Objects and the Validation Predicate
This section fixes the objects the state machine's guards refer to.
The model is implementation-agnostic: it fixes the properties that
hold and leaves their realisation to the implementing service.
4.1. Quotes and Pricing
At quote creation, the decision layer returns a price, scope
descriptor, and deadline. The quote q = <a, p, rho, m, sigma, d, R>
records the requesting agent so authority can be checked against it.
C1 (Section 6.1) freezes m(q), the scope, and the deadline for the
life of that quote; a later quote may reflect different inputs or
pricing state.
4.2. Mandates and Authority
Cumulative committed spend under a mandate is spent(M), the sum in
currency(cap(M)) of m(q) over quotes committed under M, with the
empty sum equal to zero in that currency; spent(M) is monotonic, so
refunds and credits do not reduce it or restore mandate capacity, and
replacement capacity requires a new or amended mandate outside this
model. A quote is committed when its task crosses the gate. The
accessors read tuple components by position: agent(q), scp(q), dl(q),
m(q), and R(q) read a, sigma, d, m, and R of q; issuer(M), holder(M),
audience(M), cap(M), sigma_auth(M), and d_lim(M) read c, a, aud, b,
sigma_auth, and d_lim of M; payee(R), eta(R), and t_exp(R) read
payee, eta, and t_exp of R. The predicate
requesterAuthenticatedAs(x) holds when the authenticated client
identity is x. The budget test is total: withinBudget(M, q) is false
when currency(m(q)) differs from currency(cap(M)), and is otherwise
the truth value of spent(M) + m(q) <= cap(M) evaluated in that
currency. Authority alone is:
authorises(M, q) <=> requesterAuthenticatedAs(holder(M))
AND holder(M) = agent(q)
AND payee(R(q)) is in audience(M)
AND scp(q) is in sigma_auth(M)
AND withinBudget(M, q)
AND current_time < dl(q)
AND dl(q) <= d_lim(M)
AND active(M, current_time)
Authority and escalation are two separate predicates, both evaluated
at the state pending_authority, with escalation taking precedence.
For a mandate M, chi_M(e) evaluates its contributor-criteria
predicate for contributor e, and epsilon_M(q) evaluates its
escalation predicate for quote q. The predicate epsilon_M(q) is not
King Yew Choo Expires 24 January 2027 [Page 14]
Internet-Draft Agent-Initiated Payment Gating July 2026
a conjunct of authorises and is checked first. When epsilon_M(q) is
true the operator records re-approval bound to M, q, the
authenticated approver, and the approval time before the task can
reach the gate; the task does not advance automatically (C6). The
contributor-criteria predicate chi_M is likewise not part of
authority; it constrains fulfilment through the ledger invariant
(C4), and a chi_M failure surfaces inside the fulfilment region as
the no-qualifying-contributor transition, not as an authority
failure.
4.3. Payment Requirement, Settlement, and Validation
The requirement R is issued at quote time and is settlement-method-
neutral. The map from quotes to requirements is total and injective:
it issues exactly one R per quote, and no two quotes share a
requirement. Therefore q(R) denotes the unique quote whose
requirement is R. How money moves is a separate concern: a
settlement method S realises R by producing the credential realise(S,
R). The settlement method affects validation through realise: the
same R admits different credentials under different settlement
methods, and a method that cannot produce a valid credential fails
the credential-validity conjunct. R is settlement-method-neutral at
the model boundary; for a particular wire exchange the selected
method determines the challenge and credential that realise it. On
the entitlement and credit paths the evidence is not self-
authenticating, so the gate resolves it to an account the
authenticated client may draw on under M; presenting another
principal's identifier fails the credential-validity conjunct.
The gate predicate conjoins credential validity, authority, active-
requirement status, nonce freshness, and temporal validity:
validate(R, S, M) <=> credentialValid(realise(S, R), R)
AND authorises(M, q(R))
AND current(R, q(R))
AND fresh(eta(R))
AND NOT expired(R)
Validation fails closed on any conjunct, and the wire response
distinguishes the class of failure. A payment credential that fails
verification follows the 402 retry path. A credential that verifies
but does not satisfy the mandate (over budget, outside the authorised
scope, past the authority expiry, or presented by the wrong holder)
is refused without a fresh payment challenge; under
[I-D.ryan-httpauth-payment] that refusal is a 403 response. Both
outcomes fail closed and admit no fulfilment side effect. A
successful validation consumes the nonce atomically: after
consume(eta(R)), fresh(eta(R)) is false. Nonce consumption makes the
King Yew Choo Expires 24 January 2027 [Page 15]
Internet-Draft Agent-Initiated Payment Gating July 2026
requirement non-repeatable; the task transition and C7 prevent a
second gate crossing. The authorises conjunct at settlement time re-
asserts authority already established at pending_authority; it is a
defensive re-check because budget availability and mandate status may
have changed in the interim, not a second authority gate. Escalation
is resolved earlier, at pending_authority; contributor criteria are
enforced inside fulfilment; neither is checked at this gate.
4.4. Fulfilment, Ledger, and Receipt
ValidatedReq is the set of (q, S, M) whose requirement passed the
gate, and F denotes fulfilment processing for a validated request;
its artefact and ledger effects are represented by task-state
transitions. The restriction of F to gated requests is an
implementation invariant, which is what ties the safety argument of
Section 7.1 to a successful validation.
The receipt Omega = <M, rho_pay, taskId, hashAlg, artefactHash, t,
mode> binds, in one verifiable record, who authorised (M), what was
paid (rho_pay), which task (taskId), and exactly which artefact
(artefactHash, computed over the exact delivered bytes under the
algorithm named by hashAlg). The mode field records the settlement
mode as executed, including test or mock modes in non-production
deployments; when an entitlement satisfied the gate, mode records the
entitlement path (for example, package drawdown); the receipt
structure and verify_Omega semantics are unchanged. The receipt
gives the operator a structured consistency check across the
delivered artefact and its own records; it does not provide operator-
independent evidence.
5. The Task State Machine
The task lifecycle is described as a labelled transition system T =
<Q, ->, q0, Term> over control states; the payment, budget, and
receipt effects associated with transitions are stated in prose
alongside the guards. The states appear in Table 2, the transitions
in Table 3, and Figure 2 draws the machine.
5.1. States
+===============================+================================+
| State | Meaning |
+===============================+================================+
| draft | request captured; not yet |
| | priced |
+-------------------------------+--------------------------------+
| quoted | price m, scope sigma, deadline |
| | d, and requirement R issued |
King Yew Choo Expires 24 January 2027 [Page 16]
Internet-Draft Agent-Initiated Payment Gating July 2026
+-------------------------------+--------------------------------+
| accepted | client accepts the quote |
+-------------------------------+--------------------------------+
| pending_authority | resolve authority + escalation |
| | (pre-gate); no fulfilment cost |
+-------------------------------+--------------------------------+
| pending_payment_or_plan_check | GATE g*: validate payment |
| | credential or entitlement |
| | evidence |
+-------------------------------+--------------------------------+
| pending_expert_match | (Phi) sourcing contributors |
| | satisfying chi_M |
+-------------------------------+--------------------------------+
| awaiting_expert_input | (Phi) contributors adding |
| | contributions to ledger L |
+-------------------------------+--------------------------------+
| needs_client_clarification | (Phi) blocked on a clarifying |
| | answer during fulfilment |
+-------------------------------+--------------------------------+
| in_review | (Phi) aggregation, validation, |
| | quality review of inputs |
+-------------------------------+--------------------------------+
| ready | (Phi) artefact generated; |
| | receipt Omega being |
| | constructed |
+-------------------------------+--------------------------------+
| delivered | (Phi) artefact plus Omega |
| | returned to the agent |
+-------------------------------+--------------------------------+
| cancelled | terminated before crossing the |
| | gate (no fulfilment cost |
| | incurred) |
+-------------------------------+--------------------------------+
| failed | unrecoverable system fault |
| | (cross-cutting) |
+-------------------------------+--------------------------------+
| credited_or_refunded | compensation obligation and |
| | selected remedy recorded |
| | against rho_pay |
+-------------------------------+--------------------------------+
Table 2: States of the task machine.
The start state is q0 = draft. Term = {cancelled, failed,
credited_or_refunded}. delivered is a completed fulfilment state
with one possible transition, on an upheld dispute, to
credited_or_refunded. credited_or_refunded records a compensation
obligation and the remedy selected against rho_pay: a refund returns
King Yew Choo Expires 24 January 2027 [Page 17]
Internet-Draft Agent-Initiated Payment Gating July 2026
funds, while a credit leaves the charge standing and grants
offsetting value. It does not assert that the settlement-side remedy
succeeded; a separate settlement result records the outcome, and a
compensating receipt written against rho_pay links the obligation and
its result (Section 9).
5.2. Level Function, Gate, and Fulfilment Region
A pipeline-position map orders the happy path and isolates the gate.
The level function is defined on the eleven pipeline (non-exception)
states only; the three exception terminals carry no level and are not
in Phi:
draft 0 . quoted 1 . accepted 2 . pending_authority 3 . g* 4 .
pending_expert_match 5 . awaiting_expert_input 6 .
needs_client_clarification 6 . in_review 7 . ready 8 . delivered 9
The gate is g* = pending_payment_or_plan_check, at level 4. The
fulfilment region is Phi = {states of level 5 or above} =
{pending_expert_match, awaiting_expert_input,
needs_client_clarification, in_review, ready, delivered}. The
expensive, not freely reversible side effects of fulfilment
(committing contributor sourcing, soliciting and recording paid
contributions, generating the artefact) occur only on transitions
entering or internal to Phi.
Property 1 relies on one structural condition, that the only edge
from outside Phi into Phi is the gate edge:
pending_payment_or_plan_check
--[ validate(R, S, M) = true ]--> pending_expert_match
Authority resolution and escalation happen strictly before the gate,
at pending_authority, and resolve only to the gate state on approval,
to cancelled on refusal or decline when no capture is recorded, or to
credited_or_refunded on refusal or decline when a capture is
recorded; none of these exits enters Phi. The mid-fulfilment state
needs_client_clarification is reachable only from within Phi (from
awaiting_expert_input): an intra-Phi edge, not an entry.
5.3. Transitions
Guards are necessary preconditions and, for each state, mutually
exclusive under the convention that expiry is evaluated before client
events and events are processed one at a time. The deadline rows
apply only from quoted onward, since draft has no quote and therefore
no dl(q). epsilon, authorises, and chi_M are evaluated on the in-
force (M, q).
King Yew Choo Expires 24 January 2027 [Page 18]
Internet-Draft Agent-Initiated Payment Gating July 2026
+==========================+=============+==========================+
|From |Guard / event|To |
+==========================+=============+==========================+
|draft |submit |quoted |
+--------------------------+-------------+--------------------------+
|draft |abandon |cancelled |
+--------------------------+-------------+--------------------------+
|quoted |accept AND |accepted |
| |NOT | |
| |expired(R) | |
+--------------------------+-------------+--------------------------+
|quoted |(reject OR |cancelled |
| |expired(R)) | |
| |AND no | |
| |capture | |
| |recorded | |
+--------------------------+-------------+--------------------------+
|quoted |(reject OR |credited_or_refunded |
| |expired(R)) | |
| |AND capture | |
| |recorded | |
+--------------------------+-------------+--------------------------+
|accepted |begin |pending_authority |
| |authority | |
| |check | |
+--------------------------+-------------+--------------------------+
|pending_authority |NOT epsilon |g* |
| |AND | |
| |authorises | |
+--------------------------+-------------+--------------------------+
|pending_authority |NOT epsilon |cancelled |
| |AND NOT | |
| |authorises | |
| |AND no | |
| |capture | |
| |recorded | |
+--------------------------+-------------+--------------------------+
|pending_authority |NOT epsilon |credited_or_refunded |
| |AND NOT | |
| |authorises | |
| |AND capture | |
| |recorded | |
+--------------------------+-------------+--------------------------+
|pending_authority |epsilon AND |g* |
| |human re- | |
| |approves AND | |
| |authorises | |
+--------------------------+-------------+--------------------------+
King Yew Choo Expires 24 January 2027 [Page 19]
Internet-Draft Agent-Initiated Payment Gating July 2026
|pending_authority |epsilon AND |cancelled |
| |(human | |
| |declines OR | |
| |NOT | |
| |authorises) | |
| |AND no | |
| |capture | |
| |recorded | |
+--------------------------+-------------+--------------------------+
|pending_authority |epsilon AND |credited_or_refunded |
| |(human | |
| |declines OR | |
| |NOT | |
| |authorises) | |
| |AND capture | |
| |recorded | |
+--------------------------+-------------+--------------------------+
|g* |validate = |pending_expert_match |
| |true (GATE) | |
+--------------------------+-------------+--------------------------+
|g* |validate = |cancelled |
| |false AND no | |
| |capture | |
| |recorded | |
+--------------------------+-------------+--------------------------+
|g* |validate = |credited_or_refunded |
| |false AND | |
| |capture | |
| |recorded | |
+--------------------------+-------------+--------------------------+
|pending_expert_match |contributor e|awaiting_expert_input |
| |with chi_M(e)| |
| |found | |
+--------------------------+-------------+--------------------------+
|pending_expert_match |no qualifying|credited_or_refunded |
| |contributor | |
+--------------------------+-------------+--------------------------+
|awaiting_expert_input |input |awaiting_expert_input |
| |appended to L| |
+--------------------------+-------------+--------------------------+
|awaiting_expert_input |clarification|needs_client_clarification|
| |required | |
+--------------------------+-------------+--------------------------+
|awaiting_expert_input |inputs |in_review |
| |sufficient | |
+--------------------------+-------------+--------------------------+
|needs_client_clarification|answer |awaiting_expert_input |
| |received | |
King Yew Choo Expires 24 January 2027 [Page 20]
Internet-Draft Agent-Initiated Payment Gating July 2026
+--------------------------+-------------+--------------------------+
|needs_client_clarification|timeout OR |credited_or_refunded |
| |withdraw | |
+--------------------------+-------------+--------------------------+
|in_review |review passed|ready |
+--------------------------+-------------+--------------------------+
|in_review |unrecoverable|credited_or_refunded |
| |defect | |
+--------------------------+-------------+--------------------------+
|ready |Omega |delivered |
| |constructed | |
| |and written | |
+--------------------------+-------------+--------------------------+
|delivered |dispute |credited_or_refunded |
| |upheld | |
+--------------------------+-------------+--------------------------+
|any state from quoted |dl(q) expired|cancelled |
|through g* |AND no | |
| |capture | |
| |recorded | |
+--------------------------+-------------+--------------------------+
|any state from quoted |dl(q) expired|credited_or_refunded |
|through g* |AND capture | |
| |recorded | |
+--------------------------+-------------+--------------------------+
|any Phi state except |dl(q) expired|credited_or_refunded |
|delivered | | |
+--------------------------+-------------+--------------------------+
Table 3: Transition table of the task machine (g* =
pending_payment_or_plan_check).
Three cross-cutting notes. First, the terminal failed is reserved
for an unrecoverable system fault, which can terminate any task that
has not reached delivered, cancelled, or credited_or_refunded; this
family of fault edges is omitted from the per-state rows for
readability. A fault edge from a state in Phi targets
credited_or_refunded, because the gate commit has already recorded an
accepted payment, credit, or entitlement reference that requires
reconciliation. Before the gate, a fault edge targets failed when no
capture is recorded, and targets credited_or_refunded when a capture
is recorded. Both failed and credited_or_refunded are outside Phi,
and the model does not represent whether the later settlement-side
refund, credit, or entitlement reconciliation itself succeeds.
Second, a no-qualifying-contributor outcome is a post-gate business
outcome and routes to credited_or_refunded (the client has paid; the
charge is reconciled), not to failed. Third, validation failure
before funds move cancels the task. If the credential records funds
King Yew Choo Expires 24 January 2027 [Page 21]
Internet-Draft Agent-Initiated Payment Gating July 2026
already captured, failure routes to credited_or_refunded and
reconciles the settlement against rho_pay. A fresh wire challenge
([I-D.ryan-httpauth-payment]) begins a new payment attempt; the wire
scheme does not tie that attempt to this model's task machine. In
this model the key k remains claimed by the terminated request's
challenge record or its tombstone (C8), so a new attempt proceeds as
a new activation under a fresh idempotency key against a new quote.
King Yew Choo Expires 24 January 2027 [Page 22]
Internet-Draft Agent-Initiated Payment Gating July 2026
states at or before the gate: quotation, authorisation, and
payment validation (no fulfilment effects)
draft --> quoted --> accepted --> pending_authority
| | | |
| abandon | reject / refused/ | | authorised /
| | expired(R) declined | | re-approved
v v v v
cancelled <--+----------------------+ +-----------------+
^ | g* = pending_ |
| validate = false, no capture | payment_or_ |
+-------------------------------------+ plan_check |
+--------+--------+
|
validate(R, S, M) = true
(the only edge from outside
Phi into Phi)
=================================================|===========
fulfilment region Phi (level >= 5) |
. +-------------------------------------------+ .
. v .
. pending_expert_match --- no qualifying contributor ---+ .
. | contributor e with chi_M(e) = true found | .
. v | .
. awaiting_expert_input <--+ (self-loop: contribution | .
. | | |___________| appended to L) | .
. | | | .
. | | clarification required | .
. | v | .
. | needs_client_clarification | .
. | | answer received: back to | .
. | | awaiting_expert_input | .
. | | timeout / withdraw ---------------------+ | .
. | inputs sufficient | | .
. v v v .
. in_review --- unrecoverable defect ----> credited_or_ .
. | review passed refunded .
. v ^ .
. ready --- Omega constructed and written --+ | .
. v | dispute .
. delivered -+ upheld .
. .
............................................................
Figure 2: The task state machine. States at or before the gate
(level 4 or below) incur no modelled fulfilment effects; the only
edge from outside Phi into Phi is the gate edge, taken under
validate(R, S, M) = true.
King Yew Choo Expires 24 January 2027 [Page 23]
Internet-Draft Agent-Initiated Payment Gating July 2026
A system fault can terminate any task that has not reached delivered,
cancelled, or credited_or_refunded; the resulting edge targets failed
only before the gate with no capture recorded, and targets
credited_or_refunded otherwise. Both are outside Phi.
credited_or_refunded is drawn inside the frame only for layout. The
fault edges, the dl(q) deadline edges, and the edges to
credited_or_refunded on a recorded capture (from quoted on rejection
or requirement expiry, from g* on validate = false, and from
pending_authority on an authority failure or declined escalation) are
omitted from the figure.
5.4. Activation Requests, Keys, and Nonces
The gate transition is performed by an activation request: the call
that presents (R, S, M) for validation. Each activation request
carries an idempotency key k, client-supplied, stable across retries
of the same logical request, and namespaced per client. The task
store binds k to the task by an atomic compare-and-set CAS(k: bottom
-> taskId) that succeeds at most once per key (C8), performed as part
of the successful gate commit. On the 402 path the pre-gate record
carrying k is challenge state rather than a task record; the
credential retry carries the same k and is routed to that record.
The key k identifies the logical request; the nonce eta identifies
the issued challenge. The gate transition, at most one per task,
atomically binds k to the new taskId, confirms it against the
canonical-request digest recorded with the challenge, consumes
eta(R), commits spent(M), atomically reserves or consumes any finite
entitlement, records the accepted payment, credit, or entitlement
reference, and enters Phi. A request carrying an existing k is first
routed to the record bound to it, the challenge record before the
gate commit and the task afterwards; only a completed gate commit
bypasses revalidation. If these effects span stores, the
implementation requires a documented recovery protocol that blocks
entry to Phi until every partial outcome is reconciled. This
document does not specify that protocol and does not assume that an
external settlement can be reversed. On the entitlement path of
Section 3.4, where no 402 retry occurs, the post-quote request that
presents (R, S, M) serves as the activation request and carries k.
The idempotency-key discipline is established practice on payment-
initiating HTTP interfaces, and a generic header-field form was
drafted in the HTTPAPI Working Group as
[I-D.ietf-httpapi-idempotency-key-header], which has since expired
(Section 1.1) and which documents deployed interface patterns. This
document cites that draft as provenance for the discipline the model
binds to its gate, not as a standard; what the model adds is the
binding of the key to the payment gate specifically, confirmed by the
same gate commit that consumes the nonce.
King Yew Choo Expires 24 January 2027 [Page 24]
Internet-Draft Agent-Initiated Payment Gating July 2026
6. Well-Formedness Constraints and Operating Assumptions
This section states the eight well-formedness constraints and the
operating assumptions under which the four properties hold.
6.1. Constraints
The properties of Section 7 are statements about well-formed runs,
where well-formedness is the following eight constraints:
C1 (price-freeze): A task activates only at the price of its issued
quote; any change to the product or parameters requires a new
quote and a new R.
C2 (scope): The quote's scope descriptor is in the mandate's
authorised scope set.
C3 (deadline): The quote's deadline does not exceed the mandate's
authority expiry.
C4 (contributor criteria): Every ledger entry bound to a task under
mandate M is from a contributor satisfying chi_M.
C5 (authority/budget): Committed spend plus the quoted amount does
not exceed the mandate's cap.
C6 (escalation): When epsilon_M(q) is true, the task is routed to
human re-approval at pending_authority, pre-gate, and is never
auto-fulfilled.
C7 (single requirement): Exactly one requirement R is issued for
each quote. A task has at most one current, unconsumed R. After
R expires or is invalidated, continuing requires a new quote, and
no R is issued after the task crosses the gate.
C8 (atomic activation and idempotency): A digest of a stable,
versioned canonical representation covering every field that
affects quotation, authority, settlement, and fulfilment is
recorded with k before the gate, and the store binds k to taskId
at the gate commit; the representation and digest algorithm are
deployment obligations. Reuse with different request data fails.
At activation, the following form one recoverable transaction:
binding k to taskId, confirming the recorded digest, consuming
eta(R), committing spent(M), atomically reserving or consuming any
finite entitlement, recording the accepted payment, credit, or
entitlement reference, and entering Phi. Requests carrying k
after that transaction return the stored state without
revalidating R. The binding or a non-reusable tombstone remains
King Yew Choo Expires 24 January 2027 [Page 25]
Internet-Draft Agent-Initiated Payment Gating July 2026
available for at least the longest period in which the operator
accepts a retry or permits settlement of R. After that period,
the old key is rejected rather than allowed to select a new task.
C2, C3, and C5 are conjuncts of authorises; C1 and C7 are enforced by
the quote/requirement issuing map and the task engine; C4 by the
ledger invariant; C6 by pre-gate escalation routing; C8 by the task
store's atomic activation transaction.
6.2. Assumptions
The properties hold within the model under the following named
operating conditions. Each is checkable, and each names what would
have to be re-established if a deployment context differs.
* Mandate authenticity: the mandate and payment credential are
cryptographically verifiable, and credentialValid(cred, R) is
evaluable by the operator without trusting the calling agent;
authority rests on signature verification, not the agent's
assertion.
* Deterministic pricing: the pricing function returns one value for
the product, parameters, and pricing state at quote time;
challenge expiry bounds the window in which a frozen price is
honoured. All components participating in the gate commit use a
consistent time source and boundary convention for t_exp, dl, and
d_lim.
* Gate-before-fulfilment is enforceable: the operator controls the
ordering of its own task state machine, so no transition into Phi
occurs before the gate is satisfied. This is an invariant of the
operator's own task engine, not of any external protocol, and it
holds regardless of settlement method.
* Contributor supply and deadlines: lack of a qualifying contributor
leads to credited_or_refunded. Expiry of dl(q) before the gate
leads to cancelled when no capture is recorded, and to
credited_or_refunded when one is; expiry after the gate and before
delivery leads to credited_or_refunded. These deadline edges are
evaluated before other events.
* Hash collision-resistance: hashAlg identifies the hash algorithm
and artefactHash is computed over a stable byte representation of
the delivered artefact using that collision-resistant hash, making
substitution of a different artefact computationally infeasible
under the assumed hash security.
King Yew Choo Expires 24 January 2027 [Page 26]
Internet-Draft Agent-Initiated Payment Gating July 2026
* Idempotency keys are client-supplied, stable, retained at least as
long as a payment can be retried, and bound to a request
fingerprint: a retry within that period carries the same key, so
the retry properties apply when client retries cause duplicate
processing.
* Receipt and ledger integrity: the ledger L is append-only and the
receipt store is durable and tamper-evident, so unauthorised
rewriting is detectable; durability alone does not provide
integrity.
* Record identity and final-receipt cardinality: taskId identifies
exactly one task record; rho_pay identifies exactly one record
within its method-specific payment, credit, or entitlement store;
and the receipt store accepts at most one final Omega per taskId.
* Gate-commit integrity: the operator mints nonces with negligible
collision probability; the properties are conditional on no nonce
collision occurring. The gate-commit transaction of C8 occurs as
one atomic or recoverably journalled operation; a crash cannot
commit only a subset of its effects. A consumed nonce never
returns to fresh.
* Budget accounting: spent(M) is committed atomically with the gate
transition, so concurrent activations under one mandate serialise
against the cap and cannot jointly exceed it.
7. The Four Properties
Within the model, the following four properties are conditional
invariants: they depend on the constraints and operating assumptions
of Section 6 and are not guarantees supplied by the cited protocols.
Throughout, an execution trace is a finite path from draft respecting
the guards.
Trust boundary. These properties are guarantees against a
misbehaving or compromised client side: an agent that replays a
consumed challenge, reuses a key with different request data,
presents a forged or expired credential, attempts to spend outside
its mandate, or retries in a way that could otherwise cause duplicate
processing. They are not guarantees against the operator itself.
The operator runs the task engine, the nonce store, the task store,
the ledger, and the receipt store, so gate-before-fulfilment is an
invariant the operator enforces on its own execution, not a property
an external party could compel. An external party can recompute the
artefact hash and check only operator records to which it has access;
the model provides no operator-independent evidence. Adversarial
contributors are outside the four payment-gating properties.
King Yew Choo Expires 24 January 2027 [Page 27]
Internet-Draft Agent-Initiated Payment Gating July 2026
Deployments still need to authenticate contributors, limit access to
task data, validate contributed inputs and artefacts, and protect
ledger and receipt integrity from the fulfilment path. In fair-
exchange terms the model does not solve fair exchange in the
adversarial sense: strong fair exchange is known to be unattainable
without a trusted third party [PAGNIA], and here the operator, one of
the parties to the exchange, is trusted. The gate enforces ordering
between payment assurance and fulfilment; it does not provide fair
exchange between mutually distrustful parties.
7.1. Property 1: Gate-before-Fulfilment Safety
Statement. In every reachable trace, no side effect of the
fulfilment function F occurs unless validate(R, S, M) = true held at
that or an earlier step.
Argument (by construction over the transition table).
* (a) Phi excludes the start state: draft has level 0, below 5.
* (b) Enumerating the in-edges of Phi from Table 3: the only states
outside Phi with edges that could target Phi are the pre-gate
states, draft through g* (level 4 or below); the exception
terminals have no out-edges; and the cross-cutting fault edges
target failed or credited_or_refunded, neither of which is in Phi.
Inspection shows that the set of edges from outside Phi into Phi
is the singleton {g* to pending_expert_match}, guarded by
validate(R, S, M) = true. In particular pending_authority
resolves only to g*, cancelled, or credited_or_refunded, all
outside Phi, and needs_client_clarification is entered only from
awaiting_expert_input, an intra-Phi edge.
* (c) Every other edge with target in Phi has its source already in
Phi.
* (d) Hence any trace reaching a state in Phi contains the gate step
taken under validate = true. Since the side effects of F fire
only on transitions entering or internal to Phi, each occurs no
earlier than that successful validation. The guard is evaluated
atomically with the transition, and consume(eta(R)) makes
fresh(eta(R)) false, so no trace leaves Phi and later re-enters
it: re-entry could occur only through the gate edge, whose
freshness conjunct cannot hold again for this task (C7).
King Yew Choo Expires 24 January 2027 [Page 28]
Internet-Draft Agent-Initiated Payment Gating July 2026
7.2. Property 2: Idempotency under an Idempotency Key
Statement. While the C8 binding is retained, for activation requests
in one client namespace that carry the same key and request
fingerprint, at most one task record is selected. Later requests
observe the same record; reuse with a different fingerprint is
rejected. This property does not establish settlement-side charge
uniqueness.
Argument. The gate commit for the first activation carrying k runs
CAS(k: bottom -> taskId) (C8), which succeeds and binds exactly one
task record to k. On the 402 path the pre-gate challenge record
carries k, the credential retry maps to that record, and the gate
commit it drives performs the single CAS for k. A concurrent retry
that does not win the CAS is routed to the task created by the
winning commit once its request fingerprint matches. Any request
carrying k after the gate commit finds the outcome recorded; the
server returns the existing taskId and settlement reference rho_pay
(and, after delivery, the same Omega) without re-invoking F or
repeating the gate commit. Whether a settlement method can create
more than one transfer, authorisation, or capture is outside this
property and requires a settlement-side uniqueness guarantee. Hence
a retained key selects at most one task record and one gate commit.
Later requests address that evolving record.
7.3. Property 3: Single Acceptance per Payment Requirement
Statement. For any issued requirement R, at most one successful gate
transition consumes R. This model does not prevent multiple out-of-
band payments or settlement-side charges unless the selected
settlement method provides a uniqueness guarantee bound to R. Any
subsequent compensation issues a refund or credit against the
settlement reference rho_pay.
Argument.
* (a) The issuing map produces exactly one R per quote, with a nonce
generated with negligible collision probability, and by C7 at most
one unconsumed R is in force per task.
* (b) Validation consumes the nonce atomically; thereafter fresh is
false, so re-presenting the same proof cannot produce a second
successful gate transition. Nonce consumption alone does not
prove that only one transfer, authorisation, or capture occurred.
* (c) A second, distinct R requires a new quote (C1 and C7); no
replacement requirement is issued for the existing quote or after
the task crosses the gate.
King Yew Choo Expires 24 January 2027 [Page 29]
Internet-Draft Agent-Initiated Payment Gating July 2026
* (d) By Property 2, the keyed request produces at most one task
selection and one gate commit; this does not establish settlement-
side charge uniqueness.
Combining (a) through (d): at most one successful gate transition
consumes any issued R; this constrains server activation only, and
settlement idempotency remains a separate property of the selected
method. A later credited_or_refunded transition issues a refund or
credit against rho_pay; it never captures a second charge.
7.4. Property 4: Operator-Checkable Audit Record
Statement. Every task in state delivered has an operator-issued
receipt Omega whose fields can be checked against the operator-
controlled mandate, settlement, task, and receipt stores under the
assumptions of Section 6. This property does not provide evidence
against a dishonest or compromised operator.
Argument. The only in-edge to delivered is from ready, guarded by
the construction and writing of Omega; hence delivered implies Omega
exists. Omega embeds hashAlg and artefactHash (binding the exact
artefact under the hash algorithm named by hashAlg), rho_pay
(identifying the settlement record), taskId, and M. Under the
record-identity and final-receipt-cardinality assumption of
Section 6, the final delivery receipt is immutable. Compensation
records are separate append-only records linked to rho_pay and, where
a delivery receipt exists, to Omega; they neither replace Omega nor
violate final-receipt cardinality. verify_Omega resolves taskId to
the stored final receipt and requires equality, recomputes
artefactHash over the exact delivered bytes using hashAlg and checks
equality, resolves rho_pay against the method-specific payment,
credit, or entitlement record, resolves M against the mandate
registry, and checks the taskId binding against the task store; these
checks depend on the assumptions of Section 6 and on the operator-
controlled stores.
7.5. Composition
Together, the scoped properties state that modelled fulfilment
effects follow a successful gate transition (Property 1), a correctly
keyed request selects at most one task record (Property 2), one
requirement can produce at most one successful gate acceptance
(Property 3), and delivery creates an operator-controlled record
(Property 4). Bounded delegated spend is not a separate proven
property: non-exceedance of the mandate cap is delivered by the
budget conjunct withinBudget of authorises, which enforces C5,
together with the budget-accounting assumption of Section 6, under
which concurrent activations serialise against the cap. They do not
King Yew Choo Expires 24 January 2027 [Page 30]
Internet-Draft Agent-Initiated Payment Gating July 2026
establish payment-fulfilment atomicity, settlement-side charge
uniqueness, or operator-independent verification.
8. Operational Considerations
Settlement flexibility at one gate. The payment requirement R is
settlement-method-neutral, so settlement unavailability does not
propagate into the task machine. When no method in Settle can
realise R for a given caller, jurisdiction, or account, the
request does not pass the gate and, by Property 1, no modelled
fulfilment side effect occurs in the interim; C1 governs product
or parameter changes, not settlement-method changes, and because R
is settlement-method-neutral a method change reuses the same R.
By C7 no replacement requirement is issued for an unchanged quote,
so a new R follows only from a new quote. Settlement availability
is an operating assumption, not a property guaranteed by the
architecture: as of mid-2026 the Stripe implementation of MPP
gates acceptance by geography and legal entity [MPP-STRIPE], one
reason the model does not depend on any single settlement method.
Entitlement at the same gate. An existing entitlement satisfies the
same gate state that a fresh machine payment does: the entitlement
is the settlement method that realises R, so the same validation
runs and the same nonce is consumed, with no fresh machine
payment. The receipt structure and its verification semantics are
unchanged, with the mode field of Omega recording the entitlement
path.
Interaction shape. This model covers asynchronous, human-sourced
task creation via POST, not paid content retrieval. After the
gate admits the request, the task enters Phi and the server
returns a task identifier while fulfilment proceeds; a repeated
call under a retained idempotency key returns the same task or,
after delivery, the stored artefact and receipt. Settlement-side
charge behaviour remains governed by the selected settlement
method. The safety argument in Section 7.1 is stated for the
asynchronous task shape; paid content access would require the
analogous guarded transition from the gate to a ready state,
validated by the same predicate.
Authorisation and capture. Some settlement methods separate
King Yew Choo Expires 24 January 2027 [Page 31]
Internet-Draft Agent-Initiated Payment Gating July 2026
authorisation from capture. Deferring capture until delivery
introduces authorisation-expiry and capture-failure cases that
this model does not represent. A capture that becomes effective
after the task has already terminated is likewise reconciled
settlement-side, outside the model. The properties in Section 7
apply only when gate validation secures the quoted amount for the
expected fulfilment period; otherwise explicit reauthorisation,
capture-failure, and compensation transitions are required.
Regulatory scope. Gate validation is a technical check within the
model. It does not establish legal authority or discharge
authentication, disclosure, sanctions, tax, consumer-protection,
refund, chargeback, or other scheme and regulatory obligations.
Pre-gate eligibility. Deployments commonly run eligibility controls
beyond authority (conflict, confidentiality, or topic policy). In
the model these compose as pre-gate predicates resolving alongside
authority and escalation at pending_authority, never inside Phi.
Dependency on in-progress specifications. The wire scheme underneath
the gate is a live individual-submission Internet-Draft
(Section 1.1), and the protocol above it is vendor documentation.
Implementations can limit this dependency by pinning the
implemented revision and reviewing the pinned revision when it
expires or is superseded; treating header names and challenge
shapes as versioned against the pinned revision; keeping gate
semantics owned by the server's own decision layer and task
machine, not delegated to the wire scheme; and keeping settlement
flexible so no single settlement method is indispensable. These
controls limit, but do not remove, the implementation's dependency
on the pinned payment-scheme draft revision: the gate-before-
fulfilment discipline, the idempotency and challenge-binding
rules, and the durable receipt store hold regardless of how that
payment-scheme draft evolves.
9. Security Considerations
This document describes a model rather than a protocol, so the
considerations below concern the model and the conditions under which
its properties hold. Every activation and delivery path, including
the entitlement and credit paths that use no machine-payment wire
exchange, needs transport confidentiality, integrity, and server
authentication; object signatures alone supply none of these.
Credentials and receipts need sensitive-data handling on every path.
Deployments using the referenced Payment authentication scheme also
inherit the security considerations of [I-D.ryan-httpauth-payment],
including its transport protection, credential handling, challenge
binding, intermediary behaviour, caching, and denial of service.
King Yew Choo Expires 24 January 2027 [Page 32]
Internet-Draft Agent-Initiated Payment Gating July 2026
Replay. The nonce eta is bound into the requirement R and re-
presented in the credential, so a credential cannot be replayed
against a different challenge. Validation consumes the nonce
atomically and a consumed nonce never returns to fresh, so replay
of a consumed nonce fails the freshness conjunct. A stale
requirement is rejected via expired(R) and forces a re-quote; a
fresh R carries a fresh nonce.
Double charge. One requirement per quote, the single-active-
requirement constraint (C7), and the price-freeze constraint (C1,
which forces a superseding quote for any parameter change) combine
with atomic nonce consumption to bound gate acceptance at one
requirement per task (Property 3). Retries under a stable
idempotency key are absorbed by the compare-and-set (C8) at the
gate, not inside the fulfilment region, so a duplicate request
never starts a second fulfilment execution; keys are scoped to an
authenticated client; possession of k alone does not authorise
access to the bound task or receipt. A client that retries
without a stable key can create and pay for a second task. Nonce
consumption prevents reuse of one payment requirement; it does not
provide logical-request idempotency across different keys.
Delegated authority and escalation. Authority acceptance precedes
gate acceptance, and gate acceptance precedes fulfilment. Because
settlement happens out of band, a transfer or capture can be
recorded before authority resolution completes; the capture-
recorded exits reconcile that case, so the model does not order
the movement of funds against authority resolution. An
unauthorised purchase attempt by a misbehaving agent is an
authority failure, caught at pending_authority by authorises(M, q)
before the payment gate is reached. The escalation predicate is
evaluated first and takes precedence; when it holds, the task
requires human re-approval, does not advance automatically, and
pending_authority never resolves into Phi. Within this model,
bounded delegation limits the amount committed through conforming
gate transitions to the mandate cap; it does not bound settlement-
side duplicate charges or non-monetary harm. The authority re-
check at the gate is defensive, and authority rests on signature
verification of the mandate. Authority is evaluated at
pending_authority and re-checked at the gate, and not again inside
Phi, so revocation of M after the gate does not stop fulfilment or
delivery and does not restore spent(M). A deployment that needs
revocation to take effect mid-fulfilment adds an explicit in-
region check and a compensation route.
Denial of cost. The inverted pattern, in which contributor sourcing
King Yew Choo Expires 24 January 2027 [Page 33]
Internet-Draft Agent-Initiated Payment Gating July 2026
or other operational cost precedes the gate, lets a non-paying or
unauthorised caller extract cost from the server. The transition
model places matching, ledger writes, and artefact generation
after gate validation. Before the gate, a caller can still force
quote creation, nonce issuance, challenge-state recording, and
credential checks; admission control, authenticated quotas,
bounded retention, and rate limits remain deployment concerns.
The model also does not remove authorisation-expiry or capture-
failure risk. Cost extraction after the gate remains possible: an
upheld dispute moves a delivered task to credited_or_refunded,
recording a refund or credit obligation, while the contributor
cost and the disclosed artefact are unrecoverable. Monotonic
spent(M) bounds repetition within one mandate but not across
mandates, so dispute adjudication, evidence retention, and client
reputation controls remain deployment concerns. Settlement
unavailability likewise triggers no modelled fulfilment effects.
Audit integrity. Delivery without a receipt is unreachable, since
the only in-edge to delivered is guarded by the construction of
Omega; receipt uniqueness requires one immutable Omega per task,
and verification cross-checks operator-controlled records rather
than trusting a single log entry. These guarantees hold to the
extent that the ledger is append-only and the receipt store
durable, that the artefact hash is collision-resistant, and that
the nonce store preserves its integrity. Compensations write a
compensating receipt against rho_pay, making attempted refund or
credit handling auditable; a separate settlement result
establishes whether the refund or credit succeeded; the settlement
mode as executed is recorded, including test and mock modes, so
receipts remain accurate under settlement flexibility.
Post-gate client input. The clarification channel accepts client
input inside Phi. Scope, eligibility, and escalation predicates
are evaluated at or before the gate and never inside Phi, so a
deployment re-applies scope and eligibility policy to
clarification content, or treats a clarification that changes the
work as requiring a new quote under C1.
Contributors. Contributors write to L and read task data from inside
Phi. They sit outside the four payment-gating properties;
deployments need contributor authentication, least-privilege
access to task data, validation of contributed inputs and
artefacts, and protection of the ledger and receipt stores from
the fulfilment path (Section 7).
Privacy. Omega and L are sensitive because they can identify
King Yew Choo Expires 24 January 2027 [Page 34]
Internet-Draft Agent-Initiated Payment Gating July 2026
principals, delegated authority, and contributors. The "Payment"
scheme also classifies payment receipts as sensitive
[I-D.ryan-httpauth-payment]. The full Omega remains as defined in
Section 4.4; any redacted or commitment-bearing object shared
externally is a derivative with a different verification
procedure. Deployments need documented retention, access-control,
and disclosure policies for these records.
Cache leakage. Payment challenges and receipts carry payer-specific,
time-sensitive data; the wire scheme requires 402 responses to
include "Cache-Control: no-store" and responses carrying a
"Payment-Receipt" header to include "Cache-Control: private"
([I-D.ryan-httpauth-payment]), and the model assumes receipts are
not cached in shared caches.
Trust boundary. As stated in Section 7, the four properties defend
against a misbehaving client side. They are not guarantees
against the operator, who runs all of the stores; gate-before-
fulfilment is a self-enforced operator invariant, and the only
externally checkable output is the receipt Omega, subject to the
integrity and availability of operator-controlled records.
Parties that require guarantees against the operator itself need
mechanisms outside this model, such as third-party attestation of
the stores.
Fail-closed discipline. Failure of any conjunct of validate(R, S, M)
causes access to be refused, with no modelled fulfilment side
effect.
10. IANA Considerations
This document has no IANA actions.
11. Informative References
[AP2] Google, "Powering AI commerce with the new Agent Payments
Protocol (AP2)", 16 September 2025,
<https://cloud.google.com/blog/products/ai-machine-
learning/announcing-agents-to-payments-ap2-protocol>.
[AP2-SPEC] Google, "Agent Payments Protocol (AP2) Specification,
Version 0.2", n.d.,
<https://ap2-protocol.org/ap2/specification/>. Accessed
23 July 2026; the specification page heads the document
"Agentic Payment Protocol (v0.2)".
King Yew Choo Expires 24 January 2027 [Page 35]
Internet-Draft Agent-Initiated Payment Gating July 2026
[ARCH] Choo, K. Y., "An MPP-First, Settlement-Flexible
Architecture for Self-Serve Agentic Expert-Access:
Protocol Analysis, Formal Model, and Business-Model
Transition", DOI 10.2139/ssrn.6928639, 12 June 2026,
<https://doi.org/10.2139/ssrn.6928639>.
[I-D.ietf-httpapi-idempotency-key-header]
Jena, J. and S. Dalal, "The Idempotency-Key HTTP Header
Field", Work in Progress, Internet-Draft, draft-ietf-
httpapi-idempotency-key-header-07, 15 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-
idempotency-key-header-07>.
[I-D.ryan-httpauth-payment]
Ryan, B., Moxey, J., Meagher, T., Weinstein, J., and S.
Kaliski, "The "Payment" HTTP Authentication Scheme", Work
in Progress, Internet-Draft, draft-ryan-httpauth-payment-
01, 18 March 2026, <https://datatracker.ietf.org/doc/html/
draft-ryan-httpauth-payment-01>.
[MCP] Anthropic, "Model Context Protocol specification, protocol
version 2025-11-25", November 2025,
<https://modelcontextprotocol.io/
specification/2025-11-25>.
[MPP-SPECS]
Tempo Labs and Stripe, "Machine Payments Protocol (MPP)",
2026, <https://github.com/tempoxyz/mpp-specs>. Accessed
23 July 2026; rolling "latest" release artefacts
republished 17 July 2026 (the repository publishes no
stable version tags).
[MPP-STRIPE]
Stripe, "MPP payments", 2026,
<https://docs.stripe.com/payments/machine/mpp>. Accessed
23 July 2026.
[PAGNIA] Pagnia, H. and F. C. Gaertner, "On the Impossibility of
Fair Exchange without a Trusted Third Party (Technical
Report TUD-BS-1999-02, Darmstadt University of
Technology)", 1999,
<https://web.archive.org/web/20211002203331/http://lpdwww.epfl.ch/
fgaertner/pubs/TUD-BS-1999-02.abstract.html>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>.
King Yew Choo Expires 24 January 2027 [Page 36]
Internet-Draft Agent-Initiated Payment Gating July 2026
[X402] x402, "x402", n.d., <https://www.x402.org/>. Accessed 23
July 2026.
[X402-LF] The Linux Foundation, "Linux Foundation Announces
Operational Launch of x402 Foundation to Standardize
Internet-Native Payments for AI Agents and Applications",
14 July 2026, <https://www.linuxfoundation.org/press/
linux-foundation-announces-operational-launch-of-x402-
foundation-to-standardize-internet-native-payments-for-ai-
agents-and-applications>.
Author's Address
King Yew Choo
True Primary
Email: k.choo@trueprimary.com
King Yew Choo Expires 24 January 2027 [Page 37]