HTTPAPI J. McGraw Internet-Draft TaskHawk Intended status: Standards Track 15 June 2026 Expires: 17 December 2026 The Delegation HTTP Authentication Scheme for Request-Bound Authority draft-mcgraw-httpapi-agent-budget-02 Abstract 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. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-mcgraw-httpapi-agent-budget/. Discussion of this document takes place on the HTTPAPI Working Group mailing list (mailto:httpapi@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/httpapi/. Subscribe at https://www.ietf.org/mailman/listinfo/httpapi/. McGraw Expires 17 December 2026 [Page 1] Internet-Draft Delegation June 2026 Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 17 December 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 5 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Relationship to OAuth, GNAP, and Token Exchange . . . . . 7 1.4. Relationship to Attribute Certificates . . . . . . . . . 7 1.5. Relationship to RateLimit Fields . . . . . . . . . . . . 7 1.6. Relationship to HTTP Message Signatures . . . . . . . . . 9 1.7. Relationship to HTTP 402 . . . . . . . . . . . . . . . . 9 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 9 3. Delegation Challenge Responses . . . . . . . . . . . . . . . 11 3.1. Dedicated Status Code Design Question . . . . . . . . . . 12 3.2. Delegation Error Tokens . . . . . . . . . . . . . . . . . 12 4. The "Delegation" Authentication Scheme . . . . . . . . . . . 13 4.1. Challenge Syntax . . . . . . . . . . . . . . . . . . . . 13 4.2. Credentials Syntax . . . . . . . . . . . . . . . . . . . 14 McGraw Expires 17 December 2026 [Page 2] Internet-Draft Delegation June 2026 4.3. Multi-Scheme Composition and the Delegation-Proof Field . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Budget Authority Profile: Budget-Attestation Envelope . . . . 16 5.1. Request-Binding Canonicalization . . . . . . . . . . . . 18 5.2. Primary Signature . . . . . . . . . . . . . . . . . . . . 19 5.3. Issuer Key Discovery and Trust . . . . . . . . . . . . . 19 5.4. Optional Rail-Keyed Signature . . . . . . . . . . . . . . 20 5.5. Verification . . . . . . . . . . . . . . . . . . . . . . 20 6. Versioning . . . . . . . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7.1. HTTP Status Code . . . . . . . . . . . . . . . . . . . . 21 7.2. HTTP Authentication Scheme . . . . . . . . . . . . . . . 21 7.3. HTTP Field Name . . . . . . . . . . . . . . . . . . . . . 22 7.4. Delegation Error Token Registry . . . . . . . . . . . . . 22 7.5. Media Type . . . . . . . . . . . . . . . . . . . . . . . 23 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 11.1. Normative References . . . . . . . . . . . . . . . . . . 26 11.2. Informative References . . . . . . . . . . . . . . . . . 27 Appendix A. Implementation Status . . . . . . . . . . . . . . . 29 A.1. Kevros . . . . . . . . . . . . . . . . . . . . . . . . . 29 Appendix B. Changes Since -01 . . . . . . . . . . . . . . . . . 29 Appendix C. Changes Since -00 . . . . . . . . . . . . . . . . . 30 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31 1. 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 [RFC9110] addresses whether a requester holds a usable credential. RateLimit fields [I-D.ietf-httpapi-ratelimit-headers] communicate server-defined quota policies and current service-limit information. HTTP Message Signatures [RFC9421] can provide integrity and authenticity for selected HTTP message components. OAuth Token Exchange [RFC8693] and GNAP [RFC9635] 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. McGraw Expires 17 December 2026 [Page 3] Internet-Draft Delegation June 2026 This document defines: * The "Delegation" HTTP authentication scheme (Section 4), 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 (Section 3), 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 (Section 4.3), 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 (Section 5), a CBOR-encoded [RFC8949], COSE-signed [RFC9052] structure that carries semantic claims about issuer, requester, expiry, request binding, permitted rails, and amount. 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 [RFC9964], using the ML-DSA algorithm specified in [FIPS204]. Implementations of this profile MUST support ML-DSA-65 and MAY support ML-DSA-87. A deployment MAY require ML- DSA-87 or another registered algorithm by local policy. A deployment MAY add an optional rail-keyed signature using SLH-DSA, aligned with the JOSE and COSE SLH-DSA work in [I-D.ietf-cose-sphincs-plus] and the SLH-DSA algorithm specified in [FIPS205]. That optional signature is not a replacement for the primary signature. This document does not define a payment protocol. Settlement rails such as L402 [L402], x402 [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 McGraw Expires 17 December 2026 [Page 4] Internet-Draft Delegation June 2026 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. 1.1. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 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, gateway, or intermediary that receives a Delegation proof, validates its signatures and claims, and decides whether to perform protected processing for the bearing request. 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. 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 Section 5 McGraw Expires 17 December 2026 [Page 5] Internet-Draft Delegation June 2026 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 Section 5. 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. Rail-Keyed Signature: An optional additional signature over the Budget-Attestation envelope, intended to bind a deployment's rail- specific policy to the same claims that the primary Issuer signature covers. 1.2. 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. McGraw Expires 17 December 2026 [Page 6] Internet-Draft Delegation June 2026 1.3. Relationship to OAuth, GNAP, and Token Exchange OAuth Token Exchange [RFC8693] defines an HTTP- and JSON-based Security Token Service pattern for obtaining security tokens, including delegation and impersonation cases. GNAP [RFC9635] 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. 1.4. Relationship to Attribute Certificates X.509 attribute certificates define an older authorization mechanism separate from public-key identity certificates; [RFC5755] 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. 1.5. 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. McGraw Expires 17 December 2026 [Page 7] Internet-Draft Delegation June 2026 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 | Prove bounded | | | current service limits | delegated authority | +-----------+----------------------------+----------------------+ | Failure | Client might be throttled | Request fails before | | mode | | protected processing | +-----------+----------------------------+----------------------+ Table 1 McGraw Expires 17 December 2026 [Page 8] Internet-Draft Delegation June 2026 1.6. Relationship to HTTP Message Signatures [RFC9421] 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. 1.7. Relationship to HTTP 402 HTTP 402 (Payment Required) is reserved by HTTP Semantics [RFC9110]. 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. 2. Overview of Operation A protected origin determines that a request requires delegated authority and that no acceptable Delegation credential is present: POST /datasets/regulated/export HTTP/1.1 Host: api.example It returns: McGraw Expires 17 December 2026 [Page 9] Internet-Draft Delegation June 2026 HTTP/1.1 401 Unauthorized Date: Tue, 02 Jun 2026 18:00:00 GMT Cache-Control: no-store Content-Type: application/problem+json Delegation-Version: 1 WWW-Authenticate: Delegation realm="api.example", version=1, profile="budget", proof-format="cose-ml-dsa", alg="ML-DSA-65", nonce="QMjVqg5Xb6yV0bO_t9X8gQ", max-age=300 { "type": "https://example.com/problems/delegation-required", "title": "Delegated authority proof required", "status": 401, "detail": "A valid Delegation proof is required.", "authority_requirements": { "profile": "budget", "proof_formats": ["cose-ml-dsa"], "actions": ["dataset:export"], "min_amount": "2.50", "currency": "USD", "proof_required": true, "verifier_required": true, "nonce": "QMjVqg5Xb6yV0bO_t9X8gQ", "delegation_version": "1", "max_age": 300 } } The Delegated Requester obtains a Delegation proof from its Issuer by means outside this document and retries using body carriage. In this example the proof uses the Budget authority profile: POST /datasets/regulated/export HTTP/1.1 Host: api.example Content-Type: application/delegation-proof+cose Content-Length: 4217 [COSE_Sign1 Budget-Attestation bytes] If the attestation is valid for the request and local policy, the Verifier performs protected processing. If Delegation validation fails, the Verifier returns either a 401 or 403 response as described in Section 3 and SHOULD include a reason extension member in the Problem Details body. McGraw Expires 17 December 2026 [Page 10] Internet-Draft Delegation June 2026 3. 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 [RFC9110]: 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 [RFC9111]. 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 or application/problem+cbor body using [RFC9457]. 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. 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. McGraw Expires 17 December 2026 [Page 11] Internet-Draft Delegation June 2026 3.1. 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. Implementations that experiment with an unregistered 4xx status code MUST also support the 401/403 behavior defined in Section 3 for interoperability. 3.2. 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 signature or a required rail-keyed 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. McGraw Expires 17 December 2026 [Page 12] Internet-Draft Delegation June 2026 * 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. 4. The "Delegation" Authentication Scheme The Delegation authentication scheme is used in WWW-Authenticate and Authorization fields. 4.1. Challenge Syntax The Delegation authentication scheme challenge uses the auth-param syntax defined by [RFC9110], Section 11.2: delegation-challenge = "Delegation" 1*SP 1#auth-param 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 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. McGraw Expires 17 December 2026 [Page 13] Internet-Draft Delegation June 2026 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. 4.2. Credentials Syntax delegation-credentials = "Delegation" 1*SP delegation-token delegation-token = token68 The credential token carries a base64url-encoded Delegation proof. If the encoded proof would exceed practical HTTP field size limits, the requester MUST send the proof in a request body with media type application/delegation-proof+cose or a profile-defined media type. The Budget cose-ml-dsa profile MUST support request-body carriage. Requesters using that profile SHOULD use body carriage by default because ML-DSA-backed COSE envelopes are large before base64url expansion and can exceed field-size limits enforced by intermediaries. 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. A deployment MAY bind the body-carried proof to the request using Budget-Claims field 12 or a profile-defined request-binding structure. 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. A deployment profile that needs both a large Delegation proof and an application representation in the same protected operation MUST define one of the following before claiming interoperability: McGraw Expires 17 December 2026 [Page 14] Internet-Draft Delegation June 2026 * a field-carried proof path with explicit field-size limits and failure behavior; * a media type that packages the proof and the application representation together, for example a multipart/related or profile-specific envelope; or * a preflight or two-request flow in which the proof authorizes a subsequent request bound by nonce, target, and representation digest. In all cases, the Budget profile's request-binding rules in Section 5.1 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. 4.3. 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 [RFC9651] whose bare item is a Byte Sequence containing a COSE/CBOR Delegation proof. Delegation-Proof: :2BhA...base64-cose...kQ: 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 uses Authorization, delegated authority SHOULD be carried in the request body for the cose-ml-dsa profile or, for bounded low-footprint deployments, in the Delegation-Proof field. McGraw Expires 17 December 2026 [Page 15] Internet-Draft Delegation June 2026 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 Section 3. The Delegation-Proof field is not the general-purpose carriage path for multi-kilobyte post-quantum attestations. Implementations of the cose-ml-dsa profile MUST support body carriage with media type application/delegation-proof+cose or a profile-defined media type. A deployment profile MAY permit Delegation-Proof field carriage only when it defines accepted field-size limits and failure behavior. If the target request also needs an unrelated representation body, that packaging profile MUST define how the Delegation proof and application representation are bound to each other. 5. Budget Authority Profile: Budget-Attestation Envelope The Budget authority profile defines a Budget-Attestation envelope as a COSE object [RFC9052] carrying a CBOR claims set. The claims set is encoded using deterministic CBOR [RFC8949]. The notation below uses CDDL [RFC8610]. Encoders MUST follow the core deterministic encoding requirements of [RFC8949], Section 4.2.1. Verifiers MUST reject non-deterministic encodings and MUST verify signatures over the exact received deterministic encoding, not over a locally reserialized variant. 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. McGraw Expires 17 December 2026 [Page 16] Internet-Draft Delegation June 2026 Budget-Claims = { 1 => 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, ; authorization chain or caveat proof 12 => bstr .size 32, ; representation/envelope/body digest 13 => tstr ; verifier or merchant 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. Field 11 is a profile-defined authorization chain or caveat proof. Deployments MUST specify the syntax and verification rules for this field before using it for interoperability. Field 12 is a SHA-256 digest slot used by deployments to bind an application representation, envelope, or body-digest object. A Verifier MUST NOT infer that field 12 protects an application body unless the deployment profile specifies exactly what bytes were hashed. The Request-Binding and Channel-Binding structures above are logical structures for profile extensions. They are not part of the integer- labeled Budget-Claims map unless a future revision assigns claim McGraw Expires 17 December 2026 [Page 17] Internet-Draft Delegation June 2026 labels for them. They are included here to define the semantics that field 12 or a companion profile can bind to without changing the core Delegation challenge model. 5.1. Request-Binding Canonicalization When a Budget-Attestation is bound to a bearing HTTP request, the Issuer and Verifier MUST use the same canonical 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 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. * uri-h is SHA-256 over the UTF-8 serialization of the origin-form target: the path-abempty component followed by "?" and the query component when a query is present. Verifiers MUST NOT reorder query parameters, percent-decode and re-encode octets, remove dot segments, or otherwise transform the target before hashing. * body-h, when used, is SHA-256 over the HTTP request content bytes after transfer-coding removal and before application parsing or content-coding transformation. If a request has no content, body-h SHOULD be omitted; if it is present, it MUST be the SHA-256 digest of the empty octet string. 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. McGraw Expires 17 December 2026 [Page 18] Internet-Draft Delegation June 2026 5.2. Primary Signature Every Budget-Attestation MUST contain exactly one primary Issuer signature. The primary signature MUST use an ML-DSA algorithm identifier registered for JOSE or COSE by [RFC9964]. 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 registered algorithm by local policy. * 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. 5.3. 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, for example https://example.com/.well-known/budget- 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. McGraw Expires 17 December 2026 [Page 19] Internet-Draft Delegation June 2026 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. 5.4. Optional Rail-Keyed Signature A Budget-Attestation MAY contain an additional rail-keyed signature. A rail-keyed signature MUST NOT replace the primary Issuer signature and MUST NOT be accepted when the primary signature fails. When a deployment uses SLH-DSA for rail-keyed signatures, it SHOULD use the JOSE or COSE serializations defined by [I-D.ietf-cose-sphincs-plus] once those registrations are available. Until then, private-use algorithm identifiers MUST be treated as deployment-specific and MUST NOT be advertised as interoperable. Because SLH-DSA signatures can be tens of kilobytes, an attestation that contains a rail-keyed SLH-DSA signature MUST be carried in a request body using application/delegation-proof+cose or a profile- defined media type rather than in an HTTP field. 5.5. Verification A Verifier processing a Budget-Attestation MUST: 1. Decode the CBOR envelope and reject non-deterministic or malformed encodings. 2. Verify that Budget-Claims field 1 is supported. 3. Verify the primary signature against an Issuer key authorized for the issuer and kid. 4. Verify Budget-Claims fields 8 and 9, clock skew, and maximum lifetime. Verifiers MUST reject attestations where field 9 minus field 8 exceeds 900 seconds and SHOULD apply no more than 60 seconds of clock-skew tolerance unless local policy is stricter. Issuers and Verifiers SHOULD synchronize clocks using an authenticated time source suitable for the deployment. 5. Verify that Budget-Claims field 10 matches a live challenge and has not been used before. McGraw Expires 17 December 2026 [Page 20] Internet-Draft Delegation June 2026 6. Verify request binding against the bearing request, including method, origin, target URI hash, and body hash when present. 7. Verify rail, action, or resource-class policy when Budget-Claims field 7 is present. 8. Verify any rail-keyed signature required by local policy. Failure at any step MUST cause the Verifier to reject the request. 6. 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 [RFC9651]. 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. 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. A server that receives a Delegation credential or Delegation-Version request value for an unsupported version MUST reject the request using Section 3 and a version_unsupported reason code, unless a future revision defines a different upgrade response. 7. IANA Considerations This section follows the guidance in [RFC8126] and [RFC9205]. The requested registrations use the existing HTTP and media-type registries. 7.1. 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 Section 3.1. 7.2. HTTP Authentication Scheme IANA is asked to register the following entry in the "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" defined by [RFC9110]: McGraw Expires 17 December 2026 [Page 21] Internet-Draft Delegation June 2026 +================+===========+======================================+ | Authentication | Reference | Notes | | Scheme Name | | | +================+===========+======================================+ | Delegation | This | Origin-server authentication | | | document, | using WWW-Authenticate and | | | Section 4 | Authorization; not defined | | | | for proxy authentication | +----------------+-----------+--------------------------------------+ Table 2 7.3. HTTP Field Name IANA is asked to register the following entry in the "Hypertext Transfer Protocol (HTTP) Field Name Registry": +==================+=========+==========+=========+=================+ |Field Name |Status |Structured|Reference| Comments | | | |Type | | | +==================+=========+==========+=========+=================+ |Delegation-Version|permanent|Integer |This | Version of the | | | | |document,| Delegation | | | | |Section 6| authentication | | | | | | scheme and | | | | | | authority-proof | | | | | | profile | +------------------+---------+----------+---------+-----------------+ |Delegation-Proof |permanent|Byte |This | Additive | | | |Sequence |document,| carriage of a | | | | |Section | Delegation | | | | |4.3 | proof when | | | | | | Authorization | | | | | | is used by | | | | | | another origin- | | | | | | server scheme | +------------------+---------+----------+---------+-----------------+ Table 3 7.4. Delegation Error Token Registry IANA is asked to create a "Delegation Error Tokens" registry for tokens used in the Problem Details reason extension member defined by Section 3.2. The registration policy is Specification Required [RFC8126]. Initial registrations are: McGraw Expires 17 December 2026 [Page 22] Internet-Draft Delegation June 2026 +========================+============================+===========+ | Token | Description | Reference | +========================+============================+===========+ | token_expired | The proof expired. | Section | | | | 3.2 | +------------------------+----------------------------+-----------+ | nonce_stale | The nonce is outside the | Section | | | accepted challenge window. | 3.2 | +------------------------+----------------------------+-----------+ | nonce_replay | The nonce was already | Section | | | accepted in the replay- | 3.2 | | | tracking window. | | +------------------------+----------------------------+-----------+ | bad_signature | A required signature | Section | | | failed validation. | 3.2 | +------------------------+----------------------------+-----------+ | untrusted_issuer | The issuer is not trusted | Section | | | by the Verifier. | 3.2 | +------------------------+----------------------------+-----------+ | authority_insufficient | The signed authority | Section | | | bounds do not satisfy the | 3.2 | | | resource requirement. | | +------------------------+----------------------------+-----------+ | budget_insufficient | The signed budget bounds | Section | | | do not satisfy the Budget | 3.2 | | | profile requirement. | | +------------------------+----------------------------+-----------+ | version_unsupported | The protocol or proof | Section | | | version is unsupported. | 3.2 | +------------------------+----------------------------+-----------+ | binding_mismatch | The signed request binding | Section | | | does not match the bearing | 3.2 | | | request. | | +------------------------+----------------------------+-----------+ Table 4 7.5. Media Type IANA is asked to register the following media type in the "Media Types" registry using the template from [RFC6838]: Type name: application Subtype name: delegation-proof+cose Required parameters: N/A McGraw Expires 17 December 2026 [Page 23] Internet-Draft Delegation June 2026 Optional parameters: cose-type, with the same semantics as the cose- type parameter for application/cose in [RFC9052]. Encoding considerations: binary Security considerations: See Section 8. Interoperability considerations: Implementations need to support COSE processing, deterministic CBOR, and the algorithm identifiers profiled by this document. 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 8. 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. McGraw Expires 17 December 2026 [Page 24] Internet-Draft Delegation June 2026 Verifiers MUST validate every check in Section 5 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. 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. Rail-keyed signatures are additive. They do not create authority without a valid primary Issuer signature. 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. Implementations MUST apply size limits before decoding, MUST bound CBOR nesting depth and map sizes, and SHOULD reject duplicate or unknown critical protected parameters before expensive signature verification. 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 Section 4 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 McGraw Expires 17 December 2026 [Page 25] Internet-Draft Delegation June 2026 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. 9. Privacy Considerations These considerations are informed by the privacy guidance in [RFC6973]. 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. 10. References 11. References 11.1. Normative References [FIPS204] National Institute of Standards and Technology (NIST), "Module-Lattice-Based Digital Signature Standard", FIPS PUB 204, DOI 10.6028/NIST.FIPS.204, August 2024, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . McGraw Expires 17 December 2026 [Page 26] Internet-Draft Delegation June 2026 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Caching", STD 98, RFC 9111, DOI 10.17487/RFC9111, June 2022, . [RFC9205] Nottingham, M., "Building Protocols with HTTP", BCP 56, RFC 9205, DOI 10.17487/RFC9205, June 2022, . [RFC9457] Nottingham, M., Wilde, E., and S. Dalal, "Problem Details for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023, . [RFC9651] Nottingham, M. and P. Kamp, "Structured Field Values for HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024, . [RFC9964] Prorock, M. and O. Steele, "ML-DSA for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE)", RFC 9964, DOI 10.17487/RFC9964, May 2026, . 11.2. Informative References McGraw Expires 17 December 2026 [Page 27] Internet-Draft Delegation June 2026 [FIPS205] National Institute of Standards and Technology (NIST), "Stateless Hash-Based Digital Signature Standard", FIPS PUB 205, DOI 10.6028/NIST.FIPS.205, August 2024, . [I-D.ietf-cose-sphincs-plus] Prorock, M., Steele, O., and H. Tschofenig, "SLH-DSA for JOSE and COSE", Work in Progress, Internet-Draft, draft- ietf-cose-sphincs-plus-08, 15 May 2026, . [I-D.ietf-httpapi-ratelimit-headers] Polli, R., Ruiz, A. M., and D. Miller, "RateLimit header fields for HTTP", Work in Progress, Internet-Draft, draft- ietf-httpapi-ratelimit-headers-11, 23 May 2026, . [L402] Lightning Labs, "L402 Protocol Specification", 2024, . [RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet Attribute Certificate Profile for Authorization", RFC 5755, DOI 10.17487/RFC5755, January 2010, . [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, . [RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, . McGraw Expires 17 December 2026 [Page 28] Internet-Draft Delegation June 2026 [RFC9635] Richer, J., Ed. and F. Imbault, "Grant Negotiation and Authorization Protocol (GNAP)", RFC 9635, DOI 10.17487/RFC9635, October 2024, . [X402] Coinbase, Inc., "x402: An Open Standard for Internet- Native Payments", 2025, . Appendix A. Implementation Status This appendix follows [RFC7942] and is to be removed before publication as an RFC. A.1. Kevros TaskHawk Systems operates a Kevros implementation that publishes public Delegation discovery and health metadata for a draft-02 compatibility surface, records reason-coded audit events, and reports proof-verification and rail-observation counters separately. Earlier Kevros releases experimentally emitted 427 Budget challenges; that behavior is implementation experience for the Budget authority profile only. It is not a request for status-code registration and is not required for interoperability with the 401/403 response semantics defined by this document. The Kevros compatibility surface exposes a 401/403 Delegation response mode, Delegation-Version metadata, Authorization: Delegation, Delegation-Proof, JSON delegation_proof, and application/ delegation-proof+cose carriage for the same Budget profile proof bytes. It also advertises RFC 9964 ML-DSA algorithm identifiers in public metadata while keeping private key material out of issuer-key discovery. Private no-spend proof workflows exist for Budget-Attestation verification, but each run is evidence only for the specific commit and deployment state under test. Public challenge/discovery metadata, Delegation proof verification, Budget-Attestation verification, rail observation, settlement, and revenue are separate evidence lanes and are not equivalent. This document makes no live verified-use, settlement, or revenue claim. This implementation is provided as implementation experience only. Appendix B. Changes Since -01 * Refactored the core mechanism from Budget-specific language to the Delegation HTTP authentication scheme for request-bound delegated authority. McGraw Expires 17 December 2026 [Page 29] Internet-Draft Delegation June 2026 * 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. Appendix C. Changes Since -00 * Removed language implying HTTP 402 semantics are controlled by deployed payment protocols. * Added Section 1.2 and Section 1.5. * Updated ML-DSA serialization references to [RFC9964] 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. * Kept rail-keyed SLH-DSA optional and body-carried. * Made body carriage mandatory to implement for the cose-ml-dsa profile and recommended by default for post-quantum Budget- Attestation envelopes. McGraw Expires 17 December 2026 [Page 30] Internet-Draft Delegation June 2026 * 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: exp - iat greater than 900 seconds is a verifier rejection condition. * Tightened Implementation Status to separate challenge emission, Budget-Attestation verification, rail observation, settlement, and revenue. Author's Address John Paul McGraw, Jr. TaskHawk Systems LLC Charlottesville, VA United States of America Email: j.mcgraw@taskhawktech.com McGraw Expires 17 December 2026 [Page 31]