Mission Expansion 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 26 December 2026.¶

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 "issuance profile") makes a Mission a first-class OAuth artifact: a structured, human-approved, integrity-bound task whose authority bounds and outlives every token an agent derives. It commits the Authority Set once, at the approval event, and deliberately defines no mid-stream authorization upgrade. As that profile states, widening authority requires a new approval, a successor Mission; just-in-time expansion is named as future work.¶

This document is that successor mechanism. A task an agent pursues does not always stay within the authority approved for it: the agent encounters an action the approved Authority Set does not cover, yet one the deployment's governance policy would permit under a fresh consent. Expansion is the governed path from that shortfall to a new approval. It does not patch or widen the existing Mission; it creates a new Mission, through the issuance profile's own flow, linked to the one it replaces.¶

The mechanism reuses the issuance profile end to end. An expansion is a new Mission Intent submitted through Pushed Authorization Requests ([RFC9126]), bound to the predecessor Mission's grant, leading to a fresh approval event ([I-D.draft-mcguinness-oauth-mission]) with its own intent_hash, authority_hash, and Mission record. The successor's authority comes only from that approval. This document adds exactly three things on top of the issuance profile: a way to bind an expansion request to the predecessor it expands; a predecessor lineage member on the resulting Mission; and a terminal superseded predecessor state with the reconciliation rules that keep concurrent expansions consistent.¶

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

All JSON shown in this document is non-normative and illustrative; the member definitions in the surrounding text are authoritative.¶

The following terms apply in addition to those inherited from the issuance profile (Section 1.3).¶

Predecessor Mission:

The active Mission an expansion enlarges. It is the baseline for the successor and is referenced by the successor's mission.predecessor member (Section 7).¶

Successor Mission:

The Mission a replacement expansion creates through a fresh approval event. It carries its own Authority Set, integrity anchors, and mission_id, and a predecessor member linking it to the predecessor (Section 7).¶

Expansion request:

A Mission Intent submitted via PAR, bound to a predecessor Mission's grant, that asks the Mission Issuer to adjudicate a successor (Section 4).¶

3. Expansion Overview

 Agent (client)               Mission Issuer (AS)
     |                            |
     | denied: action outside     |
     | active Mission's authority |
     |                            |
     | 1. PAR: mission_intent +   | resolve predecessor
     |    predecessor grant -----> | from the grant;
     |    <----- request_uri ----- | gate predecessor active
     |                            |
     | 2. authorization request ->| fresh consent for the
     |                            | broader authority
     |    <-------- code --------- | -> successor active
     |                            |    -> predecessor
     |                            |       superseded (atomic)
     |                            |
     | 3. token request --------> | derive under successor
     |    <----- access token ---- | (mission.predecessor set)
     v

4. The Expansion Request

An expansion request is an ordinary Mission creation request under the issuance profile, with one added binding to the predecessor.¶

5. Adjudication

Adjudication of an expansion is a fresh approval event under the issuance profile ([I-D.draft-mcguinness-oauth-mission]). The Mission Issuer runs the approval event as it does for any Mission, with the expansion-specific steps noted:¶

1. Resolve the predecessor from the presented grant and verify it is the Mission named in predecessor and is active (Section 4.2, Section 4.3).¶

2. Derive the successor's Authority Set from the submitted Mission Intent and bound it by policy, exactly as for any Mission. The successor's authority is whatever this derivation and the fresh consent yield; it is not the predecessor's authority plus a delta computed by this document. A deployment that wants the successor to retain the predecessor's authority expresses that authority in the expansion Mission Intent so the derivation reproduces it.¶

3. Authenticate the Approver and obtain fresh consent for the derived Authority Set, satisfying any context.acr, and render the Subject when the Approver is not the Subject, per the issuance profile's approval event. The consent disclosure MUST reflect the successor's authority being adjudicated. For an in-ceiling expansion under progressive authorization, this consent MAY be satisfied by policy rather than a fresh human approval, within the limits of Section 6.1.¶

4. Compute the successor's integrity anchors (intent_hash, authority_hash) and create the successor Mission record in the active state, with its predecessor member set (Section 7), atomically with the predecessor's transition to superseded (Section 8).¶

The expansion is governed by the consent obtained at step 3. Expansion never widens authority without a new consent: if the Approver declines, no successor is created and the predecessor is untouched (Section 11).¶

