Attested Payment Authorization for Autonomous Agents
draft-hawkins-scitt-attested-agent-payment-01
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 | Walter Hawkins | ||
| Last updated | 2026-08-14 (Latest revision 2026-08-05) | ||
| 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-hawkins-scitt-attested-agent-payment-01
Network Working Group Walter D. Hawkins
Internet-Draft Independent
Intended status: Standards Track 15 August 2026
Expires: 16 February 2027
Attested Payment Authorization for Autonomous Agents
draft-hawkins-scitt-attested-agent-payment-01
Abstract
Autonomous software agents increasingly initiate payments on behalf
of principals. Existing agent-payment mechanisms authenticate the
human principal, the operator, or possession of a key; none of them
establishes that the software authorized to spend is the software
that was reviewed. A key held by a compromised or silently modified
agent authenticates exactly as well as one held by an honest agent.
This document defines a payment authorization scope bound to a key
whose protection properties are attested by hardware, and registers
the resulting authorization as a Signed Statement on an SCITT
Transparency Service. The binding reuses the EAT confirmation and
key-attributes claims without modification; the contribution is the
authorization scope, the verification procedure a payment executor
performs before settlement, the transparency record that makes the
authorization artifact and its registration auditable independently
of the agent and of the executor, and an execution-record mechanism
that makes the executor's aggregate accounting auditable on
challenge. What is registered evidences the authorization; it does
not evidence that the verification procedure was performed for any
given settlement.
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 16 February 2027.
Hawkins Expires 16 February 2027 [Page 1]
Internet-Draft Attested Agent Payment Authorization August 2026
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Conventions and Definitions . . . . . . . . . . . . . . . 4
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. The Authorization Scope . . . . . . . . . . . . . . . . . . . 5
4. Verification Before Settlement . . . . . . . . . . . . . . . 9
5. Registration on a Transparency Service . . . . . . . . . . . 12
5.1. Execution Records and the Aggregate Bound . . . . . . . . 13
6. Expiry and Revocation . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction
Protocols for agent-initiated payment have converged quickly. They
differ in mechanism but agree on what they bind: the consent of a
human principal, the identity of an operator, or possession of a
private key. What none of them binds is the identity of the running
program.
This distinction is not academic. Measurements of deployed agent-
payment traffic over a 280-day window classify 21.20 percent of
settlements as fictitious and 63.78 percent as internal settlement
within a linked cluster -- 84.98 percent operator-internal in total
[MEASURE]. An independent study of the ERC-8004 agent registries
Hawkins Expires 16 February 2027 [Page 2]
Internet-Draft Attested Agent Payment Authorization August 2026
across three chains [ERC8004-STUDY] found that only 3% (Ethereum), 4%
(BSC), and 15% (Base) of registered agents had a registration file
that resolved, parsed as compliant, and declared at least one service
endpoint; that reputation feedback was almost completely decoupled
from economic activity (on Base, 93.8% of reviewers had never made a
payment yet produced 94.9% of all feedback); and that the median cost
of moving an agent's reputation score was $0.0027, against a median
agent payment volume of $0.70. Possession of a key is compatible
with all of these outcomes: it demonstrates that some party controls
a secret, not that a particular program is running, nor that its
behavior is the behavior that was authorized.
The same study reports that the registry standard's own Validation
Registry -- the component its specification reserves for independent
attestations, naming stake-secured re-execution, zkML proofs, and TEE
attestation -- had no confirmed mainnet deployment through May 2026.
The ecosystem has, in other words, already named the place where
evidence stronger than self-reported feedback belongs, and left it
empty. A track record answers whether an agent has behaved well and
can be moved for fractions of a cent; an attestation answers whether
the running code is the endorsed code, right now, and is structural
from the first transaction. This document specifies the second kind
of evidence for the payment-authorization decision in particular.
Meanwhile the primitives needed to close the gap exist and are
specified. [I-D.reddy-rats-key-binding] binds a subject key to an
attested execution environment using the EAT "cnf" claim [RFC8747]
and a "key-attributes" claim describing key protection properties.
[RFC9943] defines a Transparency Service on which signed statements
about an artifact can be registered and later audited. Nothing joins
them: no specification makes hardware attestation normative for a
payment authorization decision, and no deployed system consults an
attestation before releasing funds.
This document defines that join. It is deliberately small: it adds
no new attestation format, no new key binding, and no new
transparency mechanism. It specifies (1) what an authorization scope
contains, (2) the verification a payment executor MUST perform, and
(3) what is registered so that a third party can later audit an
authorization without trusting either the agent or the party that
executed the payment.
1.1. Non-Goals
This specification does not:
* define agent identity, naming, or discovery;
Hawkins Expires 16 February 2027 [Page 3]
Internet-Draft Attested Agent Payment Authorization August 2026
* define or require any particular payment protocol, settlement
rail, or currency;
* establish the correctness of the attested software. An
attestation proves that the running code is the endorsed code; it
says nothing about whether that code is correct. Presenting the
former as the latter is the central misuse this document warns
against (Section 7);
* replace principal consent mechanisms. Attested authorization
composes with them and is not a substitute: consent establishes
that spending was wanted, attestation establishes which program
may do the spending.
1.2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Agent: An autonomous software instance that initiates payments.
Payment Executor: The party that performs or submits settlement on
an agent's instruction. In deployed systems this is typically a
facilitator, gateway, or custodial service.
Authorization Scope: The bounded permission to spend, defined in
Section 3.
Attested Payment Key (APK): The Subject Key of
[I-D.reddy-rats-key-binding] when used to authorize payments under
this specification.
Issuer: The party that signs the Authorization Scope's Signed
Statement; the "iss" of [RFC9943]. Registration authenticates the
Issuer as the party that made the statement. It does not by
itself establish that the Issuer may bind the funds the scope
spends; that check is Check 8 of Section 4.
Authorization-Time Evidence: Attestation evidence generated at scope
issuance and registered with the scope, establishing the APK-to-
code binding as of registration. This is the evidence the Receipt
refers to.
Transaction-Time Evidence: Attestation evidence generated freshly
Hawkins Expires 16 February 2027 [Page 4]
Internet-Draft Attested Agent Payment Authorization August 2026
for one payment, under a nonce supplied by the executor,
establishing that the binding still holds at the moment of
payment. The two evidence classes are distinct artifacts and MUST
NOT be conflated: registered evidence cannot contain a nonce an
executor generates later, and fresh evidence is not the artifact
the Receipt refers to.
2. Overview
An agent operating in an attested environment generates a key pair
inside that environment and obtains an Entity Attestation Token (EAT)
[RFC9711] carrying the "cnf" claim for the public key and the "key-
attributes" claim describing its protection properties, per
[I-D.reddy-rats-key-binding].
The agent's principal (or an operator acting for it) issues an
Authorization Scope naming that key and the bounds within which it
may spend. The scope, a reference to the authorization-time
evidence, and the endorsed software identity are registered together
as a Signed Statement on a Transparency Service [RFC9943], yielding a
Receipt. At payment time the executor additionally obtains
transaction-time evidence under its own nonce; the two evidence
classes are defined in Section 1.2 and consumed by different checks
of Section 4.
When the agent later instructs a payment, the Payment Executor
verifies the attestation, verifies that the instruction is signed by
the APK, verifies that the payment falls within the scope, and
verifies the Receipt before settling. Each of these is a pre-
execution check: the authorization decision is made before funds
move, not reconstructed afterward from logs.
3. The Authorization Scope
An Authorization Scope is a CBOR map, encoded in the deterministic
encoding of Section 4.2.1 of [RFC8949]; the scope digest is computed
over exactly those bytes. Determinism here is load-bearing, not
hygienic: the digest is how a scope is referenced -- in Receipts, in
executor reports, and in the binding of a held payment to the scope
it was opened under -- and identical scopes that hash differently
across encoders would quietly break every one of those references.
The following members are defined; unknown members not named in
"crit" MUST be ignored (see "crit" below for why blanket ignoring
alone would be too permissive for authorization constraints).
apk (REQUIRED): The COSE Key Thumbprint [RFC9679] of the Attested
Hawkins Expires 16 February 2027 [Page 5]
Internet-Draft Attested Agent Payment Authorization August 2026
Payment Key, computed with SHA-256 over the required-parameter
COSE_Key construction of that document. RFC 9679 leaves the hash
function to the application; this profile fixes SHA-256 so that
independently computed thumbprints are comparable. This is the
key whose "cnf" appears in the attestation evidence; the
comparison procedure is Check 2 of Section 4.
code (REQUIRED): The endorsed software identity the attestation is
expected to report, expressed as a structure of three members:
"alg", the digest algorithm; "artifact", the class of artifact
measured (for example a confidential-VM launch measurement or a
container image), drawn from the attestation-technology profile in
use; and "digest", the expected value. RFC 9711 deliberately
leaves measurement semantics to profiles, so a bare digest is not
comparable across attesters: naming the algorithm and the measured
artifact class is what makes the Check 4 comparison defined. This
is the value that makes the authorization specific to a program
rather than to a deployment.
limits (REQUIRED): The spending bounds. At minimum a maximum amount
per payment and a maximum aggregate amount over a stated window,
each with an explicit unit. Amounts are integer counts of the
smallest unit of the stated currency, with the scale declared
explicitly; floating-point amounts MUST NOT be used, because there
is no safe float-to-integer path once value is on the wire. The
aggregate window is a rolling window of the stated number of
seconds ending at evaluation time; calendar-day readings, which
produce different authorization decisions on identical inputs
depending on time zone, are not a conforming interpretation. A
scope with no upper bound MUST NOT be registered.
executor (REQUIRED when "limits" carries an aggregate bound): The
identity of the single Payment Executor that serializes spending
under this scope. An aggregate bound is only an aggregate if one
party accounts for it: absent this binding, N executors each
enforce the bound independently and the principal's exposure
multiplies by N while every party remains conformant. An executor
presented with an instruction under a scope naming a different
executor MUST refuse. Scopes whose limits contain only a per-
payment bound MAY omit this member.
expiry (REQUIRED): The time after which the scope is invalid,
expressed as epoch seconds, a CBOR unsigned integer. This is the
only permitted form: a second accepted timestamp shape is an
encoding divergence, not a convenience. Scopes are short-lived by
design; see Section 6.
rails (OPTIONAL): The settlement systems on which the scope is
Hawkins Expires 16 February 2027 [Page 6]
Internet-Draft Attested Agent Payment Authorization August 2026
valid, enforced by Check 6 of Section 4. Absence means the scope
itself imposes no rail restriction; it does not override any
restriction the relying party's own policy imposes. Rail
identifiers are opaque strings whose namespace is defined by rail
profiles.
payees (OPTIONAL): Constraint on permitted counterparties, enforced
by Check 6 of Section 4. Payee identifiers are opaque strings
whose namespace is defined by rail profiles.
crit (OPTIONAL): A list of member names critical to this scope. An
executor that does not understand every member named in "crit"
MUST refuse instructions under the scope. This is the repair for
a conflict the extension rule would otherwise create: a future
restrictive member -- a payee category, a jurisdiction constraint
-- ignored by an older executor silently widens the effective
scope, which is precisely the widening Section 7 warns against,
produced by the extension rule itself. Blanket rejection of
unknown members would kill extensibility; criticality marking puts
the choice with the issuer, who signs the scope.
on_indeterminate (OPTIONAL): Selects the issuer's disposition when
the supersession check cannot be completed (Check 9 of Section 4).
Absent this member, the disposition is "refuse": an indeterminate
supersession result fails closed, because settling on it would be
proceeding on unknown current authority. The member MAY move off
that default to one of two named modes.
"hold": with a deadline, suspends the decision until the
supersession status is determined or the deadline passes,
whichever comes first. The deadline MUST NOT exceed "expiry"
and defaults to it. A payment held under "hold" and
subsequently evaluable MUST be re-checked against the whole of
Section 4 before settlement, including the "eat_nonce"
freshness check and the Receipt: a hold suspends the decision
and MUST NOT cache a partial pass. "hold" does not settle on an
indeterminate result; it waits for a determinate one. A hold
is bound, by digest, to the scope under which it was opened,
and a payment MUST NOT settle on the basis of a hold opened
under a scope other than the one in force at settlement: where
the scope has been superseded or reissued during the hold, the
resumed evaluation is a new evaluation under the scope then in
force, and the prior hold confers nothing. Because Section 6
prefers reissuance to long lifetimes, a hold spanning a
reissuance is the common case, not the corner case.
"bounded-fail-open": settles within "expiry" despite an
Hawkins Expires 16 February 2027 [Page 7]
Internet-Draft Attested Agent Payment Authorization August 2026
indeterminate supersession result. This is bounded fail-open
for revocation availability, named as such: it trades
revocation-safety for liveness, and its exposure -- settling a
payment whose current authority could not be confirmed -- is
stated in Section 7. It is available only by explicit issuer
selection and is never the default.
The scope is defined by the following CDDL; the prose above states
intent, this definition is the algorithm's input contract:
authorization-scope = {
"apk": bstr, ; RFC 9679 thumbprint, SHA-256
"code": software-identity,
"limits": spending-limits,
"expiry": uint, ; epoch seconds
? "rails": [+ tstr], ; namespace: rail profiles
? "payees": [+ tstr], ; namespace: rail profiles
? "executor": tstr, ; REQUIRED with an aggregate bound
? "on_indeterminate": on-indeterminate,
? "crit": [+ tstr],
* tstr => any ; unknown; refused if named in crit
}
software-identity = {
"alg": tstr, ; e.g. "sha-256", "sha-384"
"artifact": tstr, ; measured-artifact class, from the
; attestation-technology profile
"digest": bstr
}
spending-limits = {
"currency": tstr, ; asset identifier
"scale": uint, ; smallest-unit scale declaration
"per_payment": uint, ; integer count of smallest unit
? "aggregate": uint,
? "window": uint ; rolling seconds ending at
; evaluation time; REQUIRED with
; "aggregate"
}
on-indeterminate = {
"mode": "hold" / "bounded-fail-open",
? "deadline": uint ; epoch seconds; MUST NOT exceed
; "expiry"; meaningful for "hold"
}
Hawkins Expires 16 February 2027 [Page 8]
Internet-Draft Attested Agent Payment Authorization August 2026
An Authorization Scope MUST NOT be widened by any party other than
its issuer, and an agent MUST NOT be able to widen its own scope by
any means, including by presenting a newer attestation. Narrowing
MAY be performed by the executor.
4. Verification Before Settlement
Before executing a payment presented under this specification, a
Payment Executor MUST perform all of the following checks. Checks 1
through 8 are completeness checks: the executor MUST NOT settle if
any of them fails or cannot be completed. Check 9 (supersession) is
a positive-signal check whose distinct semantics are stated in that
item and in Section 6.
This profile uses the combined model of [I-D.reddy-rats-key-binding]:
a single EAT whose "cnf" claim carries the Subject Key. The split
model (a PAT carrying the KAK and a KAT carrying the Subject Key,
with its distinct verification sequence) is out of scope at this
revision; "the evidence" below is therefore unambiguous.
1. The transaction-time evidence verifies against the expected
Attester's trust anchors, including enforcement of the "iat",
"nbf", and "exp" claims per the dependency's verifier
requirements, and the freshness value in "eat_nonce" was supplied
by the verifying party for this transaction. A replayed
attestation MUST NOT be accepted. The authorization-time
evidence referenced by the Receipt (Check 8) is a distinct
artifact and does not satisfy this check.
2. The Subject Public Key carried in the evidence's "cnf" claim,
when used to construct the required-parameter COSE_Key of
[RFC9679] and hashed with SHA-256, yields a thumbprint byte-for-
byte equal to the "apk" named in the scope. The comparison is
over the computed thumbprint, never over serialized key encodings
-- the dependency's own rule for proof-of-possession comparison,
applied to the thumbprint path.
3. The "key-attributes" claim carries "never_extractable" true,
"extractable" false, and "local" true. The property this profile
relies on is never-extractability: a key that was extractable at
any point may already have copies outside the environment, so
"extractable" false alone is insufficient; "local" true
establishes the key was generated within the attested environment
rather than imported into it. Because every key-attributes
member is optional in the dependency, absence of any of these
three members is not an assertion of anything and MUST be treated
as failure of this check.
Hawkins Expires 16 February 2027 [Page 9]
Internet-Draft Attested Agent Payment Authorization August 2026
4. The software identity reported by the attestation equals the
"code" structure in the scope: the same measured-artifact class,
the same digest algorithm, and a byte-for-byte equal digest.
5. The payment instruction is signed by the APK, and the
instruction's terms are covered by that signature. Terms not
covered by the signature MUST NOT be treated as authorized. The
instruction MUST identify exactly one Authorization Scope by
scope digest, and this procedure selects the scope by that
digest, never by the APK alone: more than one live scope can
exist for one APK, differing only in rails or payees, and
selection by key would multiply the principal's exposure across
all of them. Where more than one live scope could apply and the
instruction carries no scope digest, the executor MUST refuse.
The instruction MUST additionally bind, under the same signature:
a payment intent identifier, the payee, the amount with an
explicit unit, and the rail. An executor MUST NOT settle the
same payment intent identifier more than once under a scope:
"eat_nonce" freshens the attestation, not the instruction, so
without intent identity a replayed instruction composes with
fresh evidence and consumes the aggregate ceiling in fully
conforming steps. Encodings of these fields are left to rail
profiles; their presence and their coverage by the signature are
not.
6. The payment satisfies every constraint the scope carries: it
falls within "limits"; where "rails" is present, the payment's
rail is among them; where "payees" is present, the counterparty
satisfies that constraint. Constraint members that the normative
procedure did not evaluate would not be constraints. The
aggregate bound is evaluated against the executor's enumeration
of execution digests for this scope (Section 5.1): the sum over
the enumerated payments, plus the payment being evaluated, does
not exceed the aggregate limit. The evaluation-and-settlement
sequence MUST be atomic with respect to that enumeration, so that
concurrent instructions cannot each pass this check against the
same prior state. On settlement, the payment's execution digest
joins the enumeration.
7. "expiry" has not passed.
8. A valid Receipt for the scope's registration is available from
the Transparency Service, and the executor has established, by a
rail- or deployment-defined procedure, that the scope's Issuer
may authorize spending from the account the payment draws on.
Registration authenticates the party that made the statement; it
does not establish that this party may bind those funds. This
document does not define the funds-authority procedure -- it is
Hawkins Expires 16 February 2027 [Page 10]
Internet-Draft Attested Agent Payment Authorization August 2026
necessarily rail- or deployment-specific -- but a conforming
executor MUST have one, and its absence is failure of this check,
not a permission.
9. No superseding statement for the scope is present on the
Transparency Service (Section 6). Unlike checks 1 through 8,
this is a positive-signal check: a superseding statement that is
found MUST stop settlement, and a determinate result showing none
present passes. An indeterminate result -- the executor cannot
determine whether a superseding statement exists -- is fail-
closed by default: the executor MUST NOT settle, because settling
would proceed on unknown current authority. A null or empty
answer from the Transparency Service is an indeterminate result,
and so is an answer that arrives unsigned or without a log
position where the service advertises supersession queries
(Section 6): the absence of a verifiable answer is never a
determinate showing that no superseding statement exists, and
implementations that treat the two as equivalent will diverge
exactly where the distinction matters. "expiry" bounds how long
such exposure could last, not whether this payment remains
authorized, so it is not a substitute for the check. An issuer
MAY change the indeterminate disposition per scope with
"on_indeterminate" (Section 3): "hold" to wait for a determinate
result, or "bounded-fail-open" to settle within "expiry" despite
the indeterminate result -- the latter named for the revocation-
availability exposure it accepts (Section 7), and available only
by explicit issuer selection.
The checks above establish that the reviewed program made the payment
decision only if signatures by the APK cannot originate outside it.
All use of the APK for payment signing MUST be mediated by the
component covered by the "code" measurement, such that unmeasured
software cannot cause an APK payment signature except through the
authorization checks performed by that measured component. A signing
interface inside the attested environment that accepts requests from
unmeasured software defeats the design while passing every per-
payment check: the signature is valid, the key is never-extractable,
the attestation verifies, and the payment decision was still not made
by the reviewed program. Deployments MUST NOT expose such an
interface, and Registration Policies SHOULD require the Issuer to
assert this property at registration. Without it, the step from key-
bound-to-environment to payment-decision-bound-to-reviewed-agent --
this document's thesis -- is not established.
An executor MUST distinguish, in whatever it reports to the
instructing party, between "authorization refused" and "authorization
could not be evaluated". Collapsing the two allows an outage in an
attestation or transparency service to be indistinguishable from a
Hawkins Expires 16 February 2027 [Page 11]
Internet-Draft Attested Agent Payment Authorization August 2026
policy decision, which in practice produces pressure to fail open.
Where a scope names "on_indeterminate" (Section 3), the executor MUST
record in that report the action taken under it -- refused, held
until a stated time, or re-evaluated and settled. A hold is a policy
decision, and the distinction this section requires exists precisely
so that a policy decision and an outage cannot be confused; an
unrecorded hold would reintroduce that confusion. The executor
SHOULD additionally record the disposition in force, so that the
issuer's intent and the executor's action appear on the same record
rather than the executor's action alone.
Executors MUST fail closed. An executor that cannot complete checks
1 through 8 MUST NOT settle. An indeterminate supersession result
(Check 9) is fail-closed by default -- the executor refuses, or,
where the scope so selects, holds for a determinate result. It
settles on an indeterminate result only where the scope has
explicitly selected the "bounded-fail-open" mode of
"on_indeterminate" (Section 3), which trades revocation-safety for
liveness within "expiry" and is documented as such in Section 7.
Absent that explicit selection, an indeterminate result MUST NOT
settle.
5. Registration on a Transparency Service
The Authorization Scope, together with a reference to the attestation
evidence and the endorsed software identity, is registered as a
Signed Statement per [RFC9943]. The resulting Transparent Statement
and Receipt make three properties available to parties who were not
present at authorization time:
* that a scope with these bounds existed and was registered before
the payment, rather than reconstructed afterward;
* that the authorization named a specific software identity, which
an auditor can compare against a build they can reproduce; and
* that the record is held outside both the agent and the executor,
so the audit trail does not depend on either party's own account
of events. Neutrality of the Transparency Service itself is a
deployment goal rather than a property a Receipt carries --
[RFC9943] permits a service operated by an interested party -- and
is made checkable by witnessing rather than asserted: see the
countersigned-checkpoint requirement in Section 7; and
* through the execution records of Section 5.1, that a specific
settled payment was counted against this scope, not just plausible
under it.
Hawkins Expires 16 February 2027 [Page 12]
Internet-Draft Attested Agent Payment Authorization August 2026
A Transparency Service accepting these statements records what was
submitted; it does not adjudicate it. Registration Policy SHOULD NOT
condition acceptance on the referenced attestation evidence
verifying, and a service MUST NOT label a registration as attested or
otherwise vouch for the evidence it references: verification is the
relying party's act (Section 4), and a log that grades what it stores
has acquired exactly the interest in characterization that the bullet
above disclaims for it. What Registration Policy SHOULD require is
well-formedness -- that the statement parses as an Authorization
Scope per Section 3 and that its evidence references are digest-
bearing.
Evidence and scopes SHOULD be referenced by digest rather than by
location alone, so that a later auditor can detect substitution of
the artifact a Receipt refers to.
5.1. Execution Records and the Aggregate Bound
The Receipt proves that a scope predated a payment. It does not
prove that any specific settled payment was counted against the
scope's aggregate bound: an executor's private spending record is a
claim no party outside the executor can check, and this document's
own position is that such a claim is treated as absent. The
aggregate bound is therefore made checkable as follows.
For each payment settled under a scope, the executor MUST compute an
execution digest over the settled payment's fixed fields: amount,
payee, settlement timestamp, and the scope digest under which it was
authorized. The execution digest is distinct from the scope digest
and not derivable from it; any party holding the settled payment's
terms can recompute it without the executor's cooperation.
The executor MUST maintain, per scope, the enumeration of execution
digests counted against the scope's aggregate bound, and MUST produce
that enumeration when challenged by the issuer or by an auditor. The
sum over the enumerated payments is what a challenger compares
against the aggregate limit, and a settled payment whose execution
digest is absent from the enumeration is the discoverable failure.
Without the enumeration requirement, a recomputable digest
establishes only that a payment could have been counted, which is the
same self-report one step removed.
The two digests are deliberately independent: neither is derived from
the other, and each is discoverable alone. A chained construction,
in which the execution record embeds the digest of the authorization
it answers, achieves pairing and is deployed in at least one running
system [I-D.sirkkavaara-vaara-receipt]; this document requires
independence instead, because a chained second record that the
Hawkins Expires 16 February 2027 [Page 13]
Internet-Draft Attested Agent Payment Authorization August 2026
executor withholds leaves the first record with no visible evidence
that an answer was ever owed, whereas an independently anchored
execution digest can be found by any party that holds the settled
payment's terms, whether or not the executor cooperates.
6. Expiry and Revocation
Authorization under this specification is short-lived by
construction. A scope SHOULD have an "expiry" no longer than is
operationally necessary, and issuers SHOULD prefer reissuance to long
lifetimes.
This is a deliberate design choice. Revocation that depends on a
signal reaching an executor in time is only as reliable as that
signal; expiry requires no message to arrive, no service to be
reachable, and no action by the revoking party. An issuer that stops
reissuing has revoked, and the maximum exposure is bounded by the
remaining lifetime.
Where an explicit revocation signal is also available, it MAY be
registered as a superseding statement on the Transparency Service.
Executors SHOULD consult it, but MUST NOT rely on its arrival as the
only bound on exposure. A Transparency Service that advertises
supersession queries MUST return signed responses carrying the log
inclusion position or checkpoint they were computed against, and an
executor MUST treat an unsigned or position-less answer as the log
not having answered -- which is an indeterminate result under Check 9
of Section 4, never a determinate absence. Services that do not
advertise the query are out of scope by construction. The
requirement is deliberately placed on the party making the claim: a
weaker recommendation here would reopen the gap it closes, since
every service that skipped it would return exactly the ambiguous
silence the executor cannot act on, and a determinate "none present"
would again have no stated basis.
Supersession is evaluable only if statements about one scope form a
sequence, so this profile defines the sequencing. The "sub" of the
scope's Signed Statement is the scope sequence identifier: for a new
authorization it is the scope digest of the initial scope in the
sequence, and it remains constant across reissuance, narrowing, and
revocation. A superseding or revoking statement MUST carry the same
("iss", "sub") pair as the statements it joins; a statement under a
different pair supersedes nothing. Precedence within a sequence is
established by an explicit monotonic sequence number carried in each
Signed Statement, never by registration order: [RFC9943] warns that
order on a ledger cannot be assumed to match issuance order absent
policy, so position on the log is not authority. An executor
discovers the current statement of a sequence by querying the
Hawkins Expires 16 February 2027 [Page 14]
Internet-Draft Attested Agent Payment Authorization August 2026
Transparency Service over the ("iss", "sub") pair, and a determinate
"no superseding statement" (Check 9) means a signed, position-
carrying answer showing the scope's own statement as the highest
sequence number registered for that pair. Expiry bounds the duration
of exposure; it does not establish that a payment remains authorized,
since a revocation may have occurred that the executor cannot
observe. An executor that cannot determine whether a superseding
statement exists therefore fails closed by default (Check 9 of
Section 4): to settle regardless would be to proceed on unknown
current authority. An issuer MAY direct a different indeterminate
disposition per scope through "on_indeterminate" (Section 3),
including the explicit "bounded-fail-open" mode, which accepts that
exposure knowingly.
None of these choices is novel to payments; each restates a lesson
from network policy control, where the same failure modes were worked
through in production decades ago. Preferring reissuance to long
lifetimes is the soft-state discipline of RSVP [RFC2205]:
authorization that expires unless refreshed needs no revocation
signal to arrive. Re-running the whole of Section 4 before a held
payment settles is per-command re-authorization as practiced by
TACACS+ [RFC8907], which caches no approval across requests. Binding
a hold to the scope in force at settlement is the revalidation
discipline of BGP prefix origin validation [RFC6811], under which
acceptance does not survive a change in the authorization set it was
computed from. And the question "on_indeterminate" answers -- what
an enforcement point does when its decision point cannot be reached
-- is the question COPS [RFC2748] was chartered to standardize.
These references are informative; this specification implements none
of them.
Implementers are warned that revoking authorization stops subsequent
authorized payments; it does not by itself reverse or cancel
obligations already created on a settlement system. Documents
profiling this specification for a particular rail SHOULD state
precisely what revocation does and does not undo on that rail.
7. Security Considerations
*Attestation proves provenance, not correctness.* A verified
attestation establishes that the running software is the endorsed
software. It does not establish that the software is free of
defects, that its authorization logic is sound, or that its behavior
is desirable. Systems that present attested execution as a
correctness guarantee will mislead the parties relying on them.
Where the endorsed code is itself the authorization logic, the value
of attestation is exactly that the logic cannot be silently replaced
-- no more.
Hawkins Expires 16 February 2027 [Page 15]
Internet-Draft Attested Agent Payment Authorization August 2026
*Extractable keys void the property.* If the private component of the
APK can leave the attested environment, then a payment signed by it
evidences nothing about where it was signed. This is why the "key-
attributes" check in Section 4 is mandatory rather than advisory.
*Attestation freshness.* An attestation not bound to a freshness
value supplied by the verifying party can be replayed by any party
that has observed it, including after the attested environment has
stopped running. The "eat_nonce" check is not optional.
*Scope inflation.* The most likely deployment error is a scope broad
enough to be operationally convenient -- unbounded aggregate, no
expiry, no payee constraint -- which preserves the appearance of
attested authorization while removing its effect. Registration
Policies SHOULD reject unbounded scopes.
*Transparency is not confidentiality.* Registering scopes publicly
may disclose commercially sensitive information about an agent's
spending authority. Implementers SHOULD register digests rather than
plaintext where disclosure is a concern, and SHOULD consider that the
existence and timing of registrations is itself observable.
*Verifier and Transparency Service availability.* Because executors
MUST fail closed, an unavailable verifier or Transparency Service
denies service rather than degrading security: whenever a check
cannot be completed -- for a Transparency Service, whenever the
Receipt (Check 8) cannot be obtained or the supersession status
(Check 9) cannot be determined -- the default is refusal.
Deployments SHOULD plan for this explicitly. Uncontrolled failing
open under load -- settling because a check could not be completed,
with no issuer having chosen that behavior -- is worse than denial
and MUST NOT be implemented. The single exception is the "bounded-
fail-open" mode of "on_indeterminate" (Section 3): an issuer MAY, per
scope, direct that an indeterminate supersession result settle within
"expiry", knowingly trading revocation-safety for availability. That
mode is bounded (by "expiry"), explicit (issuer-selected, never a
default), and named for the exposure it accepts; it is the only
circumstance under which an incomplete supersession check settles,
and it MUST NOT be applied to the completeness checks (1 through 8),
which always fail closed.
*The log is not disinterested by assumption.* A Transparency Service
can be operated by an interested party, and nothing in a Receipt
evidences otherwise. Deployments SHOULD require that the service's
checkpoints be countersigned by a quorum of independent witnesses, so
that a service presenting different views to different parties is
detectable by comparing countersigned checkpoints. An executor
SHOULD treat a supersession answer (Section 6) computed against an
Hawkins Expires 16 February 2027 [Page 16]
Internet-Draft Attested Agent Payment Authorization August 2026
unwitnessed checkpoint as weaker evidence than one computed against a
witnessed checkpoint, and a Registration Policy SHOULD state which
witnesses countersign its checkpoints.
*Enumeration does not close omission.* The execution-digest
enumeration of Section 5.1 makes deletion and reordering of counted
payments detectable. It does not close omission: a payment that
never entered the enumeration leaves no gap to find, so an
enumeration the executor produces remains the executor's word about
completeness, one layer down. Closing omission requires enumerating
from a vantage the executor does not control -- for example, from the
settlement rail itself, with each record bound to the settled
transaction's own digest, so that a missing leg is visible to
whichever party holds that leg. Rail-side enumeration is out of
scope for this document; profiles binding this specification to a
particular rail SHOULD state whether and how the rail's own records
can serve that role.
*The Attester is trusted.* This specification inherits the trust
model of [RFC9334]: relying parties trust the Attester's hardware
root and its endorsers. A compromise of that root compromises every
authorization derived from it.
8. Privacy Considerations
Attestation evidence can be highly identifying, potentially including
platform and firmware detail beyond what a payment decision requires.
Deployments SHOULD convey to executors only the claims their policy
consumes, and Transparency Service registrations SHOULD reference
evidence by digest rather than embedding it.
Correlation across payments is possible where the same APK is reused.
Where unlinkability matters, issuers SHOULD scope keys narrowly and
rotate them, accepting the additional attestation cost.
9. IANA Considerations
This document has no IANA actions at this revision. A future
revision is expected to request a CBOR tag or media type for the
Authorization Scope, and registration of any new EAT claims should
further revisions require them; the present design deliberately
reuses existing claims.
10. Implementation Status
This section is to be removed before publishing as an RFC.
Hawkins Expires 16 February 2027 [Page 17]
Internet-Draft Attested Agent Payment Authorization August 2026
Per [RFC7942]. The author operates a payment facilitator in which
the settlement key is generated inside an Intel TDX confidential
computing environment and never exists outside it; the environment's
software identity is endorsed on-chain and an open verifier checks
the attestation, the endorsement, and the key binding before the
service is treated as attested. A second deployment issues short-
lived credentials gating access to a permissioned trading venue,
where the issuing key is likewise generated inside the attested
environment and credential lifetime is the bound on exposure, as
described in Section 6.
These deployments predate this document and do not implement it as
written; they are offered as evidence that the pattern is operable,
not as a conformant implementation.
Independently of the author, Colin Winter (Markovian Protocol)
registered an Authorization Scope statement against the -00
registration flow on a public transparency log (leaf 7235 of
log.markovianprotocol.com), with verification code published
alongside it. That exercise surfaced the deterministic-encoding,
integer-amount, and single-expiry-form requirements now normative in
Section 3: three ways identical scopes could hash differently or
diverge across encoders, each found by attempting an implementation
rather than by review.
11. References
11.1. Normative References
[I-D.reddy-rats-key-binding]
Reddy.K, T., Tschofenig, H., Fossati, T., and I. Mihalcea,
"Key Attestation for Entity Attestation Tokens (EAT)",
Work in Progress, Internet-Draft, draft-reddy-rats-key-
binding-01, 7 June 2026,
<https://datatracker.ietf.org/doc/html/draft-reddy-rats-
key-binding-01>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Hawkins Expires 16 February 2027 [Page 18]
Internet-Draft Attested Agent Payment Authorization August 2026
[RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March
2020, <https://www.rfc-editor.org/info/rfc8747>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/info/rfc9334>.
[RFC9679] Isobe, K., Tschofenig, H., and O. Steele, "CBOR Object
Signing and Encryption (COSE) Key Thumbprint", RFC 9679,
DOI 10.17487/RFC9679, December 2024,
<https://www.rfc-editor.org/info/rfc9679>.
[RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
Wallace, "The Entity Attestation Token (EAT)", RFC 9711,
DOI 10.17487/RFC9711, April 2025,
<https://www.rfc-editor.org/info/rfc9711>.
[RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande,
Y., and S. Lasker, "An Architecture for Trustworthy and
Transparent Digital Supply Chains", RFC 9943,
DOI 10.17487/RFC9943, June 2026,
<https://www.rfc-editor.org/info/rfc9943>.
11.2. Informative References
[ERC8004-STUDY]
, , , , , and , "Can Trustless Agents Be Trusted? An
Empirical Study of the ERC-8004 Decentralized AI Agent
Ecosystem", arXiv:2606.26028, v2, 8 July 2026,
<https://arxiv.org/abs/2606.26028>.
[I-D.sirkkavaara-vaara-receipt]
Sirkkavaara, H., "The Vaara Receipt: A Recomputable
Receipt Format for Decisions About Autonomous Actions",
Work in Progress, Internet-Draft, draft-sirkkavaara-vaara-
receipt-07, 12 August 2026,
<https://datatracker.ietf.org/doc/html/draft-sirkkavaara-
vaara-receipt-07>.
Hawkins Expires 16 February 2027 [Page 19]
Internet-Draft Attested Agent Payment Authorization August 2026
[MEASURE] , , , and , "How Agentic Is Agentic Commerce? A
Population-Scale Measurement of x402 Adoption and
Authenticity", arXiv:2607.12575, 14 July 2026,
<https://arxiv.org/abs/2607.12575>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
September 1997, <https://www.rfc-editor.org/info/rfc2205>.
[RFC2748] Durham, D., Ed., Boyle, J., Cohen, R., Herzog, S., Rajan,
R., and A. Sastry, "The COPS (Common Open Policy Service)
Protocol", RFC 2748, DOI 10.17487/RFC2748, January 2000,
<https://www.rfc-editor.org/info/rfc2748>.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Austein, "BGP Prefix Origin Validation", RFC 6811,
DOI 10.17487/RFC6811, January 2013,
<https://www.rfc-editor.org/info/rfc6811>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[RFC8907] Dahm, T., Ota, A., Medway Gash, D.C., Carrel, D., and L.
Grant, "The Terminal Access Controller Access-Control
System Plus (TACACS+) Protocol", RFC 8907,
DOI 10.17487/RFC8907, September 2020,
<https://www.rfc-editor.org/info/rfc8907>.
Acknowledgments
This document exists because two specifications were written and not
connected. The key binding it depends on is the work of the authors
of [I-D.reddy-rats-key-binding], and the transparency model is that
of [RFC9943]. Reviewers in the x402 community materially improved
the author's understanding of what payment executors can and cannot
verify in practice.
Vernon Wharff (Sigilcore) identified that the -00 supersession step
carried three different normative strengths across Sections 4 and 6,
and that "fail closed" conflates two distinct behaviors -- terminal
refusal and a bounded hold -- that the issuer, who signs the scope
and chose its expiry, had no way to select between. The split of
Checks 8 and 9 and the on_indeterminate scope member follow from that
review. Iman Schrock (EMILIA) identified that the resulting fallback
default for an indeterminate supersession result was bounded fail-
Hawkins Expires 16 February 2027 [Page 20]
Internet-Draft Attested Agent Payment Authorization August 2026
open -- settling on unknown current authority, with expiry bounding
only the duration of exposure -- and that it contradicted Section 7's
own requirements. The refuse-by-default repair and the Section 7
realignment follow from that correction.
Tiago Pinto (donttrustverify.pt) reviewed the -00 in full against
pinned artifacts, together with its normative dependencies, and
applied the test a profile lives or dies by: whether two independent
implementations, given the same artifacts and inputs, evaluate the
same predicates the same way. Eight blocking findings from that
review -- thumbprint comparability, the key-attributes and evidence-
class profiles, the "code" semantics and the mediation requirement,
executor binding and atomicity for the aggregate bound, instruction
identity, constraint enforcement, and supersession sequencing --
account for most of the normative distance between -00 and this
revision, and his calibration of the citations corrected both a title
and a misattributed claim. The narrowing of Section 6's signed-
answer requirement to a MUST on services that advertise supersession
queries is likewise his: the requirement sits on the party making the
claim, which is where load-bearing distinctions belong.
Colin Winter (Markovian Protocol) attempted a registration rather
than a reading, and the deterministic-encoding, integer- amount, and
single-expiry-form requirements of Section 3 are the result; his
registration appears in the Implementation Status. Joel Hillier
(Certisyn) identified that scope selection by APK alone is ambiguous
the moment two live scopes share a key, that a null Transparency
Service answer is indeterminate rather than a determinate absence,
and that signed, position-carrying answers are what make a
determinate absence auditable; all three are now in the text. Pablo
Etcheverry identified that the -00 aggregate check was the executor
attesting to itself from records nobody else sees -- the exact class
of claim this document argues should be treated as absent -- and the
execution-digest construction and enumeration requirement of
Section 5.1 follow from that finding. Henri Sirkkavaara (Vaara)
named the limit of that construction, recorded in Security
Considerations: an executor-produced enumeration detects deletion,
not omission.
Author's Address
Walter D. Hawkins
Independent
Email: wdhawkins46@gmail.com
Hawkins Expires 16 February 2027 [Page 21]