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 11 February 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.2).¶

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 --------- | predecessor stays active
     |                            |
     | 3. token request --------> | first redemption:
     |    (redeem code)           | -> successor active
     |                            |    -> predecessor
     |                            |       superseded (atomic)
     |    <----- 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.¶

{
  "iss": "s6BhdRkqt3",
  "sub": "s6BhdRkqt3",
  "aud": "https://as.example.com",
  "iat": 1793607000,
  "exp": 1793607180,
  "jti": "rla_4mK7pQ2xV9rT6nL1sB",
  "mission_id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
  "mission_operation": "mission-expansion"
}

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.3, Section 4.4).¶

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 commit them in the authorization code the approval event issues; defer materializing the successor. On the first redemption of that authorization code (the successor's grant), 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). Until that redemption the predecessor remains active; an authorization code that is never redeemed or that expires creates no successor and leaves the predecessor active.¶

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

Supersession is a terminal exit from active, so it is a terminal cascade trigger for the predecessor's entire delegation tree under the child-delegation profile ([I-D.draft-mcguinness-oauth-mission-child-delegation]). When the predecessor has non-terminal Child Missions, the expansion consent disclosure SHOULD surface that fact as a material notice: at minimum the count of live Child Missions and that supersession terminates them. A child still needed after the expansion is re-created under the successor through ordinary child creation, in generation order. A deployment MAY additionally support an expansion-request parameter by which the client asks the Mission Issuer to refuse the expansion while live Child Missions exist.¶

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 links the successor to the Mission it replaced so that the expansion chain is observable in audit.¶

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

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. 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 lineage and audit context only. Consistent with the issuance profile's open-mission-claim rule, each of them MUST NOT grant or widen authority, and a consumer that does not understand one MUST ignore it. The successor's authority comes only from its own authority_hash, never from its predecessor.¶

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 at first redemption. The successor activates, and the predecessor enters superseded, in one atomic operation at the first redemption of the successor's authorization code (its grant), not at the approval event (Section 5). In that same operation the Mission Issuer sets the predecessor's successor member to the successor's mission_id (Section 6). Until that redemption the predecessor remains active.¶

  • An authorization code that is never redeemed or that expires activates no successor and leaves the predecessor active, so an unredeemed or expired code never strands the task's authority nor cascade-terminates the predecessor's Child Missions.¶

  • If the atomic 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.¶

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

  • A deployment that needs a lower cutoff latency on the predecessor's outstanding tokens SHOULD use short token lifetimes. It MAY additionally revoke the predecessor's refresh token where the issuance profile's optional revocation composition is in use.¶

• 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, and more than one MAY be adjudicated and hold an unredeemed authorization code. Because replacement produces exactly one successor per predecessor (Section 8) and supersession is deferred to first redemption (Section 7), the Mission Issuer MUST serialize the redemptions that would activate a successor of the same predecessor, so that concurrent expansions cannot each activate one.¶

The Mission Issuer MUST apply compare-and-set semantics at the first redemption of a successor's authorization code. In the same atomic step that would activate the successor and supersede the predecessor, the Mission Issuer MUST verify:¶

1. the predecessor is still in the active state; and¶

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

If either check fails, the Mission Issuer MUST refuse the redemption with invalid_grant and the applicable reconciliation status from the closed set below. The losing or otherwise stale expansion is rejected at redemption; it activates no 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 expansion could complete, whether caught at request binding (Section 4.4) or at the compare-and-set on first redemption (Section 9). 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 reconciliation status from this document's closed set (Section 9). It is returned by the step that failed. At the PAR and token endpoints it is a member of the JSON error response body, alongside the OAuth error member. On the front-channel authorization error response, which carries error parameters rather than a JSON body, it is carried as an error response parameter of the same name. Adjudication denial reasons ride the separate mission_denial_reason member (Section 10).¶

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 a mission_denial_reason member: at the PAR and token endpoints a member of the JSON error response body alongside the OAuth error member, on the front-channel authorization error response an error response parameter of the same name.¶

mission_denial_reason is the shared carrier for adjudication denial reasons across the profiles that mint a Mission related to an existing one: the child delegation profile ([I-D.draft-mcguinness-oauth-mission-child-delegation]) carries its own closed denial-reason set in the same member, and further such profiles do likewise. Each profile defines its values by specification; the unrecognized-code rule above applies to the member wherever it appears.¶

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.3, Section 4.4); 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_assertion=<Mission%20relationship%20assertion%20signed%20
  against%20the%20predecessor%27s%20cnf%20key>&
client_id=s6BhdRkqt3

The decoded predecessor_assertion (its signature omitted here):¶

{
  "iss": "s6BhdRkqt3",
  "sub": "s6BhdRkqt3",
  "aud": "https://as.example.com",
  "iat": 1793607000,
  "exp": 1793607180,
  "jti": "rla_4mK7pQ2xV9rT6nL1sB",
  "mission_id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
  "mission_operation": "mission-expansion"
}

The Mission Issuer resolves the predecessor from mission_id, verifies the assertion per Section 4.2.2 (its signature against that Mission's own recorded cnf, aud, lifetime, and unseen jti), confirms it matches predecessor and is active, derives the successor's Authority Set, and obtains fresh consent from alice for the widened cap, issuing an authorization code. When the client redeems that code, the Mission Issuer activates the successor and supersedes the predecessor atomically; until then the predecessor stays active. 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_assertion request parameters on a Mission creation via PAR, verify the assertion per Section 4.2.2, and treat the request as an expansion (Section 4.1);¶

• refuse a refresh token presented in predecessor_assertion with invalid_request (Section 4.1);¶

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

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

• activate the successor and transition the predecessor to superseded atomically at the first redemption of the successor's grant, leaving the predecessor active until then, 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).¶

Every expansion this document defines is adjudicated as a fresh approval event (Section 5). 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

The predecessor member of the mission claim (Section 6) is not registered in a dedicated registry: it is carried inside the already-registered mission claim, an open object for which the issuance profile establishes no member registry. 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), conveyed in mission_expansion_status, and the expansion denial reasons (Section 10), conveyed in the shared mission_denial_reason member. As members of the OAuth error response JSON body at the PAR and token endpoints, both are namespaced to their error responses and require no registration; their authorization error response parameter forms are registered below. This document creates no registry for the codes: the closed sets are small and fully specified in their defining specifications. Should interoperable extension prove necessary, a future revision can create a "Mission Expansion Reconciliation Status" registry and a shared "Mission Denial Reason" registry with a Specification Required [RFC8126] policy.¶

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

• Name: predecessor¶

• Parameter Usage Location: authorization request¶

• Change Controller: IETF¶

• Reference: this document, Section 4.1¶

• Name: predecessor_assertion¶

• Parameter Usage Location: authorization request¶

• Change Controller: IETF¶

• Reference: this document, Section 4.1, Section 4.2¶

• Name: mission_expansion_status¶

• Parameter Usage Location: authorization response¶

• Change Controller: IETF¶

• Reference: this document, Section 9¶

• Name: mission_denial_reason¶

• Parameter Usage Location: authorization response¶

• Change Controller: IETF¶

• Reference: this document, Section 10; also carried by the child delegation profile ([I-D.draft-mcguinness-oauth-mission-child-delegation])¶

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_assertion carries a Mission relationship assertion (Section 4.2), never a refresh token, and is 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