Attested Payment Authorization for Autonomous Agents

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.¶

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

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 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.¶

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 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 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 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"
}

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.¶
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 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 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.¶

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.¶

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 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.¶

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 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.¶

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.¶

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-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