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 9); and¶

• the expansion denial reasons (Section 10).¶

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:
     |                            |
     |    <-- access token ------ | (a) synchronous: subset
     |                            |     derivation, no fresh
     |                            |     consent needed
     |                            |
     |    <-- authz_pending ----- | (b) deferred: fresh async
     |    ---- poll ------------> |     approval via DTR;
     |    <-- access token ------ |     token on approval
     |                            |
     |    <-- (front channel) --> | (c) 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. When the request is a pure subset derivation of already-approved authority the exchange completes synchronously; otherwise 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). 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 13.5 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, per [I-D.draft-mcguinness-oauth-mission]. It 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.¶

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 13.6) 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 9):¶

• 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 and require subject_token with subject_token_type = urn:ietf:params:oauth:token-type:access_token; reject a refresh token (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. Verify the predecessor is active (Section 4.3) and, when predecessor is present, that it names the resolved Mission.¶

6. Determine whether the request is a pure subset derivation of already-approved authority or requires a fresh approval, and derive the successor's Authority Set under policy (Section 5.2).¶

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

5.2. Completion modes

An expansion completes in one of three modes. The deferred token response is a completion mode, not a replacement: every mode rests on the same possession-proven token exchange (Section 4), and the interactive path is retained.¶

Synchronous:

When the requested authority is a pure subset derivation of authority already approved for the predecessor, no fresh consent is needed and the Mission Issuer issues the successor's access token in the token exchange response. Under this document alone an expansion widens authority and so is not a subset derivation; this mode is reached only where a companion pre-consents an authority ceiling, so an expansion within that ceiling is a drawdown of already-approved authority (the experimental progressive authorization companion, [I-D.draft-mcguinness-oauth-mission-progressive]).¶

Deferred:

When a fresh approval is required and 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 a fresh approval is required interactively, 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.¶

Whichever mode completes, obtaining a 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 10).¶

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 exchange response for a synchronous completion, 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.¶

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

5.4. Successor expiry

The successor's expires_at 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. Expansion is an authority-addition mechanism, not a 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.¶

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

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

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

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

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

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

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

13.6. 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 10); a denial reports whether the requested authority was approved, not the full surface of what would have been.¶

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

14.1. Predecessor-chain correlation

The predecessor member that gives audit linkage (Section 13.7) 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.¶

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

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

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

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