Mission Progressive Authorization 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 8 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 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 Expansion for OAuth 2.0 [I-D.draft-mcguinness-oauth-mission-expansion] (the "expansion profile") defines the governed path from an authority shortfall to a new approval: a successor Mission, freshly consented, that supersedes its predecessor. Every expansion under that profile is adjudicated by a fresh human approval. For a task whose growth is anticipated, that discipline has a human cost: each expansion is another approval moment, and an Approver asked too often stops reading what is asked (the consent-fatigue residual of [I-D.draft-mcguinness-mission-security-model]). This profile is the structural mitigation: one considered consent to a ceiling replaces many hurried consents to increments, without widening what any single Mission actively holds.¶

An open-ended agentic task often cannot have its full authority enumerated at the initial approval, which leaves a deployment choosing between over-provisioning a broad standing Mission and interrupting the user for a fresh approval at every step. Progressive authorization is a third option: the Approver consents once to a bounded envelope and a rule for drawing authority from it, so authority can grow within the envelope at runtime without a fresh human approval each time, while the active authority any single Mission yields stays narrow.¶

2. Status: An EXPERIMENTAL Extension

This document is OPTIONAL and experimental: adopt it for evaluation, not as a stable interface. It removes the per-expansion human from a consented envelope, which is the highest-consequence capability in the expansion family; deploy it only with the rate bounds, prohibited-class rules, and audit linkage this document requires, and prefer plain expansion where task authority can be anticipated per step.¶

A Mission Issuer that does not implement this document adjudicates every expansion as a fresh human approval and is a fully conforming expansion-capable Mission Issuer ([I-D.draft-mcguinness-oauth-mission-expansion]). Nothing here places a new requirement back on the expansion profile or the issuance profile.¶

3. Relationship to the Expansion Profile

This document depends normatively on the expansion profile [I-D.draft-mcguinness-oauth-mission-expansion] and on the issuance profile [I-D.draft-mcguinness-oauth-mission], and is not implementable alone. It reuses, without restating, the expansion profile's expansion request, adjudication, predecessor member, superseded state, and reconciliation, and the issuance profile's approval event, integrity-anchor envelope, and subset rule. It uses Predecessor Mission, Successor Mission, and Expansion request as the expansion profile defines them.¶

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

Authority ceiling:

The pre-consented maximum authority any expansion of a Mission may reach without a further human approval (Section 5).¶

Drawdown policy:

The policy under which the Mission Issuer may adjudicate an in-ceiling expansion by policy rather than by a fresh human approval (Section 5).¶

5. Progressive Authorization

At the initial approval event ([I-D.draft-mcguinness-oauth-mission]), the Approver MAY additionally consent to:¶

• an authority ceiling, recorded as an authority_ceiling member on the Mission: an array of authorization-details-shaped entries, each the shape of an Authority Set entry ([I-D.draft-mcguinness-oauth-mission]), that is the pre-consented maximum any expansion of this Mission may reach without a further human approval and that every in-ceiling successor MUST be within (Section 5.1); and¶

• a drawdown policy, recorded as a drawdown_policy member on the Mission: a string or URI identifying the policy under which the Mission Issuer MAY adjudicate an in-ceiling expansion by policy rather than by a fresh human approval. The policy's content is deployment-defined.¶

Where present, authority_ceiling and drawdown_policy are recorded on the Mission and committed by a ceiling_hash, computed with the issuance profile's integrity-anchor envelope ([I-D.draft-mcguinness-oauth-mission]) under the typ mission-authority-ceiling over an object carrying both members. They are not committed under authority_hash: authority_hash commits only the consented Authority Set ([I-D.draft-mcguinness-oauth-mission]), and the ceiling is a bound on future expansions, not present authority. The consent disclosure MUST render the ceiling and the fact that in-ceiling expansion is policy-adjudicated ([I-D.draft-mcguinness-oauth-mission-consent-evidence]). A Mission that carries no authority_ceiling has no progressive authorization: every expansion of it is an ordinary, freshly approved expansion ([I-D.draft-mcguinness-oauth-mission-expansion]).¶

