Mission Progressive Authorization for OAuth 2.0

Internet-Draft	OAuth Mission Progressive Authorization	August 2026
McGuinness	Expires 24 February 2027	[Page]

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

Copyright Notice

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

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. The envelope can name a class of resources the agent will only meet during execution: the Approver consents once to the family, and every concrete binding stays inside it (Section 5.1).¶

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. This document therefore conditions the capability on the rate bounds, prohibited-class rules, and audit linkage it requires, and plain expansion remains the better fit 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.¶

Maturity: experimental. Maintenance: lab-best-effort. Adopt when: Authority cannot be enumerated up front; policy-bounded drawdown beats over-provisioning. Requires: Mission-Bound Authorization for OAuth 2.0; Mission Expansion for OAuth 2.0. Also requires, conditionally: Mission-Bound Runtime Enforcement (when drawdown maps to the runtime profile's action classes).¶

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).¶
Mission Deployment Profile:: The deployment-level manifest the architecture defines ([I-D.draft-mcguinness-mission-architecture]). The bounds, mappings, and cadence this document requires a deployment to publish are published there.¶

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. The ceiling_hash is computed with the issuance profile's integrity-anchor envelope ([I-D.draft-mcguinness-oauth-mission]):¶

typ: mission-authority-ceiling;¶
hashed object: a JSON object with exactly two members, authority_ceiling (the ceiling array) and drawdown_policy (the policy string or URI), canonicalized as the integrity-anchor envelope requires, so member order follows that canonicalization;¶
omission rule: when the Mission carries no drawdown_policy, the drawdown_policy member is omitted from the hashed object, never included as null or an empty string.¶

ceiling_hash is an envelope anchor under the issuance profile's commitment mechanisms, which this document imports normatively.¶

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

5.1. In-ceiling expansion

An in-ceiling expansion is an expansion, adjudicated per the expansion profile ([I-D.draft-mcguinness-oauth-mission-expansion]), whose successor Authority Set is within the predecessor's consented authority_ceiling. A requested successor Authority Set is in-ceiling when every one of its entries is a subset of some authority_ceiling entry under the issuance profile's subset rule ([I-D.draft-mcguinness-oauth-mission]). A constraints-bounded ceiling uses the same subset semantics. A ceiling entry MAY name a resource family rather than a single resource, under the same resource-narrowing semantics the subset rule fixes: a successor entry's resource is in-ceiling when it narrows the ceiling entry's.¶

When the predecessor consented to a drawdown policy that authorizes the requested widening, the Mission Issuer MAY satisfy the adjudication's approval event by policy rather than by a fresh human approval, exactly as a parent Mission's Authority Set may permit policy-approved child creation ([I-D.draft-mcguinness-oauth-mission-child-delegation]). This is an explicit override of the expansion profile's consent step for the in-ceiling case only.¶

The successor is created as the expansion profile requires: its Authority Set freshly derived and bound by the ceiling, its predecessor member set, the predecessor superseded. An in-ceiling successor MUST carry the predecessor's authority_ceiling and drawdown_policy unchanged or narrowed, committed under the same or, when narrowed, a recomputed ceiling_hash. Any change to either beyond narrowing requires a fresh human approval, never policy adjudication.¶

