Mission Expansion for OAuth 2.0

1.1. Status: an optional extension

This document is optional. It is a layered extension to the issuance profile, not a change to it. A deployment that implements [I-D.draft-mcguinness-oauth-mission] and never expands a Mission is fully conformant to that profile and is unaffected by this document: it issues no expansion request, records no predecessor member, and never enters the superseded state this document introduces. The issuance profile's lifecycle (active, revoked, expired) is complete without expansion; the superseded state defined here (Section 7) is relevant only when expansion is used.¶

A Mission Issuer claims conformance to this document only when it adjudicates expansion; otherwise it remains a plain issuance-profile Mission Issuer. Nothing here places a new requirement back on the issuance profile.¶

1.2. Relationship to the issuance profile

This document depends normatively on the issuance profile and is not implementable alone. It reuses, without restating, that profile's Mission Intent, submission via PAR, authority derivation, approval event with its integrity anchors, Mission record, the mission claim, the subset rule, and the lifecycle and issuance gating. It uses the terms Agent (Client), Subject, Approver, Mission Issuer, Mission Intent, Authority Set, Mission, and derived token as defined there.¶

Where this document refers to "the issuance profile" without a section, it means [I-D.draft-mcguinness-oauth-mission] as a whole.¶

1.3. Scope

This document defines:¶

• the expansion request: how a client initiates a successor Mission and how that request is bound to the predecessor's grant (Section 4);¶

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

• the terminal superseded predecessor state and its transition (Section 7);¶

• replacement expansion as the mode, with branch expansion deferred (Section 8);¶

• concurrent-expansion reconciliation, with a closed set of reconciliation status codes (Section 10); and¶

• the expansion denial reasons (Section 12).¶

This document does NOT define:¶

• a way to widen an existing Mission in place; expansion always creates a new Mission;¶

• runtime per-action enforcement or the classification of a denial as expansion-eligible; that is the runtime layer's concern (Section 3.2, [I-D.draft-mcguinness-mission-runtime]);¶

• branch expansion, in which predecessor and successor both remain active (Section 8);¶

• multi-hop or cross-domain expansion; an expansion is adjudicated by the predecessor's Mission Issuer (its issuer); or¶

• policy-adjudicated expansion within a pre-consented authority ceiling; that is progressive authorization, defined by an experimental companion ([I-D.draft-mcguinness-oauth-mission-progressive]). Under this document alone, every expansion is adjudicated by a fresh human approval.¶

3.1. Protocol flow

 Agent (client)               Mission Issuer (AS)
     |                            |
     | denied: action outside     |
     | active Mission's authority |
     |                            |
     | 1. token exchange -------> | resolve predecessor from
     |    subject_token =         | subject_token; verify
     |    predecessor's Mission-  | possession (subject_token
     |    bound access token;     | cnf); gate predecessor
     |    mission_intent          | active
     |                            |
     |                            | 2. complete, one of:
     |                            |
     |    <-- authz_pending ----- | (a) deferred: fresh async
     |    ---- poll ------------> |     approval via DTR;
     |    <-- access token ------ |     token on approval
     |                            |
     |    <-- (front channel) --> | (b) interactive: the
     |                            |     deployment's front-
     |                            |     channel approval
     |                            |
     |         at activation: successor active,
     |         predecessor superseded (atomic)
     v

The request is an [RFC8693] token exchange bound to the predecessor by possession of the predecessor's Mission-bound access token (Section 4), so the Mission Issuer adjudicates a successor of a specific predecessor rather than an unrelated new Mission. An expansion always widens authority, so a fresh consent supplies the broader authority, obtained through the deferred token response ([I-D.draft-gerber-oauth-deferred-token-response]) or the deployment's interactive approval (Section 5.2); a request that widens nothing is refused (Section 5.1). The successor's authority comes only from that consent. Supersession is deferred to activation: the successor activates and the predecessor becomes superseded atomically when the successor's authority is issued, so an expansion that never completes leaves the predecessor active (Section 7).¶

3.2. Eligibility

A client initiates expansion after an action is denied because the requested authority is outside the active Mission's Authority Set and the deployment's governance policy permits widening it. This document does not define how a denial is classified as expansion-eligible; that classification belongs to the component that denies the action.¶

A Mission-aware Resource Server enforces the token's authority statelessly and refuses an out-of-bounds action with its usual insufficient-authority error ([I-D.draft-mcguinness-oauth-mission]). The runtime enforcement profile [I-D.draft-mcguinness-mission-runtime] is one source of an expansion-eligible denial: in that profile a deny is terminal for the attempted action, and the authority-expandable-denial escalation that turns such a deny into an expansion is named there as out of scope. This document defines that expansion. This document does not require any particular denial source: a client that knows, by any means, that an action needs authority the active Mission lacks MAY initiate expansion. Whether the Mission Issuer adjudicates a successor remains its decision (Section 5); an eligible denial is not an authorization in favor of expansion.¶

3.3. Expansion is not step-up

