Mission Derivation Limits for OAuth 2.0

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 11 April 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 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

Mission-Bound Authorization for OAuth 2.0 [I-D.draft-mcguinness-oauth-mission] (the OAuth binding) gates every derivation under a Mission on its lifecycle state, its Authority Set, and its expiry. It does not bound how many derivations the issuer performs. This document adds that bound: a derivation limit on the number of derivations the issuer authorization server (AS) performs under a Mission. The limit is an issuer-side operational control. It bounds counted issuance operations at the token endpoint, or at the Mission Authority Server's grant endpoint under the Mission Issuance Grant profile (Section 4.5), not the authority any derived token carries or how often a token already issued is used. The refreshes of an async delegation family are not counted (Section 4.3), nor are redemption and refresh at a consuming Authorization Server under the Mission Issuance Grant profile (Section 4.5).¶

The limit uses these extension seams of the OAuth binding and changes none of its rules:¶

• a Mission Intent member, requested_derivation_limit, under the Mission Intent members extension point and its registry ([I-D.draft-mcguinness-oauth-mission], Section "Extensibility");¶

• a Mission Record member, derivation_limit, under the open record ([I-D.draft-mcguinness-oauth-mission], Section "Mission Record");¶

• an issuance gate at the token endpoint, refused with the invalid_grant error code and a value of the OAuth binding's mission_error diagnostic ([I-D.draft-mcguinness-oauth-mission], Section "Issuance Gating");¶

• a companion-defined member of the introspection mission member, derivations_remaining, under member-scoped disclosure ([I-D.draft-mcguinness-oauth-mission], Section "Caller Authorization and Minimization"); and¶

• rendering of the established limit at the approval event ([I-D.draft-mcguinness-oauth-mission], Section "Mission Approval").¶

An AS that does not implement this document establishes no derivation limit, and its closed-top-level validation refuses a submitted requested_derivation_limit as an unknown member ([I-D.draft-mcguinness-oauth-mission], Section "Submission via PAR"). Bounding aggregate consumption (calls, spend, or activity over the life of a Mission) is out of scope; the metering profile defines it ([I-D.draft-mcguinness-mission-metering]).¶

2. Conventions and Terminology

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

This document uses the terms Mission, Mission Intent, Mission Record, Mission Issuer (the "issuer AS" or the "AS"), Resource AS, Approver, approval event, Authority Set, Mission-bound token, and derivation from [I-D.draft-mcguinness-oauth-mission].¶

Derivation limit:

The AS-established effective ceiling on the number of derivations under one Mission, recorded as the Mission Record's derivation_limit (Section 3.3).¶

Derivation count:

The number of derivations the issuer AS has committed under a Mission (Section 4).¶

3. The Derivation Limit

A Mission's derivation limit bounds the number of derivations (Section 4) the issuer AS performs under it. The limit is AS-established operational policy; a client can request a narrower ceiling through the Mission Intent's requested_derivation_limit member (Section 3.1).¶

{
  "goal": "Reconcile Q3 invoices and post adjustments under $500.",
  "target_resources": ["https://erp.example.com"],
  "expires_at": "2026-12-31T23:59:59Z",
  "requested_derivation_limit": 200
}

4. Counting Derivations

The running derivation count is AS-side state about the Mission, not a member of the immutable record. It counts derivations as the OAuth binding defines them ([I-D.draft-mcguinness-oauth-mission], Section "Issuance Gating"): one issuance operation the issuer AS performs for a single request, namely the initial authorization-code exchange, a refresh, a Token Exchange ([RFC8693]), or a cross-domain grant issuance ([I-D.draft-mcguinness-oauth-mission-cross-domain]). Under the Mission Issuance Grant profile the list gains one entry, the Mission Authority Server's minting of a grant (Section 4.5).¶

5. Enforcement at Issuance

The derivation limit is an issuance gate beside those of the OAuth binding ([I-D.draft-mcguinness-oauth-mission], Section "Issuance Gating"). When the Mission's derivation_limit (Section 3.3) is established, the AS MUST refuse, with the invalid_grant error code, any derivation that would make the number of derivations under the Mission exceed it. Where the derivation is a Mission Authority Server's minting of a grant, the refusal is that profile's derivations_exhausted grant error instead (Section 4.5).¶

