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 4 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 AS performs under a Mission. The limit is an issuer-side operational control. It bounds issuance operations at the token endpoint, not the authority any derived token carries or how often a token already issued is used.¶

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

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

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, the AS MUST render it for consent at the approval 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.¶

The rendered limit is one Mission's local bound (Section 9.3). 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¶

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

Author's Address