The Delegation HTTP Authentication Scheme for Request-Bound Authority

The Delegation HTTP Authentication Scheme for Request-Bound Authority TaskHawk Systems LLC

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

Web and Internet Transport HTTPAPI HTTP authentication delegated authority authority proof protected processing budget profile RateLimit COSE JOSE ML-DSA CBOR Delegated software requesters increasingly make HTTP requests that spend, consume, disclose, mutate, invoke, or actuate on behalf of human or organizational principals. Existing HTTP authentication mechanisms indicate whether a requester holds a credential. RateLimit fields communicate server-advertised quota and current service-limit information. HTTP Message Signatures can protect selected components of an HTTP message. None of these mechanisms directly defines a common origin-server challenge for a requester to present verifiable, bounded authority from its principal before the server performs protected processing. This document defines the "Delegation" HTTP authentication scheme, response semantics for delegated-authority challenges using existing HTTP status codes and Problem Details, the Delegation-Proof HTTP field, and a COSE/CBOR proof carriage model for request-bound delegated authority. The initial authority profile is the Budget profile, which uses a CBOR/COSE Budget-Attestation envelope to prove bounded authority to spend, consume metered service units, or commit bounded resources. The mechanism is algorithm-agile; the initial cose-ml-dsa proof profile uses existing JOSE and COSE serializations for ML-DSA, with ML-DSA-65 as the baseline algorithm and ML-DSA-87 available as a high-assurance deployment policy option. A dedicated 4NN Delegated Authority Required status code remains an open design question for HTTP Working Group review; this revision does not depend on that status code and does not define payment semantics. This revision also defines a mandatory-to-implement preflight flow for large proof profiles so that GET and HEAD requests do not depend on request content, and so that requests with application representations do not need to multiplex the application body and the proof body in a single content stream. For implementation experience, this individual draft also includes the initial Budget authority profile. The HTTP authentication scheme, status-code semantics, Problem Details members, and field-carriage rules are intentionally separable from the COSE/CBOR Budget profile. If a Working Group chooses to progress the HTTP mechanism independently, the Budget authority profile can be moved to a companion profile document without changing the Delegation challenge semantics defined here. About This Document 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 Delegated software requesters acting on behalf of human or organizational principals increasingly make HTTP requests that may spend money, consume metered service units, disclose regulated data, mutate production state, invoke downstream services, or actuate external systems. HTTP authentication addresses whether a requester holds a usable credential. RateLimit fields communicate server-defined quota policies and current service-limit information. HTTP Message Signatures can provide integrity and authenticity for selected HTTP message components. OAuth Token Exchange and GNAP define ways to obtain or negotiate authorization artifacts. Delegated authority at the protected origin is a distinct HTTP requirement: before processing a consequential request, an origin server or gateway needs a common way to challenge for, receive, and verify a proof that the requester has bounded authority from its principal for that request. This document defines that challenge and proof-carriage layer. This document defines:

The "Delegation" HTTP authentication scheme (), used in the WWW-Authenticate response field when delegated authority is required and in the Authorization request field of a subsequent request.
Delegation challenge response semantics (), using 401 (Unauthorized) when a Delegation credential is absent, invalid, incomplete, or otherwise needs to be obtained, and 403 (Forbidden) when a Delegation credential is understood but is insufficient under local policy.
The Delegation-Proof HTTP field (), used when delegated authority is additive to another origin-server authentication mechanism already carried in Authorization.
A proof-profile model for request-bound authority. The initial Budget authority profile defines the Budget-Attestation envelope (), a CBOR-encoded , COSE-signed structure that carries semantic claims about issuer, requester, expiry, request binding, permitted rails, and amount.

This document currently contains both the generic HTTP Delegation mechanism and the initial Budget authority profile so the protocol can be reviewed with a complete running profile. The sections are scoped so the generic HTTP mechanism can be split from the Budget profile in a future revision if that is cleaner for Working Group processing. The Delegation authentication scheme is algorithm-agile. The initial Budget cose-ml-dsa profile uses ML-DSA algorithm identifiers serialized for JOSE and COSE by , using the ML-DSA algorithm specified in . Implementations of this profile MUST support ML-DSA-65 and MAY support ML-DSA-87. A deployment MAY require ML-DSA-87 or another ML-DSA algorithm registered by under local policy. Algorithm families outside that registration require a separately specified proof profile. This profile has exactly one Issuer signature in a COSE_Sign1 object. Multi-signer, countersignature, and rail-specific co-signature constructions are outside this version and require a separately versioned profile. This document does not define a payment protocol. Settlement rails such as L402 , x402 , card payments, or other systems can use Delegation proofs or the Budget profile as input to their own policy and settlement flows; however, their settlement semantics are outside the scope of this document. In particular, this document does not depend on, redefine, or reserve any semantics for HTTP 402 (Payment Required). Scope and modularization: Sections 3 and 4 define the HTTP response semantics, authentication challenge, credential syntax, and HTTP field semantics for Delegation. Section 5 defines the initial Budget authority profile to demonstrate an interoperable cryptographic binding for one class of delegated authority. During standards progression, the Working Group can move one or more proof profiles into companion documents for review by the COSE, OAuth, or GNAP communities without changing the core HTTP semantics defined by the authentication scheme, Problem Details members, and field carriage.

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.

Principal:: The human, organization, service, or other authority holder on whose behalf a delegated requester acts.
Issuer:: An entity that issues a Delegation proof on behalf of a principal. In the Budget authority profile, the Issuer is the entity that issues Budget-Attestations.
Delegated Requester:: A client, workload, device, job, agent, or other software component that presents a Delegation proof issued by an Issuer in order to make HTTP requests within delegated bounds.
Agent:: A delegated requester. The term "agent" remains the motivating deployment case and appears in existing implementation field names; it is not a protocol requirement for any specific architecture.
Verifier:: An origin server, or a gateway or reverse proxy explicitly authorized by the origin for the same protection space, that receives a Delegation proof, validates its signatures and claims, and decides whether to perform protected processing for the Protected Target Request. This document defines origin-server authentication and does not define proxy authentication. Generic forward proxies and intermediaries that are not authoritative for the origin's protection space do not issue, validate, or consume Delegation credentials except as ordinary HTTP message forwarding behavior permits.
Protected Processing:: Application processing that the Verifier will not perform until the requester has presented a Delegation proof satisfying local policy. Examples include actions that spend, consume, disclose, mutate, invoke, or actuate.
Delegation Proof:: A verifiable object presented by a delegated requester to show bounded authority from a principal for a request or class of requests.
Proof Carrier Request:: The HTTP request that transports a Delegation proof. In direct field presentation it is also the Protected Target Request. In preflight it is the POST request to the preflight endpoint and is distinct from the future Protected Target Request.
Protected Target Request:: The HTTP request whose protected processing the Delegation proof is intended to authorize. Request-Binding always describes this request, never a distinct Proof Carrier Request.
Authority Profile:: A profile that defines the claims, proof format, bounds, and verifier checks for a specific class of delegated authority. Budget is the initial authority profile in this document.
Budget Authority Profile:: The authority profile defined in for spending, consuming metered service units, or committing bounded resources.
Budget-Attestation:: The CBOR-encoded, COSE-signed Delegation proof defined for the Budget authority profile in .
Settlement Rail:: An out-of-band protocol or payment system used to transfer value or record resource consumption. Rail names can appear in field 7 of a Budget-Attestation. This document does not define how any settlement rail operates.

Applicability Delegation is a general HTTP mechanism for request-bound delegated authority. Autonomous software agents and paid-resource access are motivating deployment cases; however, the mechanism also applies to service workloads, CI/CD jobs, IoT or fleet devices, batch systems, scheduled data processors, delegated administration tools, and other requesters that need to prove bounded authority before protected processing occurs. The core mechanism is intentionally broader than budget. Authority profiles can define bounds for spending, service-unit consumption, compute allocation, data disclosure, infrastructure mutation, downstream invocation, procurement commitment, safety-relevant actuation, or other consequential actions. The Budget authority profile is the initial profile because it provides a concrete interoperable proof format and a clear deployment need. Budget-Claims field 3 carries the delegated requester identifier. Deployments MAY populate it with an agent identifier, service-account identifier, workload identity, device identifier, job identifier, or privacy-preserving alias. This field does not require the requester to be an AI system. Deployment APIs MAY continue using names such as agent_id at their local boundary, but that name is not encoded in the signed CBOR claims map.

Relationship to OAuth, GNAP, and Token Exchange OAuth Token Exchange defines an HTTP- and JSON-based Security Token Service pattern for obtaining security tokens, including delegation and impersonation cases. GNAP defines a grant negotiation and authorization protocol for delegating authorization to software and conveying the resulting artifacts. This document does not replace either protocol. Delegation defines the protected-resource challenge and presentation layer: an origin server or gateway can tell a requester which delegated authority proof is required before protected processing, and the requester can present a request-bound proof for verification. OAuth, GNAP, an STS, an issuer-managed key service, or another deployment-specific system can be used to obtain the proof. The issuance flow is outside the scope of this document. The delegation semantics in this document are closer to delegation than impersonation: the requester remains distinct from the principal, and the proof records that the requester is acting with bounded authority from the principal. The document does not define general identity authentication, user consent, account linking, or grant negotiation.