6. The out_of_ceiling Denial Reason

This document extends the expansion profile's closed set of expansion denial reasons ([I-D.draft-mcguinness-oauth-mission-expansion]) by specification, as that profile's IANA considerations anticipate, with one value, carried in mission_expansion_status exactly as that profile's reasons are:¶

out_of_ceiling:

The requested authority is not a subset of the Mission's consented authority ceiling (Section 5), so it cannot be granted by policy drawdown; raising the ceiling requires a fresh human approval.¶

A consumer that does not implement this document treats out_of_ceiling as it treats any unrecognized reason code: the expansion stays denied.¶

7. Audit Linkage

Each policy-adjudicated in-ceiling expansion is an approval event and MUST be recorded as one: the approver context is the drawdown policy (its identifier and version) rather than a human principal, and the successor's predecessor member links the drawdown chain for an authorized auditor exactly as for human-approved expansions ([I-D.draft-mcguinness-oauth-mission-expansion]). A deployment MUST retain the consented authority_ceiling, drawdown_policy, and ceiling_hash with the Mission record for the audit horizon, so an auditor can verify every drawdown was within the consented envelope.¶

8. Conformance

A Mission Issuer that claims Expansion with Progressive Authorization is a conforming expansion-capable Mission Issuer ([I-D.draft-mcguinness-oauth-mission-expansion]) and MUST:¶

• record a consented authority_ceiling and drawdown_policy on the Mission and commit them with ceiling_hash (Section 5);¶

• evaluate a requested successor Authority Set as in-ceiling by the subset rule, and refuse an out-of-ceiling request with out_of_ceiling (Section 5.1, Section 6);¶

• enforce the prohibited-class rule, requiring a fresh human approval for a drawdown that grants an irreversible, external-commitment, or privileged-administration authority, or cross-domain authority (Section 5.1); and¶

• rate-bound policy-adjudicated drawdowns per Mission and record each as an approval event (Section 5.1, Section 7).¶

9. Security Considerations

The expansion profile's security considerations apply in full. This document adds the drawdown surface:¶

• The ceiling is consented once and drawn on many times. A compromised agent can request in-ceiling drawdown unattended; the mitigations are the rate bound, the prohibited-class rule, the fall-back to human approval for unauthorized drawdowns (Section 5.1), and per-action runtime enforcement ([I-D.draft-mcguinness-mission-runtime]).¶

• The drawdown policy is authority-bearing governance. A misconfigured policy over-grants within the ceiling; it MUST be reviewed and versioned like approval policy, and its identity and version are part of the recorded approver context (Section 7).¶

• The ceiling is a consent artifact. It MUST be rendered to the Approver at the initial approval with the fact that in-ceiling expansion is policy-adjudicated (Section 5); a ceiling the Approver did not knowingly consent to is standing authority obtained by omission.¶

10. Privacy Considerations

The ceiling discloses, at initial approval time, the full envelope a task may grow into, which can reveal more about the anticipated task than any single Mission's Authority Set. The expansion profile's predecessor-chain correlation considerations apply to the drawdown chain; access to the ceiling and drawdown records SHOULD be scoped to parties with a governance need.¶

11. IANA Considerations

This document has no IANA actions. Following the expansion profile's restraint, out_of_ceiling is documented here as a specification-defined extension of that profile's denial-reason set, authority_ceiling and drawdown_policy are Mission record members defined by this profile, and the mission-authority-ceiling anchor typ follows the issuance profile's collision-resistant typ convention, none of which require registration.¶

12. References

Acknowledgments

This document is part of the Mission-Bound Authorization for OAuth 2.0 work and extends Mission Expansion with an experimental pre-consented drawdown mechanism.¶

Author's Address