Expansion is a governance operation. It is distinct from authentication step-up [RFC9470]. A request denied because an acr or amr constraint requires fresh authentication is satisfied by step-up, not by expansion: the Authority Set does not change. A request denied because the requested authority is not in the active Mission's Authority Set requires expansion: the Authority Set must be enlarged through a new approval event. The two are not interchangeable; Section 15.6 treats the security consequence of conflating them.¶

4.1. The token exchange request

A client initiates an expansion as an [RFC8693] token exchange at the token endpoint. The request carries:¶

grant_type:

REQUIRED. urn:ietf:params:oauth:grant-type:token-exchange, the [RFC8693] token-exchange grant type.¶

requested_token_type:

REQUIRED. urn:ietf:params:oauth:token-type:access_token. This value selects expansion: the Mission Issuer returns the successor's Mission-bound access token. Child creation, the peer operation on the same grant, is selected by the JWT token type ([I-D.draft-mcguinness-oauth-mission-child-delegation]).¶

subject_token:

REQUIRED. The predecessor Mission's sender-constrained Mission-bound access token. The Mission Issuer resolves the predecessor from this token (Section 4.2); this token, not any identifier, selects the predecessor authoritatively.¶

subject_token_type:

REQUIRED. urn:ietf:params:oauth:token-type:access_token. The Mission Issuer MUST reject any other value with invalid_request. A refresh token MUST NOT be accepted as the subject_token for an expansion: the possession proof is a sender-constrained access token, never a reusable bearer refresh credential.¶

actor_token:

OPTIONAL. A token identifying the acting agent, per [RFC8693]. Where it is absent, the request's client authentication identifies the acting agent. This document carries the acting-agent identity; it does not restructure any act chain. A successor Mission begins its own act chain afresh under its own approval.¶

actor_token_type:

REQUIRED when actor_token is present, per [RFC8693].¶

mission_intent:

REQUIRED. The successor's Mission Intent Submission envelope, per [I-D.draft-mcguinness-oauth-mission]: its intent is the successor's Mission Intent, and its OPTIONAL evidence array carries Intent Submission Evidence under that profile's dispatch, refusal, and never-authority rules. The Intent describes the broadened task: the goal, resources, constraints, and controls the successor needs, including the authority the denied action required. The Mission Issuer derives the successor's Authority Set from this Intent and bounds it by policy exactly as for any Mission; this document adds no authority-derivation rule.¶

authorization_details:

OPTIONAL. The successor's authority proposal: the standard [RFC9396] parameter carried on the same token request, itself ordinary [RFC9396] token-request usage. This parameter is this exchange's proposal carriage, replacing the issuance profile's PAR-only carriage rule; that profile's validation, derivation, recording, and hashing semantics apply unchanged ([I-D.draft-mcguinness-oauth-mission]). It is a proposal, never authority: the Mission Issuer derives and bounds the successor's Authority Set by policy regardless of what was proposed. A successor created from an exchange carrying one records proposed_authority and proposal_hash.¶

predecessor:

OPTIONAL. A string. The mission_id of the predecessor, a non-authoritative cross-check and audit value only. The Mission Issuer resolves and selects the predecessor from subject_token (Section 4.2); when predecessor is present the Mission Issuer MUST verify it names that same resolved Mission and refuse a mismatch with invalid_grant. predecessor does not select or authorize a predecessor: a client MUST NOT be able to expand a Mission merely by naming its mission_id.¶

creation_request_id:

REQUIRED. The creation idempotency identifier: an ASCII string of at most 255 octets, opaque to the Mission Issuer beyond equality, that identifies this one Mission-creation operation across every completion mode (Section 11). At least 128 bits of client-generated randomness is RECOMMENDED; a UUID [RFC9562] satisfies this. The Mission Issuer MUST refuse an exchange missing it with invalid_request.¶

The presence of mission_intent on a token exchange marks it as a Mission-creation exchange under this suite; an exchange whose subject_token resolves to a Mission and that carries no child_actor is an expansion. A token exchange carrying both a predecessor cross-check and the child-delegation profile's child_actor ([I-D.draft-mcguinness-oauth-mission-child-delegation]) MUST be refused with invalid_request: the operations do not combine.¶

The possession proof of Section 4.2 is presented only on the token endpoint's authenticated back channel and MUST NOT appear on any front channel. Where a deployment completes an expansion through its retained interactive approval (Section 5.2), the front-channel approval ceremony carries only the consent decision; the predecessor binding and possession proof are established by the token exchange in every completion mode.¶

4.2. Proving possession of the predecessor

The issuance profile resolves a Mission from the credential the client presents, never from a client-supplied mission_id ([I-D.draft-mcguinness-oauth-mission], grant binding). An expansion resolves the predecessor from the subject_token the client presents and proves possession against that token's own confirmation:¶

1. The Mission Issuer MUST resolve the predecessor Mission from subject_token, applying the issuance profile's token-to-Mission resolution for a Mission-bound access token.¶