Relationship to Sender-Constrained Tokens and DPoP OAuth 2.0 Demonstrating Proof of Possession (DPoP) sender-constrains OAuth access and refresh tokens by binding an issued token to a client key and requiring the client to prove possession of the corresponding private key on protected-resource requests. This reduces replay risk when an OAuth token is leaked. It does not, by itself, express bounded delegated authority for protected processing, and a valid DPoP proof is not a Delegation proof. A deployment MAY require the requester identity or session credential used with Delegation to be sender-constrained, for example by DPoP, mutual TLS, HTTP Message Signatures, or another deployment-specific mechanism. Validation of that credential is a separate authentication layer. Failure of the sender-constrained credential is handled according to that authentication layer; failure of the Delegation proof is handled with the 401/403 response semantics defined in . When OAuth DPoP and Delegation are used on the same protected request, the implementation has to define field composition because DPoP uses the Authorization: DPoP authentication scheme, while Delegation can use Authorization: Delegation. A request MUST NOT concatenate both credentials in one Authorization field. A deployment can carry the identity credential in Authorization and delegated authority in Delegation-Proof or in the base profile's preflight Proof Carrier Request. Direct body carriage on the Protected Target Request requires a separately selected and versioned noncircular packaging profile. A deployment that wants to use a preflight compact Delegation credential on a request that must also retain Authorization: DPoP needs a companion profile defining non-Authorization carriage and binding for the compact Delegation credential. This document does not define that profile.

Relationship to Attribute Certificates X.509 attribute certificates define an older authorization mechanism separate from public-key identity certificates; describes authorization as the conveyance of privilege from one entity to another. Delegation follows the same broad separation between identity and authority, but does not define an X.509 attribute-certificate profile. It defines HTTP challenge semantics and HTTP proof carriage for request-bound delegated authority.

Relationship to RateLimit Fields RateLimit fields describe service limits from the server to the client. They tell the client what quota policy applies and what capacity is currently available under that server-defined policy. They are useful for throttling, backoff, and avoiding 429 responses. Delegation proofs travel in the opposite direction. They are client-presented credentials showing that an Issuer authorized a Delegated Requester to act within stated bounds on behalf of a principal. They are evaluated before the Verifier performs protected processing. This document defines a separate mechanism rather than extending RateLimit because a signed, bearer-presented authority proof has different issuer, freshness, replay, and verification semantics from server-advertised quota metadata. Extending RateLimit-Policy would change the issuer and trust model of RateLimit from server-authored quota advertisement into principal-authorized delegated authority, which is a different protocol semantic rather than a new quota parameter. The mechanisms are complementary:

A server MAY return RateLimit fields on 200, 401, 403, 429, or other responses when it wants to communicate server-side quota state.
A server MUST NOT treat RateLimit fields as a substitute for a Delegation proof, because RateLimit fields are not signed authority from the requester's principal.
A Budget-Attestation MUST NOT be interpreted as a server quota promise. It only states the Delegated Requester's delegated authority under the Budget authority profile.

Property	RateLimit fields	Delegation proof
Direction	Server to client	Client to verifier
Issuer	Resource server or gateway	Issuer acting for the principal
Integrity	HTTP field semantics	COSE/JOSE signature
Purpose	Advertise quota and current service limits	Prove bounded delegated authority
Failure mode	Client might be throttled	Request fails before protected processing

Relationship to HTTP Message Signatures defines signatures over components of individual HTTP messages. A Delegation proof signs a portable authority object whose claims can be evaluated independently of a single HTTP message and, when required, bound to a particular bearing request. The two mechanisms can be composed: a Delegated Requester can send an HTTP-message signature that covers the request as transmitted and a Delegation proof that covers delegated authority for the action. The preflight target-binding fields defined by this document describe the protected request that will be sent after preflight. They are not intended to replace HTTP Message Signatures. Where this document needs the method and target URI of a protected request, the comparison semantics are aligned with the corresponding HTTP Message Signatures derived components, including @method and @target-uri. Where this document needs a representation digest, deployments SHOULD use the digest algorithm and syntax defined for HTTP Digest Fields , and the digest accepted during preflight SHOULD match the protected request's Content-Digest field when that field is present. A deployment can additionally require an HTTP-message signature over the protected request, including @method, @target-uri, content-digest, and authorization, when it needs message-level integrity in addition to delegated authority. This document uses target-binding fields in the preflight request because the protected request has not yet been sent when the full proof is presented. The fields identify the future protected request for verifier policy and compact credential binding; they do not sign or otherwise authenticate the preflight HTTP message itself.

Relationship to HTTP 402 HTTP 402 (Payment Required) is reserved by HTTP Semantics . Some deployed payment systems use 402 responses as part of their own settlement flows. This document neither depends on those deployments nor defines their semantics. An implementation MAY use a Delegation proof or the Budget authority profile before invoking a settlement rail. Whether that later settlement interaction uses HTTP 402, a 401 challenge, a signed request body, or another transport is out of scope for this document.

Overview of Operation A protected origin determines that a request requires delegated authority and that no acceptable Delegation credential is present: It returns: The Delegated Requester obtains a Delegation proof from its Issuer by means outside this document and submits the large proof to the advertised preflight URI. In this example the proof uses the Budget authority profile: : Content-Length: 4217 [COSE_Sign1 Budget-Attestation bytes] ]]> Angle-bracketed values in examples are placeholders, not wire syntax. If the attestation is valid for the request and local policy, the Verifier returns a compact, verifier-issued Delegation credential bound to the original method, origin, target, nonce, expiry, and representation digest: :" } } ]]> The requester then retries the original protected request using normal HTTP semantics. The final request carries the compact Delegation credential in the Authorization field. If the protected request has an application representation, that representation remains the request content: If Delegation validation fails, the Verifier returns either a 401 or 403 response as described in and SHOULD include a reason extension member in the Problem Details body.

Delegation Challenge Responses Delegation uses existing HTTP authentication semantics as its baseline response model. A Verifier that requires delegated authority and receives no Delegation credential, an invalid Delegation credential, or a partial Delegation credential SHOULD send a 401 (Unauthorized) response containing a WWW-Authenticate response field with at least one Delegation challenge. This follows the HTTP authentication model in : the response supplies a challenge that the client can answer by obtaining or presenting a Delegation credential. A Verifier that receives a syntactically valid and authenticated Delegation credential that is insufficient for the requested resource, exceeds local policy, names an unacceptable authority profile, or otherwise does not authorize the request SHOULD send a 403 (Forbidden) response. A 403 response MAY include a WWW-Authenticate response field with a Delegation challenge when a different Delegation credential might allow the request to succeed; it MUST NOT include that challenge when local policy forbids the request independent of Delegation credential contents. A Delegation challenge response SHOULD include Cache-Control: no-store as defined by HTTP caching . A Delegation challenge response that contains a nonce, requester-specific policy, or other policy-sensitive material MUST include Cache-Control: no-store. A Delegation challenge response SHOULD include an application/problem+json body using . The Problem Details object SHOULD contain an authority_requirements extension member when the Verifier can describe the delegated authority needed for the protected request. A profile MAY define additional profile-specific members; for example, the Budget authority profile can describe amounts, units, or accepted settlement rails. When a value is represented both in a WWW-Authenticate challenge parameter and in the Problem Details body, the challenge parameter is authoritative for authentication processing. The Problem Details body is explanatory and actionable metadata for clients; it does not relax, override, or extend the WWW-Authenticate challenge. This document does not redefine HTTP 402 (Payment Required), and a Delegation challenge response MUST NOT be interpreted as a settlement request. A 429 (Too Many Requests) response remains the appropriate signal for server-side quota exhaustion.

Dedicated Status Code Design Question Earlier revisions proposed a dedicated 427 (Budget Required) status code for Budget challenges. The broader design question is whether HTTP needs a dedicated status code for delegated authority challenges. A future revision can request registration of a 4NN Delegated Authority Required status code if the HTTP Working Group concludes that existing 401 and 403 semantics plus WWW-Authenticate: Delegation and Problem Details are insufficient for interoperable clients, intermediaries, and API gateways. This revision therefore uses 401 and 403 as the baseline and does not request an HTTP status-code registration. Conformant implementations use the 401/403 behavior defined in unless and until a future revision registers a dedicated status code.

Delegation Error Tokens When a Verifier returns a Delegation challenge response because a presented Delegation credential failed validation or did not satisfy policy, the Problem Details object SHOULD contain a reason extension member. The value of this member is a token identifying the validation failure. This document defines the following initial tokens:

token_expired: The presented Budget-Attestation expiry value is in the past relative to the Verifier's clock.
nonce_stale: The nonce in the attestation does not match a valid, unexpired challenge window.
nonce_replay: The nonce has already been accepted by the Verifier within its replay-tracking window.
bad_signature: Cryptographic validation of the primary Issuer signature failed.
untrusted_issuer: The issuer identifier in Budget-Claims field 2 identifies an issuer for which the Verifier has no explicit trust relationship.
authority_insufficient: The signed authority bounds do not satisfy the requirement advertised by the resource server.
budget_insufficient: The signed budget bounds in Budget-Claims fields 4 and 5 do not satisfy the budget requirement advertised by the resource server.
version_unsupported: The Budget-Claims field 1 value, Delegation-Version field, or version challenge parameter is not supported by the Verifier.
binding_mismatch: The request target URI, method, origin, or body digest does not match the signed request-binding values.

The "Delegation" Authentication Scheme The Delegation authentication scheme is used in WWW-Authenticate and Authorization fields.