6. Progressive Authorization

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

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

• an authority ceiling: the maximum authority any expansion of this Mission may reach without a further human approval, expressed as an Authority Set, or as the constraints that bound one ([I-D.draft-mcguinness-oauth-mission]), that every in-ceiling successor MUST be a subset of; and¶

• a drawdown policy: the conditions under which the Mission Issuer MAY adjudicate an in-ceiling expansion by policy rather than by a fresh human approval.¶

Where present, the ceiling and drawdown policy are recorded on the Mission and committed under their own integrity anchor, not 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. A Mission that carries no ceiling has no progressive authorization: every expansion of it is an ordinary, freshly approved expansion.¶

7. The predecessor Member

The successor records a lineage link to the predecessor as a predecessor member, both on the successor's mission claim and on the successor's Mission record.¶

The issuance profile's mission claim is an open object: additional members MAY appear alongside id, origin, and authority_hash, each defined by the profile that introduces it, and a consumer MUST ignore members it does not understand and MUST NOT use any additional member to grant or widen authority ([I-D.draft-mcguinness-oauth-mission]). This document introduces one such member:¶

predecessor:

REQUIRED on a successor Mission; absent otherwise. A string. The mission_id of the Mission this Mission succeeded by expansion. Present on every Mission created by expansion and absent on a Mission that was not created by expansion. It is a lineage and audit reference only: it links the successor to the Mission it replaced so that the expansion chain is observable in audit. Consistent with the issuance profile's open-mission-claim rule, predecessor MUST NOT grant or widen authority, and a consumer that does not understand it MUST ignore it. The successor's authority comes only from its own authority_hash, never from its predecessor.¶

The same predecessor value is recorded on the successor's immutable Mission record so that the lineage is durable independently of any derived token.¶

Properties:¶

• Cardinality. A successor has at most one predecessor. An expansion chain is expressed by walking predecessor links from a successor back toward the original Mission.¶

• Immutability. predecessor is set at the successor's approval event and MUST NOT change thereafter; the Mission record is immutable except for its state.¶

• Origin. The predecessor and successor share an origin: an expansion is adjudicated by the predecessor's Mission Issuer. A consumer correlating a chain resolves each link at that origin.¶

Example successor mission claim on a derived token (non-normative; other token claims omitted):¶

{
  "mission": {
    "id": "msn_2Yt7Qv9LqMv4z7sA2bN1k0YpEdHc9RfX",
    "origin": "https://as.example.com",
    "authority_hash":
      "sha-256:Td9bM7sX1cF8gH2vJ4kE5pNQl3KvZ4mP5x0wQrR6tY2",
    "predecessor": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-"
  }
}

8. The superseded Predecessor State

This document adds one terminal state to the issuance profile's lifecycle, used only by expansion:¶

superseded:

A predecessor Mission that a successor has replaced through a replacement expansion. Terminal and non-active.¶

A deployment that never expands a Mission never produces this state; the issuance profile's active/revoked/expired lifecycle is unchanged for it. The transition is:¶

The transition has these requirements:¶

• Atomic with successor activation. The predecessor enters superseded in the same atomic operation that activates the successor (Section 5). If that operation fails, the predecessor remains active and no successor record exists; the Mission Issuer MUST NOT produce a partial successor or a predecessor left in an indeterminate state.¶

• Non-active: no further derivation. A superseded Mission is not active, so the issuance profile's issuance gating refuses to derive any new token, refresh, token exchange, or cross-domain grant under it: derivation proceeds only from an active Mission ([I-D.draft-mcguinness-oauth-mission]). New authority for the task flows through the successor.¶

• Already-issued predecessor tokens. Tokens already derived under the predecessor before it was superseded remain valid until their own exp, exactly as in the issuance profile's revocation model: superseding a Mission stops new derivation; it does not retroactively invalidate access tokens already issued. A deployment that needs a lower cutoff latency on the predecessor's outstanding tokens SHOULD use short token lifetimes, and MAY additionally revoke the predecessor's refresh token where the issuance profile's optional revocation composition is in use. These tokens MUST NOT be silently rebound to the successor; authority under the successor is obtained only by deriving from the successor's grant, which is a new derivation governed by the successor's Authority Set.¶