A policy-adjudicated in-ceiling successor is rooted in a standing-consent approval_basis, under the issuance profile's open type set ([I-D.draft-mcguinness-oauth-mission]), with type ceiling_drawdown, defined and owned by this profile: its consent_principal is the Approver who consented the ceiling, its activation is an object with exactly two members, policy_id (the drawdown policy identifier, the Mission's drawdown_policy value) and policy_version (the deployment's version identifier for that policy's content as applied at this adjudication), its activation_actor is the requesting client, its root_commitment is the ceiling_hash, and its approved_at (the issuance profile's standing-consent requirement) is the instant the Approver consented the ceiling that ceiling_hash commits, read from the Mission Issuer's retained record of that consent, never from the drawdown request. The child delegation profile's policy_drawdown basis ([I-D.draft-mcguinness-oauth-mission-child-delegation]) is not reused: that value names policy-approved child creation, not a ceiling drawdown.¶

When the adjudication is by the pre-consented drawdown policy, the Mission Issuer MAY complete the authorization request without prompting the Approver, issuing the authorization code directly on redemption of the expansion's request_uri. The successor is still created through the full approval-event machinery of the expansion profile; only the interactive prompt is skipped.¶

Skipping the interactive prompt also skips the expansion profile's child-cascade consent notice ([I-D.draft-mcguinness-oauth-mission-expansion]), and supersession terminally cascades to the predecessor's non-terminal Child Missions ([I-D.draft-mcguinness-oauth-mission-child-delegation]).¶

The Mission Issuer therefore MUST NOT policy-adjudicate an in-ceiling drawdown while the predecessor has non-terminal Child Missions: such a request falls back to a fresh human approval, at which that notice can be rendered.¶

Policy adjudication has no interactive disclosure boundary: nothing renders the expansion profile's child-cascade consent notice for a human to witness when a policy, not an Approver, adjudicates the drawdown. The prohibition above therefore has no safe exception while live children exist; the fallback to full human approval is the only widening path at which the cascade notice can be rendered. Relaxing that for the human-approved path specifically remains future work; no such relaxation is specified here.¶

This does not widen authority without consent ([I-D.draft-mcguinness-oauth-mission-expansion]). The consent is the human consent given at the initial approval to the ceiling and the drawdown policy; policy adjudication only draws within that pre-given consent and can never exceed the ceiling.¶

The Mission Issuer MUST refuse, with out_of_ceiling (Section 6), a requested authority that is not within the consented authority_ceiling. Exceeding the ceiling requires a fresh human approval that raises it, which is an ordinary expansion.¶

Policy adjudication is bounded per drawdown and across the chain, so a pre-consented ceiling cannot become a standing grant a compromised agent walks up to unattended.¶

A single policy-adjudicated in-ceiling drawdown MUST NOT activate the entire remaining ceiling. The drawdown policy MUST bound each drawdown incrementally, by one or both of:¶

a per-drawdown delta bound; or¶
narrowing the successor's Authority Set to what the triggering action needs.¶

The concrete per-drawdown bound MUST be published in the Mission Deployment Profile. Reaching the ceiling therefore takes many bounded, individually adjudicated and recorded drawdowns, not one.¶

Each in-ceiling drawdown creates a successor Mission, so a per-Mission bound would reset at every step. A deployment:¶

MUST rate-bound policy-adjudicated expansions per expansion chain, keyed by the chain's root Mission and counted across predecessor links per unit time;¶
MUST publish the concrete rate bound in the Mission Deployment Profile; and¶
MUST record each policy-adjudicated expansion as an approval event whose approver context is the drawdown policy that authorized it (Section 7).¶

Some authority classes always require a fresh human approval even within the ceiling. To make that testable, a deployment MUST publish in the Mission Deployment Profile a mapping from its action identifiers to the runtime profile's action classes ([I-D.draft-mcguinness-mission-runtime]), or an equivalent declared classification.¶

A drawdown MUST be adjudicated by a fresh human approval when it:¶

grants authority in the irreversible, external-commitment, or privileged-administration class;¶
satisfies the runtime profile's external-communication predicate (the exfiltration leg, [I-D.draft-mcguinness-mission-runtime]); or¶
grants cross-domain authority.¶

The drawdown policy MUST NOT permit policy-only adjudication of such a drawdown.¶

An in-ceiling request the drawdown policy does not authorize is not refused with out_of_ceiling; it falls back to an ordinary, freshly human-approved expansion.¶

The drawdown policy MUST NOT policy-adjudicate a successor Authority Set entry whose authority intersects a predecessor entry discharged under the status profile's completion machinery ([I-D.draft-mcguinness-oauth-mission-status]). The test is overlap in authority, not structural equality: any successor entry that overlaps a discharged predecessor entry in authority falls back to a fresh human approval. Completion-discharged authority therefore cannot be resurrected by policy.¶

5.2. What it bounds, and what it does not

The ceiling is broad by construction, since it must cover the open-ended task. What stays narrow is the active authority any single Mission in the chain yields: each in-ceiling successor is derived for the authority actually needed at that step and is independently gated and revocable. A compromised agent cannot instantly wield the ceiling; it can exercise only the current active authority and request in-ceiling drawdown, which is policy-gated, bounded per drawdown and rate-limited per chain (Section 5.1), recorded for audit (Section 7), and enforced per action by the runtime layer ([I-D.draft-mcguinness-mission-runtime]).¶

Progressive authorization bounds, and does not eliminate, standing-authority exposure. A deployment SHOULD pair it with short successor lifetimes, constraint-bounded ceilings, and runtime enforcement.¶

The drawdown policy is enforced by the Mission Issuer and is part of its trusted governance: a misconfigured policy can over-grant within the ceiling, so it is reviewed and versioned like other approval policy, a requirement Section 9 states.¶

5.3. The Ceiling Review

A pre-consented ceiling is standing consent, and standing consent decays: a chain renewed forever on policy alone is a standing grant with a calendar. This profile therefore bounds the chain in time, not only per drawdown and per unit rate (Section 5.1).¶

A deployment MUST publish a ceiling review cadence in its Mission Deployment Profile. The Mission Issuer MUST NOT policy-adjudicate an in-ceiling drawdown for a chain whose most recent human approval of the ceiling is older than that cadence: the request falls back to a fresh human approval, exactly as a request the drawdown policy does not authorize does (Section 5.1).¶

The review approval is an ordinary expansion approval that re-consents, or narrows, the ceiling. Its consent disclosure MUST render the chain's record since the prior review:¶

the drawdown count and rate;¶
the guard exceptions escalated to human approval;¶
the out_of_ceiling refusals;¶
the entries discharged under the status profile's completion machinery ([I-D.draft-mcguinness-oauth-mission-status]); and¶
where the metering profile runs, consumption against its bounds ([I-D.draft-mcguinness-mission-metering]).¶

Where consent evidence is claimed, that disclosure is committed like any other ([I-D.draft-mcguinness-oauth-mission-consent-evidence]), so the record shows the reviewer saw the cycle they renewed. The review is where decay is caught; Section 9 names the tells a reviewer checks the records for.¶

5.4. Realizing an approved access request

Progressive authorization grows authority that a deployment anticipated well enough to express as a ceiling. The runtime enforcement layer handles the unanticipated case: it can let an agent request authority it discovers it needs at the point of use, through an access-request and approval workflow ([I-D.draft-mcguinness-mission-runtime]). That workflow yields a permit for the single re-evaluated action. To persist the newly approved authority for the rest of the task, rather than have the agent re-request it on every call, the Mission Issuer MAY realize an approved access request as an expansion:¶

a request whose authority is within the Mission's consented ceiling is realized as a policy-adjudicated in-ceiling expansion (Section 5.1); and¶
a request whose authority exceeds the ceiling is realized only on the fresh human approval the request carries, as an ordinary expansion that creates the successor and, where the Approver consents, raises the ceiling.¶

Realizing a request as an expansion is subject to every rule of the expansion profile: the successor's authority is freshly derived and bound, the predecessor is superseded, and authority is never widened without the consent the request carries ([I-D.draft-mcguinness-oauth-mission-expansion]). An access request not realized as an expansion grants only the single runtime permit and no durable Mission authority.¶

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

The record MUST carry the chain's cumulative drawdown count, so the rate bound of Section 5.1 is auditable from the records alone. A deployment MUST retain the consented authority_ceiling, drawdown_policy, and ceiling_hash with every Mission record in the chain for the audit horizon, so an auditor can verify every drawdown was within the consented envelope.¶

Where a drawdown is triggered by the agent encountering a resource not named at approval, and the resource self-declares its operations and consequences in a content-addressed form (an AAuth deployment adopting Rich Resource Requests composes one such substrate, [I-D.draft-mcguinness-mission-aauth]), the adjudication MUST evaluate the declaration against the ceiling. The record of such a drawdown MUST carry the declaration's digest as resource_declaration_digest, so the encounter is reproducible in audit: what the resource claimed to be when authority bound to it.¶

The discovery companion ([I-D.draft-mcguinness-mission-discovery]) defines the encounter adjudication contract, the identity pinning, and the floors this drawdown path carries.¶

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

for a Mission whose Approver consented to a ceiling, record the 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);¶
bound each policy-adjudicated drawdown incrementally, so a single drawdown never activates the entire remaining ceiling, and publish the concrete per-drawdown bound in the Mission Deployment Profile (Section 5.1);¶
enforce the prohibited-class rule, requiring a fresh human approval for a drawdown that grants irreversible, external-commitment, or privileged-administration authority, that satisfies the external-communication predicate, or that grants cross-domain authority, and publish the action-class mapping in the Mission Deployment Profile (Section 5.1);¶
require a fresh human approval for an in-ceiling drawdown while the predecessor has non-terminal Child Missions (Section 5.1);¶
rate-bound policy-adjudicated drawdowns per expansion chain, keyed by the chain's root Mission and counted across predecessor links, publish the concrete rate bound in the Mission Deployment Profile, and record each as an approval event carrying the chain's cumulative drawdown count (Section 5.1, Section 7); and¶
bound each chain by the published ceiling review cadence, refusing policy adjudication past it and rendering the chain's record since the prior review in the review approval's disclosure (Section 5.3).¶

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.¶
Consent decays even when nothing is misconfigured: the drawdown and rate bounds cap rate, not duration, and the ceiling review (Section 5.3) is the temporal bound. The tells of decay are checkable from the chain's own records: reviews that never narrow the ceiling, ceilings that only grow, guard exceptions trending toward zero because the policy was quietly widened, and discharge that never fires because no unit of work is scoped tightly enough to complete. A review that cannot cite the evidence of the cycle it renews has not reviewed it.¶

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 requests one registration in the expansion profile's Mission Denial Reasons registry ([I-D.draft-mcguinness-oauth-mission-expansion]): out_of_ceiling, with the semantics of Section 6 and Reference this document. Beyond that, 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