Challenge Syntax The Delegation authentication scheme challenge uses the auth-param syntax defined by , Section 11.2: The realm and nonce parameters are REQUIRED. The profile parameter identifies an acceptable authority profile, such as budget. The proof-format parameter identifies an acceptable proof serialization, such as cose-ml-dsa. The alg parameter identifies one acceptable primary signature algorithm for the indicated proof format. A Verifier that accepts multiple algorithms SHOULD send separate Delegation challenges rather than overloading a single alg parameter with a list syntax. A challenge MUST NOT contain more than one alg parameter. Authority profiles MAY define additional challenge parameters; for example, a Budget profile can define accepted settlement rails while leaving rail semantics out of scope for this document. The preflight-uri parameter is OPTIONAL. When present, it identifies the preflight endpoint for the challenged protection space. A profile that requires preflight for a challenged request SHOULD include preflight-uri in the Delegation challenge or advertise the same endpoint through an authenticated discovery mechanism. A Problem Details authority_requirements.preflight_uri member can mirror or further explain the preflight endpoint, but it does not override a preflight-uri challenge parameter. The interoperable profile identifier for the authority profile defined in this document is budget. Deployments MAY use private-use or local profile identifiers when those identifiers are mapped by authenticated configuration or discovery metadata to the same Budget claim and verification semantics. Such private-use identifiers are deployment-specific and MUST NOT be assumed interoperable by other implementations unless a future specification registers or otherwise defines them. After auth-param parsing, the nonce value MUST be the canonical base64url encoding without padding defined by , Section 5. A Verifier MUST reject an invalid or noncanonical encoding. The decoded value MUST be 16 to 64 octets. Budget-Claims field 10 is the CBOR bstr containing exactly those decoded octets; it is not the encoded challenge text. The Issuer and Verifier MUST compare those octets exactly. The nonce parameter MUST contain at least 128 bits of unpredictable entropy and MUST be generated by the Verifier for the protection space identified by realm. A Verifier MUST accept a nonce at most once. Replay of a nonce, absence of nonce state, or loss of the replay cache MUST cause the Verifier to reject the request. To reduce outstanding-challenge state, Verifiers SHOULD support self-authenticating nonce constructions. A self-authenticating nonce contains unpredictable bytes and integrity-protected metadata such as protection space, issuance time, key identifier, and policy binding. The nonce is authenticated with a server-held secret, for example using an HMAC or AEAD construction, and MUST NOT reveal that secret to clients. This construction allows a Verifier to validate the origin and age of a returned nonce without storing every issued challenge. It does not remove the requirement to enforce at-most-once acceptance; Verifiers still need accepted-nonce replay tracking or an equivalent replay-detection mechanism until the challenge can no longer be accepted. The max-age parameter, when present, is the validity window in seconds for the challenge parameters and nonce. It does not extend the Delegation proof lifetime. A Verifier MUST reject a Delegation proof whose nonce is older than max-age for the corresponding challenge. If max-age is omitted, Verifiers SHOULD apply a local default and that default SHOULD NOT exceed 900 seconds.

Credentials Syntax The credential token carries a base64url-encoded Delegation proof or a verifier-issued compact Delegation credential derived from a previously verified proof. If the encoded proof would exceed practical HTTP field size limits, the requester MUST NOT assume that the proof can be carried in an HTTP field. The Budget cose-ml-dsa profile MUST support the preflight flow defined in as the mandatory-to-implement fallback for large proofs. Before decoding an Authorization: Delegation token, the Verifier MUST know whether the selected credential kind is a full Delegation proof or a compact credential from challenge/preflight state or from a non-overlapping, authenticated local token syntax. Failure to validate the selected kind MUST cause rejection and MUST NOT trigger decoding as the other kind. Because this document leaves compact-token syntax implementation-specific, a deployment that enables both kinds in one protection space MUST configure a disjoint authenticated discriminator or equivalent state that selects exactly one kind before decoding. Without such a discriminator, it MUST NOT enable both kinds for that protection space. A client MUST NOT reuse a Delegation credential solely because a later request is in the same realm or protection space. Delegation credentials are bounded by their authority profile, nonce, expiry, request binding, and compact credential replay rules. A client can reuse a compact Delegation credential only when the credential's profile explicitly permits that reuse and the requested operation remains within the credential's verified binding. Requesters using the Budget cose-ml-dsa profile SHOULD use preflight by default because ML-DSA-backed COSE envelopes are large before base64url expansion and can exceed field-size limits enforced by intermediaries. describes the larger key, ciphertext, and signature sizes of PQC mechanisms as a protocol-design consideration rather than a transparent algorithm rollover. A deployment profile MAY permit field carriage with Authorization: Delegation only when it defines accepted field-size limits and failure behavior. A Verifier MAY reject oversized field-carried credentials before CBOR or COSE decoding. The content of GET and HEAD requests has no generally defined semantics in HTTP. The Budget cose-ml-dsa profile MUST NOT rely on GET or HEAD request content for Delegation proof carriage. When a GET or HEAD request needs a large Delegation proof, the requester MUST use the preflight flow in or another explicitly negotiated profile that does not depend on GET or HEAD request content. This requirement does not mean that every authenticated GET or HEAD request needs a new preflight exchange: small credentials that fit within deployment field-size limits, previously issued compact credentials whose profile explicitly permits the requested use, or future profile-defined proof-reference mechanisms can avoid the extra round trip. The Budget cose-ml-dsa profile only makes preflight mandatory to implement as the fallback when the proof itself is too large for ordinary field carriage. When the protected operation also requires an application request body, body-carried proof creates a packaging question: the HTTP request has only one content stream. The mandatory interoperability fallback for the Budget cose-ml-dsa profile is preflight. In the base Budget profile, application/delegation-proof+cose request-content carriage is used only for the Proof Carrier POST to the preflight endpoint; direct presentation on the Protected Target Request uses field carriage subject to its configured size limit. A deployment profile MAY additionally define a same-request packaging media type, for example a multipart/related or profile-specific envelope, but such a media type is an additional profile and not the baseline interoperability requirement. A packaging profile MUST define an unambiguous, noncircular extraction of the proof object and protected application-content octets, how those application octets are hashed without including the signature that covers the hash, and how the two are cryptographically bound before claiming interoperability. In all cases, the Budget profile's request-binding rules in apply to the protected operation. A proof body by itself MUST NOT cause the Verifier to process an unrelated application body unless the packaging profile defines how the two are cryptographically bound.

HTTP Message Completeness and Incremental Processing Regardless of carriage location, a Verifier MUST NOT accept a Delegation proof, issue a compact Delegation credential, expose verified claims, or perform the Protected Target Request until the Proof Carrier Request is complete. For direct field presentation, where the carrier is the Protected Target Request, the Verifier also MUST wait for all protected application content and any trailer-carried Content-Digest to be complete and validated. A field-carried proof can be parsed after receipt of the field section, but successful parsing does not satisfy this complete-message gate. If the HTTP stack has not supplied its end-of-message indication, the message is incomplete even if the available proof bytes decode. Abort, timeout, missing completion, or failed bound-content validation MUST cause rejection without an authority-bearing effect. When a Delegation proof is carried in request content using application/delegation-proof+cose, TLS record boundaries, HTTP message and frame boundaries, transfer-coding syntax, transport read sizes, and implementation buffer boundaries are not part of a Delegation proof. A Verifier MAY consume proof content incrementally, but it MUST derive the proof media-type data by processing exactly the ordered sequence of Proof Carrier Request content octets and then decoding any accepted content coding. Given the same complete content octets and Verifier state, every partition of those octets across TLS records, HTTP frames, reads, or internal buffers MUST produce the same derived proof data and verification result. An incremental implementation MUST NOT omit, duplicate, insert, or reorder octets. This specification defines no proof chunk format or chunk size. An authority profile that defines another proof media type MUST specify its top-level object framing and completeness rules. For body carriage, the resulting media-type data MUST contain exactly one complete tagged or untagged COSE_Sign1 value permitted by , with no trailing octets. Every accepted content coding MUST be successfully decoded before verification. Incomplete content, content-decoding or proof-decoding failure, and trailing octets MUST cause verification failure. Values obtained from partial decoding MUST NOT be treated as verified claims or used as a basis for protected processing. A Verifier MUST enforce cumulative coded-content limits while receiving a body-carried proof and cumulative decoded-proof limits after or during content decoding. Counter overflow MUST cause rejection. When either configured body-carriage limit is exceeded, the Verifier SHOULD use 413 (Content Too Large). Field-carried proofs are instead subject to the field-size limits and failure behavior required by and ; coded-content and decoded-proof body limits do not synthetically apply to a field value. A profile-defined field-value limit MUST be applied to the serialized field value as carried: this includes the authentication scheme and encoded token for Authorization, or the Structured Field Byte Sequence framing and base64 representation for Delegation-Proof. It MUST NOT be measured only over decoded COSE octets. This document does not set a universal proof-size limit, and an implementation's internal processing unit does not change any configured total limit.

Large-Proof Preflight Flow The preflight flow separates large-proof carriage from protected request processing. It is the mandatory-to-implement fallback for the Budget cose-ml-dsa profile. A Delegation challenge response for a profile that supports preflight SHOULD advertise a preflight URI in the Problem Details authority_requirements object, the preflight-uri authentication challenge parameter, or by another profile-defined discovery mechanism. A preflight-uri challenge parameter takes precedence over a Problem Details value, and a challenge-specific value takes precedence over a stable preflight URI learned through discovery. For the Budget cose-ml-dsa profile, a Verifier that requires preflight for the challenged request MUST advertise a preflight URI through one of those mechanisms. The advertised preflight URI identifies an endpoint that accepts a Delegation proof but does not perform the protected operation. Before transmitting a proof, the requester MUST obtain the preflight URI from a TLS-authenticated challenge response from the protected target origin or from authenticated configuration or discovery bound to that target's protection space. The preflight URI MUST be an absolute HTTPS URI without userinfo or a fragment, and the requester MUST authenticate its HTTPS origin. The requester MUST NOT send the proof to an endpoint that is not authorized to receive it for that protection space. Cross-origin preflight is permitted only when authenticated configuration or discovery explicitly authorizes the endpoint for that protection space; a URI in a challenge or redirect alone does not establish that authorization. The precedence rules above select among authorized endpoints and MUST NOT override these trust requirements. A requester MUST NOT follow a preflight redirect with a proof-bearing request unless it first applies the same endpoint authentication and recipient authorization requirements to the new destination. It MUST NOT forward proof content or associated credentials to an unauthorized destination, and MUST NOT follow an HTTPS-to-HTTP downgrade. These requirements do not authorize forwarding unrelated identity or session credentials. The requester submits the full Delegation proof to the preflight URI using POST. The preflight request content type MUST be application/delegation-proof+cose for the base Budget profile. A separately selected and versioned extension profile can define another exact media type and its parameters. A preflight request MUST be bound to the protected request by method, origin, target URI, nonce, expiry, and, when the protected request has content, a representation digest. The Budget cose-ml-dsa profile uses the target-binding fields defined in for this binding. The POST to the preflight URI is the Proof Carrier Request, not the Protected Target Request. When Budget-Claims field 14 is present, it MUST bind the future Protected Target Request designated by the validated Delegation-Target-* fields. It MUST NOT bind the method, URI, or proof-envelope content of the preflight POST. In particular, Request-Binding body-h covers the future protected application content identified by Delegation-Target-Content-Digest, never the body-carried COSE proof bytes. The Verifier MUST NOT perform the protected operation while processing the preflight request. A successful Budget cose-ml-dsa preflight response returns a compact verifier-issued Delegation credential as described in . A future authority profile can define another proof reference or verifier-issued artifact, but it MUST provide equivalent target binding, expiry, and replay protection before claiming interoperability. The interoperability property is that any Verifier responsible for the same protection space can validate the compact credential and enforce replay policy; a credential that can only be resolved by the individual node that processed preflight is not interoperable. The requester then sends the protected request using ordinary HTTP semantics. The protected request carries the compact Delegation credential in Authorization: Delegation. For GET and HEAD requests, the protected request does not carry Delegation proof content. For POST, PUT, PATCH, or other methods with request content, the protected request content remains the application representation. The Verifier MUST reject the compact Delegation credential if the method, origin, target URI, nonce, expiry, or representation digest observed on the protected request differs from the binding verified during preflight. The Verifier MUST enforce at-most-once acceptance for credentials that authorize a non-idempotent protected operation. For a compact credential issued by preflight, the Verifier MUST atomically consume the proof nonce when issuing the compact credential or otherwise ensure that repeated preflight requests with the same proof nonce cannot mint multiple credentials for a non-idempotent operation. The final protected request then consumes the compact credential replay key as described in .

