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

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

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

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

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

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