• Reported as non-active. A superseded predecessor is reported through the same mechanisms that report a revoked or expired Mission. Where the issuance profile's optional token introspection is offered, the composite active is false and, from the origin, the mission.state member gives superseded. Where the Mission Status profile [I-D.draft-mcguinness-oauth-mission-status] is deployed, the dedicated Status operation reports superseded among the terminal states and the Status Response mission.state gives superseded. A deployment that offers either surface and this document MUST include superseded among the lifecycle states its origin may report. Consumers rely on the issuance profile's forward-compatibility rule: superseded, like any non-active state, is non-deriving.¶

9. Replacement Expansion

A successful expansion is a replacement: the successor replaces the predecessor, and the predecessor becomes superseded (Section 8). Replacement is the only mode this document defines.¶

Under replacement, exactly one successor is created per predecessor, and the predecessor is no longer active once the successor activates. The successor carries its own complete Authority Set as derived and consented at the expansion approval event; it does not inherit the predecessor's authority by reference. A deployment that wants the successor to retain the predecessor's authority alongside the new authority expresses the combined authority in the expansion Mission Intent, so the successor's authority_hash commits exactly the authority the Approver saw and approved (Section 5).¶

A branch mode, in which the predecessor and the successor both remain active after expansion (for example, a separately scoped child task running alongside the original), is OPTIONAL and is not defined here. A deployment that needs a separately scoped task alongside a still-active Mission creates an ordinary new Mission under the issuance profile and MAY set that Mission's predecessor member to the original Mission's mission_id to preserve lineage; doing so does not supersede the original, which remains active. An atomic, grant-bound branch expansion that creates such a child within a single expansion approval event is deferred to a future revision of this document.¶

10. Concurrent Expansion Reconciliation

More than one expansion request MAY be in flight against the same predecessor at once. Because replacement produces exactly one successor per predecessor (Section 9), the Mission Issuer MUST serialize adjudications against the same predecessor so that concurrent expansions cannot each produce a successor.¶

The Mission Issuer MUST serialize expansion adjudications against the same predecessor with compare-and-set semantics. At the moment of adjudication, in the same atomic step that would activate the successor and supersede the predecessor, the Mission Issuer MUST verify:¶

1. the predecessor resolved from the presented grant is still in the active state; and¶

2. no other replacement expansion has already produced a successor for this predecessor (equivalently, the predecessor has not already transitioned to superseded).¶

If either check fails, the Mission Issuer MUST refuse the request with invalid_grant and the applicable reconciliation status from the closed set below. The losing or otherwise stale expansion request is rejected; it does not produce a second successor.¶

The reconciliation status codes are:¶

superseded_by_concurrent_expansion:

A concurrent replacement expansion has already produced a successor; the predecessor is now superseded rather than active. The client SHOULD discover the existing successor and re-evaluate whether a further expansion is still required (an expansion of the successor is a new expansion against the successor as predecessor).¶

predecessor_state_changed:

The predecessor transitioned out of active (to revoked, expired, or superseded) before this request could be adjudicated, including the cases caught at request binding (Section 4.3). The client MUST NOT retry the same expansion against this predecessor.¶

The two codes overlap in the superseded case by design: superseded_by_concurrent_expansion is the specific reconciliation outcome when the cause is a concurrent expansion that has already won, and predecessor_state_changed is the general outcome for any other exit from active. A Mission Issuer SHOULD return the specific code when it can attribute the change to a concurrent expansion.¶

How the reconciliation status is conveyed to the client alongside the invalid_grant error is a deployment matter; it MAY be carried in the OAuth error response's error_description or an implementation-defined member. This document defines the symbolic codes and their meaning, not a wire location for them.¶

11. Expansion Denial Reasons