Preflight Target Binding Fields The Budget cose-ml-dsa preflight request uses the following HTTP fields to identify the protected request to which the full Delegation proof is being bound. These fields are Structured Fields .

Delegation-Target-Method:: The HTTP method token of the protected request. HTTP method tokens are case-sensitive; the Verifier MUST compare this field using the exact method token that will be used for the protected request. The field value is a Structured Field Item whose bare item is a String. This comparison is aligned with the HTTP Message Signatures @method derived component.
Delegation-Target-URI:: The absolute URI of the protected request target as reconstructed by the Verifier after applying only trusted origin or reverse-proxy configuration. The field value is a Structured Field Item whose bare item is a String. The Verifier MUST derive scheme and authority from connection context, origin configuration, or explicitly trusted gateway metadata. It MUST ignore untrusted Forwarded, X-Forwarded-*, or similar fields when reconstructing the target URI. The Verifier MUST reject a preflight request whose target URI cannot be reconstructed deterministically, is outside the authority scope of the challenged resource, or uses a request-target form such as CONNECT authority-form or OPTIONS asterisk-form that is not defined by the authority profile. This comparison is aligned with the HTTP Message Signatures @target-uri derived component.
Delegation-Target-Content-Digest:: The digest of the protected request content, using the Digest Fields syntax defined by . The field value is a Structured Field Dictionary. The Budget cose-ml-dsa profile MUST support sha-256. This field is REQUIRED when the protected request has content, including explicitly framed zero-length content. If the protected request has no content, this field MUST be omitted. The Verifier MUST compute the digest over the complete protected-request content according to and require equality with the value accepted during preflight. When Budget-Claims field 14 contains body-h, that value MUST be the same SHA-256 digest. When the protected request carries Content-Digest, the Verifier MUST independently validate that field against the actual complete content and require its sha-256 value to equal the preflight digest and, when field 14 is present, body-h. The Verifier MUST NOT trust a client-supplied Content-Digest value without verifying it. If Content-Digest is received in a trailer section, the Verifier MUST NOT perform the protected operation before the trailer has been received and the digest has been validated.

The Verifier MUST reject the preflight request if any required target-binding field is absent, malformed, ambiguous, inconsistent with the challenged resource, or inconsistent with the request-binding claims in the Delegation proof. The Verifier MUST reject the later protected request if its observed method, effective request URI, or content digest differs from the target accepted during preflight.

Compact Credential Response A successful Budget cose-ml-dsa preflight response SHOULD use 200 (OK). A deployment MAY use 201 (Created) when it exposes a distinct resource URI for the issued credential. The response MUST include Cache-Control: no-store and MUST NOT be interpreted as a settlement signal, a payment receipt, or evidence of revenue. The response body MUST be a JSON object containing these members:

credential_type:: The string delegation-compact.
credential:: An opaque token68 compact Delegation credential. The credential syntax is implementation-specific; clients MUST treat it as opaque.
authorization:: A convenience string equal to Delegation followed by the credential value. The client MAY copy it directly into the protected request's Authorization field.
expires_in:: The remaining credential lifetime in seconds, expressed as a non-negative integer. The compact credential lifetime MUST NOT exceed the challenge window or the underlying Delegation proof lifetime.
target:: A JSON object restating the accepted protected-request binding. It MUST include method and uri. It MUST include content_digest when the protected request content digest was part of the preflight binding. The content_digest value uses the Digest Fields syntax defined by .

A successful preflight response MUST NOT be interpreted as a settlement signal, a payment receipt, or evidence of revenue. Profiles or deployments can include additional metadata in the response body, but such metadata does not change the Delegation authorization semantics unless a future specification defines that behavior. A compact Delegation credential MUST be integrity protected by the Verifier and bound to the verified proof, issuer and requester identifiers when available, method, origin, target URI, representation digest when present, nonce, expiry, and local authority requirements. The Budget cose-ml-dsa profile MUST NOT depend on node-local preflight state that is unavailable to another Verifier in the same protection space. Implementations SHOULD use a self-authenticating compact credential, such as an opaque verifier-protected token whose contents are integrity protected and confidential from clients when necessary. A deployment MAY instead use a server-side credential handle only when lookup, validation, and consumption state is consistently available to all Verifiers that can receive the protected request. A Verifier MUST fail closed if it cannot validate, look up, or consume the compact credential and its replay state. A compact Delegation credential that authorizes a non-idempotent protected operation MUST be accepted at most once. At protected-request acceptance, the Verifier MUST check the compact credential against the currently applicable local authority requirements and the authorization status of the original Issuer signing key. A successful preflight check alone is not sufficient. The credential or its integrity-bound validation state MUST identify the original Issuer and signing key and the policy context needed for those checks. The Verifier MUST reject the request if the key is revoked, expired, or no longer authorized, or if current policy does not permit the request. Required policy or key-status information MUST be authenticated and within its applicable freshness lifetime; unavailable or stale required information is a validation failure. Implementations can use integrity-protected version references or shared validation state to enforce invalidation, without prescribing a compact token format or requiring the original proof to be transmitted again. Key rotation alone does not invalidate a credential when the original key remains authorized under current policy. Replay tracking for compact Delegation credentials is based on a Verifier-selected replay key, not on a client-interpretable token format. A self-authenticating compact credential SHOULD contain or yield an integrity-protected credential identifier suitable for replay tracking. The accepted challenge nonce MUST remain bound to the compact credential, either directly or through the integrity-bound proof or validation state. A compact credential MAY contain an explicit representation of that nonce; omitting that representation MUST NOT omit the nonce binding or its verification. This does not change the mandatory nonce in Budget-Claims field 10. If no separate credential identifier is available to verifier logic, the Verifier MAY derive the replay key from a cryptographic hash of the received compact credential, the protection space, and the accepted protected-request binding. Verifiers MUST NOT rely on a client-supplied, unauthenticated identifier for replay tracking. For non-idempotent protected operations, replay-state unavailability or an inability to atomically consume the replay key is a validation failure.

Multi-Scheme Composition and the Delegation-Proof Field The Delegation-Proof field carries a Delegation proof when the request already uses Authorization for another origin-server credential or when a deployment wants delegated authority to be visibly additive to another authentication scheme. The field value is a Structured Field Item whose bare item is a Byte Sequence containing a COSE/CBOR Delegation proof. If both Authorization: Delegation and Delegation-Proof are present, the Verifier MUST reject the request unless a deployment profile explicitly defines how the two credentials compose. This avoids ambiguity about which signed authority object is authoritative. The Authorization field MUST NOT be used to concatenate a non-Delegation credential and a Delegation credential into a single field value unless a future HTTP authentication scheme explicitly defines such composition. When identity authentication must retain Authorization on the Protected Target Request, bounded low-footprint delegated authority SHOULD be presented in the Delegation-Proof field. Using a preflight compact Delegation credential in that case requires a companion profile defining its non-Authorization carriage and binding; this document does not define that profile. A proof body carried on the Protected Target Request requires the separate packaging profile described in . When a request carries both an identity credential and a Delegation proof, the Verifier MUST evaluate the identity authentication layer and the delegated authority layer independently. Failure of the identity authentication layer is handled according to that authentication scheme, typically with 401 or 403. Failure of the delegated authority layer is handled with the 401/403 response semantics defined in . Responses whose selected representation, protected processing, or authorization decision depends on a Delegation-Proof field are sensitive to a credential field that is not the Authorization field. Unless the response is otherwise safe for shared caching, an origin server or origin-authorized gateway SHOULD send Cache-Control: no-store or Cache-Control: private. If a response to a request carrying Delegation-Proof is intentionally cacheable, the response MUST make the cache key explicit, for example by including Vary: Delegation-Proof and any other Delegation request fields that affect response selection. Challenge responses and preflight responses remain subject to the Cache-Control: no-store requirements in and . The Delegation-Proof field is not the general-purpose carriage path for multi-kilobyte post-quantum attestations. Implementations of the base cose-ml-dsa profile MUST support preflight body carriage with media type application/delegation-proof+cose. A separately selected and versioned extension profile can define another proof media type or same-request packaging. A deployment profile MAY permit Delegation-Proof field carriage only when it defines accepted field-size limits and failure behavior. A field-carried proof and the protected application content are bound using and the complete-message checks in . Field carriage alone does not require a same-request body-packaging profile; that additional profile is needed when the proof and application content share one request-content stream. The interoperable media type for body-carried Delegation proofs defined by this document is application/delegation-proof+cose. Earlier or local media types, including Budget-specific deployment aliases, are implementation experience and MUST NOT be assumed interoperable unless separately specified or registered.

