Web Authorization Protocol K. McGuinness Internet-Draft Independent Intended status: Experimental 4 October 2026 Expires: 7 April 2027 Mission Progressive Authorization for OAuth 2.0 draft-mcguinness-oauth-mission-progressive-latest Abstract Mission Expansion for OAuth 2.0 widens an agent's authority only through a fresh human approval that creates a successor Mission. 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. This document defines an experimental third option, progressive authorization: at the initial approval the Approver additionally consents to a bounded authority ceiling and a drawdown policy, and the Mission Issuer may then adjudicate an expansion that stays within that ceiling by policy rather than by a fresh human approval. Authority can grow within the consented envelope at runtime while the active authority any single Mission yields stays narrow. Authority classes named by the runtime profile's high-consequence classification, and the external-communication exfiltration leg, always require a fresh human approval, even within the ceiling. A single drawdown never activates the whole ceiling: each is bounded incrementally. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://mcguinness.github.io/mission-bound-authorization/draft- mcguinness-oauth-mission-progressive.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- mcguinness-oauth-mission-progressive/. Source for this draft and an issue tracker can be found at https://github.com/mcguinness/mission-bound-authorization. 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 7 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 2. Relationship to the Expansion Profile 3. Conventions and Terminology 4. Progressive Authorization 4.1. In-ceiling expansion 4.2. What it bounds, and what it does not 4.3. The Ceiling Review 4.4. Realizing an approved access request 5. The out_of_ceiling Denial Reason 6. Audit Linkage 7. Conformance 8. Security Considerations 9. Privacy Considerations 10. IANA Considerations 11. References 11.1. Normative References 11.2. Informative References Appendix A. Document History Acknowledgments Author's Address 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 4.1). 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. 2. 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. 3. 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 4). This bound is distinct from the template profile's Template Ceiling on Missions dispatched from a template and from the shaping companion's caller-supplied shaping ceiling on a proposal ([I-D.draft-mcguinness-oauth-mission-template], [I-D.draft-mcguinness-mission-shaping]). 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 4). 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. 4. 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 4.1); and * a *drawdown policy*, recorded as a drawdown_policy member on the Mission: an activation policy reference, an object of id, version, and digest ([I-D.draft-mcguinness-oauth-mission], Section "Standing-Consent Bases"), identifying the policy under which the Mission Issuer MAY adjudicate an in-ceiling expansion by policy rather than by a fresh human approval, and committing its content. The policy's content is deployment-defined. Because ceiling_hash covers this member, the ceiling commits the exact policy the human consented to, and the Mission Issuer verifies its digest before each policy-adjudicated drawdown under that section's rule. 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 activation policy reference object), 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 object. 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]). 4.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 Mission's drawdown_policy.id) and policy_version (its drawdown_policy.version, the version whose content drawdown_policy.digest commits and this adjudication evaluated), 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. Its record's approval_event_id identifies this drawdown, never the ceiling consent: a unique value the Mission Issuer allocates when it creates the exchange's (client, creation_request_id) reservation and retains with the committed successor ([I-D.draft-mcguinness-oauth-mission-expansion], Section "Creation Idempotency"). A retry recovers it; a reservation created after that key's tombstone expires receives a new one. 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. The issuance profile's fourth high-risk class, a consumption bound ([I-D.draft-mcguinness-oauth-mission]), is not held back here: a successor continues its predecessor's consumption counters, and a policy-adjudicated successor cannot raise a bound ([I-D.draft-mcguinness-mission-metering]), so a drawdown widens authority within the ceiling without granting new capacity. The ceiling_drawdown approval_basis already carries the trace the issuance profile's approval-authentication floor requires for that class, through the consent_principal and approved_at fields this section defines; a deployment recording Consent Evidence renders the bound at the same surface under the metering profile's consent- integrity rule ([I-D.draft-mcguinness-mission-metering]). Where a deployment adopts Approval Governance ([I-D.draft-mcguinness-mission-approval-governance]) and records a Governance Record for a policy-adjudicated drawdown, the ceiling_drawdown approval_basis satisfies that profile's accountable- approver rule directly, through the same consent_principal, root_commitment, and approved_at this document already requires: no assertion is fabricated in the name of the requesting client or the drawdown policy to stand in for a fresh human decision that did not occur. Approval Governance's own high-risk-class default still binds that record: a policy-adjudicated drawdown carrying a consumption bound activates only where a committed, class-named exception admits it; absent the exception, the Mission fails to activate under that profile's atomic-commitment rule. A drawdown that passes every policy-adjudication guard of this section completes synchronously in the token-exchange response ([I-D.draft-mcguinness-oauth-mission-expansion], Section "The Expansion Request"), which returns the successor's access token. The successor is still created through the full approval-event machinery of the expansion profile, under the ceiling_drawdown basis; only the interactive prompt is skipped. The Mission Issuer MUST commit the successor's activation, the predecessor's supersession, and the creation reservation, applying the expansion profile's activation checks in that same atomic step, before it delivers the response. A lost response is recovered through creation_request_id ([I-D.draft-mcguinness-oauth-mission-expansion], Section "Creation Idempotency"). A drawdown that falls back to a fresh human approval completes deferred or interactively, as any expansion does. 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 5), 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 6). 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. A drawdown policy snapshot that does not match drawdown_policy.digest authorizes nothing, so a request under it falls back the same way. The drawdown policy MUST NOT policy-adjudicate a successor whose complete Authority Set, including authority carried forward from its predecessor, overlaps in authority the authority a discharge restriction of its expansion chain covers ([I-D.draft-mcguinness-oauth-mission-discharge]). The test is overlap in authority, not structural equality or entry identity. Such a request falls back to a fresh human approval whose consent disclosure names the discharged entry and the condition that discharged it. The Mission Issuer MUST apply this test to every drawdown in the chain after the discharge, not only to one from the Mission that holds the discharged entry, and neither an approval of unrelated authority nor a ceiling review clears the restriction (Section 4.3). Completion-discharged authority therefore cannot be resurrected by policy. The drawdown policy MUST NOT policy-adjudicate a successor whose complete Authority Set, including authority carried forward from its predecessor, overlaps in authority capability under a containment restriction of its expansion chain ([I-D.draft-mcguinness-oauth-mission-containment]). Such a request falls back to a fresh human approval whose consent disclosure names the contained capability and the event class that caused its containment. The Mission Issuer MUST apply this test to every drawdown in the chain after the containment, not only to one from the Mission that holds the overlay, and neither an approval of unrelated authority nor a ceiling review clears the restriction (Section 4.3). A drawdown whose authority overlaps no restricted capability remains eligible for policy adjudication under the other guards of this section. Contained authority therefore cannot be restored by policy. Both tests are re-applied at successor activation, so a containment or discharge that lands after adjudication is caught there ([I-D.draft-mcguinness-oauth-mission-expansion], Section "Concurrent Expansion Reconciliation"). 4.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 4.1), recorded for audit (Section 6), 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 8 states. 4.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 4.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 4.1). The cadence is a recency ceiling on the ceiling_drawdown approval basis's approved_at, the kind of declared maximum standing-consent age the issuance profile permits a deployment to declare ([I-D.draft-mcguinness-oauth-mission]); this profile makes publishing one mandatory rather than optional. The cadence is part of the drawdown policy's own versioned content: a deployment's drawdown policy document MUST state the cadence effective under a given version, identified by the policy_id and policy_version the ceiling_drawdown activation carries (Section 4), per the issuance profile's own rule that a mutable, unversioned value MUST NOT serve this role. Because ceiling_hash commits that policy's digest, the cadence is anchored with it: changing the cadence changes the policy snapshot, so a drawdown under the changed policy no longer matches the committed digest and falls back to a fresh human approval until a review approval re-consents the ceiling under the new policy. An auditor recovers the cadence that governed a given drawdown from the retained snapshot that digest names, exactly as it resolves the drawdown logic itself. 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 Entry Discharge companion's completion machinery ([I-D.draft-mcguinness-oauth-mission-discharge]), and the chain's outstanding discharge restrictions, which re-consenting the ceiling does not clear; * the chain's outstanding containment restrictions, each with its contained capability and the event class that caused it ([I-D.draft-mcguinness-oauth-mission-containment]), which re- consenting the ceiling does not clear; 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 8 names the tells a reviewer checks the records for. 4.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 4.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. 5. 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 4), 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. 6. 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 4.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 and, by resolving the retained drawdown policy document at the policy_version each drawdown's ceiling_drawdown approval basis already records, against the cadence that applied when it was adjudicated (Section 4.3). 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. 7. 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 4); * 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 4.1, Section 5); * 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 4.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 4.1); * require a fresh human approval for an in-ceiling drawdown while the predecessor has non-terminal Child Missions (Section 4.1); * require a fresh human approval for a drawdown whose complete Authority Set overlaps authority under a containment or discharge restriction of its chain, from any Mission in the chain (Section 4.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 4.1, Section 6); 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 4.3); state the cadence effective under each drawdown policy version in that policy's own versioned content (Section 4.3). 8. 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 4.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 6). * 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 4); 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 4.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. 9. 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. 10. 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 5 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. 11. References 11.1. Normative References [I-D.draft-mcguinness-mission-runtime] McGuinness, K., "Mission-Bound Runtime Enforcement", 2026, . [I-D.draft-mcguinness-oauth-mission] McGuinness, K., "Mission-Bound Authorization for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-expansion] McGuinness, K., "Mission Expansion for OAuth 2.0", 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 11.2. Informative References [I-D.draft-mcguinness-mission-aauth] McGuinness, K., "Mission Context Binding for AAuth", 2026, . [I-D.draft-mcguinness-mission-approval-governance] McGuinness, K., "Mission Approval Governance", 2026, . [I-D.draft-mcguinness-mission-architecture] McGuinness, K., "An Architecture for Mission-Bound Authorization", 2026, . [I-D.draft-mcguinness-mission-discovery] McGuinness, K., "Mission Open-World Discovery", 2026, . [I-D.draft-mcguinness-mission-metering] McGuinness, K., "Mission Consumption Metering", 2026, . [I-D.draft-mcguinness-mission-security-model] McGuinness, K., "Mission Security Model", 2026, . [I-D.draft-mcguinness-mission-shaping] McGuinness, K., "Mission Intent Shaping", 2026, . [I-D.draft-mcguinness-oauth-mission-child-delegation] McGuinness, K., "Mission Child Delegation for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-consent-evidence] McGuinness, K., "Mission Consent Evidence for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-containment] McGuinness, K., "Mission Containment for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-discharge] McGuinness, K., "Mission Entry Discharge for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-template] McGuinness, K., "Mission Template for OAuth 2.0", 2026, . Appendix A. Document History [[ To be removed from the final specification ]] -01 * In-ceiling expansion: a ceiling_drawdown successor's approval_event_id identifies the drawdown: a unique value allocated with the exchange's (client, creation_request_id) reservation and retained with the successor, so a retry recovers it and reuse of the key after its tombstone expires receives a new one; no new member (#1017). * In-ceiling expansion: a drawdown that passes every policy- adjudication guard completes synchronously in the token-exchange response, committing activation, supersession and the creation reservation before the response; the undefined request_uri redemption is removed. * In-ceiling expansion: the discharge guard tests the complete successor Authority Set against the chain's discharge restrictions, from any later Mission, and the ceiling review discloses outstanding discharge restrictions. * In-ceiling expansion: a policy-adjudicated drawdown whose complete Authority Set overlaps capability under a containment restriction of its chain falls back to a fresh human approval naming the contained capability and its cause, from any later Mission in the chain; the ceiling review discloses outstanding restrictions and does not clear them. * drawdown_policy is an activation policy reference (id, version, digest) under the issuance profile's Standing-Consent Bases, replacing the string or URI and the SHOULD to commit the policy body; ceiling_hash covers the object, and a snapshot that does not match falls back to a fresh human approval. The ceiling_drawdown activation maps to drawdown_policy.id and .version, and the review cadence, part of the policy content, is anchored with it. * The consumption-bound rationale rests on the metering profile's successor rule: a successor continues its predecessor's counters, and a policy-adjudicated successor cannot raise a bound. * Editorial: disambiguated authority_ceiling from the template profile's Template Ceiling and the shaping companion's shaping ceiling at its first definition (Section 3), no normative change. * Mirrored the OAuth binding's Mission Template uncommitted-policy- body pattern onto drawdown_policy: a SHOULD to additionally commit the policy body under an integrity anchor or disclose it under Consent Evidence (Section 4). Reframed the ceiling review cadence as a recency ceiling on the ceiling_drawdown approval basis's approved_at, reproducible from the drawdown policy's own versioned content identified by the existing policy_id/policy_version rather than a new commitment or a new, separately versioned member (Section 4.3, Section 6). 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