Web Authorization Protocol K. McGuinness Internet-Draft Independent Intended status: Standards Track 8 October 2026 Expires: 11 April 2027 Mission Status and Lifecycle for OAuth 2.0 draft-mcguinness-oauth-mission-status-latest Abstract The Mission-Bound Authorization for OAuth 2.0 profile binds issued authority to a durable, human-approved Mission and gates issuance on Mission state, but it observes Mission state only through token lifetime and optional token introspection. This document defines the Mission state-management surfaces it defers: the Mission Status operation (keyed by mission_id) with signed responses, the Mission projection for token introspection, the Mission Lifecycle endpoint with revoke, suspend, resume, and complete operations, the suspended and completed states with the consolidated lifecycle state machine this profile owns, and revocation-propagation guidance. It defines an extension point through which a companion profile MAY add a fleet- scale Mission Status List or an entry-grain discharge operation without altering this profile's own surfaces. Each capability is independently optional; an implementation can adopt any subset, and one that adopts none remains a conforming issuance profile. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://mcguinness.github.io/mission-bound-authorization/draft- mcguinness-oauth-mission-status.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- mcguinness-oauth-mission-status/. Source for this draft and an issue tracker can be found at https://github.com/mcguinness/mission-bound-authorization. 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 April 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 2. Conventions and Terminology 3. Mission Status Operation 3.1. Request 3.2. Authentication 3.2.1. Authentication Failures 3.3. Worked Request Example 3.4. Response 3.5. Caching 3.6. Anti-Oracle Property 3.7. Error Responses 4. Token Introspection Mission Projection 5. Mission Lifecycle Endpoint 5.1. Operations 5.2. Legal Transitions 5.3. Consolidated State Machine 5.4. Authentication 5.5. Authorization 5.6. Worked Examples 5.7. Idempotency and Conflicts 5.8. Relationship to RFC 7009 5.9. Deferred Lifecycle Capabilities 6. Revocation Propagation 6.1. Recommended Access-Token TTL 7. Operational Considerations 8. Authorization Server Metadata 8.1. Worked Metadata Example 9. Conformance 10. Security Considerations 10.1. Mission Status Enumeration 10.2. Mission Status Response Replay 10.3. Mission Status Denial of Service 10.4. RFC 9701 vs. New Media Type 10.5. Signing-Key Retention for Audit 10.6. General OAuth Security 11. Privacy Considerations 11.1. Status and Lifecycle as Disclosure Surfaces 11.2. Status Audit Logging 12. IANA Considerations 12.1. OAuth Authorization Server Metadata Registration 12.2. Media Type Registration 12.2.1. application/mission-status-response+jwt 12.3. Mission Lifecycle States Registrations 12.4. Well-Known URI Acknowledgments References Normative References Informative References Appendix A. Document History Author's Address 1. Introduction The issuance profile [I-D.draft-mcguinness-oauth-mission] 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 is, by design, a minimum-viable issuance layer. It gates derivation on Mission state, carries the mission claim on every derived token, and offers only OPTIONAL token introspection ([I-D.draft-mcguinness-oauth-mission], Section "Mission State via Token Introspection") as a way for a resource server to observe Mission state. It names this profile for the canonical Mission Status surface (keyed by mission_id) and its signed status evidence, and defers a standardized management endpoint for lifecycle transitions to this document. This document specifies those surfaces as optional extensions that build on the issuance profile. The capabilities are: * A dedicated *Mission Status operation* (Section 3), which any consumer holding a mission_id resolves, with responses signed as a JWS [RFC7515]. * An extension to OAuth token introspection that carries a Mission projection, which a deployment MAY return as a [RFC9701]-signed response (Section 4). * A *Mission Lifecycle endpoint* (Section 5) for explicit revoke, suspend, resume, and complete operations, distinct from [RFC7009] token revocation, with an extension point through which a companion profile MAY register a further operation value, such as the Entry Discharge companion's discharge ([I-D.draft-mcguinness-oauth-mission-discharge]). * A fleet-scale *Mission Status List* extension point, profiled by the Status List companion ([I-D.draft-mcguinness-oauth-mission-status-list]). * *Revocation propagation* guidance (Section 6): a mission_max_stale_seconds bound and how to size token lifetimes to the propagation mechanisms in use. * *authorization server metadata* members (Section 8) advertising the endpoints above. Each capability is independently optional. An implementation states which it supports through the metadata of Section 8 and the conformance language of Section 9. An implementation that supports none of them is unaffected and remains a conforming issuance profile. This document does not restate the issuance profile. The Mission Intent, authority derivation, the mission claim, the integrity anchors, Mission-bound token issuance, the subset rule, and lifecycle gating are all defined in [I-D.draft-mcguinness-oauth-mission]; the mission_resource_access authorization details type is defined in its Mission Resource Access Profile ([I-D.draft-mcguinness-oauth-mission-resource-access]); both are referenced, not re-specified, here. 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. This document uses the terms defined in the issuance profile [I-D.draft-mcguinness-oauth-mission], in particular Mission, Mission Issuer (the Mission issuer: in this document's OAuth binding the authorization server; a standalone Mission Issuer, the Mission Authority Server [I-D.draft-mcguinness-mission-authority-server], serves these surfaces with the same semantics; the AAuth Person Server plays the same role for its native missions through its own AAuth-native management surface [I-D.draft-mcguinness-mission-aauth]), Authority Set, the mission claim, and mission_id; and the mission_resource_access authorization details type defined in its Mission Resource Access Profile ([I-D.draft-mcguinness-oauth-mission-resource-access]). Resource AS is used as defined in the cross-domain companion [I-D.draft-mcguinness-oauth-mission-cross-domain]. It additionally uses: Mission Status Response: A signed payload returned by the dedicated Mission Status operation (Section 3), reporting a Mission's current state and the audience-scoped evidence a consumer needs. Discharge: The state of a mission_resource_access entry whose terminal_when completion condition has been met, as defined by the Entry Discharge companion ([I-D.draft-mcguinness-oauth-mission-discharge]). A discharged entry's authority is spent: it is no longer derivable. Effective Authority Set: The approved Authority Set after applying every issuer-held, monotonic narrowing mechanism the deployment runs. Where the Entry Discharge companion is adopted, it contributes discharged entries ([I-D.draft-mcguinness-oauth-mission-discharge]). Each other narrowing profile defines its own subtraction. No narrowing mechanism adds or restores authority. Membership in this set is necessary, never sufficient, for an action to proceed: the runtime decision evaluates it alongside every other required decision input ([I-D.draft-mcguinness-mission-runtime]). All JSON shown in this document is non-normative and illustrative; the member definitions in the surrounding text are authoritative. HTTP message examples follow the conventions of [RFC9110]; long URLs and form parameters are wrapped for display. JWT and JWS examples are shown as decoded JSON with separate header objects; on the wire the JWS Compact Serialization [RFC7515] applies. 3. Mission Status Operation This section is OPTIONAL. The issuance profile's stateless baseline needs no dedicated status surface ([I-D.draft-mcguinness-oauth-mission], Section "Mission Lifecycle and Gating"); a deployment that does not stand up this operation, and a consumer that does not use it, are unaffected. The dedicated Mission Status operation is the canonical status surface the issuance profile defers. Unlike token introspection (Section 4), which answers "is this token's authorization still good," the Mission Status operation answers "what is the state of this Mission" keyed by the mission_id alone. Any consumer holding a mission_id (including an auditor or a cross-domain Resource AS) resolves it without holding a token the authorization server (AS) issued. The Mission Issuer publishes its Mission Status endpoint URL in authorization server metadata (Section 8) as mission_status_endpoint, which a consumer resolves from a credential's mission.issuer. The endpoint MUST be served over TLS 1.2 or later (TLS 1.3 RECOMMENDED), following the recommendations of [RFC9325]. 3.1. Request The request is an HTTPS POST with an application/x-www-form- urlencoded body containing: mission_id: REQUIRED. A string. The canonical Mission Identifier, named per the issuance profile's external-surface convention ([I-D.draft-mcguinness-oauth-mission]). audience: CONDITIONAL. A string. The audience identifier of the requesting consumer, or of another audience the Mission Issuer authorizes that consumer to request (below). An authorized consumer that is not a resource server (for example an auditor or a cross-domain Resource AS) that needs only Mission state, not audience-scoped authority, MAY omit audience; the response is then state-only and carries no authorization_details (Section 3.4). A resource server resolving authority for a specific audience MUST send it. nonce: REQUIRED. A string. A client-generated nonce binding the response to this request. It MUST be unique per request within the response lifetime. A consumer MUST reject a response whose nonce does not equal the one it sent. This is a standard client challenge: echoing it in the signed response anti-replay-binds that response to this specific request. A request's audience names the caller's own audience unless the Mission Issuer's configuration authorizes the caller for another. A consuming Authorization Server under the Mission Issuance Grant profile ([I-D.draft-mcguinness-oauth-mission-issuance-grant]), for example, requests the projection for each resource it issues tokens for. The Mission Issuer MUST honor a request naming an audience other than the caller's own only where its configuration authorizes the authenticated caller for that audience, and MUST otherwise refuse it with the not-found response of Section 3.7. The response's aud is the requested audience (Section 3.4). 3.2. Authentication The request MUST be authenticated. The AS MUST support at least one of the following mechanisms. The client MUST use exactly one of them per request: 1. *mTLS client authentication* [RFC8705]. The AS validates the client's X.509 certificate against its configured trust anchors and the client's registered tls_client_auth metadata. 2. *Sender-constrained access token*. The client presents a mission_status-scoped access token (see the authorization requirement below) in the Authorization header, sender- constrained either by DPoP [RFC9449] (the DPoP scheme with a DPoP proof header, the token's cnf.jkt matching the proof key thumbprint) or by mTLS [RFC8705] (a certificate-bound token, the Bearer scheme, whose cnf.x5t#S256 matches the presented client certificate). The token MUST be audience-restricted to this endpoint's protected-resource identifier (below). 3. *Private-key-JWT client authentication* [RFC7523]. The client presents client_assertion_type with the exact value urn:ietf:params:oauth:client-assertion-type:jwt-bearer and a signed JWT as client_assertion. The assertion's aud MUST name the URL of the endpoint being invoked (the mission_status_endpoint for a Status request, the mission_lifecycle_endpoint for a Lifecycle request), not the token endpoint; the AS MUST reject an assertion whose aud names no such endpoint. The AS accepts only the JWS [RFC7515] algorithms it advertises for that endpoint (Section 8); none MUST NOT be used. Plain Basic or POST client authentication MUST NOT be used for this endpoint. The AS MUST refuse a request not authenticated by one of the three mechanisms, with the outcome Section 3.2.1 assigns: unauthorized (HTTP 401) or invalid_client (HTTP 400). The mechanism is determined by wire evidence in order: a request presenting an access token in Authorization is mechanism 2, and any client certificate is then evaluated only as that token's mTLS sender constraint; otherwise a request presenting client_assertion is mechanism 3, and any client certificate is not treated as client authentication; otherwise a request presenting only a client certificate is mechanism 1. This order keeps "exactly one mechanism" satisfiable when mTLS terminates at the edge. An authenticated caller MUST additionally carry an explicit read authorization: a mission_status scope on the presented access token, or a deployment-defined equivalent grant bound to the authenticated client. The mission_status scope authorizes the Mission Status read operation and mirrors the mission_lifecycle scope of the Mission Lifecycle endpoint (Section 5). The token-less path is preserved: a consumer that holds only a mission_id and authenticates directly as a client (mechanism 1 or 3) carries the deployment-defined equivalent grant, not a scope, and so resolves Mission state without holding an access token the AS issued. A caller carrying no such authorization is refused with the not-found response of Section 3.7 (Section 3.6). A presented access token (mechanism 2) MUST be audience-restricted to this endpoint's protected-resource identifier: the resource value the AS publishes for this endpoint in its Protected Resource Metadata [RFC9728]. For these surfaces that identifier is the endpoint's own URL (the mission_status_endpoint or mission_lifecycle_endpoint), so the mechanism-2 access-token audience and the mechanism-3 private- key-JWT aud name the same value. The AS MUST reject a token whose audience does not name that identifier. This token audience is distinct from the request body's audience parameter (Section 3.1): the token audience authorizes the call at this endpoint, whereas the request audience carries no authentication weight and only selects the Resource-Server-specific authority projection the response returns (Section 3.4). Which mechanisms and authorization this endpoint accepts are discoverable per endpoint, not inferred from the token endpoint's metadata. The AS advertises the methods this endpoint accepts in mission_status_endpoint_auth_methods_supported (Section 8). For the sender-constrained access-token path, this endpoint is an OAuth protected resource: the AS publishes, in its Protected Resource Metadata for this resource [RFC9728], the resource identifier the token's audience MUST name, the mission_status scope it requires (scopes_supported), and the presentation and sender constraints it accepts (bearer_methods_supported, dpop_bound_access_tokens_required, tls_client_certificate_bound_access_tokens). For the retained direct-client-authentication path (mTLS [RFC8705] or private-key JWT [RFC7523]), the accepted methods and, for private_key_jwt, the accepted client-assertion signing algorithms are advertised for this endpoint (Section 8), not read from the token endpoint's token_endpoint_auth_methods_supported [RFC8414]. Both paths are therefore discoverable. 3.2.1. Authentication Failures A request that fails authentication receives the outcome for the credential it presented: * A request whose presented access token fails authentication receives HTTP 401 unauthorized with a WWW-Authenticate challenge in the scheme it used: Bearer with the error attributes of Section 3 of [RFC6750], or DPoP under Section 7.1 of [RFC9449], including its algs parameter and error codes. * A request whose mTLS or private-key-JWT client authentication fails at the HTTP layer receives HTTP 400 with the invalid_client error code, as Section 5.2 of [RFC6749] answers a failed client authentication carried outside the Authorization header. It carries no WWW-Authenticate challenge and is not reported as an access-token failure. A client certificate rejected during the TLS handshake fails at the TLS layer, before any HTTP response. * A request that presented no credential receives, where the endpoint accepts an access-token scheme, HTTP 401 unauthorized with one challenge for each access-token scheme the endpoint accepts and no error attribute (Section 3.1 of [RFC6750]); where it accepts none, it receives HTTP 400 invalid_client. Every challenge carries the resource_metadata parameter naming the endpoint's Protected Resource Metadata (Section 5.1 of [RFC9728]). An authenticated caller not authorized for the referenced Mission receives not_found (404) with no challenge (Section 3.6). 3.3. Worked Request Example POST /as/mission/status HTTP/1.1 Host: as.example.com Content-Type: application/x-www-form-urlencoded Authorization: DPoP eyJhbGciOiJFUzI1NiIsImtpZCI6... DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2Iiwi... mission_id=msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9- &audience=https%3A%2F%2Ferp.example.com &nonce=nonce_K9pV4nT2sR7mB1xQ 3.4. Response On success the AS returns a JWS Compact Serialization [RFC7515] signed with a key published in the AS's jwks_uri. The JWS header carries typ of mission-status-response+jwt and a kid identifying the signing key. Per [RFC7515] Section 4.1.9 the typ header omits the application/ prefix; the full media type application/mission-status- response+jwt (registered in Section 12) is used as the HTTP Content- Type. Exact validation of the protected typ value, together with mutually exclusive validation rules for the artifact profiles, implements the substitution defense of [RFC8725], Sections 3.11 and 3.12. [RFC9701] signed introspection responses are scoped to token introspection and do not apply to a lookup keyed by mission_id; the dedicated Mission Status operation therefore uses a new media type and a JWS, not [RFC9701] (see Section 10.4). Implementations MUST NOT use [RFC9701] for the dedicated Mission Status operation. The signed payload reports the Mission's current state and the audience-scoped evidence the consumer needs. HTTP/1.1 200 OK Content-Type: application/mission-status-response+jwt Cache-Control: no-store Pragma: no-cache eyJhbGciOiJFUzI1NiIsImtpZCI6InNhLWtleS0yMDI2LXEzIi... Decoded JWS header: { "alg": "ES256", "kid": "sa-key-2026-q3", "typ": "mission-status-response+jwt" } Decoded JWS payload: { "iss": "https://as.example.com", "aud": "https://erp.example.com", "sub": "client_erp-recon-agent", "nonce": "nonce_K9pV4nT2sR7mB1xQ", "iat": 1793606400, "exp": 1793606460, "mission": { "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-", "issuer": "https://as.example.com", "authority_hash": "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ", "state": "active", "version": 4, "expires_at": "2026-12-31T23:59:59Z", "fresh_until": "2026-11-02T08:00:45Z" }, "authorization_details": [ { "type": "mission_resource_access", "resource": "https://erp.example.com", "actions": ["invoices.read", "journal-entries.write"] } ] } The members are: * The signed JWT envelope iss, aud, sub, nonce, iat, exp. The aud is the response's audience binding and the nonce its request binding. When the request omitted audience (Section 3.1), the response is state-only and the AS MUST set aud to the authenticated requester's identifier, as the Lifecycle endpoint does (Section 5); the consumer's aud verification below then checks that identifier. exp bounds the validity of the signed response itself; how long the consumer MAY rely on the reported state is given separately by mission.fresh_until below. * mission: the mission object, the same shape as the mission claim of [I-D.draft-mcguinness-oauth-mission] (Section "The Mission Claim") with status members added. It carries: - id, issuer: the subject Mission's identifier and issuer. - authority_hash: OPTIONAL. The issuance profile's consent commitment over the Authority Set ([I-D.draft-mcguinness-oauth-mission], Section "Integrity Anchors"), disclosed at the AS's discretion to a caller it authorizes for audit or correlation use, on the same minimization footing as the issuance profile's introspection disclosure privilege ([I-D.draft-mcguinness-oauth-mission], Section "Caller Authorization and Minimization"). Not carried on the issuance profile's baseline mission claim. - state: the current Mission lifecycle state. The authoritative state space is the issuance profile's ([I-D.draft-mcguinness-oauth-mission], Section "Mission Lifecycle and Gating"): the issuance profile states active, revoked, expired, this profile's suspended and completed when the Mission Lifecycle endpoint (Section 5) is deployed, and any further state a companion profile defines and the deployment runs (for example superseded, defined by the Mission Expansion profile ([I-D.draft-mcguinness-oauth-mission-expansion]) for an expanded predecessor, or cascaded, defined by the Mission Child Delegation profile ([I-D.draft-mcguinness-oauth-mission-child-delegation]) for a cascade-terminated Child Mission). A consumer applies the issuance profile's forward-compatibility rule: only active permits reliance, and every other value, recognized or not, is non-active. This profile's reliance behavior does not depend on recognizing these companion-defined states; the fail-safe rule above governs. - expires_at: the point at which the Mission itself expires, the Mission record's expires_at ([I-D.draft-mcguinness-oauth-mission]). - fresh_until: an RFC 3339 [RFC3339] date-time giving the point until which the consumer MAY rely on the reported state without re-checking, governing caching (Section 3.5). It is report- freshness metadata, carried in mission so it travels with state even on the introspection projection, which has no signed envelope to carry it (Section 4). - suspend_until, on_expiry: CONDITIONAL. Present only while the Mission is suspended under a deadline (Section 5): the RFC 3339 [RFC3339] deadline, and the transition (resume or revoke) the AS applies when it passes. - successor: OPTIONAL. A string, the successor mission_id. Present only when state is superseded, giving the successor that replaced this Mission, set atomically at supersession on the predecessor's record ([I-D.draft-mcguinness-oauth-mission-expansion]). - carried_to: CONDITIONAL string. A deployment implementing Child Mission Carryover MUST include the committed replacement Mission identifier when reporting the old child's cascaded state, and MUST omit it when no replacement was committed. It is same-issuer correlation, not authority ([I-D.draft-mcguinness-oauth-mission-child-delegation], Section "Carryover Evidence and Observation"). - version: REQUIRED. The Mission's *state version*: a strictly monotonic per-Mission counter the Mission Issuer maintains, incremented on each committed lifecycle transition (the approval event is version 1) and each committed metadata-only change, current as of the reported state. It orders observations of one Mission across every surface: an event consumer that re-established state through this operation re- seats its gap detection on it (the last-applied Signals version becomes this value, [I-D.draft-mcguinness-oauth-mission-signals]), a lifecycle mutation can guard on it (Section 5.7), and a materialized policy view names the value it materialized ([I-D.draft-mcguinness-mission-runtime]). Companion records carry this same counter under their own member names: mission_state_version in Decision Evidence ([I-D.draft-mcguinness-mission-runtime-evidence]), prior_version and new_version in Containment Evidence ([I-D.draft-mcguinness-oauth-mission-containment]), prior_version and current_version in a Discharge Result ([I-D.draft-mcguinness-oauth-mission-discharge]), and expected_version on a lifecycle request (Section 5.7). - Extension members: a companion profile MAY add further members to this object. For example, the Status List companion adds a status_list reference where the deployment publishes a Mission Status List ([I-D.draft-mcguinness-oauth-mission-status-list]). * authorization_details: the Authority Set entries of every AS- supported authorization_details type ([I-D.draft-mcguinness-oauth-mission], Section "Authorization Details Types") relevant to the requesting audience, audience relevance determined per each entry's own type specification (for the general-purpose mission_resource_access type, by its resource member, [I-D.draft-mcguinness-oauth-mission-resource-access]), carried at the top level as a sibling of mission (as on the token and in the introspection response). Entries addressed to other audiences MUST NOT be disclosed. When the request omits audience (Section 3.1), there is no requesting audience: the response is state-only and MUST NOT carry authorization_details. A consumer MUST verify, before honoring a response: 1. the JWS header typ is mission-status-response+jwt; 2. the JWS header alg is one the AS advertises in mission_status_signing_alg_values_supported (Section 8), rejecting none and any algorithm not listed; 3. the JWS signature against a current jwks_uri entry for the issuer AS; 4. iss equals the expected AS issuer URL; 5. aud equals the audience the request named or, for a state-only response, the requester's identifier (Section 3.1); 6. sub equals the requesting client's identifier; 7. nonce equals the request's nonce; 8. mission.id equals the requested mission_id; and 9. iat is not in the future and exp is not in the past, with up to 30 seconds clock-skew tolerance. 3.5. Caching Caching follows these rules: * *Cache key.* Consumers SHOULD cache a response keyed on (mission_id, audience), or on (mission_id, requester identifier) for a state-only response, until mission.fresh_until. * *Hard stop.* Consumers MUST NOT use a cached response after mission.fresh_until. In particular, a consumer MUST NOT extend reliance on a cached suspended (or any non-active) response beyond mission.fresh_until. * *Freshness cap.* When the AS advertises mission_max_stale_seconds (Section 8), it MUST NOT set mission.fresh_until later than the response iat plus that value. * *Skew tolerance.* When comparing the current time to mission.fresh_until, a consumer MAY allow up to 30 seconds of tolerance for the active state only, and no tolerance for any other state. The tolerance MUST NOT exceed the AS's advertised mission_max_stale_seconds (Section 8). The freshness cap keeps report freshness within the deployment's advertised revocation-propagation tolerance. The skew tolerance is a clock-skew allowance on the reliance path, bounding the disagreement between the AS's and the consumer's clocks, not a property of state reversibility. The hard stop is absolute for non-active states because a suspended Mission may be resumed to active. 3.6. Anti-Oracle Property A mission_id is never a bearer capability. The AS MUST authenticate the requester and authorize it for the requested mission_id and audience. Unknown mission_id values and known-but-unauthorized references MUST produce indistinguishable responses (HTTP 404 with a generic not- found body; see Section 3.7). The AS MUST return an identical HTTP status code, response body, and headers for the two cases. The AS SHOULD NOT vary response timing in a way that distinguishes the two cases. It SHOULD mitigate timing side channels (for example by padding response time or by taking a uniform lookup path for both the unknown and the unauthorized case). 3.7. Error Responses Mission Status outcomes are of two kinds. A success outcome is a found, visible, authorized Mission: the AS returns HTTP 200 with a signed Mission Status Response, and the outcome is described by mission.state in that response, not by a separate symbol. A wire error is a hard failure: the AS returns the matching HTTP status with a JSON object [RFC8259] body whose error member carries the symbol below. Success outcomes (HTTP 200, signed Mission Status Response, described by mission.state): +==============================+===========================+ | mission.state | Description | +==============================+===========================+ | active | Mission is active and | | | permits reliance. | +------------------------------+---------------------------+ | suspended | Mission is suspended | | | (non-terminal). | +------------------------------+---------------------------+ | revoked, expired, completed, | Mission is in a terminal, | | superseded, cascaded | non-active state. | +------------------------------+---------------------------+ Table 1 This document uses "terminated" in prose for any terminal non-active state; it is not itself a mission.state value, and the terminal set is not closed. The terminal row above and the list that follows enumerate the companion-defined states this suite currently runs, for the reader's reference; a deployment reports whichever it runs, and a consumer's reliance decision never depends on recognizing them. The terminal states currently defined across this suite are revoked and expired ([I-D.draft-mcguinness-oauth-mission]), completed (this document), superseded ([I-D.draft-mcguinness-oauth-mission-expansion]), and cascaded ([I-D.draft-mcguinness-oauth-mission-child-delegation]). The binding rule is the issuance profile's forward-compatibility rule: every value other than active is non-active, whether or not the consumer recognizes it. Wire error codes (carried in the error member of a JSON body): +=================+======+=========================================+ | error | HTTP | Description | +=================+======+=========================================+ | invalid_request | 400 | Malformed request: an unparseable body, | | | | a required member missing or malformed, | | | | an invalid member combination, or a | | | | retransmitted nonce paired with a | | | | request that is not byte-identical to | | | | the original (Section 5.7). | +-----------------+------+-----------------------------------------+ | invalid_client | 400 | Direct client authentication (mTLS or | | | | private-key JWT) failed, or no | | | | credential was presented where no | | | | access-token scheme is accepted | | | | (Section 3.2.1). | +-----------------+------+-----------------------------------------+ | unauthorized | 401 | Access-token authentication failed, or | | | | no credential was presented where an | | | | access-token scheme is accepted; the | | | | response carries the challenges of | | | | Section 3.2.1. | +-----------------+------+-----------------------------------------+ | not_found | 404 | Reference does not exist OR is not | | | | visible. | +-----------------+------+-----------------------------------------+ | conflict | 409 | Lifecycle operation not legal from the | | | | current state (Section 5.7). | +-----------------+------+-----------------------------------------+ | stale_version | 409 | expected_version differs from the | | | | current state version (Section 5.7). | +-----------------+------+-----------------------------------------+ | rate_limited | 429 | Consumer is rate-limited. | +-----------------+------+-----------------------------------------+ | unavailable | 503 | AS temporarily cannot serve status. | +-----------------+------+-----------------------------------------+ Table 2 Note the distinction between the access failures: unauthorized (401) and invalid_client (400) mean the request carried no valid authentication, whereas a request that is authenticated but not authorized for the referenced Mission returns not_found (404), never an authentication failure, so that an unauthorized reference is indistinguishable from an unknown one (Section 3.6). The error body is: HTTP/1.1 404 Not Found Content-Type: application/json Cache-Control: no-store { "error": "not_found", "error_description": "Mission reference is not found or not visible.", "nonce": "nonce_K9pV4nT2sR7mB1xQ" } The body MUST contain error and error_description, and MUST additionally contain nonce when the request carried a well-formed nonce. A request whose nonce is absent or malformed is refused invalid_request with no nonce member echoed. The body MUST NOT contain any member that would let a caller distinguish unknown from unauthorized references. For rate_limited, the response SHOULD include a Retry-After header [RFC9110] and a retry_after body member in seconds. The OAuth-shaped surfaces of this family, this Status and Lifecycle endpoint, Mission Management [I-D.draft-mcguinness-oauth-mission-management], and the Mission Authority Server's submission surface [I-D.draft-mcguinness-mission-authority-server], share the error/ error_description JSON body idiom for consistency with the OAuth- shaped APIs they compose with. Each surface's exact member requiredness is its own: here and in Mission Management, error_description and nonce are REQUIRED; the Mission Authority Server makes error_description OPTIONAL and adds the MAS-only error_reason. The body is application/json with Cache-Control: no-store. error_description is diagnostic and is never authorization input. nonce correlates the response to the request in support of the signed-response and retry model of Section 5.7 and is not, by itself, replay protection, per the absent-or-malformed-nonce rule above. RFC 9457 [RFC9457] problem details is neither used on these surfaces nor disparaged: the AuthZEN profile [I-D.draft-mcguinness-mission-authzen] carries it where that ecosystem does, and a future non-OAuth-shaped HTTP API in this family MAY choose it. 4. Token Introspection Mission Projection This section is OPTIONAL and is a thin delta over the OAuth 2.0 Token Introspection [RFC7662] projection of [I-D.draft-mcguinness-oauth-mission] (Section "Mission State via Token Introspection"). That section already defines a mission member on the introspection response carrying id and issuer, and (from the Mission's issuer) the lifecycle state, with authority_hash disclosed only to a caller holding that member's disclosure privilege, together with the caller-authorization, minimization, and issuer-only-reports- state rules. This document does not restate those rules. This extension adds the following to that projection: * An introspection response that carries a Mission projection is protected by TLS, as for token introspection generally ([I-D.draft-mcguinness-oauth-mission], Section "Mission State via Token Introspection"). Where the projection's integrity and provenance need to be verifiable independently of the transport (for example when the response transits intermediaries or is retained for audit), the AS SHOULD return it as a [RFC9701]-signed response, advertised through the introspection_signing_alg_values_supported metadata that [RFC9701] registers in the [RFC8414] registry. * When the responding AS is the Mission's issuer, the projection MAY additionally carry fresh_until, an RFC 3339 [RFC3339] date-time giving the point until which the consumer MAY rely on the reported state without re-checking, governed by the caching rule of Section 3.5. When fresh_until is absent (for example a non-issuer projection), the consumer MUST NOT cache the reported state across requests and re-checks per use or relies on the token's own lifetime. This projection and the dedicated Mission Status Response (Section 3.4) carry Mission facts in a mission object of the same shape: the open mission claim object of [I-D.draft-mcguinness-oauth-mission] (Section "The Mission Claim") with status members (state, fresh_until, any companion-defined extension member such as the Status List companion's status_list reference ([I-D.draft-mcguinness-oauth-mission-status-list]), and, on the dedicated response, expires_at and version) added. This projection populates the subset a token-holding consumer needs; the dedicated response populates more. Either way a consumer reads the same fact from the same place. Example [RFC9701]-signed introspection response (decoded payload), for a token whose Mission is active: { "iss": "https://as.example.com", "aud": "https://erp.example.com", "iat": 1793606400, "token_introspection": { "active": true, "client_id": "s6BhdRkqt3", "sub": "user_3p2q8mN1a0kV7tR", "scope": "invoices.read", "mission": { "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-", "issuer": "https://as.example.com", "authority_hash": "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ", "state": "active", "fresh_until": "2026-11-02T08:00:45Z" } } } Per [RFC9701], the signed response is a JWT of typ token- introspection+jwt whose [RFC7662] members, including the mission projection, ride in the token_introspection claim; only iss, aud, and iat are top-level. A consumer holding only a mission_id, or one that needs signed evidence independent of a specific token (an auditor or a cross- domain Resource AS), uses the dedicated Mission Status operation (Section 3); the introspection projection is purely a same-call convenience for token-holding consumers and is never the sole Mission Status path. 5. Mission Lifecycle Endpoint This section is OPTIONAL. The issuance profile lets the Subject, Approver, or an administrator revoke a Mission by an authenticated, deployment-defined means and defers a standardized management API and the richer suspend, resume, and complete operations ([I-D.draft-mcguinness-oauth-mission], Section "Revocation"). This section standardizes that management surface. The AS publishes its Mission Lifecycle endpoint URL in authorization server metadata (Section 8) as mission_lifecycle_endpoint, distinct from [RFC7009] token revocation. The endpoint MUST be served over TLS 1.2 or later (TLS 1.3 RECOMMENDED), following the recommendations of [RFC9325]. Adopting this endpoint extends the issuance profile's lifecycle state space ([I-D.draft-mcguinness-oauth-mission], Section "Mission Lifecycle and Gating") with two additional states: suspended (a non- terminal paused Mission that derives no tokens until resumed) and completed (a terminal state recording successful completion). Issuance gating treats any state other than active as non-deriving, exactly as the issuance profile gates on active. A transition to suspended or completed gates new derivation only. Tokens already derived under the Mission remain valid until their own exp, exactly as in the issuance profile's revocation model and mirroring the treatment of superseded ([I-D.draft-mcguinness-oauth-mission-expansion]). A deployment that needs a prompt cutoff on outstanding tokens uses the propagation mechanisms of Section 6. Suspension is reversible, so a refresh refused for it should not spend the client's ability to refresh after a resume. After validating a refresh request and before consuming or rotating its refresh token, the AS SHOULD check whether the Mission, or an ancestor whose state gates its derivation ([I-D.draft-mcguinness-oauth-mission-child-delegation]), is suspended. When this check detects suspension, the AS SHOULD refuse the request without consuming the refresh token or invalidating its otherwise-valid grant solely because of that suspension. This check does not replace issuance-time state validation. A concurrent suspension can still cause issuance to be refused after the preliminary check, and preserving refresh capability across that interval requires coordination with the issuance commit. The check leaves refresh-token rotation and reuse detection intact, and a resume does not revive a credential that expired or was revoked independently. An error code alone does not tell a client whether a resume can lift a refusal. When the issuance profile's gating refuses a derivation because the Mission is suspended or completed, the AS SHOULD include, alongside error, the mission_error token-error-response member ([I-D.draft-mcguinness-oauth-mission], Section "Issuance Gating") with the value mission_suspended or mission_completed, respectively. The issuance profile's rules for that member apply: it is diagnostic only, it grants nothing, an unrecognized value is ignored, and it is returned only to the authenticated client presenting the Mission's grant. mission_suspended reports a refusal that a resume can lift; mission_completed reports a terminal one. 5.1. Operations The endpoint accepts authenticated POST requests with a form- urlencoded body: mission_id: REQUIRED. A string. The canonical Mission Identifier, named per the issuance profile's external-surface convention ([I-D.draft-mcguinness-oauth-mission]). operation: REQUIRED. A string. One of revoke, suspend, resume, complete, or a further value a companion profile registers as an extension operation on this endpoint, such as the Entry Discharge companion's discharge ([I-D.draft-mcguinness-oauth-mission-discharge]). reason: OPTIONAL. A string. A human-readable reason recorded in audit, maximum 1024 characters. Not used by a companion- registered operation that records its own request members in audit, such as discharge ([I-D.draft-mcguinness-oauth-mission-discharge]). suspend_until: OPTIONAL. An RFC 3339 [RFC3339] date-time. Valid only on the suspend operation. When present, it sets a deadline after which the AS applies on_expiry. on_expiry: CONDITIONAL. A string, one of resume or revoke. REQUIRED when suspend_until is present; otherwise MUST NOT be sent. It selects the transition the AS applies when suspend_until passes. nonce: REQUIRED. A string. A client-generated nonce. A companion-registered extension operation, such as discharge, carries additional REQUIRED and OPTIONAL members of its own, defined completely by the companion that registers it ([I-D.draft-mcguinness-oauth-mission-discharge]). The base operations are: * revoke: terminate the Mission; transition to revoked. * suspend: pause the Mission; transition to suspended. * resume: return a suspended Mission to active. * complete: mark the Mission completed; transition to completed. A companion profile MAY register a further operation value on this endpoint that changes no Mission-level state, provided it defines the value's request members, authorization, anti-oracle behavior, and result shape completely. The Entry Discharge companion registers discharge this way: it commits that a completion condition has fired, discharging a Mission-record entry, and is defined in full by that companion ([I-D.draft-mcguinness-oauth-mission-discharge]). A suspend MAY carry suspend_until with a REQUIRED on_expiry; the pair is the Mission's schedule. When the suspend_until of a current schedule passes, the AS MUST apply on_expiry (transition to active for resume, or to revoked for revoke) and emit the corresponding transition, without a further request. While the Mission is suspended under a deadline, both suspend_until and on_expiry surface in the signed Mission Status Response (Section 3.4) so a consumer sees the pending outcome. The AS authorizes a schedule when it commits it (Section 5.5) and does not re-authorize it at the deadline: a later expiry or withdrawal of the committing party's grant does not by itself cancel it. A schedule is current until its suspension ends or an authorized replacement supersedes it (Section 5.7). The AS MUST NOT apply a schedule that is no longer current, so an earlier deadline never acts on a later suspension. A deadline applies only a transition legal from the Mission's current state (Section 5.2) and never changes a terminal Mission. 5.2. Legal Transitions An operation is legal only from the source states below. A terminal state (revoked, expired, completed, or the companion-defined superseded and cascaded) admits no transition. An operation whose resulting state equals the current state, terminal or not, is idempotent success (Section 5.7). This table governs Mission-level state; a companion-registered extension operation such as discharge produces no Mission-state transition and is not a row of it, following instead the entry-grain rules the Entry Discharge companion defines ([I-D.draft-mcguinness-oauth-mission-discharge]). resume is the sole exception: it is legal only from suspended (its resulting state, active, is also the baseline a Mission holds before any suspension), so resume on an active or terminal Mission is a conflict, not idempotent success. +===========+===================+=================+ | Operation | Legal from | Resulting state | +===========+===================+=================+ | revoke | active, suspended | revoked | +-----------+-------------------+-----------------+ | suspend | active | suspended | +-----------+-------------------+-----------------+ | resume | suspended | active | +-----------+-------------------+-----------------+ | complete | active, suspended | completed | +-----------+-------------------+-----------------+ Table 3 complete is legal from suspended as well as active: completion is a monotonic narrowing to a terminal state and needs no derivation window, so a suspended Mission need not first be resumed to be completed. Requests are adjudicated by the single rule of Section 5.7: an operation whose resulting state equals the Mission's current state is idempotent success, with the resume exception above. Any other operation not legal from the current state, including resume on a Mission that is not suspended, is refused as a conflict. A Mission that reaches its expires_at transitions to expired independently of this endpoint, from active or suspended. When a schedule's suspend_until is at or after the Mission's expires_at, expiry governs: the Mission becomes expired at expires_at, and the AS MUST NOT apply that schedule's on_expiry. 5.3. Consolidated State Machine This profile owns the extension of the issuance profile's lifecycle state space ([I-D.draft-mcguinness-oauth-mission], Section "Mission Lifecycle and Gating"). The table below is the authoritative view of that space: every state, every transition, and the source of the event that drives it. Event sources are the lifecycle endpoint (an operation of Section 5), the expiry clock (a deadline reached without a request), and companion adjudication (a transition a companion profile commits). The lifecycle-endpoint rows are exactly the Mission-state-changing operations of Section 5.2; a companion-registered extension operation such as discharge ([I-D.draft-mcguinness-oauth-mission-discharge]) is a lifecycle-endpoint operation that changes no Mission state and so is not a row of this table. Only active permits derivation; every other state is non-deriving. +===========+====================+==================+============+ | From | Event | Event source | To | +===========+====================+==================+============+ | (none) | approval event | issuance profile | active | +-----------+--------------------+------------------+------------+ | active | revoke | lifecycle | revoked | | | | endpoint | | +-----------+--------------------+------------------+------------+ | suspended | revoke | lifecycle | revoked | | | | endpoint | | +-----------+--------------------+------------------+------------+ | active | suspend | lifecycle | suspended | | | | endpoint | | +-----------+--------------------+------------------+------------+ | suspended | resume | lifecycle | active | | | | endpoint | | +-----------+--------------------+------------------+------------+ | active | complete | lifecycle | completed | | | | endpoint | | +-----------+--------------------+------------------+------------+ | suspended | complete | lifecycle | completed | | | | endpoint | | +-----------+--------------------+------------------+------------+ | active | expires_at reached | expiry clock | expired | +-----------+--------------------+------------------+------------+ | suspended | expires_at reached | expiry clock | expired | +-----------+--------------------+------------------+------------+ | suspended | suspend_until | expiry clock | active | | | reached, on_expiry | | | | | = resume | | | +-----------+--------------------+------------------+------------+ | suspended | suspend_until | expiry clock | revoked | | | reached, on_expiry | | | | | = revoke | | | +-----------+--------------------+------------------+------------+ | active | successor | expansion | superseded | | | activates | profile | | +-----------+--------------------+------------------+------------+ | active | parent reaches a | child-delegation | cascaded | | | terminal state | profile | | +-----------+--------------------+------------------+------------+ | suspended | parent reaches a | child-delegation | cascaded | | | terminal state | profile | | +-----------+--------------------+------------------+------------+ Table 4 revoke and the Mission's expires_at both apply in suspended as well as active, so a suspended Mission can still be terminated or expire. A suspend_until row fires only for a current schedule whose deadline falls before expires_at (Section 5, Operations; Section 5.2). The superseded and cascaded rows are companion-defined and shown here for reference: superseded is committed by the expansion profile and requires an active predecessor ([I-D.draft-mcguinness-oauth-mission-expansion]); cascaded is committed by the child-delegation profile only when a parent reaches a terminal state. A suspended parent holds a dependent Child Mission non-active reversibly rather than driving it to cascaded ([I-D.draft-mcguinness-oauth-mission-child-delegation]). Neither companion state is produced by this profile's endpoint. 5.4. Authentication The lifecycle endpoint uses the same authentication mechanisms as the Mission Status endpoint (Section 3.2): mTLS client authentication, a sender-constrained access token (DPoP- or mTLS-bound), or private-key JWT. Its discovery mirrors that endpoint: the accepted methods in mission_lifecycle_endpoint_auth_methods_supported and, for private_key_jwt, the accepted client-assertion algorithms in mission_lifecycle_endpoint_auth_signing_alg_values_supported (Section 8). Its authentication failures follow Section 3.2.1. For the sender-constrained access-token path, this endpoint is an OAuth protected resource exactly as the Mission Status endpoint is: the AS publishes, in its Protected Resource Metadata for this resource [RFC9728], the resource identifier the token's audience MUST name and the scopes it requires (scopes_supported): mission_lifecycle for revoke, suspend, resume, and complete (Section 5), and, where the deployment adopts the Entry Discharge companion, mission_discharge as well ([I-D.draft-mcguinness-oauth-mission-discharge]). A private-key JWT client_assertion MUST name the mission_lifecycle_endpoint URL in aud, and a presented access token MUST be audience-restricted to this endpoint's protected-resource identifier, exactly as at the Mission Status endpoint. Direct mTLS or private-key-JWT callers continue to use the deployment-defined equivalent grant, never a scope, exactly as a companion-registered extension operation such as discharge does ([I-D.draft-mcguinness-oauth-mission-discharge]). 5.5. Authorization This section governs revoke, suspend, resume, and complete; a companion-registered extension operation such as discharge has its own distinct authority model ([I-D.draft-mcguinness-oauth-mission-discharge]), which a mission_lifecycle grant under this section MUST NOT imply. The AS authorizes lifecycle operations against deployment policy. This document sets the minimum authorization semantics and leaves finer policy deployment-defined. Every authenticated caller, whatever its authentication mechanism (Section 3.2), MUST be governed by an explicit lifecycle authorization: a mission_lifecycle scope or a deployment-defined equivalent grant that names who may perform the transition. The AS MUST refuse a caller that carries no such authorization. The acting party, and where the AS checks the lifecycle authorization, follow from the authentication case: 1. When an access token authenticates the call, the token identifies the parties per the issuance profile's access-token model ([I-D.draft-mcguinness-oauth-mission]): for a delegated access token its sub denotes the resource owner (the represented party), matching the [RFC9068] access-token sub model; the calling party is identified by client_id ([RFC8693] Section 4.3); and, where a delegation chain is present, the immediate actor is identified by the act claim ([RFC8693], [I-D.draft-mcguinness-oauth-mission]). A DPoP [RFC9449] or mTLS [RFC8705] sender constraint binds the presenter to a key; it does not change what sub denotes. The acting party is the calling party so identified, and the presented token MUST carry the lifecycle authorization the AS checks against it. 2. When the caller authenticates directly as a client (mTLS client authentication [RFC8705] or private-key JWT [RFC7523]), the authenticated client is the acting party. The AS MUST check the deployment-defined lifecycle grant bound to that client. In every case the AS MUST record the acting party and SHOULD reflect it in the signed response's audit surface: the response envelope's sub, distinct from any access token's sub, or a deployment-defined audit member of the Mission Status Response. Which parties may perform which operation is deployment-defined. Typical deployments authorize revoke to the Mission's Subject or Approver and to administrators; suspend and resume to administrators; and complete to the requesting client or an administrator. Because resume returns a suspended Mission to active and so undoes the containment a suspend established, a deployment SHOULD require a distinct or elevated authorization for resume, mirroring the treatment of bulk resume in Mission Management ([I-D.draft-mcguinness-oauth-mission-management]). A suspend whose on_expiry is resume schedules a later resume. The AS MUST authorize it against both the caller's authorization for suspend and the authorization the deployment requires for a direct resume of that Mission, including when it sets or replaces the schedule of a Mission already suspended, whoever suspended it. The AS checks both before any change and refuses a caller lacking either as an unauthorized lifecycle request (below), leaving the Mission's state and schedule unchanged. A suspend whose on_expiry is revoke needs only the authorization for suspend. The AS MUST record with each committed schedule its committing party, the acting party of the request that committed it; an authorized replacement records its own. The AS MUST refuse an unauthorized lifecycle request with the not- found response shape of Section 3.7, so the endpoint does not act as a Mission enumeration oracle. 5.6. Worked Examples Revoke request: POST /as/mission/lifecycle HTTP/1.1 Host: as.example.com Content-Type: application/x-www-form-urlencoded Authorization: DPoP eyJhbGciOiJFUzI1NiIsImtpZCI6... DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2Iiwi... mission_id=msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9- &operation=revoke &reason=Quarterly+reconcile+completed+early &nonce=nonce_8Y3vN0sM6tP1xR9bQ5 Revoke success response: the AS returns the updated status as a signed Mission Status Response (Section 3.4). Because the Lifecycle request carries no audience, the response is state-only: the AS sets aud to the authenticated requester and omits authorization_details (a lifecycle confirmation reports state, not audience-scoped authority). Here the response envelope's sub, distinct from any access token's sub, carries the acting party: the calling client identified by client_id. The AS records that acting party and reflects it in this signed response as well as in its audit log. HTTP/1.1 200 OK Content-Type: application/mission-status-response+jwt Cache-Control: no-store eyJhbGciOiJFUzI1NiIsImtpZCI6InNhLWtleS0yMDI2LXEzIi... Decoded JWS payload: { "iss": "https://as.example.com", "aud": "client_erp-recon-agent", "sub": "client_erp-recon-agent", "nonce": "nonce_8Y3vN0sM6tP1xR9bQ5", "iat": 1793609600, "exp": 1793609660, "mission": { "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-", "issuer": "https://as.example.com", "authority_hash": "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ", "state": "revoked", "version": 7, "expires_at": "2026-12-31T23:59:59Z", "fresh_until": "2026-11-02T08:54:05Z" } } The AS records the operation, actor, time, and any reason in its audit log; the response confirms the outcome through the updated state. Suspend request with a deadline, here also carrying the OPTIONAL expected_version guard against deciding over stale state (Section 5.7): POST /as/mission/lifecycle HTTP/1.1 Host: as.example.com Content-Type: application/x-www-form-urlencoded Authorization: DPoP eyJhbGciOiJFUzI1NiIsImtpZCI6... DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2Iiwi... mission_id=msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9- &operation=suspend &suspend_until=2026-11-09T08%3A15%3A00Z &on_expiry=revoke &expected_version=5 &reason=Pending+quarterly+access+review &nonce=nonce_4Dq2mV8kX1sB7nR3tW Suspend success response: the signed Mission Status Response reports suspended and surfaces the pending outcome, carrying suspend_until and on_expiry in mission alongside state. Decoded JWS payload: { "iss": "https://as.example.com", "aud": "client_erp-recon-agent", "sub": "client_erp-recon-agent", "nonce": "nonce_4Dq2mV8kX1sB7nR3tW", "iat": 1793607600, "exp": 1793607660, "mission": { "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-", "issuer": "https://as.example.com", "authority_hash": "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ", "state": "suspended", "version": 6, "suspend_until": "2026-11-09T08:15:00Z", "on_expiry": "revoke", "expires_at": "2026-12-31T23:59:59Z", "fresh_until": "2026-11-02T08:20:45Z" } } When suspend_until passes without a resume, the AS applies on_expiry and transitions the Mission to revoked without a further request. 5.7. Idempotency and Conflicts The request nonce (Section 5, Operations) is the idempotency key: an opaque string of 1 to 255 characters. The AS treats an absent, empty, longer, or non-string nonce as malformed (invalid_request, with no nonce echoed). The AS MUST deduplicate lifecycle requests by the triple (client, mission_id, nonce) for a bounded window. On a retransmit carrying a nonce already seen for that client and mission_id, together with a request byte-identical to the original, the AS MUST replay the original response rather than re-execute the operation. The same nonce paired with a request that is not byte-identical to the original MUST be refused invalid_request (Section 3.7); the AS MUST NOT answer it with the unrelated original response. The window MUST be at least the validity span of the signed response the AS would replay (its iat to exp, Section 3.4), so any retransmit that could still present a live response is deduplicated. A deployment MAY use a longer window. This makes a retransmit safe against reordering: a delayed suspend retry that arrives after a resume is recognized as a duplicate and replays the original suspend response, so it cannot re-suspend an already-resumed Mission. Deduplication guards a retransmitted request; it does not guard a valid request decided over stale state, a fresh suspend issued from a console that has not yet seen a newer resume. For that a lifecycle request MAY carry expected_version, the state version (Section 3.4) the caller last observed: when present, the AS MUST refuse the operation with HTTP 409 and error symbol stale_version, leaving the Mission unchanged, when the Mission's current state version differs. A deployment SHOULD require expected_version on the operations it classifies high-risk. The nonce remains the replay key; the two guards are independent, one against duplicate delivery, one against stale decisions. Lifecycle operations that change Mission state follow one rule. An operation whose resulting state (Section 5.2) equals the Mission's current state is idempotent success, terminal or not: the AS returns the current Mission Status Response, with no state change and no event emitted. Any other operation not legal from the current state (for example suspend against a terminal state) is a conflict: the AS MUST refuse it with HTTP 409 and a JSON body whose error symbol is conflict, leaving the Mission state unchanged. A companion- registered extension operation that changes no Mission state, such as discharge, is not bound by this rule; its own idempotency and outcome vocabulary are defined by the companion that registers it, for discharge by the Entry Discharge companion ([I-D.draft-mcguinness-oauth-mission-discharge]). resume is the sole exception to the idempotent-success arm. It is legal only from suspended, and its resulting state active is also the baseline a Mission holds before any suspension, so resume on an active Mission (one never suspended, or already resumed) or on a terminal Mission is not idempotent success but a conflict. One idempotent case carries metadata. A suspend against a suspended Mission that carries a suspend_until and on_expiry pair differing from the recorded schedule, or where none is recorded, replaces the schedule once authorized (Section 5.5): the AS MUST update the recorded values and their committing party, emitting the corresponding transition-metadata change and reporting the updated values in the response; silent acceptance without effect is not conforming. A suspend that omits both members leaves the recorded schedule, if any, and its committing party unchanged: omission never clears a deadline. A suspend carrying only one of the two remains invalid (Section 5, Operations) and changes nothing. 5.8. Relationship to RFC 7009 A Mission revocation through this endpoint cascades to credentials derived from the Mission per the AS's advertised revocation propagation (Section 6). The AS MAY additionally revoke specific outstanding tokens it knows by jti, with the same effect as [RFC7009] revocation of each token. [RFC7009] alone does NOT revoke a Mission; the lifecycle endpoint is the authoritative Mission state change. 5.9. Deferred Lifecycle Capabilities This endpoint operates on one Mission at a time. Mission enumeration and bulk lifecycle operations for incident response, such as revoking every Mission for a compromised Subject, client, or tenant, are specified separately by Mission Management [I-D.draft-mcguinness-oauth-mission-management]; this document does not require them. The following capabilities remain deferred to future work: * Approver transfer or re-anchoring, changing the party that anchors a Mission's consent, is not defined here. * Administrative monotonic narrowing, such as shortening a Mission's expires_at, is not defined here. 6. Revocation Propagation This section is OPTIONAL. The issuance profile bounds outstanding self-contained tokens by their lifetime and OPTIONAL token introspection ([I-D.draft-mcguinness-oauth-mission], Section "Revocation"). A deployment that needs a Mission state change to take effect faster than token lifetime alone combines the propagation mechanisms this suite offers and sizes token lifetimes to match. The mechanisms are each discovered from their own metadata, not from a separate posture list: * consulting Mission state at each derivation event (the token endpoint, refresh, Token Exchange), the issuance profile's always- present baseline, which does not invalidate already-issued self- contained tokens; * token introspection (Section 4), which returns active: false for a token whose Mission state disallows use even before the token expires, discovered from introspection_endpoint and introspection_signing_alg_values_supported; * the Mission Status operation (Section 3) for per-request state checks by high-assurance resource servers, discovered from mission_status_endpoint; and * event-driven propagation of state changes over a Shared Signals stream ([I-D.draft-mcguinness-oauth-mission-signals]), discovered from mission_event_stream_endpoint. A deployment advertises mission_max_stale_seconds (Section 8), the maximum interval it tolerates for a Mission state change to take effect, so a consumer can size token lifetimes and choose propagation mechanisms to match. When the member is absent, no propagation bound is declared: a consumer MUST size reliance to token lifetime alone and MUST NOT assume a tighter bound. Where the member is present, a status response's mission.fresh_until MUST NOT exceed the response's issuance time plus the advertised bound: the advertisement is the ceiling on every reliance window built from these surfaces, including a runtime permit's validity window, which is capped by the state view's freshness. As sizing guidance, the runtime enforcement profile's recommended defaults target an effective bound under 300 seconds for the high-consequence classes; the 60-second value in this document's examples is a tight deployment's choice, not a floor. 6.1. Recommended Access-Token TTL Where Mission revocation must take effect but only the baseline derivation-time check is in use, Mission-bound access tokens SHOULD use TTLs no longer than the declared mission_max_stale_seconds. Deployments where revocation propagates out of band (token introspection, per-request status checks, or the event stream) MAY use longer TTLs. Sizing to the bound is itself a propagation mechanism: expiry performs the state check, and the consumer integrates nothing (the runtime profile names this token-lifetime freshness for the classes below its high-consequence floor). Introspection and per-request status checks tighten specific paths; they are upgrades, not prerequisites. 7. Operational Considerations A deployment declaring revocation propagation SHOULD publish the recovery objective considered when choosing mission_max_stale_seconds and the availability consequence when recovery takes longer than that bound. The security ceiling governs the choice: an operational recovery objective never authorizes extending a published freshness horizon during an incident. An existing observation's remaining validity is not reset when an outage is detected. An issuer outage and a state- source outage are distinct where the topology provides an independently available authoritative source. Runtime's Operational Considerations gives the per-action-class dependency analysis ([I-D.draft-mcguinness-mission-runtime]). The deployment describes its distribution posture per surface: Status responses are reused only to their authenticated fresh_until and other applicable bounds; Status Lists are fetched within their freshness window and checked locally; Signals accelerate learning of transitions over a correctly bounded state source, not replace that source after confidence is lost. The Status List freshness rules ([I-D.draft-mcguinness-oauth-mission-status-list]) and Signals' Missed Events Are Not Fail-Open rule ([I-D.draft-mcguinness-oauth-mission-signals]) remain authoritative. Operators watch observation age and remaining validity, failed refreshes, stream gaps, fallback availability, clock health, and catch-up after recovery. A recovery check reconciles committed state and versions before publishing newly fresh observations. A successful HTTP response or a new signature alone does not establish that reconciliation. No new endpoint, metadata member, availability target, or replication protocol is defined here. 8. Authorization Server Metadata This section is OPTIONAL and applies only to a deployment that adopts one or more of the extensions above. An AS advertises the surfaces it supports through the following members of its authorization server metadata document [RFC8414], in addition to the issuance profile's mission_bound_authorization_supported ([I-D.draft-mcguinness-oauth-mission], Section "Authorization Server Metadata"). Unlike the issuance profile, which advertises only that boolean, this document defines OAuth AS metadata members for the endpoints and classes it introduces, so a consumer discovers them through standard [RFC8414] discovery. mission_status_endpoint: OPTIONAL. A string containing a URL. The URL of the dedicated Mission Status operation (Section 3). Present when the AS supports it. mission_status_endpoint_auth_methods_supported: OPTIONAL. A JSON array of strings naming the authentication methods the Mission Status endpoint (Section 3) accepts. Its value space is a closed set defined by this document, not the OAuth Token Endpoint Authentication Methods registry: tls_client_auth (mutual-TLS client authentication [RFC8705]), private_key_jwt (private-key JWT client authentication [RFC7523]), and access_token (a mission_status-scoped, sender-constrained access token, whose presentation and DPoP or mTLS binding are described by this endpoint's Protected Resource Metadata [RFC9728]). The first two values are spelled identically to registered token-endpoint authentication methods by intent; this member describes this endpoint, not the token endpoint. Present, and SHOULD be advertised, when the AS serves the Mission Status endpoint. mission_status_endpoint_auth_signing_alg_values_supported: OPTIONAL. A JSON array of strings, the JWS [RFC7515] algorithm values the AS accepts for the private_key_jwt client-assertion JWT (Section 3.2) at the Mission Status endpoint. This is the client-assertion verification set, not the response-signing algorithms of mission_status_signing_alg_values_supported below. none MUST NOT be used. Present when that endpoint lists private_key_jwt. mission_status_signing_alg_values_supported: OPTIONAL. A JSON array of strings. The JWS [RFC7515] algorithm values the AS uses to sign the Mission Status Response shape (Section 3.4), on whichever surfaces of this profile family serve it (the dedicated Mission Status operation, the Lifecycle endpoint, and Mission Management), mirroring introspection_signing_alg_values_supported. These are the response-signing algorithms, not the algorithms the AS accepts on private_key_jwt client assertions (the endpoint auth-signing members). Present when the AS serves any such surface. mission_lifecycle_endpoint: OPTIONAL. A string containing a URL. The URL of the Mission Lifecycle endpoint (Section 5). Present when the AS supports it. mission_lifecycle_endpoint_auth_methods_supported: OPTIONAL. A JSON array of strings naming the authentication methods the Mission Lifecycle endpoint (Section 5) accepts, from the same closed value space as mission_status_endpoint_auth_methods_supported (with access_token naming a mission_lifecycle-scoped access token). Present, and SHOULD be advertised, when the AS serves the Mission Lifecycle endpoint. mission_lifecycle_endpoint_auth_signing_alg_values_supported: OPTIONAL. A JSON array of strings, the JWS [RFC7515] algorithm values the AS accepts for the private_key_jwt client-assertion JWT (Section 3.2) at the Mission Lifecycle endpoint. This is the client-assertion verification set, not the response-signing algorithms of mission_status_signing_alg_values_supported. none MUST NOT be used. Present when that endpoint lists private_key_jwt. mission_max_stale_seconds: OPTIONAL. An integer. The maximum tolerated interval, in seconds, for revocation propagation (Section 6). When absent, no bound is declared, and a consumer sizes reliance to token lifetime alone. When an endpoint's *_auth_methods_supported member is absent, the methods that endpoint accepts are known only by out-of-band configuration; token_endpoint_auth_methods_supported [RFC8414] describes the token endpoint alone and is never read in its place. DPoP and mTLS support for issued credentials are read from the standard dpop_signing_alg_values_supported [RFC9449] and tls_client_certificate_bound_access_tokens [RFC8705] metadata; this document defines no separate sender-constraint member. When the introspection projection (Section 4) is signed, the signing is discovered through the standard introspection_signing_alg_values_supported metadata. 8.1. Worked Metadata Example A discovery response from https://as.example.com/.well-known/oauth- authorization-server, showing the issuance profile members plus the extension members of this document: HTTP/1.1 200 OK Content-Type: application/json Cache-Control: max-age=3600 { "issuer": "https://as.example.com", "token_endpoint": "https://as.example.com/as/token", "introspection_endpoint": "https://as.example.com/as/introspect", "jwks_uri": "https://as.example.com/.well-known/jwks.json", "introspection_signing_alg_values_supported": ["ES256"], "mission_bound_authorization_supported": true, "mission_status_endpoint": "https://as.example.com/as/mission/status", "mission_status_endpoint_auth_methods_supported": ["tls_client_auth", "private_key_jwt", "access_token"], "mission_status_endpoint_auth_signing_alg_values_supported": ["ES256"], "mission_status_signing_alg_values_supported": ["ES256"], "mission_lifecycle_endpoint": "https://as.example.com/as/mission/lifecycle", "mission_lifecycle_endpoint_auth_methods_supported": ["tls_client_auth", "private_key_jwt", "access_token"], "mission_lifecycle_endpoint_auth_signing_alg_values_supported": ["ES256"], "mission_max_stale_seconds": 60 } 9. Conformance An implementation conforms to the issuance profile [I-D.draft-mcguinness-oauth-mission] or implements the Mission Issuer role of a binding that serves these surfaces, such as the standalone Mission Authority Server [I-D.draft-mcguinness-mission-authority-server]. Each extension in this document is independently OPTIONAL; an implementation names the ones it supports (for example, "issuance profile with Mission Status and Mission Lifecycle"), and an implementation that supports none of them is still a conforming issuance profile. An implementation claiming an extension MUST meet its requirements: * *Mission Status*: serve the dedicated Mission Status operation (Section 3) with JWS-signed responses (application/mission-status- response+jwt), the authentication and read authorization of Section 3.2, the anti-oracle property (Section 3.6), and the error shape of Section 3.7; and advertise mission_status_endpoint and mission_status_endpoint_auth_methods_supported. * *Introspection projection*: carry the Mission projection on the introspection response (Section 4), returning it as a [RFC9701]- signed response where end-to-end integrity is required. * *Mission Lifecycle*: serve the management endpoint (Section 5), gate the suspended and completed states it introduces exactly as the issuance profile gates on non-active state, and advertise mission_lifecycle_endpoint and mission_lifecycle_endpoint_auth_methods_supported. * *Revocation propagation*: advertise mission_max_stale_seconds and size Mission-bound access-token TTLs to it (Section 6). A companion profile MAY register a further extension operation on the Mission Lifecycle endpoint and carry its own conformance requirements; the Entry Discharge companion's terminal_when and discharge capability is conformant to its own document, not to this one ([I-D.draft-mcguinness-oauth-mission-discharge]). An implementation meets the following requirement independent of which extensions above it claims, and independent of which companion profiles it adopts. Every issuer-held narrowing mechanism a deployment runs, an adopted companion's discharge mechanism or another companion profile's own overlay alike, MUST feed the single Effective Authority Set computation. Every derivation and every authority-reporting surface MUST use that same computation; no mechanism computes a parallel view, and no surface reports authority the computation has not reduced. 10. Security Considerations The security considerations of the issuance profile [I-D.draft-mcguinness-oauth-mission] apply in full. This section covers threats specific to the extensions defined here. 10.1. Mission Status Enumeration Per the anti-oracle property (Section 3.6), the AS MUST NOT let a caller readily distinguish an unknown mission_id from a known-but- unauthorized one at the Status or Lifecycle endpoint. The error shape of Section 3.7 requires identical body content, identical HTTP status, and identical headers between the two cases, and the AS SHOULD additionally suppress timing side channels (for example by padding response time or by taking a uniform lookup path). An implementation that leaks the distinction exposes the Mission space to enumeration. 10.2. Mission Status Response Replay A Mission Status Response is bound to (caller sub, audience, nonce, issuance time). Replay against a different caller or audience, or beyond mission.fresh_until, is detectable by signature verification and by verifying the bindings; a consumer MUST verify all the checks of Section 3.4 before honoring a response. A response cached and replayed by the same caller within mission.fresh_until is equivalent to a fresh response; a consumer MUST NOT use a cached response after mission.fresh_until, with the skew tolerance of Section 3.5. 10.3. Mission Status Denial of Service The Mission Status operation is on the consumption path of every Mission-bound credential validation in deployments where consumers query Mission Status per request. The AS MUST implement per-consumer rate limiting (returning rate_limited, Section 3.7) and SHOULD encourage consumer-side caching (Section 3.5) to reduce traffic. 10.4. RFC 9701 vs. New Media Type When the introspection projection is signed (Section 4), it uses [RFC9701], which is scoped to token introspection. The dedicated Mission Status operation uses a new media type (application/mission- status-response+jwt, Section 12) and a JWS [RFC7515], because [RFC9701] does not apply to a lookup keyed by mission_id. Implementations MUST NOT use [RFC9701] for the dedicated Mission Status operation, and MUST NOT accept an unsigned response from the dedicated Mission Status operation in place of the signed form it requires. 10.5. Signing-Key Retention for Audit The AS signs Mission Status and Lifecycle responses with a key from its jwks_uri. The AS MUST keep the public JWK for every kid it has signed such a response under resolvable in its jwks_uri for at least the Mission record retention period, so an archived application/ mission-status-response+jwt remains verifiable for audit and dispute. This is the issuance profile's retired-key rule ([I-D.draft-mcguinness-oauth-mission]), with the record retention period as the bound. A key known or suspected compromised is the exception: the AS removes it, and the Mandate profile's compromise- time rule governs how artifacts signed under it are then classified. 10.6. General OAuth Security This document inherits OAuth 2.0 Best Current Practice [RFC9700] for the OAuth surfaces it composes with; implementers MUST follow current OAuth security guidance. 11. Privacy Considerations The privacy considerations of the issuance profile [I-D.draft-mcguinness-oauth-mission] apply in full. This section covers privacy specific to the extensions here. 11.1. Status and Lifecycle as Disclosure Surfaces The Mission Status operation (Section 3) and the introspection projection (Section 4) disclose Mission state and the audience-scoped authorization_details to the authenticated, authorized requester, and MAY additionally disclose authority_hash to a requester authorized for it. A deployment MUST treat both as Mission information- disclosure surfaces with the same privacy posture, audience-filtering the disclosed authority so a consumer never sees entries addressed to audiences it is not authorized to request (Section 3.1, Section 3.4). 11.2. Status Audit Logging The AS records Status and Lifecycle requests (containing mission_id, audience, caller, and timing) in audit logs. Deployments MUST treat these logs as PII sinks per the issuance profile's privacy considerations. 12. IANA Considerations This document requests IANA actions for OAuth AS metadata members and a media type. It defines no new registry of its own: the endpoint authentication-method value space is a closed set defined inline (Section 8). mission_suspended and mission_completed (Section 5) are values of the issuance profile's mission_error member, which has no IANA registry, so this document requests no registration for them. A companion profile MAY register further extension members or Common Constraints against a family registry; the Entry Discharge companion registers terminal_when in the Mission Resource Access Profile's Mission Common Constraints registry this way ([I-D.draft-mcguinness-oauth-mission-discharge]). 12.1. OAuth Authorization Server Metadata Registration IANA is requested to register the following in the "OAuth Authorization Server Metadata" registry [RFC8414]. For each: Change Controller IETF; Reference this document, Section 8. * mission_status_endpoint * mission_status_endpoint_auth_methods_supported * mission_status_endpoint_auth_signing_alg_values_supported * mission_status_signing_alg_values_supported * mission_lifecycle_endpoint * mission_lifecycle_endpoint_auth_methods_supported * mission_lifecycle_endpoint_auth_signing_alg_values_supported * mission_max_stale_seconds 12.2. Media Type Registration IANA is requested to register one media type per [RFC6838]. 12.2.1. application/mission-status-response+jwt * Type name: application * Subtype name: mission-status-response+jwt * Required parameters: none * Optional parameters: none * Encoding considerations: binary; JWS Compact Serialization * Security considerations: see Section 10 * Interoperability considerations: see this document * Published specification: this document * Applications that use this media type: OAuth Mission-Bound consumers * Fragment identifier considerations: not applicable * Restrictions on usage: none * Provisional registration: no * Magic number(s): none * File extension(s): none * Macintosh file type code(s): none * Person & email address to contact: Karl McGuinness public@karlmcguinness.com (mailto:public@karlmcguinness.com) * Intended usage: COMMON * Author/Change controller: IETF 12.3. Mission Lifecycle States Registrations This document requests registration of two states in the issuance profile's Mission Lifecycle States registry ([I-D.draft-mcguinness-oauth-mission]), under that registry's Specification Required policy: +===========+==========+==================+============+===========+ | Value | Terminal | Semantics | Change | Reference | | | | | Controller | | +===========+==========+==================+============+===========+ | suspended | no | A paused Mission | IETF | this | | | | that derives no | | document, | | | | tokens until | | Section 5 | | | | resumed. | | | +-----------+----------+------------------+------------+-----------+ | completed | yes | Records | IETF | this | | | | successful | | document, | | | | completion of | | Section 5 | | | | the Mission. | | | +-----------+----------+------------------+------------+-----------+ Table 5 12.4. Well-Known URI This document registers no new Well-Known URI. The metadata members of Section 8 are added to the OAuth Authorization Server Metadata document at /.well-known/oauth-authorization-server [RFC8414]. Acknowledgments The author thanks the implementers and reviewers of the Mission-Bound Authorization work for feedback that shaped these extensions. References Normative References [I-D.draft-mcguinness-oauth-mission] McGuinness, K., "Mission-Bound Authorization for OAuth 2.0", 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, August 2013, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May 2015, . [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, . [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, . [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, . [RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October 2021, . [RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November 2022, . [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, . [RFC9701] Lodderstedt, T., Ed. and V. Dzhuvinov, "JSON Web Token (JWT) Response for OAuth Token Introspection", RFC 9701, DOI 10.17487/RFC9701, January 2025, . [RFC9728] Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0 Protected Resource Metadata", RFC 9728, DOI 10.17487/RFC9728, April 2025, . Informative References [I-D.draft-mcguinness-mission-aauth] McGuinness, K., "Mission Context Binding for AAuth", 2026, . [I-D.draft-mcguinness-mission-authority-server] McGuinness, K., "Mission Authority Server", 2026, . [I-D.draft-mcguinness-mission-authzen] McGuinness, K., "Mission-Bound Runtime Enforcement: AuthZEN Profile", 2026, . [I-D.draft-mcguinness-mission-mandate] McGuinness, K., "Mission Mandate", 2026, . [I-D.draft-mcguinness-mission-runtime] McGuinness, K., "Mission-Bound Runtime Enforcement", 2026, . [I-D.draft-mcguinness-mission-runtime-evidence] McGuinness, K., "Mission Runtime Evidence", 2026, . [I-D.draft-mcguinness-oauth-mission-child-delegation] McGuinness, K., "Mission Child Delegation for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-containment] McGuinness, K., "Mission Containment for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-cross-domain] McGuinness, K., "Mission Cross-Domain Projection for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-discharge] McGuinness, K., "Mission Entry Discharge for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-expansion] McGuinness, K., "Mission Expansion for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-issuance-grant] McGuinness, K., "Mission Issuance Grant for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-management] McGuinness, K., "Mission Management for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-resource-access] McGuinness, K., "Mission Resource Access Profile for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-signals] McGuinness, K., "Mission Lifecycle Signals for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-status-list] McGuinness, K., "Mission Status List for OAuth 2.0", 2026, . [RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, February 2020, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [RFC9457] Nottingham, M., Wilde, E., and S. Dalal, "Problem Details for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023, . [RFC9700] Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, "Best Current Practice for OAuth 2.0 Security", BCP 240, RFC 9700, DOI 10.17487/RFC9700, January 2025, . Appendix A. Document History [[ To be removed from the final specification ]] * A suspend whose on_expiry is resume needs the authorization the deployment requires for a direct resume as well as for suspend, including when it replaces the schedule of a Mission already suspended, and the AS records each schedule's committing party. Omitting both schedule members preserves the recorded schedule. A schedule applies only while current, never to a later suspension, and expiry governs a suspend_until at or after expires_at (#1002). * Authentication failures at the Status and Lifecycle endpoints: a failed access token gets a 401 WWW-Authenticate challenge in its scheme (Bearer or DPoP); a request with no credential gets a challenge for each accepted access-token scheme, always with resource_metadata; failed mTLS or private-key-JWT client authentication, or no credential where no access-token scheme is accepted, gets 400 invalid_client (#972 item 18). * A derivation refused because the Mission is suspended or completed carries the mission_error value mission_suspended or mission_completed, so a client can tell a refusal that a resume lifts from a terminal one. * A caller may request the projection for an audience other than its own, such as each resource a Mission Issuance Grant consuming Authorization Server serves, only where the Mission Issuer's configuration authorizes it; the consumer checks aud against the audience its request named (#963). * The mutual-TLS method value is tls_client_auth, the registered [RFC8705] spelling, and an absent endpoint auth-methods member is never read from token-endpoint metadata. The Mission Authority Server publishes the same per-endpoint members. * A refresh against a suspended Mission is checked, and refused, before its refresh token is consumed, so a resume restores refresh with the same token; issuance-time validation still governs a concurrent suspension (#914). * Added conditional carryover correlation on an old child's cascaded observation; no state or authority is inferred from the pointer (#576). * Operational Considerations added (#310): recovery sizing for the advertised propagation ceiling, the per-surface distribution posture, and the operator observations after a degraded surface recovers. No freshness window is extended and no member is added. Author's Address Karl McGuinness Independent Email: public@karlmcguinness.com