Budget Authority Profile: Budget-Attestation Envelope

Profile and Version Selection Before interpreting an integer label in a Budget-Claims map, a Verifier MUST select the expected Delegation authentication-scheme version, authority profile, proof format, algorithm policy, and carriage location from challenge state and authenticated local configuration for the protection space. The carriage location identifies request-content carriage, Authorization field carriage, or Delegation-Proof field carriage. Media metadata is conditional: for request-content carriage, the selected tuple also includes the expected proof media type and any permitted media-type parameters; for either field carriage location, no HTTP proof media type exists and a Verifier MUST NOT infer or synthesize one from the COSE object or proof-format name. For Authorization field carriage, the expected credential kind is also selected before token decoding as required by . A full-proof selection enters the Budget-Claims processing defined here; a compact-token selection enters only the configured compact-token verifier. Failure of either selected path MUST NOT fall back to the other. For body carriage in this profile, the media type is application/delegation-proof+cose and the optional outer parameter is constrained by ; this base-profile carriage location is the preflight Proof Carrier Request, not the Protected Target Request. Field carriage is permitted only under the size-limit and failure rules in or , as applicable, and carries no proof media type. The Verifier MUST record the selected tuple, including carriage location, credential kind when applicable, and conditional media metadata, with the issued challenge nonce and, after decoding field 10 under the already-selected schema, MUST confirm that the same tuple is associated with that live nonce. A requester-provided value MUST NOT alter any member of the selected tuple. A Verifier MUST NOT select a claim schema by trying multiple decoders, by inspecting the CBOR type associated with a claim label, or by falling back to another profile after a decode or verification failure. For this profile, the selected values include Delegation version 1, authority profile budget, proof format cose-ml-dsa, Budget-Claims version 1, and the algorithm policy advertised in the challenge and required locally. The outer COSE structure and Budget-Claims field 1 are decoded only to confirm the selected profile and version. A mismatch, an unknown claim label, a claim whose type or meaning belongs to another profile, or a mixture of fields from different profile versions MUST cause rejection. Duplicate map keys are ambiguous and MUST cause rejection before any claim is used. Label 14 has only the Request-Binding type and semantics defined by this profile; any other type or interpretation is a mixed-profile encoding and MUST cause rejection.

COSE_Sign1 and Budget-Claims Encoding The Budget authority profile defines a Budget-Attestation envelope as exactly one COSE_Sign1 object carrying one CBOR claims set. The claims set is encoded using deterministic CBOR . The notation below uses CDDL . Encoders MUST follow the core deterministic encoding requirements of , Section 4.2.1. Verifiers MUST reject non-deterministic encodings. When constructing the COSE Sig_structure, Verifiers MUST use the exact protected-header bstr and payload bstr received in the COSE_Sign1 object and MUST NOT substitute a locally reserialized CBOR value for either bstr. Verifiers MUST reject duplicate map keys in any map in the COSE_Sign1 object, the decoded Budget-Claims payload, or a nested Request-Binding map. Duplicate detection MUST occur during CBOR decoding or in a representation that preserves every encoded pair; a decoder MUST NOT first collapse pairs into an ordinary map and then attempt duplicate detection. A header label occurring in both protected and unprotected header maps also causes rejection. This document defines the cose-ml-dsa Budget profile using integer-labeled CBOR claims to avoid a drift-prone translation between text claim names and signed bytes. The text names in comments below are descriptive only and are not encoded. For this profile, the Delegation proof is a COSE_Sign1 object carrying the deterministically encoded Budget-Claims map as its payload. A COSE_Sign1 object can be encoded with COSE tag 18 or as the untagged four-element COSE_Sign1 array; Verifiers SHOULD accept both forms and Issuers SHOULD send the tagged form unless a deployment profile says otherwise. The payload element MUST contain the Budget-Claims bstr; detached payloads represented by null are not permitted and MUST be rejected. The protected header map MUST contain the algorithm header parameter. When multiple issuer keys are available, the protected header map MUST contain a kid value identifying the Issuer key. The algorithm and kid header parameters MUST NOT appear in the unprotected header map. The unprotected header map MUST be empty in this profile. A crit protected header parameter, when present, MUST be understood by the Verifier before the proof is accepted. The COSE content type (ctyp) header parameter describes the COSE payload, not the outer HTTP representation. The base Budget profile assigns no media type to the inner Budget-Claims map. A base-profile Issuer therefore MUST omit ctyp, and a base-profile Verifier MUST reject a protected or unprotected ctyp parameter. Only a separately selected and versioned extension profile can define an exact protected ctyp value and its verification rules. Such an extension MUST treat ctyp only as a signed consistency condition and MUST NOT use it to select or change the authority profile. No profile can place the outer application/delegation-proof+cose media type in ctyp merely because that media type carried the COSE_Sign1 object. This profile permits exactly one primary Issuer signature: the signature element of that COSE_Sign1 object. Issuers MUST NOT use COSE_Sign, a COSE countersignature, a signature-bearing Budget-Claims field, a second signature slot, or a trailing signature object in this profile. Verifiers MUST reject each of those constructions rather than ignore an additional signature or reinterpret the proof under another profile. The signature input is the COSE_Sign1 Sig_structure defined by , using context string Signature1, the encoded protected header bstr, an empty external_aad bstr unless a future profile defines another value, and the exact Budget-Claims payload bstr received by the Verifier. Verifiers MUST reject proofs whose payload bstr does not decode to a deterministic Budget-Claims map or whose protected header bstr is not deterministically encoded. uint, ; version 2 => tstr, ; issuer identifier 3 => tstr, ; delegated requester identifier 4 => tstr, ; authorized budget total or limit 5 => tstr, ; remaining budget 6 => tstr, ; currency or metered-unit identifier 7 => [+ tstr], ; permitted rails/actions/classes 8 => uint, ; issued-at ms since Unix epoch 9 => uint, ; expires-at ms since Unix epoch 10 => bstr .size (16..64), ; nonce from the Delegation challenge ? 11 => bstr, ; reserved profile extension slot ? 12 => bstr .size 32, ; reserved digest extension slot 13 => tstr, ; verifier or merchant binding ? 14 => Request-Binding ; signed request binding } Request-Binding = { "method" => tstr, "uri-h" => bstr .size 32, "origin" => tstr, ? "body-h" => bstr .size 32 } Channel-Binding = { "type" => tstr, "value" => bstr } ]]> Fields 4 and 5 carry decimal string values rather than binary floating-point numbers. A Verifier MUST interpret them according to the authority profile's currency or metered-unit policy and MUST reject values it cannot parse unambiguously. A Delegation challenge response using the Budget profile can advertise a minimum budget, unit requirement, or action requirement in its Problem Details body; that response member is an input to client policy and does not become authoritative unless it is reflected in the signed claims. Fields 11 and 12 are reserved extension slots and are optional in Budget-Claims version 1. An Issuer using the base Budget cose-ml-dsa profile MUST omit both fields, and a Verifier of that base profile MUST accept their absence. Their presence is valid only when the already-selected, separately specified profile defines their types, exact byte semantics, verification procedure, failure behavior, and version negotiation. For field 12, such a profile MUST also define the digest algorithm and the exact bytes covered. A Verifier MUST reject a proof containing field 11 or 12 when the selected profile does not define that field, when the Verifier does not explicitly support that profile, or when the field fails the profile-defined validation. It MUST NOT infer extension semantics from a field's length or contents and MUST NOT retry the proof under another profile. Field 12 is not a replacement for field 14, a preflight target-content digest, an independently verified Content-Digest field, or computation of the actual protected-request content digest. No extension profile can obtain those bindings merely by placing an unspecified digest in field 12. Field 14, when present, carries a signed Request-Binding structure. A Budget-Attestation that is intended to authorize only one specific protected request under this profile MUST include field 14 using exactly the construction defined in . Any other type or semantics at label 14 is a mixed-profile encoding and MUST be rejected. When field 14 is absent, the Budget-Attestation is authority for the class of actions and bounds expressed by its other claims; a Verifier can still issue a compact credential bound to one protected request after preflight, but it MUST NOT describe that original Budget-Attestation as issuer-bound to that specific HTTP target. The Channel-Binding structure above is a logical structure for profile extensions. It is not part of the integer-labeled Budget-Claims map unless a future revision assigns a claim label for it. It is included here to define semantics that a companion profile can bind to without changing the core Delegation challenge model.

Request-Binding Canonicalization When a Budget-Attestation is bound to a Protected Target Request, the Issuer and Verifier MUST use the same canonical target-request components:

method is the HTTP method token as received by the origin server. HTTP method tokens are case-sensitive; Verifiers MUST NOT case-normalize this value before comparison.
origin is scheme "://" authority for the effective request URI as reconstructed by the Verifier after applying only trusted origin, gateway, or reverse-proxy configuration. The scheme and host are serialized in lowercase. A default port for the scheme is omitted; a non-default port is included. Verifiers MUST NOT use untrusted Forwarded, X-Forwarded-*, or similar fields when reconstructing the origin.
uri-h is SHA-256 over the UTF-8 serialization of the origin-form target. An empty path is serialized as /. An absent query contributes no ?, while a present but empty query contributes a final ?; otherwise the path is followed by "?" and the query component. Verifiers MUST NOT reorder query parameters, percent-decode and re-encode octets, remove dot segments, or otherwise transform the target before hashing. Verifiers MUST reject target forms they cannot bind deterministically, including CONNECT authority-form and OPTIONS asterisk-form unless a profile explicitly defines those cases.
body-h is SHA-256 over the HTTP request content bytes after transfer-coding removal and before application parsing or content-coding transformation. It is REQUIRED when the protected request has content, including explicitly framed zero-length content, and MUST be omitted when the request has no content.

