@techreport{mcgraw-httpapi-agent-budget-04,
    number =    {draft-mcgraw-httpapi-agent-budget-04},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-mcgraw-httpapi-agent-budget/04/},
    author =    {John Paul McGraw, Jr.},
    title =     {{The Delegation HTTP Authentication Scheme for Request-Bound Authority}},
    pagetotal = 52,
    year =      2026,
    month =     sep,
    day =       10,
    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. 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.},
}