The issuer AS enforces the limit at each derivation. The bound is never absent at the issuer when established, and it does not bound another domain's local minting (Section 4.4). The rendered limit (Section 7) is therefore a bound a named party enforces, so rendering it meets the OAuth binding's rule against presenting a rendered bound as enforced when no party enforces it ([I-D.draft-mcguinness-oauth-mission], Section "Mission Approval").¶

invalid_grant alone does not tell a client which gate refused. On a refusal under this section the AS SHOULD include, alongside error, the mission_error token-error-response member ([I-D.draft-mcguinness-oauth-mission], Section "Issuance Gating") with the value derivations_exhausted. The OAuth binding's rules for that member apply: it is diagnostic only, it grants nothing, an unrecognized value is ignored, and it is returned only to the authenticated client presenting the Mission's grant. The refusal maps as the OAuth binding's other token-endpoint lifecycle refusals do ([I-D.draft-mcguinness-oauth-mission], Section "Error and Challenge Mapping"): invalid_grant (Section 5.2 of [RFC6749]), with mission_error as the optional detail.¶

The following is an example of a token error response refusing a derivation under an exhausted limit:¶

HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store

{
  "error": "invalid_grant",
  "mission_error": "derivations_exhausted"
}

6. Remaining Derivations in Token Introspection

Where the AS supports token introspection [RFC7662] for Mission-bound tokens ([I-D.draft-mcguinness-oauth-mission], Section "Mission State via Token Introspection"), the mission member of the introspection response can carry one member this document defines:¶

• derivations_remaining: when derivation_limit (Section 3.3) is established, the derivations left under the cap at the time of the response, counting committed issuances (Section 4.2) (number).¶

derivations_remaining lets an issuance-budget consumer plan refreshes against the cap. It is not an enforcement input ([I-D.draft-mcguinness-oauth-mission], Section "Resource Server Enforcement").¶

The OAuth binding's caller authorization and minimization rules apply to it ([I-D.draft-mcguinness-oauth-mission], Section "Caller Authorization and Minimization"), and its disclosure is member-scoped. derivations_remaining serves issuance-budget consumers, not resource server enforcement, and the AS MUST disclose it only to a caller the deployment has granted that member's disclosure privilege. By default, an audience-authorized resource server receives the audience-filtered enforcement projection without it.¶

An AS MUST NOT include derivations_remaining in an introspection response unless it holds the Mission, that is, unless it is the Mission issuer ([I-D.draft-mcguinness-oauth-mission], Section "Only the Issuer Reports Mission State").¶

The following is an example of an introspection response to a caller granted the derivations_remaining disclosure privilege:¶

{
  "active": true,
  "client_id": "s6BhdRkqt3",
  "exp": 1790000000,
  "mission": {
    "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
    "issuer": "https://as.example.com",
    "state": "active",
    "derivations_remaining": 187
  }
}

7. Approval Rendering

Where an effective derivation_limit is established at a human approval event, the AS MUST render it for consent at that event, as context beside the derived Authority Set, in the rendering step of the OAuth binding's approval sequence ([I-D.draft-mcguinness-oauth-mission], Section "Mission Approval"). The rendering shows the established value, not only the requested one. Where the AS supports the Continuation profile's async delegation transport, the rendering MUST also state that the refreshes of an async delegation family are not counted against the limit (Section 4.3). Where the Mission Issuer is a Mission Authority Server issuing grants under the Mission Issuance Grant profile, the rendering MUST also state that the limit bounds the grants it issues, not the tokens consuming Authorization Servers issue from them (Section 4.5).¶

The rendered limit is one Mission's local bound (Section 9.4). Where a deployment runs child delegation, that profile states what an approval interface discloses beside it ([I-D.draft-mcguinness-oauth-mission-child-delegation]).¶

8. Conformance

An AS conforming to this document MUST implement:¶

• the requested limit, the effective limit, and the record member (Section 3);¶