2. The Mission Issuer MUST verify that the presenter controls the subject_token's own confirmation key: a [RFC9449] DPoP proof whose key matches the token's cnf jkt, or the [RFC8705] mutual-TLS certificate whose thumbprint matches the token's cnf x5t#S256. Possession is proven against the token's confirmation, a sender-constrained proof; it is not read from any Mission-record field. A subject_token that is not sender-constrained cannot carry this proof, so the Mission Issuer MUST refuse it with invalid_request.¶

3. Where the proof is a DPoP proof, its jti is single-use per [RFC9449]: the Mission Issuer MUST reject a replayed proof.¶

4. When predecessor is present, the Mission Issuer MUST verify the resolved Mission is the one it names (Section 4.1).¶

The confirmation key, not the identifier, authorizes the expansion. A client that does not hold the predecessor's Mission-bound access token and its sender-constraint key cannot present a valid subject_token and so cannot expand the predecessor. Establishing this at the token exchange, before any approval, means the Mission Issuer confirms the predecessor is real, active, and possessed before prompting an Approver, so expansion cannot drive approval prompts against another party's Mission.¶

Stated as the eligibility rule rather than a consequence: this profile's expansion requires a sender-constrained Mission-bound access token to present, and a deployment that issues only bearer tokens for a Mission, or none, forgoes it. Nothing else is lost. Succession stays reachable through a fresh approval, a new Mission whose disclosure references the work it continues, since the successor's authority comes only from the fresh consent in any case; and the Subject or an administrator acts on the predecessor at the management plane regardless, whose standing is the authenticated principal, never a token's possession ([I-D.draft-mcguinness-oauth-mission-status]). The possession proof gates the proposal channel (who may put an expansion wearing this predecessor's name in front of the Approver, and who may trigger the atomic supersession), never the authority: no proof failure can widen anything.¶

The Mission Issuer MUST record each expansion presentation and count it toward the deployment's anomaly detection, and the per-predecessor rate limit (Section 15.7) applies unconditionally. Because the subject_token is a short-lived, sender-constrained access token rather than a reusable refresh credential, presenting it for expansion carries no refresh rotation or replay-detection interaction: it is consumed only to resolve and bind the predecessor, never to refresh.¶

Because expansion binds to the predecessor's Mission-bound access token, it needs no opaque expansion ticket or other new bearer: the predecessor is identified and authorized by a credential the client already holds and can prove possession of, and a client cannot name an arbitrary predecessor.¶

4.3. Predecessor must be active

The Mission Issuer MUST resolve the predecessor from subject_token and verify it is in the active state before adjudicating, and MUST re-verify it at completion when adjudication is deferred or interactive (Section 5.3). An expansion request against a predecessor that is not active MUST be refused with invalid_grant and a reconciliation status (Section 10):¶

• if the predecessor made a terminal exit from active (it is revoked, expired, or already superseded, Section 7), the status is predecessor_state_changed;¶

• if the predecessor is in a non-terminal non-active state, for example suspended where the Mission Status profile [I-D.draft-mcguinness-oauth-mission-status] is deployed, the status is predecessor_not_active.¶

Issuance gating in the issuance profile already refuses to derive from a non-active Mission; this rule extends the same gate to adjudicating an expansion of one.¶

5.1. Mission Issuer verification order

The Mission Issuer MUST evaluate an expansion token exchange in this order, refusing on the first failure:¶

1. Parse the exchange, require subject_token with subject_token_type = urn:ietf:params:oauth:token-type:access_token, rejecting a refresh token, and require creation_request_id (Section 4.1).¶

2. Resolve the predecessor Mission from subject_token (Section 4.2).¶

3. Verify possession: the presenter controls the subject_token's own confirmation key ([RFC9449] DPoP proof jkt, or [RFC8705] mTLS x5t#S256), and, for a DPoP proof, the proof jti is single-use (Section 4.2).¶