12.1. Normative References

[I-D.draft-mcguinness-mission-runtime]: McGuinness, K., "Mission-Bound Runtime Enforcement", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-runtime.html>.
[I-D.draft-mcguinness-oauth-mission]: McGuinness, K., "Mission-Bound Authorization for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission.html>.
[I-D.draft-mcguinness-oauth-mission-expansion]: McGuinness, K., "Mission Expansion for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-expansion.html>.
[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>.
[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>.

12.2. Informative References

[I-D.draft-mcguinness-mission-aauth]: McGuinness, K., "Mission Context Binding for AAuth", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-aauth.html>.
[I-D.draft-mcguinness-mission-architecture]: McGuinness, K., "An Architecture for Mission-Bound Authorization", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-architecture.html>.
[I-D.draft-mcguinness-mission-discovery]: McGuinness, K., "Mission Open-World Discovery", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-discovery.html>.
[I-D.draft-mcguinness-mission-metering]: McGuinness, K., "Mission Consumption Metering", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-metering.html>.
[I-D.draft-mcguinness-mission-security-model]: McGuinness, K., "Mission Security Model", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-security-model.html>.
[I-D.draft-mcguinness-oauth-mission-child-delegation]: McGuinness, K., "Mission Child Delegation for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-child-delegation.html>.
[I-D.draft-mcguinness-oauth-mission-consent-evidence]: McGuinness, K., "Mission Consent Evidence for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-consent-evidence.html>.
[I-D.draft-mcguinness-oauth-mission-status]: McGuinness, K., "Mission Status and Lifecycle for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-status.html>.

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

Karl McGuinness

Independent

Email: public@karlmcguinness.com