An adjudication that completes with the Approver declining, or with the Mission Issuer refusing on policy grounds, denies the expansion: no successor is created and the predecessor remains active and untouched. Such a denial is an OAuth error at the approval or token step per the issuance profile (typically invalid_request for a request the Mission Issuer will not derive a valid Authority Set from, or the approval flow's own decline path). It MAY additionally carry one machine-readable reason code from the closed set below:¶

out_of_policy:

The Mission Issuer's governance policy refuses the requested authority class for this Mission, independent of who approves.¶

approver_rejected:

The Approver declined the expansion at the consent step.¶

out_of_scope_for_purpose:

The requested authority is incompatible with the Mission's recorded purpose; a different Mission, not an expansion of this one, is the appropriate vehicle.¶

out_of_ceiling:

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

A Mission Issuer MUST NOT use a reason code to disclose policy boundaries beyond the adjudicated request (Section 13.5); omitting the reason code is always permitted. As with reconciliation status, the wire location of a reason code is a deployment matter.¶

Two failure classes are not denial reasons and use the issuance profile's error vocabulary directly: an expansion request whose predecessor does not match the grant-resolved Mission, or whose predecessor is not active, fails with invalid_grant (Section 4.2, Section 4.3); an expansion Mission Intent the Mission Issuer cannot parse or cannot derive a valid Authority Set from fails with invalid_request or, where the issuance profile uses it, invalid_authorization_details ([RFC9396]), exactly as for any Mission creation.¶

12. Conformance

An implementation claims conformance to this document only in the Mission Issuer role and only when it adjudicates expansion. A conforming expansion-capable Mission Issuer MUST:¶

• accept the predecessor and predecessor_token request parameters on a Mission creation via PAR and treat the request as an expansion (Section 4.1);¶

• bind the expansion request to the predecessor's grant and refuse a request whose predecessor does not match the grant-resolved Mission, or whose predecessor is not active, with invalid_grant (Section 4.2, Section 4.3);¶

• adjudicate the expansion as a fresh approval event that obtains new consent for the successor's authority (Section 5), enforcing the successor-expiry rule (Section 5.1);¶

• record the predecessor member on the successor's mission claim and Mission record (Section 7);¶

• transition the predecessor to superseded atomically with successor activation, and refuse further derivation under a superseded Mission (Section 8); and¶

• serialize concurrent expansions against the same predecessor with the reconciliation semantics of Section 10.¶

An expansion-capable Mission Issuer is also a conforming issuance-profile Mission Issuer ([I-D.draft-mcguinness-oauth-mission]); this document adds the expansion surface to that role. A Resource Server requires no new behavior: it enforces a successor's tokens exactly as it enforces any Mission-bound token, and treats the predecessor member, if it reads it at all, as audit context it MUST NOT use to grant authority (Section 7).¶

13. Security Considerations

Expansion's central guarantee is the issuance profile's, applied to the successor: a user's fresh approval bounds every token derived for the broadened task. The risks specific to expansion are in the predecessor binding, the predecessor-to-successor handoff, and the lineage link.¶

14. Privacy Considerations

The privacy surface expansion adds over the issuance profile is the lineage link and the authority detail disclosed when a task is broadened.¶

15. IANA Considerations

Consistent with the issuance profile, which establishes no registry of mission claim members and registers the mission claim as an open object, this document defines the predecessor member of the mission claim (Section 7) without registering it in a dedicated registry: it is a member defined by this profile, carried inside the already-registered mission claim. No new claim, parameter, or token-introspection registration is required for the lineage link.¶

This document defines two closed sets of symbolic codes: the expansion reconciliation status codes (Section 10) and the expansion denial reasons (Section 11). Like the issuance profile's restraint with mission members, these are documented in this specification rather than placed in new IANA registries: they are conveyed inside existing OAuth error responses at deployment-defined locations, not on a new wire surface, and the closed sets are small and fully specified here. Should interoperable extension of either set prove necessary, a future revision can create a "Mission Expansion Reconciliation Status" registry and a "Mission Expansion Denial Reason" registry with a Specification Required [RFC8126] policy; this document does not create them.¶

This document registers two parameters in the "OAuth Parameters" registry:¶

• Name: predecessor¶

• Parameter Usage Location: authorization request¶

• Change Controller: IETF¶

• Reference: this document, Section 4.1¶

• Name: predecessor_token¶

• Parameter Usage Location: authorization request¶

• Change Controller: IETF¶

• Reference: this document, Section 4.1¶

As with mission_intent in the issuance profile, PAR [RFC9126] carries authorization-request parameters without a distinct usage location, so the pushed submission of these parameters needs no separate registration. predecessor_token carries a refresh token and MUST be submitted only through PAR, never on a front-channel authorization request (Section 4.1).¶

Acknowledgments

The author thanks the reviewers of the Mission-Bound Authorization for OAuth 2.0 profile for feedback on the expansion model and its composition with the issuance flow.¶

References

Author's Address