]> TaskHawk Systems LLC

Charlottesville VA United States of America j.mcgraw@taskhawktech.com

Web and Internet Transport HTTPAPI HTTP status code authentication post-quantum ML-DSA SLH-DSA CBOR COSE agentic payments budget x402 L402 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. Status information for this document may be found at . Discussion of this document takes place on the HTTPAPI Working Group mailing list (), which is archived at . Subscribe at .

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 as historically deployed addresses "who are you" questions through schemes such as Basic, Bearer, and DPoP , and the HTTP 402 (Payment Required) status code has been appropriated by the L402 protocol and the x402 protocol 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 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 (), 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 (), 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 (), a CBOR-encoded , COSE-signed 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 ; an optional rail-keyed signature () uses any IETF-registered SLH-DSA parameter set. A version-negotiation mechanism () using a Protocol-427-Version response field and the existing 426 (Upgrade Required) status code for cases in which the requester presents a Protocol-427 version the origin does not support.

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.

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

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.

Relationship to HTTP Message Signatures 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. 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. 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 and COSE signing structures 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 ; in that case, the RFC 9421 signature covers the request as transmitted, and the embedded Budget-Attestation covers the spending authority irrespective of transport.

Venue and Coordination This document is submitted to the HTTPAPI Working Group. It defines protocol elements that, per the HTTPAPI charter and , 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 , 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 for applications that use HTTP. Where it deviates -- specifically, by defining a new HTTP status code -- it does so consistent with the guidance of .

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 () is set to Specification Required; alternative policies may be considered during Working Group review. The author seeks feedback on whether the rail-keyed signature () belongs in this document or in a separate companion document focused on settlement-rail bindings.

Overview of Operation A typical Protocol 427 exchange proceeds as follows.

The origin determines that processing the request will incur cost and that no Budget-Attestation accompanies the request. It returns:

The Agent obtains a Budget-Attestation from its Operator (out of band; issuance is not specified by this document) and retries:

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 ().

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 () and a WWW-Authenticate header field specifying the "Budget" authentication scheme (). A 427 response SHOULD include a response body in the "application/problem+json" or "application/problem+cbor" media type carrying diagnostic information. When present, the body SHOULD use the "budget-required" problem type defined in .

Cacheability Responses with the 427 status code are not cacheable by default; per , status codes not enumerated as cacheable are not cacheable absent explicit cache directives. A server SHOULD send Cache-Control: no-store () 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 .

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 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. 426 (Upgrade Required) is used by this document to negotiate Protocol-427 versions; see .

The "Budget" Authentication Scheme The "Budget" authentication scheme is registered in . 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.

Challenge Syntax A WWW-Authenticate challenge using the "Budget" scheme has the following syntax, expressed in ABNF :

Parameter semantics:

realm:

A protection-space identifier as defined in . REQUIRED.

alg:

A space-separated list of acceptable signature algorithm names for the Budget-Attestation primary signature. Tokens correspond to COSE algorithm names (). REQUIRED.

rails:

A space-separated list of settlement-rail tokens acceptable to the Verifier. REQUIRED if the Verifier expects a rail-keyed signature (); 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.

Credentials Syntax An Authorization request header field using the "Budget" scheme has the following syntax:

The value of the attestation parameter is the base64url encoding of the CBOR Budget-Attestation envelope (). When the encoded envelope would exceed an HTTP-implementation header size limit (a typical limit is 8 KiB; SLH-DSA signatures () can exceed this), the Agent MUST instead submit the envelope in a request body of media type "application/budget-attestation+cose" () and convey only the scheme name and a content-binding parameter in the Authorization header field, as follows:

The binding value is the base64url-encoded SHA-256 hash of the CBOR-encoded envelope contained in the request body.

The Budget-Attestation Envelope The Budget-Attestation envelope is a COSE_Sign structure 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.

CDDL Definition The schema below is given in CDDL .

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

Canonical Encoding Budget-Attestations MUST be encoded using the Core Deterministic Encoding Requirements of . Verifiers MUST reject envelopes whose CBOR encoding does not satisfy those requirements.

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 . Future revisions of this document MAY add additional MUST-implement primary algorithms; the rules of algorithm agility () apply.

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 . Implementations of this document MUST support SLH-DSA-SHA2-128f as the rail-keyed algorithm (); 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.

Verification A Verifier processing a Budget-Attestation MUST, in order: Verify that the encoded CBOR satisfies the Core Deterministic Encoding Requirements of . Verify that the version claim is supported (). Verify the primary signature against the operator key identified by the kid parameter or otherwise resolved by deployment policy. Verify that iat and exp define a non-empty interval that includes the current time, allowing for clock skew of at most 60 seconds. 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. 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. 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.

Versioning This document defines version 1 of Protocol 427. Future revisions MAY define additional versions.