The Issuer constructs the Request-Binding map from those components, encodes that map as Budget-Claims field 14 before constructing the Budget-Claims payload bstr, and signs that payload through the COSE_Sign1 Sig_structure. No member other than those defined by Request-Binding is permitted in this version. The Verifier independently reconstructs the method, origin, target, and body digest when present and compares them with the signed values. A missing required member, an unknown member, a type mismatch, or any unequal component MUST cause rejection. For direct presentation in Authorization or Delegation-Proof, the Proof Carrier Request and Protected Target Request are the same request, and the Verifier reconstructs Request-Binding from that current request. For preflight, they are distinct: the Verifier reconstructs Request-Binding from the validated Delegation-Target-* fields describing the future Protected Target Request. It MUST NOT compare field 14 to the preflight POST method, preflight URI, or body-carried proof-envelope bytes. A same-request packaging profile MUST define a noncircular extraction and hashing rule as required by before its application content can be used for body-h. If the Verifier cannot reconstruct these components deterministically, it MUST reject the Delegation proof rather than process the request under an ambiguous binding. A future profile extension can bind an attestation to an external channel-binding value such as a TLS exporter using a structure with the semantics of Channel-Binding above. This document defines the channel-binding semantics but does not assign a Budget-Claims label or define mandatory channel-binding types. A Verifier that implements such an extension MUST reject a channel-binding value whose type it does not understand or whose value does not match the locally computed channel-binding value for that type.

Primary Signature Every Budget-Attestation MUST contain exactly one primary Issuer signature. The protected COSE algorithm header MUST use the COSE algorithm identifier registered for the selected ML-DSA algorithm by . The textual alg challenge name identifies that same algorithm; it is not the integer encoded in the protected COSE header. The Delegation authentication scheme is algorithm-agile. The Budget cose-ml-dsa profile defined by this document has the following interoperability requirements:

Implementations of this profile MUST support ML-DSA-65.
Implementations MAY support ML-DSA-87.
Deployments MAY require ML-DSA-87 or another ML-DSA algorithm registered by under local policy. Supporting ML-DSA-65 does not require a Verifier to accept it when the selected deployment policy requires ML-DSA-87.
Verifiers MUST validate that the signed protected-header algorithm matches local policy and MUST reject algorithm downgrades.

Future documents can define additional authority profiles or proof formats using other COSE or JOSE algorithm identifiers without changing the semantics of the Delegation authentication scheme. ML-DSA processing follows , including its empty ctx parameter. The message being signed is the complete COSE Sig_structure. The ML-DSA ctx parameter is distinct from the COSE context string Signature1 and from COSE external_aad. HashML-DSA and nonempty ML-DSA contexts are not defined by the algorithm identifiers used by this profile.

Issuer Key Discovery and Trust A Verifier MUST establish trust in an Issuer public key before accepting a Budget-Attestation signed by that key. Trust can be established through local configuration, an authenticated out-of-band agreement, or an issuer-controlled HTTPS key-set endpoint. A Verifier MUST NOT treat an untrusted issuer identifier in Budget-Claims field 2 or arbitrary key URL in an attestation as sufficient authority to trust a key. One interoperable deployment profile is an issuer-controlled HTTPS key-set URI obtained through authenticated configuration or discovery, for example https://example.com/issuer-keys, returning a COSE_KeySet with media type application/cose-key-set. A Verifier using this profile MUST authenticate the HTTPS origin, MUST require each accepted key to carry a key identifier usable as kid, MUST bind each key to the expected issuer and algorithm policy, and MUST reject the request if the key set is unavailable or omits the referenced key. Cached key material MUST NOT be used beyond its authenticated freshness lifetime. Key rotation SHOULD provide overlap between old and new keys for already-issued attestations. This document does not define a fixed discovery path or register a well-known URI suffix. The trusted configuration or discovery mechanism identifies the issuer origin and key-set URI. The example path has no special protocol meaning. Deployment-specific aliases do not create an interoperable discovery name or authorize trusting a key at an otherwise untrusted origin. Implementation-specific JSON key-set formats MAY be used by deployments during migration, but such formats are not the interoperable key-discovery profile defined by this document unless a future revision specifies their media type, schema, and security processing rules. Deployments that publish JSON transition metadata SHOULD include enough information to map each public key to the corresponding RFC 9964 JOSE or COSE algorithm identifier and MUST NOT publish private AKP priv seed material. COSE key parameters or labels that are not registered for interoperable use are private-use deployment metadata; a key-set that depends on such labels is not an interoperable key-discovery profile unless a companion specification defines those labels and their validation rules.

Future Multi-Signer Profiles This version defines no second signer, rail co-signature, countersignature, or multi-signature encoding. A future specification can define a separately versioned profile using COSE_Sign or a COSE countersignature construction, but that profile has to specify the complete COSE structure, signature inputs, signer roles and trust, algorithms and key identification, cardinality, downgrade and stripping behavior, verification order, media-type signaling, and version negotiation. Private-use or experimental algorithm identifiers and signature containers are outside the Budget cose-ml-dsa profile. They MUST NOT be advertised or accepted as interoperable values for this profile and MUST be isolated behind an explicitly selected private profile and media-type policy.

Verification A Verifier processing a Budget-Attestation MUST:

Select the expected Delegation version, authority profile, proof format, algorithm policy, carriage location, credential kind when applicable, and body-carriage media metadata when applicable, as required by . Reject an unsupported or mixed selection without attempting a fallback decode.
Apply for every carriage location. Decode exactly one COSE_Sign1 value encoded in CBOR from the selected body or field representation and reject non-deterministic, malformed, incomplete, or trailing octets. Reject COSE_Sign, countersignatures, nonempty unprotected headers, signature-bearing claims, additional signature slots, and trailing signature objects.
Verify that Budget-Claims field 1 is supported and matches the selected profile version. Reject unknown or duplicate labels, labels with the wrong type, and any label 14 value other than Request-Binding. Accept absence of fields 11 and 12; when either is present, apply the extension-profile rules above and reject unless the selected profile explicitly defines and the Verifier supports and validates that field.
Verify the one primary signature against an Issuer key authorized for the issuer and kid.
Verify that Budget-Claims field 13 matches an expected verifier or merchant identifier established by authenticated local configuration for the protected resource. Reject a mismatch whether or not field 14 is present; successful request-binding verification does not replace this check.
Parse Budget-Claims fields 4 and 5 under the selected unit policy, verify field 6 identifies the required currency or metered unit, and verify the signed bounds satisfy the protected resource's policy. Reject ambiguous, unparseable, unsupported, or insufficient values.
Verify Budget-Claims fields 8 and 9, clock skew, and maximum lifetime. Both fields are milliseconds since the Unix epoch. Verifiers MUST first reject field 9 values earlier than field 8, without performing an underflowing subtraction, and then MUST reject lifetimes greater than 900000 milliseconds. Verifiers SHOULD apply no more than 60000 milliseconds of clock-skew tolerance unless local policy is stricter. Issuers and Verifiers SHOULD synchronize clocks using an authenticated time source suitable for the deployment.
Verify that Budget-Claims field 10 matches a live challenge and has not been used before.
Verify request binding against the Protected Target Request when the attestation includes Budget-Claims field 14, including method, origin, target URI hash, and body hash when present. For preflight, derive that request only from validated Delegation-Target-* fields, never from the Proof Carrier Request. If field 14 is absent, the Verifier MUST enforce the action, resource-class, and preflight compact-credential binding needed by local policy before processing the protected request.
Verify the permitted rail, action, or resource-class policy expressed by mandatory Budget-Claims field 7.

Failure at any step MUST cause the Verifier to reject the request. A rejected proof MUST NOT expose any decoded claim as verified, MUST NOT result in compact credential issuance, and MUST NOT cause the protected operation or any other authority-bearing effect.

Versioning This document defines version 1 of the Delegation authentication scheme and the initial Budget authority profile. A Delegation challenge response MUST include a Delegation-Version response field containing a Structured Field Integer . A Delegation challenge SHOULD also include a version auth-param when the Verifier supports more than one version or expects clients to use a specific version. When both Delegation-Version and a version auth-param are present in the same challenge response, they MUST identify the same Delegation authentication-scheme version. A client that receives conflicting values MUST treat the challenge as unsupported. A client that receives an unknown Delegation-Version value or version challenge parameter MUST NOT guess at wire compatibility. It MAY retry using a version it supports only when the server advertises that version through local policy or a future version-negotiation mechanism. The Delegation authentication-scheme version is distinct from Budget-Claims field 1, which is the Budget profile/envelope version. A server that receives a Delegation credential or Delegation-Version request value for an unsupported version MUST reject the request using and a version_unsupported reason code, unless a future revision defines a different upgrade response.

IANA Considerations This section follows the guidance in and . The requested registrations use the existing HTTP and media-type registries.

HTTP Status Code This revision does not request a new HTTP status-code registration. The dedicated 4NN Delegated Authority Required design question is tracked in .

HTTP Authentication Scheme IANA is asked to register the following entry in the "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" defined by :

Authentication Scheme Name	Reference	Notes
Delegation	This document,	Origin-server authentication using `WWW-Authenticate` and `Authorization`; not defined for proxy authentication

HTTP Field Name IANA is asked to register the following entry in the "Hypertext Transfer Protocol (HTTP) Field Name Registry":

Field Name	Status	Structured Type	Reference	Comments
Delegation-Version	permanent	Item	This document,	Integer item identifying the Delegation authentication-scheme version
Delegation-Proof	permanent	Item	This document,	Byte Sequence item carrying a Delegation proof when `Authorization` is used by another origin-server scheme
Delegation-Target-Method	permanent	Item	This document,	String item identifying the protected request method for Delegation preflight target binding
Delegation-Target-URI	permanent	Item	This document,	String item identifying the protected request target URI for Delegation preflight target binding
Delegation-Target-Content-Digest	permanent	Dictionary	This document,	Digest Fields dictionary identifying the protected request content digest for Delegation preflight target binding