• derivation counting (Section 4);¶

• enforcement at issuance (Section 5);¶

• approval rendering (Section 7); and¶

• where it supports token introspection for Mission-bound tokens, the rules for derivations_remaining (Section 6).¶

A resource server does not need to understand this document to enforce Mission-bound tokens; derivations_remaining is not an enforcement input (Section 6).¶

9. Security Considerations

The security considerations of [I-D.draft-mcguinness-oauth-mission] apply. This section covers what the derivation limit adds.¶

10. Privacy Considerations

derivations_remaining reveals how actively a Mission's grant is exercised and, across successive responses, its issuance cadence. Member-scoped disclosure (Section 6) limits it to callers the deployment grants that privilege.¶

11. IANA Considerations

This document requests registration of the following in the "Mission Intent Members" registry established by [I-D.draft-mcguinness-oauth-mission]:¶

• Name: requested_derivation_limit¶

• Status: stable¶

• Semantics: Client-requested derivation-count ceiling (Section 3).¶

• Change Controller: IETF¶

• Reference: this document, Section 3.1¶

This document's promotion criterion for the member is a complete definition of its request semantics, effective limit, counting, and enforcement. The definitions in Section 3, Section 4, and Section 5 meet it, which a Designated Expert confirms before the stable registration ([I-D.draft-mcguinness-oauth-mission], Section "Mission Intent Members Registry").¶

derivation_limit is a Mission Record member and derivations_remaining a member of the introspection mission member, each under an extension point of the OAuth binding, and derivations_exhausted is a value of the OAuth binding's mission_error member. None of these has an IANA registry, so this document requests no further registration.¶

12. References

Appendix A. Integrity Anchor Test Vector

This non-normative vector shows requested_derivation_limit committed by intent_hash, computed as the OAuth binding specifies ([I-D.draft-mcguinness-oauth-mission], Sections "Integrity Anchors" and "Canonicalization Rules"), with the issuer https://as.example.com. The canonical-bytes block is the exact JCS [RFC8785] output, wrapped here for layout only; removing the line breaks, and adding no characters, recovers the canonical form.¶

intent_hash, over this Mission Intent as the envelope value with typ mission-intent:¶

{
  "goal": "Reconcile Q3 invoices",
  "target_resources": ["https://erp.example.com"],
  "expires_at": "2026-12-31T23:59:59Z",
  "requested_derivation_limit": 20
}

Canonical bytes of the envelope:¶

{"iss":"https://as.example.com","typ":"mission-intent","value":{"e
xpires_at":"2026-12-31T23:59:59Z","goal":"Reconcile Q3 invoices","r
equested_derivation_limit":20,"target_resources":["https://erp.exa
mple.com"]}}

intent_hash = sha-256:r--mF07yZfWRGV6N28A2u_8rUzIG-bNhpvFSS5FhoBk

Appendix B. Document History

[[ To be removed from the final specification ]]¶

-00¶

• Effective Limit and What Counts: a ceiling-drawdown successor carries forward its predecessor's committed derivation count and never exceeds its limit, alongside the carryover exception; its successor access token counts once, against the successor (#1079).¶

• Approval Rendering applies where the limit is established at a human approval event; a policy-adjudicated instance has no consent rendering (#1078).¶

• What Counts states that a child-creation token exchange is not counted against the Parent Mission's limit, and that the child's redemption of its initial grant counts against the child's own limit.¶

• Composition Across Missions states that the example's 12 descendants and 120 derivations count Missions live at once, not a lifetime total.¶

• Initial version. Carries the derivation limit of Mission-Bound Authorization for OAuth 2.0 with its wire names and rules unchanged: the requested_derivation_limit Intent member, the derivation_limit record member, counting and refusal at issuance, the derivations_exhausted diagnostic, the derivations_remaining introspection member, and approval rendering.¶

• Under the Mission Issuance Grant profile, the Mission Authority Server's committed grant minting is a counted derivation; redemption and refresh at a consuming Authorization Server are not, and the limit does not cap the tokens they issue; the approval rendering states that bound (#963).¶

Author's Address