The Delegation HTTP Authentication Scheme for Request-Bound Authority

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

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

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 Sender-Constrained Tokens and DPoP

OAuth 2.0 Demonstrating Proof of Possession (DPoP) [RFC9449] 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 Section 3.¶

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 body-carried proof where the target method and request representation allow that carriage. 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.¶

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

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

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 [RFC9530], 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.¶

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

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. Conformant implementations use the 401/403 behavior defined in Section 3 unless and until a future revision registers a dedicated status code.¶

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

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

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

4.2. Credentials Syntax

delegation-credentials = "Delegation" 1*SP delegation-token
delegation-token       = token68

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 Section 4.3 as the mandatory-to-implement fallback for large proofs.¶

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. [RFC9958] 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 Section 4.3 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. 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 how the Delegation proof and the application representation are cryptographically bound to each other before claiming interoperability.¶

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

The requester submits the full Delegation proof to the preflight URI using POST. The preflight request content type MUST be application/delegation-proof+cose or another media type defined by the authority profile. 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 Section 4.4 for this binding.¶

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

4.4. 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 [RFC9651].¶

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 [RFC9530]. 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. If the protected request has no content, this field MAY be omitted; if it is present for a no-content request, it MUST be the digest of the empty content. When the protected request carries Content-Digest, the Verifier MUST reject the protected request if the Content-Digest value is inconsistent with the digest accepted during preflight.¶

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

4.5. 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 [RFC9530].¶

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

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 and MAY also bind the challenge nonce used to obtain the credential. 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.¶

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

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

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 Section 3 and Section 4.5.¶

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

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

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

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

Deployments that implemented earlier Budget-specific discovery names MAY retain those names as aliases, but the Delegation discovery name above is the interoperable endpoint name for this revision.¶

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

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

6. Verify request binding against the bearing request when the attestation includes Budget-Claims field 14 or another profile-defined signed request-binding claim, including method, origin, target URI hash, and body hash when present. If no signed request-binding claim is present, the Verifier MUST enforce the action, resource-class, verifier binding, and preflight compact-credential binding needed by local policy before processing the protected request.¶

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

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]:¶

7.3. HTTP Field Name

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

This revision does not request creation of a Delegation error-token registry. The reason values in Section 3.2 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.¶

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

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¶

10.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, <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC6838]

Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/rfc/rfc6838>.

[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, <https://www.rfc-editor.org/rfc/rfc8126>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[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, <https://www.rfc-editor.org/rfc/rfc8610>.

[RFC8949]

Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/rfc/rfc8949>.

[RFC9052]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, <https://www.rfc-editor.org/rfc/rfc9052>.

[RFC9110]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.

[RFC9111]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Caching", STD 98, RFC 9111, DOI 10.17487/RFC9111, June 2022, <https://www.rfc-editor.org/rfc/rfc9111>.

[RFC9205]

Nottingham, M., "Building Protocols with HTTP", BCP 56, RFC 9205, DOI 10.17487/RFC9205, June 2022, <https://www.rfc-editor.org/rfc/rfc9205>.

[RFC9457]

Nottingham, M., Wilde, E., and S. Dalal, "Problem Details for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023, <https://www.rfc-editor.org/rfc/rfc9457>.

[RFC9530]

Polli, R. and L. Pardue, "Digest Fields", RFC 9530, DOI 10.17487/RFC9530, February 2024, <https://www.rfc-editor.org/rfc/rfc9530>.

[RFC9651]

Nottingham, M. and P. Kamp, "Structured Field Values for HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024, <https://www.rfc-editor.org/rfc/rfc9651>.

[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, <https://www.rfc-editor.org/rfc/rfc9964>.

10.2. Informative References

[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, <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.pdf>.

[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-09, 6 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-cose-sphincs-plus-09>.

[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, <https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-ratelimit-headers-11>.

[L402]

Lightning Labs, "L402 Protocol Specification", 2024, <https://github.com/lightninglabs/L402>.

[RFC5755]

Farrell, S., Housley, R., and S. Turner, "An Internet Attribute Certificate Profile for Authorization", RFC 5755, DOI 10.17487/RFC5755, January 2010, <https://www.rfc-editor.org/rfc/rfc5755>.

[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, <https://www.rfc-editor.org/rfc/rfc6973>.

[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, <https://www.rfc-editor.org/rfc/rfc7942>.

[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, <https://www.rfc-editor.org/rfc/rfc8693>.

[RFC9421]

Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, <https://www.rfc-editor.org/rfc/rfc9421>.

[RFC9449]

Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, <https://www.rfc-editor.org/rfc/rfc9449>.

[RFC9635]

Richer, J., Ed. and F. Imbault, "Grant Negotiation and Authorization Protocol (GNAP)", RFC 9635, DOI 10.17487/RFC9635, October 2024, <https://www.rfc-editor.org/rfc/rfc9635>.

[RFC9958]

Banerjee, A., Reddy.K, T., Schoinianakis, D., Hollebeek, T., and M. Ounsworth, "Post-Quantum Cryptography for Engineers", RFC 9958, DOI 10.17487/RFC9958, June 2026, <https://www.rfc-editor.org/rfc/rfc9958>.

[X402]

Coinbase, Inc., "x402: An Open Standard for Internet-Native Payments", 2025, <https://www.x402.org/x402-whitepaper.pdf>.

A.1. Kevros

TaskHawk Systems operates a Kevros implementation that publishes public Delegation discovery and health metadata. The public metadata identifies the published Datatracker revision as draft-mcgraw-httpapi-agent-budget-02 and the local implementation target as draft-mcgraw-httpapi-agent-budget-03. That implementation target includes a draft-03 preview of Delegation preflight and compact Delegation credentials, while preserving the -02 publication boundary. Kevros records reason-coded audit events and reports proof-verification, Delegation preflight, compact-credential, rail-observation, settlement, and revenue signals 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. Its public challenge and discovery metadata use the deployment-specific profile identifier bounded-authority, mapped by discovery metadata to the Budget claim and verification semantics used by this draft-03 preview. That local profile identifier is implementation experience only and is not an interoperable profile identifier defined by this document. Kevros also advertises RFC 9964 ML-DSA algorithm identifiers in public metadata while keeping private key material out of issuer-key discovery. Its issuer-key discovery endpoint defaults to JSON transition metadata but returns the interoperable application/cose-key-set representation when requested through HTTP content negotiation.¶

Kevros health metadata can report an operational enforce_soft mode for compatibility and public-discovery lanes. That health field does not mean that protected executable requests are processed without authority. Protected executable requests still fail closed unless an accepted Delegation credential, Delegation proof, API key, or other configured execution credential is present.¶

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 appendix is not evidence that any particular repository checkout or deployed revision currently contains each draft-03 preview behavior; dated implementation evidence needs to identify the commit, deployment, probe, and artifact under test. This implementation is provided as implementation experience only.¶