This revision does not request creation of a Delegation error-token registry. The reason values in are defined for this authentication scheme and its initial Budget authority profile. A future revision can request a registry if multiple independent extensions need a shared token namespace.

Media Type IANA is asked to register the following media type in the "Media Types" registry using the template from :

Type name:: application
Subtype name:: delegation-proof+cose
Required parameters:: N/A
Optional parameters:: cose-type, with the same semantics as the cose-type parameter for application/cose in . Profile selection already restricts this media type to exactly one COSE_Sign1 structure, so the parameter is OPTIONAL for both tagged and untagged forms. When present, its only accepted form in this profile is cose-type="cose-sign1". A value identifying COSE_Sign or another COSE structure is not valid for the Budget cose-ml-dsa profile.
Encoding considerations:: binary
Security considerations:: See .
Interoperability considerations:: Implementations need to support COSE processing, deterministic CBOR, and the algorithm identifiers profiled by this document, and meet the complete-content requirements in .
Published specification:: This document.
Applications that use this media type:: HTTP clients, gateways, and origin servers that exchange Delegation proofs, including Budget-Attestation envelopes under the Budget authority profile.
Fragment identifier considerations:: This media type does not support fragment identifiers.
Additional information:: Deprecated alias names for this type: N/A; Magic number(s): N/A; File extension(s): N/A; Macintosh file type code(s): N/A.
Person & email address to contact for further information:: John McGraw, j.mcgraw@taskhawktech.com
Intended usage:: COMMON
Restrictions on usage:: N/A
Author:: John McGraw
Change controller:: IESG
Provisional registration?: No

Security Considerations Delegation proofs are bearer credentials until verified. HTTP exchanges carrying them MUST use TLS. Servers SHOULD scrub Authorization field values, Delegation-Proof field values, and body-carried Delegation credential values from logs. Deployments that use bearer, DPoP-bound, mutual-TLS-bound, or otherwise sender-constrained credentials for identity or session authentication MUST validate those credentials before treating the requester as authenticated. Sender-constraining an identity or session token does not replace Delegation nonce validation, request binding, Issuer trust, Budget bounds, or Verifier policy. Conversely, a valid Delegation proof does not authorize use of an unrelated OAuth access token, API key, or other execution credential. Verifiers MUST validate every check in before processing the protected request. Missing keys, unavailable verification dependencies, malformed CBOR, non-deterministic CBOR, expired proofs, signature failures, nonce replay, unsupported versions, and loss of nonce state all require request rejection. Profile and version selection is part of that fail-closed boundary. A Verifier MUST NOT infer a profile from a claim's CBOR type, interpret one claim label under multiple schemas, accept a field from an unselected extension, or retry a failed proof under a legacy or private profile. Fields 11 and 12 have no semantics in the base profile and their unexpected presence requires rejection. Label 14 has exactly the signed Request-Binding type and semantics defined by this document; any other interpretation requires rejection. A carriage-location mismatch, body-media mismatch, synthesized field media type, credential-kind fallback, or base-profile ctyp parameter also requires rejection. The COSE or JOSE algorithm identifier is part of the signed protected metadata. Verifiers MUST compare it against configured policy and MUST NOT let a challenge parameter or client preference downgrade the algorithm. The Budget authority profile uses post-quantum digital signatures for delegated-authority proofs. It does not define post-quantum key establishment, confidentiality migration, certificate migration, hybrid key exchange, or a general post-quantum migration protocol. Implementers need to evaluate those surrounding cryptographic migration questions separately; see for engineer-facing discussion of PQC migration impacts. Deployments with long-lived confidentiality or quantum-transition requirements need to make independent TLS and certificate migration decisions under the applicable TLS profiles and deployment policy. This document does not choose or recommend a TLS key-establishment profile. Support for a TLS quantum-transition profile MUST NOT be represented as support for the Budget cose-ml-dsa profile, and support for the Budget profile MUST NOT be represented as post-quantum transport confidentiality. Cryptographic signature verification establishes integrity of the exact signed protected-header and payload bytes and provenance from a key trusted for the selected Issuer and profile. Successful overall Delegation proof verification additionally establishes satisfaction of the checks that the Verifier actually performs. Neither establishes that a signed assertion is factually true or that an external system performed a claimed action. A deployment that relies on external evidence needs a separate, explicitly specified provenance and validation procedure and MUST fail closed when that procedure is unavailable or fails. This profile has exactly one signature. Additional signers, countersignatures, and private-use signature slots are not additive inputs to this profile; their presence makes the proof invalid under this version. At-most-once credential acceptance does not guarantee exactly-once completion of protected processing. A failure can occur after replay state is consumed but before an operation completes, or after an operation completes but before its response is delivered. Application transaction, idempotency, and recovery semantics remain separate from this authentication scheme. An uncertain outcome does not permit reuse of a credential that the replay rules require to be single-use. Key lifecycle is security-critical. Issuers SHOULD rotate signing keys on a predictable schedule, publish revocation information through the same trust channel used for key distribution, and avoid issuing attestations whose lifetime extends beyond the authenticated lifetime of the signing key. Verifiers MUST reject attestations signed by revoked, expired, or unexpected keys. Large post-quantum signatures can create denial-of-service pressure on HTTP parsers, HTTP field-section processing, and COSE libraries. ML-DSA-backed COSE envelopes are commonly too large to assume safe carriage through general-purpose HTTP fields after base64url expansion. This is consistent with the protocol-redesign and constrained-network concerns discussed in . Implementations MUST apply size limits before decoding, MUST bound CBOR nesting depth and map sizes, and MUST reject duplicate keys and unsupported critical protected parameters before expensive signature verification. Verifiers that fetch issuer key sets or discovery metadata MUST bound response sizes, redirect behavior, parsing depth, and cache lifetimes. They MUST NOT fetch arbitrary key URLs supplied inside an untrusted proof. Verifier nonce state can itself become a resource-exhaustion target. Verifiers MUST bound the number of outstanding nonces per issuer, protection space, and client identity signal available to the deployment, and MUST expire unused nonces no later than their challenge max-age. When nonce state reaches a configured limit, the Verifier MUST reject requests that depend on an untracked nonce or shed unauthenticated challenge issuance rather than accept a request with an untracked nonce. At high scale, deployments SHOULD use self-authenticating nonces as described in so challenge issuance does not require allocating distributed state for every unauthenticated request. Such constructions reduce outstanding-challenge state but do not remove the need for bounded accepted-nonce replay tracking when at-most-once acceptance is required. The Budget authority profile describes channel-binding extension semantics for deployments that need binding to a particular TLS session or exporter value. Specific channel-binding types are not mandatory-to-implement in this revision and need profiling before they can be assumed interoperable. In the absence of channel binding, short lifetimes, single-use nonces, request binding, and replay-cache enforcement are mandatory replay controls.

Privacy Considerations These considerations are informed by the privacy guidance in . Delegation proofs can reveal delegated requester identifiers, principal or issuer identifiers, requested actions, authority bounds, rail preferences, and amount limits. Implementations SHOULD use short lifetimes, random nonces, data minimization in requester identifiers, and body carriage when field logging by intermediaries would create avoidable privacy risk. Issuer and requester identifiers SHOULD be pairwise or otherwise scoped when a stable global identifier is not required by deployment policy. Challenge responses SHOULD reveal only the authority requirements needed for the client to obtain an acceptable proof. Public reason tokens and detailed Problem Details bodies can become policy or issuer-enumeration oracles; deployments SHOULD rate-limit unauthenticated challenge traffic and avoid returning unnecessary detail to untrusted clients. Logs SHOULD redact Authorization, Delegation-Proof, body-carried proof bytes, compact credentials, and preflight target URIs or content digests when those values could reveal sensitive resources or actions.

References Normative References The Base16, Base32, and Base64 Data Encodings Guidelines for Writing an IANA Considerations Section in RFCs 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. Media Type Specifications and Registration Procedures 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. Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures 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. Concise Binary Object Representation (CBOR) 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. CBOR Object Signing and Encryption (COSE): Structures and Process 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. HTTP Semantics 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. HTTP Caching 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. Building Protocols with HTTP 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. Digest Fields This document defines HTTP fields that support integrity digests. The Content-Digest field can be used for the integrity of HTTP message content. The Repr-Digest field can be used for the integrity of HTTP representations. Want-Content-Digest and Want-Repr-Digest can be used to indicate a sender's interest and preferences for receiving the respective Integrity fields. This document obsoletes RFC 3230 and the Digest and Want-Digest HTTP fields. Problem Details for HTTP APIs 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. Structured Field Values for HTTP 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. ML-DSA for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) This document specifies JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for the Module-Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in US NIST FIPS 204. Module-Lattice-Based Digital Signature Standard National Institute of Standards and Technology (NIST) Key words for use in RFCs to Indicate Requirement Levels 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. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words 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. Informative References Privacy Considerations for Internet Protocols 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. Improving Awareness of Running Code: The Implementation Status Section 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. An Internet Attribute Certificate Profile for Authorization This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPsec, and WWW security applications. This document obsoletes RFC 3281. [STANDARDS-TRACK] OAuth 2.0 Token Exchange This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. OAuth 2.0 Demonstrating Proof of Possession (DPoP) 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. HTTP Message Signatures 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. Grant Negotiation and Authorization Protocol (GNAP) The Grant Negotiation and Authorization Protocol (GNAP) defines a mechanism for delegating authorization to a piece of software and conveying the results and artifacts of that delegation to the software. This delegation can include access to a set of APIs as well as subject information passed directly to the software. Post-Quantum Cryptography for Engineers The advent of a cryptographically relevant quantum computer (CRQC) would render state-of-the-art, traditional public key algorithms deployed today obsolete, as the mathematical assumptions underpinning their security would no longer hold. To address this, protocols and infrastructure must transition to post-quantum algorithms, which are designed to resist both traditional and quantum attacks. This document explains why engineers need to be aware of and understand post-quantum cryptography (PQC), and it details the impact of CRQCs on existing systems and the challenges involved in transitioning to post-quantum algorithms. Unlike previous cryptographic updates, this shift may require significant protocol redesign due to the unique properties of post-quantum algorithms. RateLimit header fields for HTTP Team Digitale, Italian Government Red Hat Microsoft This document defines the RateLimit-Policy and RateLimit HTTP header fields for servers to advertise their quota policies and the current service limits, thereby allowing clients to avoid being throttled. x402: An Open Standard for Internet-Native Payments Coinbase, Inc. L402 Protocol Specification Lightning Labs

