Network Working Group Walter D. Hawkins Internet-Draft Independent Intended status: Standards Track 6 August 2026 Expires: 7 February 2027 Attested Payment Authorization for Autonomous Agents draft-hawkins-scitt-attested-agent-payment-00 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, and the transparency record that makes the authorization auditable independently of the agent and of the executor. 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 7 February 2027. Hawkins Expires 7 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. The Authorization Scope . . . . . . . . . . . . . . . . . . . 4 4. Verification Before Settlement . . . . . . . . . . . . . . . 5 5. Registration on a Transparency Service . . . . . . . . . . . 6 6. Expiry and Revocation . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 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. Hawkins Expires 7 February 2027 [Page 2] Internet-Draft Attested Agent Payment Authorization August 2026 This distinction is not academic. Measurements of deployed agent- payment traffic report that a large fraction of settlement volume is either fictitious or internal to linked clusters [MEASURE], and that a majority of entries in at least one agent identity registry could not be reached at all. 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. 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; * 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. Hawkins Expires 7 February 2027 [Page 3] Internet-Draft Attested Agent Payment Authorization August 2026 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. 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, the attestation evidence, and the endorsed software identity are registered together as a Signed Statement on a Transparency Service [RFC9943], yielding a Receipt. 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. The following members are defined; unknown members MUST be ignored. apk (REQUIRED): The thumbprint [RFC9679] of the Attested Payment Hawkins Expires 7 February 2027 [Page 4] Internet-Draft Attested Agent Payment Authorization August 2026 Key. This is the key whose "cnf" appears in the attestation evidence. code (REQUIRED): The endorsed software identity the attestation is expected to report, expressed as a digest. 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 interval, each with an explicit unit. A scope with no upper bound MUST NOT be registered. expiry (REQUIRED): The time after which the scope is invalid. Scopes are short-lived by design; see Section 6. rails (OPTIONAL): The settlement systems on which the scope is valid. Absence means the scope is rail-agnostic, which relying parties SHOULD treat as broader than intended rather than as permission. payees (OPTIONAL): Constraint on permitted counterparties. 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, and MUST NOT settle if any of them fails or cannot be completed: 1. The attestation evidence verifies against the expected Attester's trust anchors, and the freshness value in "eat_nonce" was supplied by the verifying party for this transaction. A replayed attestation MUST NOT be accepted. 2. The "cnf" key in the evidence equals the "apk" named in the scope. 3. The "key-attributes" claim asserts that the private key is non- extractable and was generated within the attested environment. An extractable payment key MUST be rejected: an extractable key can authorize payments from outside the environment whose properties are being relied upon. Hawkins Expires 7 February 2027 [Page 5] Internet-Draft Attested Agent Payment Authorization August 2026 4. The software identity reported by the attestation equals the "code" value in the scope. 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. 6. The payment falls within "limits", and the executor's own record of prior spending under this scope confirms the aggregate bound is not exceeded. 7. "expiry" has not passed. 8. A valid Receipt for the scope's registration is available from the Transparency Service, and the scope has not been superseded (Section 6). 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. Executors MUST fail closed. An executor that cannot complete the checks above 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 by a party with no interest in how the transaction is later characterized, satisfying the common requirement that an agent's audit trail not depend on the agent's own account of events. Hawkins Expires 7 February 2027 [Page 6] Internet-Draft Attested Agent Payment Authorization August 2026 Registration Policy for a Transparency Service accepting these statements SHOULD require that the attestation evidence referenced by a scope verifies at registration time. A service MAY register statements whose evidence it cannot verify, but MUST NOT represent such registrations as attested. 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. 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 7 February 2027 [Page 7] 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. Deployments SHOULD plan for this explicitly; the alternative -- failing open under load -- is worse and MUST NOT be implemented. *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. Hawkins Expires 7 February 2027 [Page 8] Internet-Draft Attested Agent Payment Authorization August 2026 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. 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, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Hawkins Expires 7 February 2027 [Page 9] 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, . [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, . [RFC9679] Isobe, K., Tschofenig, H., and O. Steele, "CBOR Object Signing and Encryption (COSE) Key Thumbprint", RFC 9679, DOI 10.17487/RFC9679, December 2024, . [RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, April 2025, . [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, . 11.2. Informative References [MEASURE] arXiv preprint 2607.12575, "Measurement of deployed agent- payment settlement activity", July 2026, . [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, . 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. Author's Address Hawkins Expires 7 February 2027 [Page 10] Internet-Draft Attested Agent Payment Authorization August 2026 Walter D. Hawkins Independent Email: wdhawkins46@gmail.com Hawkins Expires 7 February 2027 [Page 11]