HTTPAPI J. McGraw Internet-Draft TaskHawk Intended status: Standards Track 5 May 2026 Expires: 6 November 2026 Protocol 427: An HTTP Budget-Required Status Code with Post-Quantum- Signed Budget Attestations draft-mcgraw-httpapi-agent-budget-00 Abstract Internet-deployed software agents are increasingly authorized to spend money, consume metered services, or commit other resources on behalf of human or organizational principals. Existing HTTP authentication and payment patterns conflate two orthogonal concerns: whether the requester holds a credential at all (the "401" axis), and whether the requester has been authorized to spend a specific amount through a specific settlement rail (the "budget" axis). This document defines the 427 (Budget Required) HTTP status code, the "Budget" HTTP authentication scheme, a CBOR-encoded Budget- Attestation envelope signed with a post-quantum digital signature algorithm, and a version-negotiation mechanism using the existing 426 (Upgrade Required) status code. The mandatory primary signature uses ML-DSA-87 (FIPS 204). An optional "rail-keyed" signature, computed with a hash-based stateless signature algorithm, provides cryptographic diversification for settlement-rail submissions. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-mcgraw-httpapi-agent-budget/. Discussion of this document takes place on the HTTPAPI Working Group mailing list (mailto:httpapi@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/httpapi/. Subscribe at https://www.ietf.org/mailman/listinfo/httpapi/. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. McGraw Expires 6 November 2026 [Page 1] Internet-Draft Protocol 427 May 2026 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 6 November 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation and Use Cases . . . . . . . . . . . . . . . . 4 1.2. Conventions and Definitions . . . . . . . . . . . . . . . 5 1.3. Relationship to HTTP Message Signatures . . . . . . . . . 5 1.4. Venue and Coordination . . . . . . . . . . . . . . . . . 6 1.5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 6 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7 3. The 427 (Budget Required) Status Code . . . . . . . . . . . . 8 3.1. Cacheability . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Relationship to 401, 402, 426 . . . . . . . . . . . . . . 8 4. The "Budget" Authentication Scheme . . . . . . . . . . . . . 9 4.1. Challenge Syntax . . . . . . . . . . . . . . . . . . . . 9 4.2. Credentials Syntax . . . . . . . . . . . . . . . . . . . 10 5. The Budget-Attestation Envelope . . . . . . . . . . . . . . . 10 5.1. CDDL Definition . . . . . . . . . . . . . . . . . . . . . 10 5.2. Canonical Encoding . . . . . . . . . . . . . . . . . . . 12 5.3. Primary Signature . . . . . . . . . . . . . . . . . . . . 12 5.4. Rail-Keyed Signature . . . . . . . . . . . . . . . . . . 12 5.5. Verification . . . . . . . . . . . . . . . . . . . . . . 12 6. Versioning . . . . . . . . . . . . . . . . . . . . . . . . . 13 McGraw Expires 6 November 2026 [Page 2] Internet-Draft Protocol 427 May 2026 6.1. The Protocol-427-Version Field . . . . . . . . . . . . . 13 6.2. Version Negotiation via 426 . . . . . . . . . . . . . . . 14 7. Reason Codes . . . . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8.1. Status Code 427 . . . . . . . . . . . . . . . . . . . . . 15 8.2. "Budget" Authentication Scheme . . . . . . . . . . . . . 16 8.3. "Protocol-427-Version" Field . . . . . . . . . . . . . . 16 8.4. "Protocol-427" Upgrade Token . . . . . . . . . . . . . . 16 8.5. "application/budget-attestation+cose" Media Type . . . . 17 8.6. "budget-required" Problem Type . . . . . . . . . . . . . 18 8.7. Protocol-427 Reason Codes Registry . . . . . . . . . . . 18 8.8. CBOR Tag for Budget-Attestation . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9.1. Replay Protection . . . . . . . . . . . . . . . . . . . . 19 9.2. Signature Substitution and Multiple-Signature Confusion . . . . . . . . . . . . . . . . . . . . . . . . 19 9.3. Algorithm Downgrade . . . . . . . . . . . . . . . . . . . 19 9.4. Operator Key Compromise and Revocation . . . . . . . . . 20 9.5. Post-Quantum Cryptographic Considerations . . . . . . . . 20 9.6. Bearer-Token Hygiene . . . . . . . . . . . . . . . . . . 20 9.7. Verifier Responsibilities . . . . . . . . . . . . . . . . 20 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . 21 12.2. Informative References . . . . . . . . . . . . . . . . . 23 Appendix A. CDDL Schema (Collected) . . . . . . . . . . . . . . 24 Appendix B. Example . . . . . . . . . . . . . . . . . . . . . . 25 Appendix C. Implementation Status . . . . . . . . . . . . . . . 27 C.1. Kevros (TaskHawk Systems) . . . . . . . . . . . . . . . . 27 Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 27 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28 1. Introduction Software agents acting on behalf of human or organizational principals increasingly need to make HTTP requests that may incur cost, consume metered services, or trigger settlement on a payment rail. The HTTP authentication framework [RFC9110] as historically deployed addresses "who are you" questions through schemes such as Basic, Bearer, and DPoP [RFC9449], and the HTTP 402 (Payment Required) status code has been appropriated by the L402 protocol [L402] and the x402 protocol [X402] to convey "you must pay before proceeding" semantics. Neither pattern cleanly captures the question this specification addresses: "do you hold a recently-issued, cryptographically-attested authorization to spend up to a stated amount, valid for this McGraw Expires 6 November 2026 [Page 3] Internet-Draft Protocol 427 May 2026 request?" That question is orthogonal to the bearer-credential axis; an agent may hold a perfectly valid bearer token and still lack any spending authority, or hold a spending authority and need to present it for any of several requests across one or more origins. This document defines: * The 427 (Budget Required) HTTP status code (Section 3), used by an origin server or gateway to indicate that a request will not be processed until the requester presents a valid Budget-Attestation. * The "Budget" HTTP authentication scheme (Section 4), used in the WWW-Authenticate response header field of a 427 response and in the Authorization request header field of subsequent requests. * The Budget-Attestation envelope (Section 5), a CBOR-encoded [RFC8949], COSE-signed [RFC9052] structure that carries semantic claims about the issuer, the agent, the bound request, the permitted settlement rails, and the spending amount. The envelope's primary signature uses ML-DSA-87 [FIPS204]; an optional rail-keyed signature (Section 5.4) uses any IETF-registered SLH- DSA [FIPS205] parameter set. * A version-negotiation mechanism (Section 6) using a Protocol- 427-Version response field [RFC9651] and the existing 426 (Upgrade Required) status code [RFC9110] for cases in which the requester presents a Protocol-427 version the origin does not support. 1.1. Motivation and Use Cases A representative scenario is an autonomous research agent that has been issued, by its operating organization, a cryptographically- attested allowance of "USD 10 over the next 60 seconds, spendable through any of {x402, L402, mpp}". The agent traverses several origins, some of which require payment. At each origin requiring payment, the agent presents the same Budget-Attestation; each origin verifies the attestation and either processes the request directly or initiates a rail-specific settlement that consumes from the attested allowance. The benefits of attesting authority separately from invoking a settlement rail are: (1) operators retain control over how much an agent can spend without participating in every transaction; (2) origins can verify authorization without coupling to any specific payment rail's protocol; (3) cryptographic agility, including post- quantum agility, can be applied uniformly to the authorization layer without modifying any settlement-rail protocol. McGraw Expires 6 November 2026 [Page 4] Internet-Draft Protocol 427 May 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. The following terms are used throughout this document: Operator: An entity that issues Budget-Attestations on behalf of a principal. Agent: An entity that holds and presents Budget-Attestations issued by an Operator in order to make HTTP requests. Verifier: An origin server, gateway, or intermediary that receives a Budget-Attestation, validates its signatures, and decides whether to process the bearing request. Budget-Attestation: The CBOR-encoded, signed envelope defined in Section 5. Settlement Rail: An out-of-band protocol used to effect actual transfer of value associated with a Budget-Attestation. Examples include x402, L402, and Lightning multi-path payments ("mpp"). Rail names are carried as text strings in the Budget-Attestation; this document does not define how settlements are performed. Rail-Keyed Signature: An optional second signature on the Budget- Attestation envelope, computed with a stateless hash-based signature algorithm (SLH-DSA), used to provide cryptographic diversification when the attestation is presented in connection with a settlement-rail submission. 1.3. Relationship to HTTP Message Signatures [RFC9421] defines a generic mechanism for digitally signing components of individual HTTP messages. Although both that mechanism and Budget-Attestation involve cryptographic signatures that travel with HTTP traffic, they address different concerns. McGraw Expires 6 November 2026 [Page 5] Internet-Draft Protocol 427 May 2026 RFC 9421 signatures bind a signature to a single HTTP message; their subject is "the message". A Budget-Attestation, by contrast, is a portable spending authority issued by an Operator and presented by an Agent across one or more requests; its subject is "the authority", and it carries semantic claims (issuer, agent, expiry, permitted settlement rails, amounts) that are not part of any HTTP message component. [RFC9421] references signing keys by keyid and, as of the publication of this document, registers no post-quantum signature algorithm in the "HTTP Signature Algorithms" registry. This document specifies CBOR encoding [RFC8949] and COSE signing structures [RFC9052] for the Budget-Attestation envelope so that multi-kilobyte post-quantum signature sizes are accommodated outside HTTP header fields. The two mechanisms are complementary. An Agent MAY carry a Budget- Attestation in a request that is itself signed per [RFC9421]; in that case, the RFC 9421 signature covers the request as transmitted, and the embedded Budget-Attestation covers the spending authority irrespective of transport. 1.4. Venue and Coordination This document is submitted to the HTTPAPI Working Group. It defines protocol elements that, per the HTTPAPI charter and Section 4.6 of [RFC9205], require coordination with the HTTP Working Group. In particular, registration of the 427 status code in the "HTTP Status Codes" registry is subject to IETF Review under Section 16.2.1 of [RFC9110], and the author expects that registration to be reviewed by the HTTP Working Group prior to IESG approval. This document follows the best practices of [RFC9205] for applications that use HTTP. Where it deviates -- specifically, by defining a new HTTP status code -- it does so consistent with the guidance of Section 4.6 of [RFC9205]. 1.5. Open Issues This subsection is to be removed before Working Group adoption or publication. * The CBOR tag value for the tagged form of the Budget-Attestation envelope is marked TBD pending IANA assignment. * The default reason-code registry policy (Section 8.7) is set to Specification Required; alternative policies may be considered during Working Group review. McGraw Expires 6 November 2026 [Page 6] Internet-Draft Protocol 427 May 2026 * The author seeks feedback on whether the rail-keyed signature (Section 5.4) belongs in this document or in a separate companion document focused on settlement-rail bindings. 2. Overview of Operation A typical Protocol 427 exchange proceeds as follows. GET /research/papers/12345 HTTP/1.1 Host: api.example The origin determines that processing the request will incur cost and that no Budget-Attestation accompanies the request. It returns: HTTP/1.1 427 Budget Required Date: Tue, 05 May 2026 14:00:00 GMT Cache-Control: no-store Content-Type: application/problem+json Content-Length: 213 Protocol-427-Version: 1 WWW-Authenticate: Budget realm="api.example", alg="ML-DSA-87", rails="x402 l402 mpp", nonce="QMjVqg5Xb6yV0bO_t9X8gQ", max-age=900 { "type": "https://taskhawktech.com/problems/budget-required", "title": "Budget attestation required", "status": 427, "detail": "A valid Budget-Attestation is required.", "min-budget": {"USD": 250}, "accepted-rails": ["x402","l402","mpp"], "max-age": 900, "protocol-version": 1 } The Agent obtains a Budget-Attestation from its Operator (out of band; issuance is not specified by this document) and retries: POST /research/papers/12345 HTTP/1.1 Host: api.example Authorization: Budget attestation=":2BhA...base64url-CBOR...kQ==" Content-Length: 0 McGraw Expires 6 November 2026 [Page 7] Internet-Draft Protocol 427 May 2026 If the attestation validates against the Verifier's policy, the Verifier processes the request normally. If validation fails, the Verifier returns 427 again with a reason extension member in the Problem Details body indicating the failure (Section 7). 3. The 427 (Budget Required) Status Code The 427 (Budget Required) status code indicates that the requester must present a valid Budget-Attestation as defined in this document before the request can be processed. The 427 status code differs from 401 (Unauthorized) in that the requester may hold a fully-valid authentication credential (for example, a Bearer token) and still receive 427 because the request requires a budget attestation in addition to, or instead of, that credential. It differs from 402 (Payment Required) in that 427 is a request for evidence of pre- issued spending authority, not a request to immediately initiate payment. A 427 response MUST include a Protocol-427-Version response header field (Section 6.1) and a WWW-Authenticate header field specifying the "Budget" authentication scheme (Section 4). A 427 response SHOULD include a response body in the "application/ problem+json" [RFC9457] or "application/problem+cbor" [RFC9457] media type carrying diagnostic information. When present, the body SHOULD use the "budget-required" problem type defined in Section 8.6. 3.1. Cacheability Responses with the 427 status code are not cacheable by default; per Section 15.1 of [RFC9110], status codes not enumerated as cacheable are not cacheable absent explicit cache directives. A server SHOULD send Cache-Control: no-store (Section 5.2.2.5 of [RFC9111]) with a 427 response, and a cache MUST NOT store a 427 response unless explicitly permitted by Cache-Control directives in the response. This rule mirrors the treatment of 428, 429, and 431 in [RFC6585]. 3.2. Relationship to 401, 402, 426 * 401 (Unauthorized) is returned when no, or insufficient, authentication credential is supplied. A request MAY receive 401 for credential reasons even if a Budget-Attestation is present. * 402 (Payment Required) is "reserved for future use" by Section 15.5.2 of [RFC9110] but has been adopted by L402 and x402 to mean "initiate a payment-rail interaction". A request MAY receive 402 from a downstream rail-handling endpoint after a 427 has been satisfied, depending on deployment. McGraw Expires 6 November 2026 [Page 8] Internet-Draft Protocol 427 May 2026 * 426 (Upgrade Required) is used by this document to negotiate Protocol-427 versions; see Section 6. 4. The "Budget" Authentication Scheme The "Budget" authentication scheme is registered in Section 8.2. It is used in the WWW-Authenticate response header field of a 427 response and in the Authorization request header field of a subsequent request. 4.1. Challenge Syntax A WWW-Authenticate challenge using the "Budget" scheme has the following syntax, expressed in ABNF [RFC9110]: budget-challenge = "Budget" 1*SP budget-params budget-params = budget-param *( OWS "," OWS budget-param ) budget-param = ( "realm" "=" quoted-string ) / ( "alg" "=" quoted-string ) / ( "rails" "=" quoted-string ) / ( "nonce" "=" quoted-string ) / ( "max-age" "=" 1*DIGIT ) / ( "attestation" "=" quoted-string ) / auth-param Parameter semantics: realm: A protection-space identifier as defined in Section 11.5 of [RFC9110]. REQUIRED. alg: A space-separated list of acceptable signature algorithm names for the Budget-Attestation primary signature. Tokens correspond to COSE algorithm names ([I-D.ietf-cose-dilithium]). REQUIRED. rails: A space-separated list of settlement-rail tokens acceptable to the Verifier. REQUIRED if the Verifier expects a rail-keyed signature (Section 5.4); OPTIONAL otherwise. nonce: A server-supplied opaque value, base64url-encoded, that the Agent SHOULD echo in the nonce claim of any presented Budget- Attestation bound to this challenge. REQUIRED. max-age: An advisory, non-negative integer indicating, in seconds, the maximum recommended lifetime of any Budget-Attestation presented in response to this challenge. OPTIONAL. attestation: Reserved for future use; servers MUST NOT include it in challenges emitted under this version of Protocol 427. McGraw Expires 6 November 2026 [Page 9] Internet-Draft Protocol 427 May 2026 4.2. Credentials Syntax An Authorization request header field using the "Budget" scheme has the following syntax: budget-credentials = "Budget" 1*SP "attestation" "=" quoted-string The value of the attestation parameter is the base64url Section 5 of [RFC8949] encoding of the CBOR Budget-Attestation envelope (Section 5). When the encoded envelope would exceed an HTTP-implementation header size limit (a typical limit is 8 KiB; SLH-DSA signatures (Section 5.4) can exceed this), the Agent MUST instead submit the envelope in a request body of media type "application/budget- attestation+cose" (Section 8.5) and convey only the scheme name and a content-binding parameter in the Authorization header field, as follows: budget-credentials-body = "Budget" 1*SP "binding" "=" quoted-string The binding value is the base64url-encoded SHA-256 hash of the CBOR- encoded envelope contained in the request body. 5. The Budget-Attestation Envelope The Budget-Attestation envelope is a COSE_Sign structure [RFC9052] carrying a Budget-Claims set as its payload. It MAY be transported as a tagged CBOR value (CBOR tag TBD) or as an untagged value when delivered as the body of an "application/budget-attestation+cose" HTTP message. 5.1. CDDL Definition The schema below is given in CDDL [RFC8610]. ; Budget-Attestation envelope (Protocol 427) ; The tagged form uses CBOR tag TBD; the untagged form is used in ; HTTP message bodies of media type ; application/budget-attestation+cose. Budget-Attestation = #6.TBD(Budget-Attestation-Untagged) / Budget-Attestation-Untagged Budget-Attestation-Untagged = [ protected : bstr .cbor Protected-Header, unprotected : Unprotected-Header, claims : bstr .cbor Budget-Claims, McGraw Expires 6 November 2026 [Page 10] Internet-Draft Protocol 427 May 2026 signatures : [+ Signature] ] Protected-Header = { 1 => int, ; alg of the primary signature (ML-DSA-87) ? 4 => bstr ; kid (operator key identifier) } Unprotected-Header = { * (int / tstr) => any } Budget-Claims = { "version" => uint, ; protocol version "iss" => tstr, ; issuer (operator) identifier "agent" => tstr, ; agent identifier "iat" => uint, ; issued-at, seconds since epoch "exp" => uint, ; expiry, seconds since epoch "nonce" => bstr .size (16..64), ; replay-protection nonce "rb" => Request-Binding, "rails" => [+ tstr], ; permitted settlement rails ? "amt" => Rail-Amount-Map ; amount cap (minor units) } Request-Binding = { "method" => tstr, ; e.g., "POST" "uri-h" => bstr .size 32, ; SHA-256 of canonical target URI ? "body-h" => bstr .size 32 ; SHA-256 of body, if bound } Rail-Amount-Map = { + tstr => uint ; minor units per currency code } Signature = [ protected : bstr .cbor Sig-Protected-Header, unprotected : Unprotected-Header, signature : bstr ] Sig-Protected-Header = { 1 => int, ; alg id (COSE) ? 4 => bstr, ; kid ? "role" => "operator" / "rail" ; primary vs rail-keyed } McGraw Expires 6 November 2026 [Page 11] Internet-Draft Protocol 427 May 2026 5.2. Canonical Encoding Budget-Attestations MUST be encoded using the Core Deterministic Encoding Requirements of Section 4.2.1 of [RFC8949]. Verifiers MUST reject envelopes whose CBOR encoding does not satisfy those requirements. 5.3. Primary Signature The Budget-Attestation envelope MUST include exactly one primary signature. The primary signature's Sig-Protected-Header MUST set alg to the COSE identifier for ML-DSA-87 as defined by [I-D.ietf-cose-dilithium]. Future revisions of this document MAY add additional MUST-implement primary algorithms; the rules of algorithm agility (Section 9.3) apply. 5.4. Rail-Keyed Signature A Budget-Attestation envelope MAY include a second signature, denoted the "rail-keyed" signature, distinguished by role = "rail" in its Sig-Protected-Header. The rail-keyed signature provides cryptographic diversification: even if the primary lattice-based signature key is compromised, settlement-rail interactions can require an additional, hash-based signature over the same envelope. The rail-keyed signature, when present, MUST use a stateless hash- based signature algorithm registered in the COSE Algorithms Registry under [I-D.ietf-cose-sphincs-plus]. Implementations of this document MUST support SLH-DSA-SHA2-128f as the rail-keyed algorithm ([FIPS205]); implementations MAY additionally support any other SLH- DSA parameter set with a registered COSE algorithm identifier. A Verifier that requires a rail-keyed signature for settlement-rail acceptance MUST advertise this expectation through deployment- specific means; this document does not extend the WWW-Authenticate challenge to advertise per-rail signature requirements. Because SLH-DSA signatures are large (FIPS 205 reports 17,088 bytes for SLH-DSA-SHA2-128f and may be tens of kilobytes for higher parameter sets), envelopes carrying a rail-keyed signature MUST be transported in an HTTP message body of media type "application/ budget-attestation+cose"; they MUST NOT be carried in the Authorization header field's attestation parameter. 5.5. Verification A Verifier processing a Budget-Attestation MUST, in order: McGraw Expires 6 November 2026 [Page 12] Internet-Draft Protocol 427 May 2026 1. Verify that the encoded CBOR satisfies the Core Deterministic Encoding Requirements of Section 4.2.1 of [RFC8949]. 2. Verify that the version claim is supported (Section 6). 3. Verify the primary signature against the operator key identified by the kid parameter or otherwise resolved by deployment policy. 4. Verify that iat and exp define a non-empty interval that includes the current time, allowing for clock skew of at most 60 seconds. 5. Verify that the nonce was issued by the Verifier as part of an outstanding 427 challenge, and has not previously been observed for this Verifier. 6. Verify that rb.method matches the request method, that rb.uri-h matches the SHA-256 of the canonical target URI, and (if body-h is present) that body-h matches the SHA-256 of the request body. 7. Verify that any rail-keyed signature, if present, validates under a configured rail key. If all checks pass, the Verifier processes the request normally. If any check fails, the Verifier MUST respond with 427 and SHOULD include a reason extension member in the Problem Details body indicating the failure. 6. Versioning This document defines version 1 of Protocol 427. Future revisions MAY define additional versions. 6.1. The Protocol-427-Version Field The Protocol-427-Version response header field is a Structured Field [RFC9651] of type Item containing an Integer. Its value is the Protocol-427 version under which the response was constructed. A 427 response MUST include exactly one Protocol-427-Version header field. Other responses MAY include the field to advertise the origin's Protocol-427 capability. McGraw Expires 6 November 2026 [Page 13] Internet-Draft Protocol 427 May 2026 6.2. Version Negotiation via 426 If a request bearing an Authorization: Budget credential carries a version claim that the Verifier does not support, the Verifier MUST respond with 426 (Upgrade Required) per Section 15.5.22 of [RFC9110] and MUST include an Upgrade header field listing one or more Protocol-427/N tokens for versions the Verifier supports. The token "Protocol-427" is registered in Section 8.4. Example: HTTP/1.1 426 Upgrade Required Upgrade: Protocol-427/1 Connection: Upgrade Protocol-427-Version: 1 7. Reason Codes A Verifier returning 427 SHOULD include a reason extension member in the Problem Details body indicating the cause of failure. This document defines the following initial reason codes: McGraw Expires 6 November 2026 [Page 14] Internet-Draft Protocol 427 May 2026 +=====================+=======================================+ | Reason | Meaning | +=====================+=======================================+ | ok | Used in audit and diagnostic contexts | | | only; never appears on a 427. | +---------------------+---------------------------------------+ | expired | The presented attestation's exp is in | | | the past. | +---------------------+---------------------------------------+ | signature_mismatch | A signature on the envelope did not | | | validate. | +---------------------+---------------------------------------+ | replay | The presented nonce has previously | | | been observed. | +---------------------+---------------------------------------+ | unknown_operator | The iss is not recognized. | +---------------------+---------------------------------------+ | malformed_cbor | The envelope failed CBOR | | | canonicalization checks. | +---------------------+---------------------------------------+ | version_unsupported | The version claim is not supported. | +---------------------+---------------------------------------+ | rail_not_authorized | A rail in rails is not permitted by | | | policy. | +---------------------+---------------------------------------+ | revoked | The operator key has been revoked. | +---------------------+---------------------------------------+ Table 1 A registry for additional reason codes is established in Section 8.7. 8. IANA Considerations This document creates registrations in several IANA registries. 8.1. Status Code 427 IANA is requested to register the following entry in the "HTTP Status Codes" registry [IANA.HTTP.StatusCodes] established by Section 16.2.1 of [RFC9110]: McGraw Expires 6 November 2026 [Page 15] Internet-Draft Protocol 427 May 2026 +=======+=================+============================+ | Value | Description | Reference | +=======+=================+============================+ | 427 | Budget Required | Section 3 of this document | +-------+-----------------+----------------------------+ Table 2 8.2. "Budget" Authentication Scheme IANA is requested to register the following scheme in the "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" [IANA.HTTP.AuthSchemes] established by Section 16.4.1 of [RFC9110]: +================+===============+=============================+ | Authentication | Reference | Notes | | Scheme Name | | | +================+===============+=============================+ | Budget | Section 4 of | Conveys a CBOR-encoded, | | | this document | post-quantum signed Budget- | | | | Attestation; see Section 5. | +----------------+---------------+-----------------------------+ Table 3 8.3. "Protocol-427-Version" Field IANA is requested to register the following entry in the "HTTP Field Name Registry" [IANA.HTTP.Fields] established by Section 18.4 of [RFC9110]: +======================+===========+=============+================+ | Field Name | Status | Reference | Comments | +======================+===========+=============+================+ | Protocol-427-Version | permanent | Section 6.1 | Structured | | | | of this | Field, Item of | | | | document | type Integer; | | | | | see [RFC9651]. | +----------------------+-----------+-------------+----------------+ Table 4 8.4. "Protocol-427" Upgrade Token IANA is requested to register the following entry in the "HTTP Upgrade Token Registry" [IANA.HTTP.UpgradeTokens] established by Section 16.7 of [RFC9110]: McGraw Expires 6 November 2026 [Page 16] Internet-Draft Protocol 427 May 2026 +==============+==============+======================+===========+ | Value | Description | Expected Version | Reference | | | | Tokens | | +==============+==============+======================+===========+ | Protocol-427 | Agent Budget | A non-negative | Section 6 | | | Negotiation | integer denoting the | of this | | | Protocol | Protocol-427 version | document | +--------------+--------------+----------------------+-----------+ Table 5 8.5. "application/budget-attestation+cose" Media Type IANA is requested to register the following media type [RFC6838] in the "Media Types" registry [IANA.MediaTypes]: Type name: application Subtype name: budget-attestation+cose Required parameters: N/A Optional parameters: cose-type (when present, MUST be identical to its usage for application/cose, per Section 2 of [RFC9052]) Encoding considerations: binary; uses Concise Binary Object Representation (CBOR) [RFC8949]. Security considerations: See Section 9 of this document. Interoperability considerations: Implementations MUST follow the CBOR encoding rules of [RFC8949] and the CDDL definition of Section 5 of this document. Published specification: This document. Applications that use this media type: Agents, Operators, and Verifiers implementing Protocol 427. Fragment identifier considerations: As specified for "+cose" in the corresponding structured-syntax suffix registration. Additional information: * Deprecated alias names for this type: N/A * Magic number(s): (none, generic CBOR) McGraw Expires 6 November 2026 [Page 17] Internet-Draft Protocol 427 May 2026 * File extension(s): .cbor * Macintosh file type code(s): N/A Person & email address to contact for further information: John Paul McGraw, Jr. Intended usage: COMMON Restrictions on usage: N/A Author: John Paul McGraw, Jr. Change controller: IETF Provisional registration?: No. 8.6. "budget-required" Problem Type IANA is requested to register the following entry in the "HTTP Problem Types" registry [IANA.HTTPProblemTypes] established by Section 6 of [RFC9457]: +==================+====================================+ | Field | Value | +==================+====================================+ | Type URI | https://taskhawktech.com/problems/ | | | budget-required | +------------------+------------------------------------+ | Title | Budget attestation required | +------------------+------------------------------------+ | Recommended HTTP | 427 | | status code | | +------------------+------------------------------------+ | Reference | Section 8.6 of this document | +------------------+------------------------------------+ Table 6 8.7. Protocol-427 Reason Codes Registry IANA is requested to establish a new registry titled "Protocol-427 Reason Codes" with registration policy "Specification Required" Section 4.6 of [RFC8126]. Each registration consists of a Reason token (printable ASCII, no whitespace), a Description, and a Reference. The initial registry contents are the entries listed in Section 7. McGraw Expires 6 November 2026 [Page 18] Internet-Draft Protocol 427 May 2026 8.8. CBOR Tag for Budget-Attestation IANA is requested to assign one tag from the "First Come First Served" range of the "CBOR Tags" registry to identify the tagged form of the Budget-Attestation envelope (Section 5). 9. Security Considerations This section follows the guidance of [RFC9205] and adapts the threat- class analysis of [RFC9421] to the Budget-Attestation envelope. 9.1. Replay Protection Each Budget-Attestation carries a server-issued nonce (echoed from the WWW-Authenticate challenge), an iat and exp, and a request_binding. Verifiers MUST reject attestations whose nonce has previously been observed for the same Verifier and MUST reject attestations whose iat-exp interval does not include the current time. Implementations are reminded of the early-data replay considerations of [RFC8470]: Verifiers SHOULD NOT accept Budget-Attestations carried in TLS 1.3 0-RTT data, or MUST employ the Early-Data header field mechanism of [RFC8470]. 9.2. Signature Substitution and Multiple-Signature Confusion The Budget-Attestation envelope can carry exactly one primary signature and at most one rail-keyed signature. Verifiers MUST require the primary signature for any acceptance decision; the rail- keyed signature is additive authority and MUST NOT substitute for the primary. Verifiers SHOULD reject envelopes containing multiple primary signatures. 9.3. Algorithm Downgrade The COSE alg parameter in each Sig-Protected-Header is part of the signed input. Verifiers MUST compare the alg in the signed protected header against a configured policy and MUST NOT permit clients to "negotiate down" to a weaker algorithm via the WWW-Authenticate alg parameter. McGraw Expires 6 November 2026 [Page 19] Internet-Draft Protocol 427 May 2026 9.4. Operator Key Compromise and Revocation Operator keys SHOULD be rotated periodically. When a key is compromised or retired, Verifiers MUST be able to learn of the revocation through deployment-specific means (for example, an operator JWKS endpoint or signed revocation list); the revoked reason code is provided for diagnostic responses to the bearer of an attestation under a revoked key. 9.5. Post-Quantum Cryptographic Considerations Per [I-D.ietf-cose-dilithium], the ML-DSA seed and the expanded private key require equal protection. Implementations SHOULD use constant-time, side-channel-resistant ML-DSA implementations. ML-DSA is non-deterministic; implementations SHOULD prefer the hedged randomization mode defined in [FIPS204], Section 3. SLH-DSA is hash-based and offers an independent cryptographic foundation; this is the rationale for offering a rail-keyed signature option (Section 5.4). Implementations MUST use the pure mode of SLH- DSA per [I-D.ietf-cose-sphincs-plus]; HashSLH-DSA is not supported. 9.6. Bearer-Token Hygiene Until validated, a Budget-Attestation has bearer-token characteristics (possession implies authority). TLS MUST be used for any HTTP exchange involving Authorization: Budget. Servers SHOULD scrub Authorization header values from request logs. 9.7. Verifier Responsibilities Failure to verify is the dominant failure mode for any signature- based protocol. Verifiers MUST validate every check listed in Section 5 and MUST NOT short-circuit verification under any condition. 10. Privacy Considerations This section follows the guidance of [RFC6973] and Section 6.1 of [RFC9205]. Budget-Attestations carry identifiers (iss, agent) and authority metadata (rails, amt) that, if leaked or correlated across Verifiers, can enable tracking of an Agent's commercial activity. Mitigations include: * short attestation lifetimes (RECOMMENDED exp - iat <= 900 seconds); McGraw Expires 6 November 2026 [Page 20] Internet-Draft Protocol 427 May 2026 * TLS confidentiality for any HTTP message bearing an attestation or a 427 challenge; * uniformly random nonce values, at least 128 bits long, that MUST NOT encode timestamps or sequence numbers; * Operator-managed rotation of the agent identifier; * restraint in Problem Details detail content (it MUST NOT contain the agent identifier or signature material); * the option to omit the rail-keyed signature when not required by policy. The nonce issued by a Verifier in a 427 challenge can itself be a tracking vector across multiple Agents observed by an on-path attacker. Verifiers SHOULD generate independent random nonces per challenge. This document does not require Verifiers to retain any per-Agent state beyond what is necessary to detect nonce replay. Implementations SHOULD apply data minimization Section 6.1 of [RFC6973] when constructing the agent identifier and when logging verification outcomes. 11. References 12. References 12.1. Normative References [FIPS204] National Institute of Standards and Technology (NIST), "Module-Lattice-Based Digital Signature Standard", FIPS PUB 204, DOI 10.6028/NIST.FIPS.204, August 2024, . [FIPS205] National Institute of Standards and Technology (NIST), "Stateless Hash-Based Digital Signature Standard", FIPS PUB 205, DOI 10.6028/NIST.FIPS.205, August 2024, . McGraw Expires 6 November 2026 [Page 21] Internet-Draft Protocol 427 May 2026 [I-D.ietf-cose-dilithium] Prorock, M. and O. Steele, "ML-DSA for JOSE and COSE", Work in Progress, Internet-Draft, draft-ietf-cose- dilithium-11, 15 November 2025, . [I-D.ietf-cose-sphincs-plus] Prorock, M., Steele, O., and H. Tschofenig, "SLH-DSA for JOSE and COSE", Work in Progress, Internet-Draft, draft- ietf-cose-sphincs-plus-07, 15 March 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . McGraw Expires 6 November 2026 [Page 22] Internet-Draft Protocol 427 May 2026 [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Caching", STD 98, RFC 9111, DOI 10.17487/RFC9111, June 2022, . [RFC9205] Nottingham, M., "Building Protocols with HTTP", BCP 56, RFC 9205, DOI 10.17487/RFC9205, June 2022, . [RFC9457] Nottingham, M., Wilde, E., and S. Dalal, "Problem Details for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023, . [RFC9651] Nottingham, M. and P. Kamp, "Structured Field Values for HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024, . 12.2. Informative References [L402] Lightning Labs, "L402 Protocol Specification", 2024, . [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012, . [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, . [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, . [RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 2018, . McGraw Expires 6 November 2026 [Page 23] Internet-Draft Protocol 427 May 2026 [RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, . [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, . [X402] Coinbase, Inc., "x402: An Open Standard for Internet- Native Payments", 2025, . Appendix A. CDDL Schema (Collected) The following CDDL block consolidates the schema of Section 5 for ease of implementation. Budget-Attestation = #6.TBD(Budget-Attestation-Untagged) / Budget-Attestation-Untagged Budget-Attestation-Untagged = [ protected : bstr .cbor Protected-Header, unprotected : Unprotected-Header, claims : bstr .cbor Budget-Claims, signatures : [+ Signature] ] Protected-Header = { 1 => int, ? 4 => bstr } Unprotected-Header = { * (int / tstr) => any } Budget-Claims = { "version" => uint, "iss" => tstr, "agent" => tstr, "iat" => uint, "exp" => uint, "nonce" => bstr .size (16..64), "rb" => Request-Binding, "rails" => [+ tstr], ? "amt" => Rail-Amount-Map } McGraw Expires 6 November 2026 [Page 24] Internet-Draft Protocol 427 May 2026 Request-Binding = { "method" => tstr, "uri-h" => bstr .size 32, ? "body-h" => bstr .size 32 } Rail-Amount-Map = { + tstr => uint } Signature = [ protected : bstr .cbor Sig-Protected-Header, unprotected : Unprotected-Header, signature : bstr ] Sig-Protected-Header = { 1 => int, ? 4 => bstr, ? "role" => "operator" / "rail" } Appendix B. Example The following example shows a complete 427 challenge, the Agent's follow-up request body containing a Budget-Attestation envelope (in CBOR diagnostic notation per Section 8 of [RFC8949]), and the Verifier's response. Initial response: McGraw Expires 6 November 2026 [Page 25] Internet-Draft Protocol 427 May 2026 HTTP/1.1 427 Budget Required Date: Tue, 05 May 2026 14:00:00 GMT Cache-Control: no-store Content-Type: application/problem+json Protocol-427-Version: 1 WWW-Authenticate: Budget realm="api.example", alg="ML-DSA-87", rails="x402 l402 mpp", nonce="QMjVqg5Xb6yV0bO_t9X8gQ", max-age=900 { "type": "https://taskhawktech.com/problems/budget-required", "title": "Budget attestation required", "status": 427, "min-budget": {"USD": 250}, "accepted-rails": ["x402","l402","mpp"], "max-age": 900, "protocol-version": 1 } Follow-up request (CBOR shown in diagnostic notation): POST /research/papers/12345 HTTP/1.1 Host: api.example Content-Type: application/budget-attestation+cose Authorization: Budget binding="lQ7M...base64url-sha256..." [ << { 1: -50 } >>, {}, << { "version": 1, "iss": "https://op.example/operators/42", "agent": "agent-7c2e", "iat": 1746453600, "exp": 1746454500, "nonce": h'40c8d5aa0e576fac95d1b3bfb7d5fc81', "rb": { "method": "POST", "uri-h": h'a3f1...', "body-h": h'0000...' }, "rails": ["x402","l402","mpp"], "amt": { "USD": 250 } } >>, [ [ << { 1: -50, "role": "operator" } >>, {}, h'' ] ] ] Successful response: as for the underlying request (200 OK, etc.). McGraw Expires 6 November 2026 [Page 26] Internet-Draft Protocol 427 May 2026 Appendix C. Implementation Status This appendix is to be removed before publishing as an RFC. This section records known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, in accordance with the guidelines of [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Listing of any individual implementation does not imply endorsement by the IETF. No effort has been spent to verify the information presented here. Other implementations may exist. C.1. Kevros (TaskHawk Systems) Organization: TaskHawk Systems LLC Name: Kevros Description: An implementation of Protocol 427, including issuance and verification of Budget-Attestation envelopes signed with ML- DSA-87. Coverage: Section 3 through Section 8.7 of this document; settlement-rail bindings for x402, L402, and Lightning multi-path payments. Implementation experience: The host enforcement kernel within which Protocol 427 issuance and verification logic executes is formally specified in TLA+ and Lean 4. 12 safety invariants and 4 liveness properties of the kernel have been machine-checked: TLC bounded model checking explored 1.94 billion states with zero violations; Lean 4 interactive proof verifies 20 theorems with zero "sorry". Protocol 427 endpoints run inside this verified kernel and inherit its fail-closed and chain-integrity guarantees. A separate state- machine specification of Protocol 427 version negotiation and Budget-Attestation signature verification has not yet been written. Contact: j.mcgraw@taskhawktech.com Appendix D. Acknowledgments The author thanks the Working Group for early feedback on this document. McGraw Expires 6 November 2026 [Page 27] Internet-Draft Protocol 427 May 2026 Author's Address John Paul McGraw, Jr. TaskHawk Systems LLC Charlottesville, VA United States of America Email: j.mcgraw@taskhawktech.com McGraw Expires 6 November 2026 [Page 28]