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 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-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, as specified by this companion profile.¶

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

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

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 controls.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. (The experimental progressive authorization companion defines a policy-adjudicated override of this step for expansions within a pre-consented ceiling, [I-D.draft-mcguinness-oauth-mission-progressive].)¶

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 6), atomically with the predecessor's transition to superseded (Section 7).¶

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

6. The Predecessor Mission Reference

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

This document defines two further lineage members:¶

related_to:

OPTIONAL. A string. The mission_id of a Mission this Mission is related to by lineage without superseding it, used for a non-superseding link such as a branch (Section 8). Unlike predecessor, its presence does not imply that the referenced Mission was superseded and it carries no lifecycle consequence. Like predecessor, it is lineage and audit context only: it MUST NOT grant or widen authority, and a consumer that does not understand it MUST ignore it.¶

successor:

OPTIONAL. A string. The mission_id of the successor that superseded this Mission by expansion, recorded on the superseded predecessor's Mission record at supersession (Section 7). It is the reverse of the successor's predecessor link, letting a consumer that holds a superseded predecessor discover its successor directly. It is lineage and audit context only and MUST NOT grant or widen authority. The Status profile surfaces it in the status response ([I-D.draft-mcguinness-oauth-mission-status]) and the Signals profile in the superseded lifecycle event ([I-D.draft-mcguinness-oauth-mission-signals]).¶

predecessor, related_to, and successor are each a bare Mission Identifier string, not an object like the parent member of a Child Mission ([I-D.draft-mcguinness-oauth-mission-child-delegation]): same-issuer succession needs only the identifier to resolve the linked Mission at the shared issuer, whereas parentage carries cascade semantics and cross-object integrity that require a structured member.¶

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 and the one-time successor link a supersession sets on the predecessor (Section 7).¶

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

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

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

7. 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), and in that same operation the Mission Issuer sets the predecessor's successor member to the successor's mission_id (Section 6). 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 issuer, 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 issuer may report. Consumers rely on the issuance profile's forward-compatibility rule: superseded, like any non-active state, is non-deriving.¶

8. Replacement Expansion

A successful expansion is a replacement: the successor replaces the predecessor, and the predecessor becomes superseded (Section 7). 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 related_to member (Section 6) to the original Mission's mission_id to preserve lineage; it does not set predecessor, which would imply a supersession, so the original 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.¶

9. 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 8), 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 made a terminal exit from 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.¶

predecessor_not_active:

The predecessor is in a non-terminal non-active state (for example suspended under the Mission Status profile [I-D.draft-mcguinness-oauth-mission-status]) and cannot be expanded until it returns to active. The client MAY retry the expansion after the predecessor is active again.¶

The two terminal-exit 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 terminal exit from active. A Mission Issuer SHOULD return the specific code when it can attribute the change to a concurrent expansion. predecessor_not_active is distinct from both: it reports a reversible, non-terminal state, so it invites the retry the terminal codes forbid.¶

The Mission Issuer conveys the reconciliation status in a mission_expansion_status member of the OAuth error response body, alongside the invalid_grant error:¶

mission_expansion_status:

A string carrying one code from this document's closed sets: a reconciliation status (Section 9) or an expansion denial reason (Section 10). It is returned in the error response of the step that failed: the PAR error response for a binding or reconciliation failure, and the approval or token error response for a denial.¶

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

A companion profile MAY extend this set by specification (the experimental progressive authorization companion defines out_of_ceiling, [I-D.draft-mcguinness-oauth-mission-progressive]); a consumer MUST treat an unrecognized reason code as a denial with no further semantics.¶

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. When present, a reason code is carried in the mission_expansion_status member of the OAuth error response body (Section 9), the same member that carries a reconciliation status.¶

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

11. Worked Example

The Q3 reconciliation Mission msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9- authorizes reading invoices and posting journal entries under $500. Mid-task the agent finds an adjustment of $1,200, outside the active Mission's authority. It cannot widen in place; it requests an expansion, submitting a new Mission Intent through PAR bound to the predecessor's grant:¶

POST /par HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

mission_intent=%7B...journal-entries%20cap%20%242000...%7D&
predecessor=msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-&
predecessor_token=<refresh%20token%20bound%20to%20the%20predecessor>&
client_id=s6BhdRkqt3

The Mission Issuer resolves the predecessor from the grant, confirms it matches predecessor and is active, derives the successor's Authority Set, and obtains fresh consent from alice for the widened cap. On approval it creates the successor active and supersedes the predecessor atomically. The successor's token carries a predecessor member:¶

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

The predecessor is now superseded: it derives no new tokens, its already-issued tokens run out their short lifetimes, and the task continues under the successor. The widening came only from alice's fresh consent; the successor's authority_hash commits the widened Authority Set it was actually approved for, not the predecessor's plus a delta.¶

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 6);¶

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

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

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

Under this document, every expansion is adjudicated by a fresh human approval. The experimental progressive authorization companion defines a further OPTIONAL capability, Expansion with Progressive Authorization, with its own conformance requirements ([I-D.draft-mcguinness-oauth-mission-progressive]).¶

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 6) 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 9) and the expansion denial reasons (Section 10), both conveyed in the mission_expansion_status member of the OAuth error response body (Section 9). mission_expansion_status is a member of the OAuth error response JSON body, not an OAuth protocol parameter, and is namespaced to this document's error responses, so it requires no registration. Like the issuance profile's restraint with mission members, the codes are documented in this specification rather than placed in new IANA registries: 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