Implementation Status This appendix follows and is to be removed before publication as an RFC.

Kevros Organization: TaskHawk Systems LLC. Contact: j.mcgraw@taskhawktech.com. Maturity and coverage: Experimental implementation experience with earlier revisions informed this document. It includes delegated-authority challenge, proof-carriage, and verification work. Deployment-specific formats are not asserted to be wire-compatible with the Budget profile defined here. Conformance and interoperability: This report does not claim a complete implementation of this revision or interoperability with an independent implementation. In particular, it makes no implementation claim for the complete-message, segmentation-independence, optional-extension, profile-first dispatch, and Request-Binding requirements added or clarified here. Local authoring checks and fixed test cases do not establish those runtime properties. This implementation report is included for review under . It does not assert deployment readiness, verified live use, settlement, revenue, or IETF Working Group adoption.

Changes Since -03

Limited the recommended Problem Details response to the application/problem+json format defined by RFC 9457.
Made verifier or merchant identifier validation unconditional, independently of the optional signed request binding.
Required authenticated and authorized preflight destinations, including explicit cross-origin authorization and validation before redirecting a proof-bearing request.
Clarified compact-credential acceptance against current policy and Issuer-key status, and distinguished mandatory nonce binding from optional explicit nonce representation in the compact credential.
Clarified the single-signature ML-DSA algorithm boundary, the distinction between textual challenge names and COSE identifiers, and RFC 9964's empty ML-DSA context requirement.
Clarified direct field-carried proof binding without requiring a body packaging profile when the proof is outside application content.
Left the issuer key-set URI to authenticated configuration or discovery, without defining an unregistered well-known URI suffix.
Distinguished at-most-once credential acceptance from exactly-once application completion and reduced the implementation report to relevant interoperability and maturity information.
Required body-carried Delegation proof processing to be independent of HTTP framing and implementation read boundaries, without defining a proof chunk format or chunk size, and extended the complete-message gate to field carriage.
Required a complete Proof Carrier Request and, for the Budget profile, exactly one permitted COSE_Sign1 value before proof acceptance, compact-credential issuance, or protected processing, with fail-closed handling of decoding failure and trailing octets.
Required cumulative bounds for coded request content and decoded proof octets, fail-closed counter-overflow handling, and recommended 413 (Content Too Large) when a configured bound is exceeded; scoped field limits to the serialized HTTP field value rather than decoded COSE size.
Scoped COSE signature verification to the exact protected-header and payload bstr values used by Sig_structure, prohibited detached payloads, and required duplicate-key detection before native-map collapse.
Required Verifiers to compute Content-Digest over complete protected-request content, require exact agreement with preflight and Request-Binding digests, and wait for validation of a trailer-carried digest before protected processing.
Limited the Budget cose-ml-dsa profile to exactly one COSE_Sign1 Issuer signature and deferred multi-signer, countersignature, and rail co-signature constructions to a separately versioned future profile.
Made claim labels 11 and 12 optional reserved extension slots. Their absence is valid in the base profile; their presence fails closed unless an explicitly selected and supported profile defines and verifies them.
Required scheme/profile/proof-format/algorithm/carriage selection, conditional body-media selection, credential-kind selection, and nonce binding before claim-label interpretation; prohibited trial decoding and mixed-profile or full-proof/compact-token fallback; and fixed label 14 to the single Request-Binding construction defined by this document.
Defined the exact canonical base64url-without-padding conversion between the Delegation challenge nonce and the 16-to-64-octet Budget-Claims field 10 bstr.
Required base-profile omission and rejection of COSE ctyp; only a separately selected and versioned extension can define an exact protected value.
Clarified that signature verification establishes exact-byte integrity and trusted-key provenance, while overall proof success additionally establishes only the checks actually performed; neither establishes factual truth, external-hardware validity, model correctness, or theorem discharge.
Corrected the Budget-Claims lifetime check to use the millisecond units of fields 8 and 9, reject expiration before issuance without underflow, and cap the lifetime at 900000 milliseconds.
Made verification of mandatory field 7 unconditional and specified the exact optional media-type parameter form cose-type="cose-sign1".
Defined empty-path and absent-versus-empty-query Request-Binding behavior, required body-h exactly when request content is present, and prohibited any verified-claim, credential, or protected effect after rejection.
Distinguished the Proof Carrier Request from the Protected Target Request so preflight Request-Binding covers the designated future application request, never the preflight POST or body-carried proof bytes.
Corrected the RFC 7942 implementation appendix to distinguish private legacy envelopes from this interoperable profile and remove equivalence claims.

Changes Since -02

Made the large-proof preflight flow mandatory to implement for the Budget cose-ml-dsa profile.
Specified that the Budget cose-ml-dsa profile MUST NOT rely on GET or HEAD request content for Delegation proof carriage.
Defined preflight as the baseline interoperability fallback for large post-quantum proofs and for operations that also carry an application representation body.
Left same-request multipart/related or profile-specific envelopes as optional packaging profiles rather than the baseline interoperability path.
Clarified that a successful preflight returns a compact Delegation credential bound to method, origin, target URI, nonce, expiry, and representation digest, while leaving other proof-reference artifacts to future profiles.
Defined the Delegation-Target-Method, Delegation-Target-URI, and Delegation-Target-Content-Digest fields used by the Budget cose-ml-dsa preflight flow.
Clarified that those target-binding fields align with HTTP Message Signatures derived-component semantics and HTTP Digest Fields rather than replacing message-level signatures.
Defined the Budget cose-ml-dsa compact credential response shape, including credential_type, opaque credential, authorization convenience value, expires_in, and target, while keeping settlement and revenue semantics out of the preflight response.
Clarified that compact credentials need verifier-portable validation within the protection space and cannot depend on node-local preflight state.
Added an optional signed Request-Binding claim for request-specific Budget attestations and clarified the difference between issuer-bound request authority and verifier-bound compact credentials issued after preflight.
Tightened origin-authorized verifier scope, target URI reconstruction, cache behavior for Delegation-Proof, preflight URI challenge carriage, IANA field registration metadata, and security/privacy considerations based on HTTP-focused review.
Clarified that the combined HTTP mechanism plus Budget profile is current implementation-experience packaging and can be split into companion drafts for Working Group processing.
Added as an informative reference for post-quantum migration and large-signature protocol-design considerations.
Clarified that the Budget authority profile uses PQC signatures for delegated-authority proofs but does not define PQC key establishment, confidentiality migration, certificate migration, hybrid key exchange, or a general PQC migration protocol.
Added DPoP/sender-constrained-token composability text, including the Authorization field composition boundary when Authorization: DPoP and Delegation are both required.
Added a neutral transport-security migration note for TLS and certificate migration, while keeping TLS key establishment separate from the Budget cose-ml-dsa proof profile.
Clarified private-use authority-profile identifiers and their relationship to the interoperable budget profile identifier.
Updated issuer-key discovery guidance and retained authenticated origin, key identity, algorithm policy, and freshness requirements; this revision leaves the concrete key-set URI to authenticated configuration or discovery.
Tightened Kevros implementation-status text to distinguish published draft-02 metadata, local draft-03 preview behavior, operational enforcement health fields, proof verification, rail observation, settlement, and revenue.

Changes Since -01

Refactored the core mechanism from Budget-specific language to the Delegation HTTP authentication scheme for request-bound delegated authority.
Made Budget the initial authority profile rather than the protocol boundary.
Replaced core Budget challenge examples with WWW-Authenticate: Delegation, Delegation-Version, Delegation-Proof, and authority_requirements.
Made 401 and 403 with WWW-Authenticate: Delegation and Problem Details the baseline response model for delegated-authority challenges.
Moved the dedicated status-code question to 4NN Delegated Authority Required instead of requesting status-code registration in this revision.
Tightened the alg challenge parameter to one algorithm per challenge.
Kept the COSE/CBOR Budget-Attestation profile separable from the core HTTP authentication and Problem Details semantics.
Replaced explanatory text-claim CDDL with the integer-labeled Budget claims map used by the initial cose-ml-dsa Budget profile.
Added request-binding canonicalization rules and called out the packaging question for large proof bodies plus application request bodies.
Clarified that JSON issuer-key discovery formats are transition metadata, not the interoperable COSE_KeySet profile.

Changes Since -00

Removed language implying HTTP 402 semantics are controlled by deployed payment protocols.
Added and .
Updated ML-DSA serialization references to and changed the initial cose-ml-dsa interoperability baseline to ML-DSA-65, with ML-DSA-87 available as a high-assurance deployment policy option.
Made body carriage mandatory to implement for the cose-ml-dsa profile and recommended by default for post-quantum Budget-Attestation envelopes.
Kept Authorization: Delegation and Delegation-Proof as explicitly bounded field-carriage options for deployment profiles that define accepted field sizes and failure behavior.
Added nonce replay, key-distribution, IANA, deterministic-CBOR, and expanded security text based on review feedback.
Aligned the attestation lifetime rule with implementation behavior: after rejecting exp < iat, an exp - iat interval greater than 900000 milliseconds is a verifier rejection condition.
Tightened Implementation Status to separate challenge emission, Budget-Attestation verification, rail observation, settlement, and revenue.