The Protocol-427-Version Field The Protocol-427-Version response header field is a Structured Field 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.

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 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 . Example:

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: 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. A registry for additional reason codes is established in .

IANA Considerations This document creates registrations in several IANA registries.

Status Code 427 IANA is requested to register the following entry in the "HTTP Status Codes" registry [IANA.HTTP.StatusCodes] established by : Value Description Reference 427 Budget Required of this document

"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 : Authentication Scheme Name Reference Notes Budget of this document Conveys a CBOR-encoded, post-quantum signed Budget-Attestation; see .

"Protocol-427-Version" Field IANA is requested to register the following entry in the "HTTP Field Name Registry" [IANA.HTTP.Fields] established by : Field Name Status Reference Comments Protocol-427-Version permanent of this document Structured Field, Item of type Integer; see .

"Protocol-427" Upgrade Token IANA is requested to register the following entry in the "HTTP Upgrade Token Registry" [IANA.HTTP.UpgradeTokens] established by : Value Description Expected Version Tokens Reference Protocol-427 Agent Budget Negotiation Protocol A non-negative integer denoting the Protocol-427 version of this document

"application/budget-attestation+cose" Media Type IANA is requested to register the following media type 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 )

Encoding considerations:

binary; uses Concise Binary Object Representation (CBOR) .

Security considerations:

See of this document.

Interoperability considerations:

Implementations MUST follow the CBOR encoding rules of and the CDDL definition of 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) File extension(s): .cbor Macintosh file type code(s): N/A

Person & email address to contact for further information:

John Paul McGraw, Jr. <j.mcgraw@taskhawktech.com>

Intended usage:

COMMON

Restrictions on usage:

N/A

Author:

John Paul McGraw, Jr.

Change controller:

IETF

Provisional registration?:

No.

"budget-required" Problem Type IANA is requested to register the following entry in the "HTTP Problem Types" registry [IANA.HTTPProblemTypes] established by : Field Value Type URI https://taskhawktech.com/problems/budget-required Title Budget attestation required Recommended HTTP status code 427 Reference of this document

Protocol-427 Reason Codes Registry IANA is requested to establish a new registry titled "Protocol-427 Reason Codes" with registration policy "Specification Required" . 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 .

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 ().

Security Considerations This section follows the guidance of and adapts the threat-class analysis of to the Budget-Attestation envelope.

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 : Verifiers SHOULD NOT accept Budget-Attestations carried in TLS 1.3 0-RTT data, or MUST employ the Early-Data header field mechanism of .

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.

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.

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.

Post-Quantum Cryptographic Considerations Per , 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 , Section 3. SLH-DSA is hash-based and offers an independent cryptographic foundation; this is the rationale for offering a rail-keyed signature option (). Implementations MUST use the pure mode of SLH-DSA per ; HashSLH-DSA is not supported.

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.

Verifier Responsibilities Failure to verify is the dominant failure mode for any signature-based protocol. Verifiers MUST validate every check listed in and MUST NOT short-circuit verification under any condition.

Privacy Considerations This section follows the guidance of and . 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); 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 when constructing the agent identifier and when logging verification outcomes.

References

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. This document obsoletes RFC 7234. Applications often use HTTP as a substrate to create HTTP-based APIs. This document specifies best practices for writing specifications that use HTTP to define new application protocols. It is written primarily to guide IETF efforts to define application protocols using HTTP for deployment on the Internet but might be applicable in other situations. This document obsoletes RFC 3205. This document defines a "problem detail" to carry machine-readable details of errors in HTTP response content to avoid the need to define new error response formats for HTTP APIs. This document obsoletes RFC 7807. This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields. This document obsoletes RFC 8941. This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. Tradeverifyd Tradeverifyd This document specifies JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for Module- Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in US NIST FIPS 204. mesur.io Tradeverifyd University of the Bundeswehr Munich This document specifies JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for Stateless Hash-Based Digital Signature Standard (SLH-DSA), a Post- Quantum Cryptography (PQC) digital signature scheme defined in US NIST FIPS 205. National Institute of Standards and Technology (NIST) National Institute of Standards and Technology (NIST) This document specifies additional HyperText Transfer Protocol (HTTP) status codes for a variety of common situations. [STANDARDS-TRACK] This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. Using TLS early data creates an exposure to the possibility of a replay attack. This document defines mechanisms that allow clients to communicate with servers about HTTP requests that are sent in early data. Techniques are described that use these mechanisms to mitigate the risk of replay. This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange. This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. Coinbase, Inc. Lightning Labs

CDDL Schema (Collected) The following CDDL block consolidates the schema of for ease of implementation.

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

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 ), and the Verifier's response. Initial response:

Follow-up request (CBOR shown in diagnostic notation):

>, {}, << { "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.).

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

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:

through 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

Acknowledgments The author thanks the Working Group for early feedback on this document.