The Delegation HTTP Authentication Scheme for Request-Bound Authority
draft-mcgraw-httpapi-agent-budget-03
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | John Paul McGraw, Jr. | ||
| Last updated | 2026-07-23 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-mcgraw-httpapi-agent-budget-03
HTTPAPI J. McGraw
Internet-Draft TaskHawk
Intended status: Standards Track 23 July 2026
Expires: 24 January 2027
The Delegation HTTP Authentication Scheme for Request-Bound Authority
draft-mcgraw-httpapi-agent-budget-03
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. This
revision also defines a mandatory-to-implement preflight flow for
large proof profiles so that GET and HEAD requests do not depend on
request content, and so that requests with application
representations do not need to multiplex the application body and the
proof body in a single content stream.
McGraw Expires 24 January 2027 [Page 1]
Internet-Draft Delegation July 2026
For implementation experience, this individual draft also includes
the initial Budget authority profile. The HTTP authentication
scheme, status-code semantics, Problem Details members, and field-
carriage rules are intentionally separable from the COSE/CBOR Budget
profile. If a Working Group chooses to progress the HTTP mechanism
independently, the Budget authority profile can be moved to a
companion profile document without changing the Delegation challenge
semantics defined here.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-mcgraw-httpapi-agent-budget/.
Discussion of this document takes place on the HTTPAPI Working Group
mailing list (mailto:httpapi@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/httpapi/. Subscribe at
https://www.ietf.org/mailman/listinfo/httpapi/.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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 24 January 2027.
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
McGraw Expires 24 January 2027 [Page 2]
Internet-Draft Delegation July 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions and Definitions . . . . . . . . . . . . . . . 5
1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 7
1.3. Relationship to OAuth, GNAP, and Token Exchange . . . . . 7
1.4. Relationship to Sender-Constrained Tokens and DPoP . . . 8
1.5. Relationship to Attribute Certificates . . . . . . . . . 9
1.6. Relationship to RateLimit Fields . . . . . . . . . . . . 9
1.7. Relationship to HTTP Message Signatures . . . . . . . . . 10
1.8. Relationship to HTTP 402 . . . . . . . . . . . . . . . . 11
2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 11
3. Delegation Challenge Responses . . . . . . . . . . . . . . . 13
3.1. Dedicated Status Code Design Question . . . . . . . . . . 14
3.2. Delegation Error Tokens . . . . . . . . . . . . . . . . . 15
4. The "Delegation" Authentication Scheme . . . . . . . . . . . 15
4.1. Challenge Syntax . . . . . . . . . . . . . . . . . . . . 16
4.2. Credentials Syntax . . . . . . . . . . . . . . . . . . . 17
4.3. Large-Proof Preflight Flow . . . . . . . . . . . . . . . 18
4.4. Preflight Target Binding Fields . . . . . . . . . . . . . 20
4.5. Compact Credential Response . . . . . . . . . . . . . . . 21
4.6. Multi-Scheme Composition and the Delegation-Proof
Field . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5. Budget Authority Profile: Budget-Attestation Envelope . . . . 23
5.1. Request-Binding Canonicalization . . . . . . . . . . . . 26
5.2. Primary Signature . . . . . . . . . . . . . . . . . . . . 27
5.3. Issuer Key Discovery and Trust . . . . . . . . . . . . . 27
5.4. Optional Rail-Keyed Signature . . . . . . . . . . . . . . 28
5.5. Verification . . . . . . . . . . . . . . . . . . . . . . 29
6. Versioning . . . . . . . . . . . . . . . . . . . . . . . . . 29
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
7.1. HTTP Status Code . . . . . . . . . . . . . . . . . . . . 30
7.2. HTTP Authentication Scheme . . . . . . . . . . . . . . . 30
7.3. HTTP Field Name . . . . . . . . . . . . . . . . . . . . . 30
7.4. Media Type . . . . . . . . . . . . . . . . . . . . . . . 32
8. Security Considerations . . . . . . . . . . . . . . . . . . . 33
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 35
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
10.1. Normative References . . . . . . . . . . . . . . . . . . 35
10.2. Informative References . . . . . . . . . . . . . . . . . 37
Appendix A. Implementation Status . . . . . . . . . . . . . . . 38
A.1. Kevros . . . . . . . . . . . . . . . . . . . . . . . . . 38
Appendix B. Changes Since -02 . . . . . . . . . . . . . . . . . 39
Appendix C. Changes Since -01 . . . . . . . . . . . . . . . . . 41
McGraw Expires 24 January 2027 [Page 3]
Internet-Draft Delegation July 2026
Appendix D. Changes Since -00 . . . . . . . . . . . . . . . . . 42
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 42
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.
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.6), 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.
McGraw Expires 24 January 2027 [Page 4]
Internet-Draft Delegation July 2026
This document currently contains both the generic HTTP Delegation
mechanism and the initial Budget authority profile so the protocol
can be reviewed with a complete running profile. The sections are
scoped so the generic HTTP mechanism can be split from the Budget
profile in a future revision if that is cleaner for Working Group
processing.
The Delegation authentication scheme is algorithm-agile. The initial
Budget cose-ml-dsa profile uses ML-DSA algorithm identifiers
serialized for JOSE and COSE by [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
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
McGraw Expires 24 January 2027 [Page 5]
Internet-Draft Delegation July 2026
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
McGraw Expires 24 January 2027 [Page 6]
Internet-Draft Delegation July 2026
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.
McGraw Expires 24 January 2027 [Page 7]
Internet-Draft Delegation July 2026
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.
McGraw Expires 24 January 2027 [Page 8]
Internet-Draft Delegation July 2026
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.
McGraw Expires 24 January 2027 [Page 9]
Internet-Draft Delegation July 2026
+===========+============================+======================+
| 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
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.
McGraw Expires 24 January 2027 [Page 10]
Internet-Draft Delegation July 2026
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.
2. Overview of Operation
A protected origin determines that a request requires delegated
authority and that no acceptable Delegation credential is present:
POST /export HTTP/1.1
Host: api.example
It returns:
McGraw Expires 24 January 2027 [Page 11]
Internet-Draft Delegation July 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",
preflight-uri="https://api.example/preflight",
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,
"preflight_uri": "https://api.example/preflight",
"nonce": "QMjVqg5Xb6yV0bO_t9X8gQ",
"max_age": 300
}
}
The Delegated Requester obtains a Delegation proof from its Issuer by
means outside this document and submits the large proof to the
advertised preflight URI. In this example the proof uses the Budget
authority profile:
POST /preflight HTTP/1.1
Host: api.example
Content-Type: application/delegation-proof+cose
Delegation-Target-Method: "POST"
Delegation-Target-URI: "https://api.example/export"
Delegation-Target-Content-Digest: sha-256=:<base64-sha-256-digest>:
Content-Length: 4217
[COSE_Sign1 Budget-Attestation bytes]
McGraw Expires 24 January 2027 [Page 12]
Internet-Draft Delegation July 2026
Angle-bracketed values in examples are placeholders, not wire syntax.
If the attestation is valid for the request and local policy, the
Verifier returns a compact, verifier-issued Delegation credential
bound to the original method, origin, target, nonce, expiry, and
representation digest:
HTTP/1.1 200 OK
Cache-Control: no-store
Content-Type: application/json
{
"credential_type": "delegation-compact",
"credential": "kdc1.Pz9leGFtcGxlLW9wYXF1ZS10b2tlbg",
"authorization": "Delegation kdc1.Pz9leGFtcGxlLW9wYXF1ZS10b2tlbg",
"expires_in": 120,
"target": {
"method": "POST",
"uri": "https://api.example/export",
"content_digest": "sha-256=:<base64-sha-256-digest>:"
}
}
The requester then retries the original protected request using
normal HTTP semantics. The final request carries the compact
Delegation credential in the Authorization field. If the protected
request has an application representation, that representation
remains the request content:
POST /export HTTP/1.1
Host: api.example
Authorization: Delegation kdc1.Pz9leGFtcGxlLW9wYXF1ZS10b2tlbg
Content-Type: application/json
{"format":"jsonl","limit":1000}
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.
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
McGraw Expires 24 January 2027 [Page 13]
Internet-Draft Delegation July 2026
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. When a value is represented both in a WWW-Authenticate
challenge parameter and in the Problem Details body, the challenge
parameter is authoritative for authentication processing. The
Problem Details body is explanatory and actionable metadata for
clients; it does not relax, override, or extend the WWW-Authenticate
challenge.
This document does not redefine HTTP 402 (Payment Required), and a
Delegation challenge response MUST NOT be interpreted as a settlement
request. A 429 (Too Many Requests) response remains the appropriate
signal for server-side quota exhaustion.
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.
McGraw Expires 24 January 2027 [Page 14]
Internet-Draft Delegation July 2026
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. The "Delegation" Authentication Scheme
The Delegation authentication scheme is used in WWW-Authenticate and
Authorization fields.
McGraw Expires 24 January 2027 [Page 15]
Internet-Draft Delegation July 2026
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.
McGraw Expires 24 January 2027 [Page 16]
Internet-Draft Delegation July 2026
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.
McGraw Expires 24 January 2027 [Page 17]
Internet-Draft Delegation July 2026
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
McGraw Expires 24 January 2027 [Page 18]
Internet-Draft Delegation July 2026
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.
McGraw Expires 24 January 2027 [Page 19]
Internet-Draft Delegation July 2026
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.
McGraw Expires 24 January 2027 [Page 20]
Internet-Draft Delegation July 2026
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
McGraw Expires 24 January 2027 [Page 21]
Internet-Draft Delegation July 2026
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.
McGraw Expires 24 January 2027 [Page 22]
Internet-Draft Delegation July 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.
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. 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
McGraw Expires 24 January 2027 [Page 23]
Internet-Draft Delegation July 2026
translation between text claim names and signed bytes. The text
names in comments below are descriptive only and are not encoded.
For this profile, the Delegation proof is a COSE_Sign1 object
carrying the deterministically encoded Budget-Claims map as its
payload. A COSE_Sign1 object can be encoded with COSE tag 18 or as
the untagged four-element COSE_Sign1 array; Verifiers SHOULD accept
both forms and Issuers SHOULD send the tagged form unless a
deployment profile says otherwise. The protected header map MUST
contain the algorithm header parameter and a content type identifying
the Delegation proof payload. When multiple issuer keys are
available, the protected header map MUST contain a kid value
identifying the Issuer key. The algorithm and kid header parameters
MUST NOT appear in the unprotected header map. The unprotected
header map SHOULD be empty; if it is not empty, Verifiers MUST ignore
or reject unrecognized unprotected header parameters according to
local policy and MUST NOT let unprotected parameters change
signature, key-selection, request-binding, or authority semantics. A
crit protected header parameter, when present, MUST be understood by
the Verifier before the proof is accepted.
The signature input is the COSE_Sign1 Sig_structure defined by
[RFC9052], using context string Signature1, the encoded protected
header bstr, an empty external_aad bstr unless a future profile
defines another value, and the exact Budget-Claims payload bstr
received by the Verifier. Verifiers MUST reject proofs whose payload
bstr does not decode to a deterministic Budget-Claims map or whose
protected header bstr is not deterministically encoded.
McGraw Expires 24 January 2027 [Page 24]
Internet-Draft Delegation July 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
? 14 => Request-Binding ; signed request binding
}
Request-Binding = {
"method" => tstr,
"uri-h" => bstr .size 32,
"origin" => tstr,
? "body-h" => bstr .size 32
}
Channel-Binding = {
"type" => tstr,
"value" => bstr
}
Fields 4 and 5 carry decimal string values rather than binary
floating-point numbers. A Verifier MUST interpret them according to
the authority profile's currency or metered-unit policy and MUST
reject values it cannot parse unambiguously. A Delegation challenge
response using the Budget profile can advertise a minimum budget,
unit requirement, or action requirement in its Problem Details body;
that response member is an input to client policy and does not become
authoritative unless it is reflected in the signed claims.
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.
McGraw Expires 24 January 2027 [Page 25]
Internet-Draft Delegation July 2026
Field 14, when present, carries a signed Request-Binding structure.
A Budget-Attestation that is intended to authorize only one specific
protected request MUST include field 14 or another profile-defined
signed request-binding claim. When field 14 is absent, the Budget-
Attestation is authority for the class of actions and bounds
expressed by its other claims; a Verifier can still issue a compact
credential bound to one protected request after preflight, but it
MUST NOT describe that original Budget-Attestation as issuer-bound to
that specific HTTP target.
The Channel-Binding structure above is a logical structure for
profile extensions. It is not part of the integer-labeled Budget-
Claims map unless a future revision assigns a claim label for it. It
is included here to define semantics that a companion profile can
bind to without changing the core Delegation challenge model.
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.
McGraw Expires 24 January 2027 [Page 26]
Internet-Draft Delegation July 2026
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.
McGraw Expires 24 January 2027 [Page 27]
Internet-Draft Delegation July 2026
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.
McGraw Expires 24 January 2027 [Page 28]
Internet-Draft Delegation July 2026
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.
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. When both Delegation-Version and a version auth-param are
present in the same challenge response, they MUST identify the same
McGraw Expires 24 January 2027 [Page 29]
Internet-Draft Delegation July 2026
Delegation authentication-scheme version. A client that receives
conflicting values MUST treat the challenge as unsupported.
A client that receives an unknown Delegation-Version value or version
challenge parameter MUST NOT guess at wire compatibility. It MAY
retry using a version it supports only when the server advertises
that version through local policy or a future version-negotiation
mechanism. The Delegation authentication-scheme version is distinct
from Budget-Claims field 1, which is the Budget profile/envelope
version. A server that receives a Delegation credential or
Delegation-Version request value for an unsupported version MUST
reject the request using 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]:
+================+===========+======================================+
| 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":
McGraw Expires 24 January 2027 [Page 30]
Internet-Draft Delegation July 2026
+=============+=========+============+===========+=================+
| Field Name |Status | Structured | Reference | Comments |
| | | Type | | |
+=============+=========+============+===========+=================+
| Delegation- |permanent| Item | This | Integer item |
| Version | | | document, | identifying the |
| | | | Section 6 | Delegation |
| | | | | authentication- |
| | | | | scheme version |
+-------------+---------+------------+-----------+-----------------+
| Delegation- |permanent| Item | This | Byte Sequence |
| Proof | | | document, | item carrying a |
| | | | Section | Delegation |
| | | | 4.6 | proof when |
| | | | | Authorization |
| | | | | is used by |
| | | | | another origin- |
| | | | | server scheme |
+-------------+---------+------------+-----------+-----------------+
| Delegation- |permanent| Item | This | String item |
| Target- | | | document, | identifying the |
| Method | | | Section | protected |
| | | | 4.4 | request method |
| | | | | for Delegation |
| | | | | preflight |
| | | | | target binding |
+-------------+---------+------------+-----------+-----------------+
| Delegation- |permanent| Item | This | String item |
| Target-URI | | | document, | identifying the |
| | | | Section | protected |
| | | | 4.4 | request target |
| | | | | URI for |
| | | | | Delegation |
| | | | | preflight |
| | | | | target binding |
+-------------+---------+------------+-----------+-----------------+
| Delegation- |permanent| Dictionary | This | Digest Fields |
| Target- | | | document, | dictionary |
| Content- | | | Section | identifying the |
| Digest | | | 4.4 | protected |
| | | | | request content |
| | | | | digest for |
| | | | | Delegation |
| | | | | preflight |
| | | | | target binding |
+-------------+---------+------------+-----------+-----------------+
Table 3
McGraw Expires 24 January 2027 [Page 31]
Internet-Draft Delegation July 2026
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
McGraw Expires 24 January 2027 [Page 32]
Internet-Draft Delegation July 2026
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.
Deployments that use bearer, DPoP-bound, mutual-TLS-bound, or
otherwise sender-constrained credentials for identity or session
authentication MUST validate those credentials before treating the
requester as authenticated. Sender-constraining an identity or
session token does not replace Delegation nonce validation, request
binding, Issuer trust, Budget bounds, or Verifier policy.
Conversely, a valid Delegation proof does not authorize use of an
unrelated OAuth access token, API key, or other execution credential.
Verifiers MUST validate every check in 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.
The Budget authority profile uses post-quantum digital signatures for
delegated-authority proofs. It does not define post-quantum key
establishment, confidentiality migration, certificate migration,
hybrid key exchange, or a general post-quantum migration protocol.
Implementers need to evaluate those surrounding cryptographic
migration questions separately; see [RFC9958] for engineer-facing
discussion of PQC migration impacts. Deployments with long-lived
confidentiality or quantum-transition requirements need to make
independent TLS and certificate migration decisions under the
applicable TLS profiles and deployment policy. This document does
not choose or recommend a TLS key-establishment profile. Support for
a TLS quantum-transition profile MUST NOT be represented as support
for the Budget cose-ml-dsa profile, and support for the Budget
profile MUST NOT be represented as post-quantum transport
confidentiality.
McGraw Expires 24 January 2027 [Page 33]
Internet-Draft Delegation July 2026
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. This is consistent with the protocol-redesign and
constrained-network concerns discussed in [RFC9958]. 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.
Verifiers that fetch issuer key sets or discovery metadata MUST bound
response sizes, redirect behavior, parsing depth, and cache
lifetimes. They MUST NOT fetch arbitrary key URLs supplied inside an
untrusted proof.
Verifier nonce state can itself become a resource-exhaustion target.
Verifiers MUST bound the number of outstanding nonces per issuer,
protection space, and client identity signal available to the
deployment, and MUST expire unused nonces no later than their
challenge max-age. When nonce state reaches a configured limit, the
Verifier MUST reject requests that depend on an untracked nonce or
shed unauthenticated challenge issuance rather than accept a request
with an untracked nonce. At high scale, deployments SHOULD use self-
authenticating nonces as described in 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
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.
McGraw Expires 24 January 2027 [Page 34]
Internet-Draft Delegation July 2026
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. Issuer and requester
identifiers SHOULD be pairwise or otherwise scoped when a stable
global identifier is not required by deployment policy. Challenge
responses SHOULD reveal only the authority requirements needed for
the client to obtain an acceptable proof. Public reason tokens and
detailed Problem Details bodies can become policy or issuer-
enumeration oracles; deployments SHOULD rate-limit unauthenticated
challenge traffic and avoid returning unnecessary detail to untrusted
clients. Logs SHOULD redact Authorization, Delegation-Proof, body-
carried proof bytes, compact credentials, and preflight target URIs
or content digests when those values could reveal sensitive resources
or actions.
10. References
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>.
McGraw Expires 24 January 2027 [Page 35]
Internet-Draft Delegation July 2026
[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>.
McGraw Expires 24 January 2027 [Page 36]
Internet-Draft Delegation July 2026
[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>.
McGraw Expires 24 January 2027 [Page 37]
Internet-Draft Delegation July 2026
[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>.
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. 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
McGraw Expires 24 January 2027 [Page 38]
Internet-Draft Delegation July 2026
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.
Appendix B. Changes Since -02
* Made the large-proof preflight flow mandatory to implement for the
Budget cose-ml-dsa profile.
* Specified that the Budget cose-ml-dsa profile MUST NOT rely on GET
or HEAD request content for Delegation proof carriage.
McGraw Expires 24 January 2027 [Page 39]
Internet-Draft Delegation July 2026
* Defined preflight as the baseline interoperability fallback for
large post-quantum proofs and for operations that also carry an
application representation body.
* Left same-request multipart/related or profile-specific envelopes
as optional packaging profiles rather than the baseline
interoperability path.
* Clarified that a successful preflight returns a compact Delegation
credential bound to method, origin, target URI, nonce, expiry, and
representation digest, while leaving other proof-reference
artifacts to future profiles.
* Defined the Delegation-Target-Method, Delegation-Target-URI, and
Delegation-Target-Content-Digest fields used by the Budget cose-
ml-dsa preflight flow.
* Clarified that those target-binding fields align with HTTP Message
Signatures derived-component semantics and HTTP Digest Fields
rather than replacing message-level signatures.
* Defined the Budget cose-ml-dsa compact credential response shape,
including credential_type, opaque credential, authorization
convenience value, expires_in, and target, while keeping
settlement and revenue semantics out of the preflight response.
* Clarified that compact credentials need verifier-portable
validation within the protection space and cannot depend on node-
local preflight state.
* Added an optional signed Request-Binding claim for request-
specific Budget attestations and clarified the difference between
issuer-bound request authority and verifier-bound compact
credentials issued after preflight.
* Tightened origin-authorized verifier scope, target URI
reconstruction, cache behavior for Delegation-Proof, preflight URI
challenge carriage, IANA field registration metadata, and
security/privacy considerations based on HTTP-focused review.
* Clarified that the combined HTTP mechanism plus Budget profile is
current implementation-experience packaging and can be split into
companion drafts for Working Group processing.
* Added [RFC9958] as an informative reference for post-quantum
migration and large-signature protocol-design considerations.
McGraw Expires 24 January 2027 [Page 40]
Internet-Draft Delegation July 2026
* Clarified that the Budget authority profile uses PQC signatures
for delegated-authority proofs but does not define PQC key
establishment, confidentiality migration, certificate migration,
hybrid key exchange, or a general PQC migration protocol.
* Added DPoP/sender-constrained-token composability text, including
the Authorization field composition boundary when Authorization:
DPoP and Delegation are both required.
* Added a neutral transport-security migration note for TLS and
certificate migration, while keeping TLS key establishment
separate from the Budget cose-ml-dsa proof profile.
* Clarified private-use authority-profile identifiers and their
relationship to the interoperable budget profile identifier.
* Updated issuer-key discovery text to use /.well-known/delegation-
issuer-keys as the Delegation discovery endpoint name, while
allowing earlier Budget-specific discovery names as aliases.
* Tightened Kevros implementation-status text to distinguish
published draft-02 metadata, local draft-03 preview behavior,
operational enforcement health fields, proof verification, rail
observation, settlement, and revenue.
Appendix C. Changes Since -01
* Refactored the core mechanism from Budget-specific language to the
Delegation HTTP authentication scheme for request-bound delegated
authority.
* Made Budget the initial authority profile rather than the protocol
boundary.
* Replaced core Budget challenge examples with WWW-Authenticate:
Delegation, Delegation-Version, Delegation-Proof, and
authority_requirements.
* Made 401 and 403 with WWW-Authenticate: Delegation and Problem
Details the baseline response model for delegated-authority
challenges.
* Moved the dedicated status-code question to 4NN Delegated
Authority Required instead of requesting status-code registration
in this revision.
* Tightened the alg challenge parameter to one algorithm per
challenge.
McGraw Expires 24 January 2027 [Page 41]
Internet-Draft Delegation July 2026
* 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 D. Changes Since -00
* Removed language implying HTTP 402 semantics are controlled by
deployed payment protocols.
* Added Section 1.2 and Section 1.6.
* 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.
* 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
McGraw Expires 24 January 2027 [Page 42]
Internet-Draft Delegation July 2026
John Paul McGraw, Jr.
TaskHawk Systems LLC
Charlottesville, VA
United States of America
Email: j.mcgraw@taskhawktech.com
McGraw Expires 24 January 2027 [Page 43]