Attested Payment Authorization for Autonomous Agents
draft-hawkins-scitt-attested-agent-payment-00

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,
              <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 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, <https://www.rfc-editor.org/info/rfc8747>.

   [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

   [MEASURE]  arXiv preprint 2607.12575, "Measurement of deployed agent-
              payment settlement activity", July 2026,
              <https://arxiv.org/abs/2607.12575>.

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

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]