4. Verify the acting agent (actor_token, or the request's client authentication) is authorized to request expansion of this predecessor.¶

5. Look up the (client, creation_request_id) reservation and, where one exists, recover the recorded operation instead of proceeding (Section 11). The lookup follows client authentication and possession verification and precedes the predecessor lifecycle gate of step 6 (Section 11.4).¶

6. Verify the predecessor is active (Section 4.3) and, when predecessor is present, that it names the resolved Mission.¶

7. Derive the successor's Authority Set under policy from the submitted Mission Intent (Section 5) and verify that it widens the predecessor: when the derived requested authority is a subset of the predecessor's own Effective Authority Set, refuse the exchange with the nothing_to_expand denial reason, as there is nothing to expand (Section 12).¶

8. Complete per Section 5.2; at a deferred or interactive completion, re-verify the predecessor's Mission state before issuing (Section 5.3).¶

On any failure the Mission Issuer MUST refuse with invalid_request, invalid_grant, or invalid_token as appropriate, and MUST NOT create a successor.¶

The predecessor's Effective Authority Set, the right-hand side of step 7's subset test, is the term [I-D.draft-mcguinness-oauth-mission-status] defines: the approved Authority Set after applying every issuer-held narrowing mechanism the deployment runs, including the containment profile's overlay where deployed ([I-D.draft-mcguinness-oauth-mission-containment]).¶

Authority the predecessor once held but containment or discharge has removed is therefore never nothing_to_expand: a request for it widens the effective set and is expansion-eligible. Such authority returns only through a fresh-consent successor, with the predecessor's containment history surfaced in the expansion consent disclosure (Section 5.2, [I-D.draft-mcguinness-oauth-mission-containment]), never by re-deriving under the predecessor.¶

5.2. Completion modes

An expansion completes in one of two modes, each obtaining the fresh approval the successor's authority requires. The deferred token response is a completion mode, not a replacement: both modes rest on the same possession-proven token exchange (Section 4), and the interactive path is retained.¶

Deferred:

When approval is asynchronous, the Mission Issuer returns the deferred token response of the family's Mission Deferred Approval substrate ([I-D.draft-gerber-oauth-deferred-token-response], profiled for Missions by [I-D.draft-mcguinness-oauth-mission-approval]): authorization_pending with a polling interval. The Approver acts on the deployment's asynchronous review surface; the client polls; the poll resolves to the successor's access token on approval, or to access_denied or expired_token. This document references that substrate and does not redefine it.¶

Interactive:

When approval is interactive, the Mission Issuer runs the deployment's existing front-channel approval event, the issuance profile's own approval ceremony ([I-D.draft-mcguinness-oauth-mission]), issuing an authorization code the client redeems to obtain the successor's authority. This is the interactive path retained from earlier revisions of this document.¶

This document defines no synchronous exchange completion. An expansion response is a successor or a refusal, never a token derived under the predecessor: a request whose derived authority is a subset of the predecessor's own Effective Authority Set is refused with nothing_to_expand (Section 5.1, Section 12). Policy-adjudicated expansion within a pre-consented authority ceiling is the experimental progressive authorization companion's concern ([I-D.draft-mcguinness-oauth-mission-progressive]): an in-ceiling drawdown completes through the retained interactive path with the approval prompt skipped, as that companion defines.¶

Whichever mode completes, obtaining the fresh approval means the Mission Issuer authenticates the Approver, obtains fresh consent for the derived Authority Set, satisfies any controls.acr, and renders 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. Expansion never widens authority without a new consent: if the Approver declines, no successor is created and the predecessor is untouched (Section 12).¶

At completion the Mission Issuer computes the successor's integrity anchors (intent_hash, authority_hash, and, where the exchange carried an authority proposal, proposal_hash) and, at the point the successor's authority is issued (the resolving poll for a deferred completion, or the code redemption for an interactive completion), creates 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 the successor activates the predecessor remains active; an expansion that never completes, whose deferred approval lapses, or whose authorization code is never redeemed or expires, creates no successor and leaves the predecessor active.¶

Whichever mode is selected, the exchange's creation_request_id reservation (Section 11) makes completion recoverable: a client that loses the response recovers the one committed operation, never a second creation.¶

5.3. The deferred window

A completion may occur later than the request, across a deferred or interactive approval window. Two rules govern that window:¶

• The predecessor's Mission state MUST be re-verified at issuance (completion), not only at request time. A predecessor that was terminated or contained during the window MUST fail completion, per the compare-and-set of Section 10. This preserves the new-derivation kill a terminal predecessor state effects: a deferred approval MUST NOT become a bypass of it.¶

• Expiry of the subject_token during the window MUST NOT gate completion. The predecessor binding and the possession proof are evaluated and recorded at request time (Section 4.2); the short-lived subject_token expiring while approval is pending does not invalidate the pending exchange. The re-verification above is of the predecessor's Mission state, not of the expired token.¶

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

This is the priced limitation of the current design. Cascade applies to every non-terminal Child Mission regardless of whether that child's own Authority Set would still satisfy strict-subset validation against the successor: the successor's Authority Set is freshly derived, not inherited by reference, so a child's creation-time subset check does not carry forward ([I-D.draft-mcguinness-oauth-mission-child-delegation], Section "Cascade Revocation"). The re-creation above is paid for per child: a fresh assertion conveyed to the child actor that held the terminated child, and an interval in which that child actor's outstanding tokens under the terminated child run to the earlier of their own exp and the runtime staleness bound, where the runtime enforcement layer is deployed, while the replacement is delivered ([I-D.draft-mcguinness-oauth-mission-child-delegation], Section "Cascade Failure"). Where a deployment provides the notice recommended above, the expansion consent event is where this price is rendered; that consent event is the only point in this profile at which a human can witness the cascade before it happens.¶

5.4. Successor expiry

The successor's effective expires_at follows the issuance profile's requested-versus-effective rule ([I-D.draft-mcguinness-oauth-mission]). It MUST NOT be later than the expansion submission's intent.expires_at, the requested ceiling. It MUST NOT exceed the predecessor's expires_at unless the Mission Issuer's policy explicitly permits extension and the extension is disclosed to the Approver at the expansion consent event, which records the exact approved extension ceiling. Expansion is an authority-addition mechanism, not a silent lifetime-extension mechanism. The issuance profile caps every derived credential's exp at the Mission's expires_at; a successor that silently outlived its predecessor would let expansion launder a longer-lived Mission past the originally approved horizon.¶

The completing success response, the resolving poll or the code redemption, MUST carry the effective value in the issuance profile's mission_expires_at response member. Completion inherits the issuance profile's atomic creation-time check: where the submission's intent.expires_at passes while the expansion is pending, completion creates no successor Mission and the exchange fails with this profile's denial semantics (Section 12).¶

An auditor verifies the successor record by inequalities, never by matching a recomputed minimum: in every case the effective value is no later than the submission's intent.expires_at; without an approved extension it is also no later than the predecessor's expires_at; with one, it MAY be later than the predecessor's expires_at only when the Mission Issuer's policy permits the extension and the exact effective value was rendered and approved at the expansion consent event. Any further shortening is justified by recorded policy.¶

7.1. No implicit rollback

The Mission Issuer MUST NOT implicitly resurrect a superseded predecessor when its successor is later revoked, expired, or itself superseded; superseded is terminal. A deployment that needs "revert to the predecessor's authority" semantics expresses that as a new approval event creating a new Mission that carries the relevant authority, with its own predecessor link preserving the lineage. A rollback is therefore a new governed Mission, not a state reversal.¶

11.1. The operation fingerprint

The operation fingerprint commits what the operation is, so a repeated identifier is distinguishable from a reused one. It is computed as an issuance-profile integrity anchor ([I-D.draft-mcguinness-oauth-mission]) whose typ is mission-creation-fingerprint, under that profile's collision-resistant typ convention, and whose committed value is the object below: the anchor envelope is canonicalized with JCS [RFC8785], hashed with SHA-256, and encoded as sha-256: followed by the base64url, no-padding, encoding of the digest, exactly as for the profile's other anchors. It is an envelope anchor under the issuance profile's commitment mechanisms, which this document imports normatively. As a JCS commitment-envelope typ, mission-creation-fingerprint names a hash domain, not a representation crossing a protocol boundary, and is deliberately not a media type ([I-D.draft-mcguinness-oauth-mission], Section "Namespace Taxonomy").¶

The fingerprint object carries exactly these members:¶

op:

expansion for this document's exchange; child-creation for the child delegation profile's. This member domain-separates the two operations that share the token-exchange grant.¶

iss:

The Mission Issuer's issuer identifier.¶

client:

The authenticated client identifier.¶

source:

The mission_id of the source Mission resolved from subject_token (Section 4.2): the predecessor here, the parent under child delegation. The resolved identifier is the member, never the raw subject_token, since a legitimate retry may carry a newly issued token for the same Mission, and never the optional cross-check alone, which is non-authoritative.¶

cnf:

The verified presenter confirmation: the DPoP proof key's jkt, or the mTLS certificate's x5t#S256 (Section 4.2).¶

actor:

The verified acting-agent identity, with its relevant actor context, where the exchange carries one (actor_token); absent where client authentication alone identifies the acting agent.¶

intent:

The semantic intent object of the parsed mission_intent Submission envelope ([I-D.draft-mcguinness-oauth-mission]).¶

evidence:

The parsed evidence array of the Submission envelope, when present. Presented evidence affects admission, derivation, approval, and side effects, so a retry presenting different evidence is a different operation, refused on the fingerprint mismatch below.¶

proposal:

The parsed authorization_details array, when present.¶

child_actor:

The parsed child_actor object; child creation only, absent on an expansion.¶

requested_token_type:

The exchange's requested_token_type value.¶

cross_check:

The supplied predecessor value (under child delegation, the supplied parent value), when present.¶

An extension that defines a new parameter affecting the authorization, derivation, approval, output, or side effects of the creation MUST extend the fingerprint object with it. Attempt-specific material is excluded: the DPoP proof serialization and its jti, the client-authentication assertion serialization, the raw subject_token serialization, and creation_request_id itself.¶

11.2. The durable reservation

A reservation is the durable record binding the authenticated client, the creation_request_id, and the fingerprint. It is created in a reserved state and moves to completed or failed. The (client, creation_request_id) pair is unique, and the store MUST enforce that uniqueness as a constraint; a read-before-insert check without one does not withstand concurrent retries.¶

The reservation and the created Mission's identifier MUST be committed atomically with Mission creation; credential generation MAY follow the commit. This closes the crash window: when the Mission commits and the Mission Issuer fails before responding, the retry finds the committed operation and resumes delivery (Section 11.3), never creating again.¶

A repeated presentation of the same (client, creation_request_id) resolves by fingerprint:¶

• same fingerprint, operation completed: recover it (Section 11.3);¶

• same fingerprint, operation reserved or pending: return the same continuation, or a retryable in-progress result;¶

• different fingerprint: refuse with invalid_request. The identifier was reused for a different operation.¶

11.3. Recovery is delivery

The Mission Issuer stores the operation's stable outcome, never its serialized response: the completion mode with its continuation handle, or the created Mission's identifier with its delivery-artifact metadata. A revalidated retry (Section 11.4) recovers that outcome:¶

• A pending deferred completion returns the same deferral: the same (client, creation_request_id) resolves to the same deferred continuation, scoped to the authenticated client, never to a second deferral.¶

• A pending interactive completion returns the same continuation reference. The reservation is made at initiation, so a retry cannot start a second approval ceremony.¶

• A completed operation whose delivery credential is still valid returns that credential.¶

• A completed operation whose delivery credential has expired is recovered by minting a fresh delivery credential for the already-created successor, provided that successor remains active and the requester re-establishes the recorded authorization context (Section 11.4). The fresh credential is a delivery event with ordinary issuance accounting; it MUST NOT repeat creation accounting: no second creation lifecycle event, no second evidence emission, no second count against any creation budget.¶

Recovery never re-creates. Whatever the outcome tier, a recovered operation yields the Mission the operation already created, or the continuation it already opened, and nothing else.¶

11.4. Revalidation and lookup order

A matching creation_request_id never bypasses authentication or possession. Before recovering anything, the Mission Issuer MUST establish:¶

• the same authenticated client;¶

• the recorded source Mission;¶

• the same authorized acting agent;¶

• possession of the recorded sender-constraint identity, the stored cnf of Section 11.1; and¶

• fingerprint compatibility (Section 11.2).¶

No key-rotation recovery path is defined: a requester that can no longer prove possession of the recorded cnf does not recover the operation.¶

The idempotency lookup occurs after client authentication and possession verification and before the predecessor lifecycle gate (Section 5.1). The order is load-bearing: the retry worth recovering is exactly the one whose predecessor transitioned to superseded when the first attempt succeeded (Section 7), so re-running the predecessor-active gate first would refuse the very recovery this mechanism exists to serve.¶

11.5. Tombstone retention

Retention has two tiers. The full delivery-artifact record MAY be retained briefly. The idempotency tombstone, the (client, creation_request_id) binding with its fingerprint and its Mission or continuation reference, MUST survive at least the deployment's published retry horizon, and retention to the source or created Mission's lifetime, or to the deployment's audit horizon, is RECOMMENDED. The retry horizon is a published deployment bound, like the deployment's other operational bounds. A client MUST NOT retry a creation past the published horizon: reuse of an identifier after its tombstone expires is outside the contract and is processed as a new operation.¶

15.1. Predecessor confusion

A client could attempt to expand a Mission it does not control, for example by naming another tenant's or subject's mission_id in the predecessor parameter.¶

Mitigations:¶

• The predecessor is resolved from the subject_token the client presents, not from the predecessor value, and possession is proven against that token's own confirmation key; the Mission Issuer verifies that the resolved Mission matches the named one and refuses a mismatch with invalid_grant (Section 4.2). A client that does not hold the predecessor's Mission-bound access token and its sender-constraint key cannot expand it.¶

• The issuance profile's integrity anchors are issuer-bound, so a Mission's governance state cannot be transplanted across Mission Issuers; an expansion is adjudicated only at the predecessor's own issuer.¶

15.2. Possession proof

A stolen or exfiltrated predecessor credential could be replayed to request an expansion.¶

Mitigations:¶

• The subject_token is a sender-constrained access token, not a reusable bearer refresh credential, and possession is proven against the token's own confirmation key (Section 4.2): a bearer copy of the token, without its DPoP key or mTLS certificate, cannot carry the proof. A refresh token MUST NOT be accepted as the subject_token (Section 4.1).¶

• The DPoP proof jti is single-use ([RFC9449]), so a captured proof cannot be replayed (Section 5.1).¶

• The short-lived subject_token bounds the window in which even a key-holding attacker could act, and the possession proof is bound and recorded at request time so a legitimate deferred completion is not gated on that lifetime (Section 5.3).¶

15.3. Authority comes only from new consent

An expansion could be misused to widen authority without the Approver re-consenting, if a successor were allowed to inherit or extend authority without a fresh approval.¶

Mitigations:¶

• The successor's authority comes only from the Authority Set derived and consented at the expansion approval event; the authority_hash commits exactly that set (Section 5). The predecessor member carries no authority and cannot widen the successor (Section 6).¶

• The successor-expiry rule (Section 5.4) keeps the successor's expires_at from silently exceeding the predecessor's, so expansion cannot launder a longer lifetime past the originally approved horizon.¶

15.4. Race against predecessor lifecycle

Between the moment a client decides to expand and the moment the successor activates, the predecessor may be revoked, expire, or be superseded by a concurrent expansion. A deferred or interactive completion widens this window. Without serialization an expansion could appear to succeed against a predecessor that is no longer authoritative, or two successors could be created.¶

Mitigations:¶

• The Mission Issuer verifies predecessor state and the no-existing-successor condition in the same atomic step that would activate the successor (Section 5.3), and serializes the completions that activate a successor of the same predecessor (Section 10).¶

• A failed check refuses with invalid_grant and a reconciliation status that tells the client whether to discover an existing successor or stop, without leaking the predecessor's new internal state beyond that (Section 10).¶

15.5. Duplicate creation

To a client, a lost response is indistinguishable from a failed creation. Without idempotency the natural retry after a network fault creates a second Mission: live authority nobody intended and, under the child delegation profile, a consumed fan-out budget ([I-D.draft-mcguinness-oauth-mission-child-delegation]). Proof jti single-use does not close this fault: the retry carries a fresh, valid proof.¶

Mitigations:¶

• The REQUIRED creation_request_id, with its durable reservation and uniqueness constraint, makes the retry recover the one committed operation, concurrent retries included (Section 11, Section 11.2).¶

• The identifier is a deduplication handle, not a secret and not a credential: recovery re-establishes client authentication, possession of the recorded confirmation key, and the recorded authorization context, so the recovery path never weakens the possession requirements of Section 4.2 (Section 11.4).¶

• Reservations are scoped to the authenticated client, so one client's identifiers cannot interfere with, or replay, another's.¶

• Storage is bounded: the tombstone is small, its horizon is published (Section 11.5), and a Mission Issuer MAY cap outstanding reservations per client.¶

15.6. Expansion versus step-up

Conflating expansion with authentication step-up [RFC9470] would route an authentication shortfall through an approval event the Approver did not need to perform, surfacing irrelevant consent and risking approval fatigue, or conversely would treat a genuine authority shortfall as a mere re-authentication and silently widen nothing.¶

Mitigation: a denial that is an authentication shortfall (acr, amr) is satisfied by step-up and MUST NOT be routed to expansion; a denial that is an authority shortfall is the one expansion addresses (Section 3.3). The component that classifies the denial (Section 3.2) makes this distinction.¶

15.7. Policy probing

A client could submit many expansion requests for the same predecessor to map the Mission Issuer's policy boundary from the denial reasons.¶

Mitigations:¶

• The Mission Issuer MUST rate-limit expansion requests per predecessor per client. The bound is unconditional: it caps both policy probing and the approval prompts a client can drive against an Approver (prompt fatigue). Every expansion presentation is recorded and counted toward anomaly detection (Section 4.2).¶

• A denial reason MUST NOT disclose policy boundaries beyond the adjudicated request (Section 12); a denial reports whether the requested authority was approved, not the full surface of what would have been.¶

15.8. Audit linkage

The predecessor member makes the expansion chain observable: an authorized auditor can trace a successor back through its predecessors to the original Mission. This is a core governance property of expansion. An implementation that omits the member breaks the chain and defeats it; the member is therefore mandatory on a successor (Section 6).¶

General OAuth security guidance applies to the underlying credentials through the issuance profile.¶

16.1. Predecessor-chain correlation

The predecessor member that gives audit linkage (Section 15.8) is also a correlation surface: it links a successor to its predecessor across distinct approval events, so a party that can read the chain can correlate the evolving task over time, which is more than any single Mission discloses. This is intrinsic to the governance value of expansion. Deployments SHOULD scope read access to the predecessor member, and to any Mission-state surface that exposes it, to parties with a governance need, rather than exposing the chain to every credential audience. The issuance profile's Mission Identifier correlation considerations apply to each Mission in the chain.¶

16.2. Related-work correlation

related_to correlates independently approved tasks the way the predecessor chain correlates a succession, without the authority linkage. The same scoping applies: deployments SHOULD disclose the member only to audiences that require the governance relationship, and the issuance profile's Mission Identifier correlation considerations apply to both Missions it names.¶

16.3. Disclosure of the broadened task

The expansion Mission Intent and the consent disclosure rendered at the expansion approval event reveal how the approved task is evolving. The Mission Issuer SHOULD render that disclosure only to the Approver and authorized governance consumers, consistent with the issuance profile's treatment of consent disclosure.¶

17.1. Mission Lifecycle States Registration

This document requests registration of one state in the issuance profile's Mission Lifecycle States registry ([I-D.draft-mcguinness-oauth-mission]), under that registry's Specification Required policy:¶

17.2. Mission Denial Reasons Registry

IANA is requested to create the "Mission Denial Reasons" registry. The registration policy is Specification Required [RFC8126]. A Designated Expert reviews a submission for the discipline Section 12 requires: a Value matching ^[a-z][a-z0-9_]*$ not already registered, a Semantics sentence precise enough that a consumer can tell the denial from every other registered value, and a Reference that fixes which specification defines it. Registration does not require IETF review or a Standards Track document; a Specification Required reference that a Designated Expert can review against these criteria suffices.¶

The registry covers values of the mission_denial_reason parameter only (Section 12); the Resource Server WWW-Authenticate mission_denial attribute ([I-D.draft-mcguinness-oauth-mission], Section "Resource Server Enforcement") and AuthZEN decision-context denial reasons ([I-D.draft-mcguinness-mission-authzen]) are separate specification-defined value spaces, outside this registry's scope. A companion that adds a denial value states whether it adds a row to this carrier's registry or defines a value in a separate space; a shared spelling across carriers is a coincidence, never shared semantics, unless the defining documents state the mapping.¶

A consumer MUST treat an unrecognized value as a denial with no further semantics (Section 12). A Designated Expert MUST reject a registration whose governing specification attempts to redefine this interaction rather than adding a value bound by it.¶

Each registration records:¶

• Value: the mission_denial_reason symbolic string.¶

• Semantics: one sentence stating what the denial means.¶

• Change Controller: IETF, or the registrant for any other registration.¶

• Reference: the specification defining the value.¶

This document seeds the registry with the values it defines (Section 12):¶

Each further document that defines a value on this carrier requests that value's registration in its own IANA considerations, carrying its Internet-Draft reference as a publication dependency under this registry's policy until it is published; Specification Required does not require Standards Track maturity of the registrant.¶

The expansion request is an [RFC8693] token exchange carrying the already-registered mission_intent request parameter and the already-registered token-exchange parameters subject_token, subject_token_type, requested_token_type, actor_token, and actor_token_type; none of these needs registration by this document. The deferred completion mode uses the deferred token response substrate ([I-D.draft-gerber-oauth-deferred-token-response]) and registers nothing here. This document removes the earlier revision's registration request for a predecessor_token parameter: the predecessor is resolved from subject_token, so no dedicated predecessor-token parameter exists.¶

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

• Name: predecessor¶

• Parameter Usage Location: token request, authorization request¶

• Change Controller: IETF¶

• Reference: this document, Section 4.1¶

• Name: mission_expansion_status¶

• Parameter Usage Location: token response, authorization response¶

• Change Controller: IETF¶

• Reference: this document, Section 10¶

• Name: mission_denial_reason¶

• Parameter Usage Location: token response, authorization response¶

• Change Controller: IETF¶

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

• Name: creation_request_id¶

• Parameter Usage Location: token request¶

• Change Controller: IETF¶

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

The predecessor cross-check rides the token exchange request at the token endpoint and, on the retained interactive path, the authorization request; the reconciliation status and denial reason ride the token error response and, on the interactive path, the authorization error response. The creation_request_id identifier rides the token exchange request at the token endpoint in every completion mode and never appears on a front channel.¶

Normative References

[I-D.draft-mcguinness-oauth-mission]

McGuinness, K., "Mission-Bound Authorization for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission.html>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8693]

Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, <https://www.rfc-editor.org/rfc/rfc8693>.

[RFC8705]

Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, DOI 10.17487/RFC8705, February 2020, <https://www.rfc-editor.org/rfc/rfc8705>.

[RFC8785]

Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, <https://www.rfc-editor.org/rfc/rfc8785>.

[RFC9126]

Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", RFC 9126, DOI 10.17487/RFC9126, September 2021, <https://www.rfc-editor.org/rfc/rfc9126>.

[RFC9396]

Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, <https://www.rfc-editor.org/rfc/rfc9396>.

[RFC9449]

Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, <https://www.rfc-editor.org/rfc/rfc9449>.

Informative References

[I-D.draft-gerber-oauth-deferred-token-response]

Jacobsen, F. K., de Oliveira Niero, G., and M. Gerber, "Deferred Token Response", Work in Progress, Internet-Draft, draft-gerber-oauth-deferred-token-response-00, 23 June 2026, <https://datatracker.ietf.org/doc/html/draft-gerber-oauth-deferred-token-response-00>.

[I-D.draft-mcguinness-mission-authority-server]

McGuinness, K., "Mission Authority Server", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-authority-server.html>.

[I-D.draft-mcguinness-mission-authzen]

McGuinness, K., "Mission-Bound Runtime Enforcement: AuthZEN Profile", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-authzen.html>.

[I-D.draft-mcguinness-mission-harness]

McGuinness, K., "Mission-Aware Agent Harnesses", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-harness.html>.

[I-D.draft-mcguinness-mission-runtime]

McGuinness, K., "Mission-Bound Runtime Enforcement", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-runtime.html>.

[I-D.draft-mcguinness-oauth-mission-approval]

McGuinness, K., "Mission Deferred Approval for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-approval.html>.

[I-D.draft-mcguinness-oauth-mission-child-delegation]

McGuinness, K., "Mission Child Delegation for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-child-delegation.html>.

[I-D.draft-mcguinness-oauth-mission-containment]

McGuinness, K., "Mission Containment for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-containment.html>.

[I-D.draft-mcguinness-oauth-mission-continuation]

McGuinness, K., "Mission Continuation: Authorization Continuity for Mission-Bound Authorization", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-continuation.html>.

[I-D.draft-mcguinness-oauth-mission-progressive]

McGuinness, K., "Mission Progressive Authorization for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-progressive.html>.

[I-D.draft-mcguinness-oauth-mission-signals]

McGuinness, K., "Mission Lifecycle Signals for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-signals.html>.

[I-D.draft-mcguinness-oauth-mission-status]

McGuinness, K., "Mission Status and Lifecycle for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-status.html>.

[I-D.draft-mcguinness-oauth-mission-template]

McGuinness, K., "Mission Template for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-template.html>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/rfc/rfc8126>.

[RFC9470]

Bertocci, V. and B. Campbell, "OAuth 2.0 Step Up Authentication Challenge Protocol", RFC 9470, DOI 10.17487/RFC9470, September 2023, <https://www.rfc-editor.org/rfc/rfc9470>.

[RFC9562]

Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May 2024, <https://www.rfc-editor.org/rfc/rfc9562>.