Network Working Group K. McGuinness Internet-Draft Independent Intended status: Standards Track 23 June 2026 Expires: 25 December 2026 Mission Status and Lifecycle for OAuth 2.0 draft-mcguinness-oauth-mission-status-latest Abstract The Mission-Bound Authorization for OAuth 2.0 profile [I-D.draft-mcguinness-oauth-mission] (the "issuance 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: a canonical Mission Status operation (keyed by mission_id), a management endpoint for explicit lifecycle transitions (revoke, suspend, resume, complete), revocation-propagation guidance, and signed status evidence. Each capability is independently optional; an implementation MAY adopt any subset, and one that adopts none remains a conforming issuance profile. This document does not restate the base 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/draft-mcguinness-oauth-mission/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/draft-mcguinness-oauth-mission. 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 25 December 2026. 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.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. Authentication 5.3. Authorization 5.4. Worked Example 5.5. Idempotency 5.6. Relationship to RFC 7009 6. Revocation Propagation 6.1. Recommended Access-Token TTL 7. Authorization Server Metadata 7.1. Worked Metadata Example 8. Security Considerations 8.1. Mission Status Enumeration 8.2. Mission Status Response Replay 8.3. Mission Status Denial of Service 8.4. RFC 9701 vs. New Media Type 8.5. Signing-Key Retention for Audit 8.6. General OAuth Security 9. Privacy Considerations 9.1. Status and Lifecycle as Disclosure Surfaces 9.2. Status Audit Logging 10. Conformance 11. IANA Considerations 11.1. OAuth Authorization Server Metadata Registration 11.2. Media Type Registration 11.2.1. application/mission-status-response+jwt 11.3. Well-Known URI Acknowledgments References Normative References Informative References 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 explicitly leaves the canonical Mission Status surface (keyed by mission_id), a standardized management endpoint for lifecycle transitions, signed status evidence, and revocation- propagation guidance to future work. This document specifies those deferred 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 transitions, distinct from [RFC7009] token revocation. * *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 7) advertising the endpoints above. Each capability is independently optional. An implementation states which it supports through the metadata of Section 7 and the conformance language of Section 10. An implementation that supports none of them is unaffected and remains a conforming issuance profile. This document does not restate the base profile. The Mission Intent, authority derivation, the mission_resource_access authorization details type, 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] and 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 (Authorization Server, the Mission origin), Resource AS, Authority Set, the mission claim, mission_id, and the mission_resource_access authorization details type. 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. 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 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 AS issued. The Mission Issuer publishes its Mission Status endpoint URL in Authorization Server metadata (Section 7) as mission_status_endpoint, which a consumer resolves from a credential's mission.origin. 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: REQUIRED. A string. The canonical mission_id. audience: REQUIRED. A string. The audience identifier of the requesting consumer. 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. 3.2. Authentication The request MUST be authenticated. The AS MUST support, and the client MUST use, exactly one of the following 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. *DPoP-bound bearer token* [RFC9449]. The client presents a Mission-Status-scoped DPoP-bound token in the Authorization header with a DPoP proof header; the token's cnf.jkt MUST match the proof key thumbprint. 3. *Private-key-JWT client authentication* [RFC7523]. The client presents a signed JWT assertion as client_assertion. 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 unauthorized (HTTP 401). Which mechanisms the AS accepts is discovered through the AS's existing OAuth client- authentication metadata [RFC8414]. 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=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 11) is used as the HTTP Content- Type. [RFC9701] signed introspection responses are scoped to token introspection and do not apply to a lookup keyed by mission_id; the dedicated operation therefore uses a new media type and a JWS, not [RFC9701] (see Section 8.4). Implementations MUST NOT use [RFC9701] for the dedicated 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": 1797840000, "exp": 1797840060, "mission": { "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-", "origin": "https://as.example.com", "authority_hash": "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ", "state": "active", "expires_at": "2026-11-02T08:15:00Z", "mission_expiry": "2026-12-31T23:59:59Z" }, "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. exp bounds the validity of the signed response itself; how long the consumer MAY rely on the reported state is given separately by mission.expires_at 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, origin: the subject Mission's identifier and origin. - authority_hash: the issuance profile's consent commitment over the Authority Set ([I-D.draft-mcguinness-oauth-mission], Section "Integrity Anchors"). - state: the current Mission lifecycle state. With this extension the state space is active, revoked, expired ([I-D.draft-mcguinness-oauth-mission], Section "Mission Lifecycle and Gating"), extended with suspended and completed when the Mission Lifecycle endpoint (Section 5) is deployed. - expires_at: an [RFC8259] string 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). - mission_expiry: the point at which the Mission itself expires ([I-D.draft-mcguinness-oauth-mission]). * authorization_details: the audience-scoped Authority Set entries relevant to the requesting audience, as the mission_resource_access shape of [I-D.draft-mcguinness-oauth-mission] (Section "Mission Authority"), 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. A consumer MUST verify, before honoring a response: 1. the JWS signature against a current jwks_uri entry for the origin AS; 2. iss equals the expected AS issuer URL; 3. aud equals the consumer's own audience identifier; 4. sub equals the requesting client's identifier; 5. nonce equals the request's nonce; and 6. iat is not in the future and exp is not in the past, with up to 30 seconds clock-skew tolerance. 3.5. Caching Consumers SHOULD cache a response keyed on (mission_id, audience) until mission.expires_at. Consumers MUST NOT use a cached response after mission.expires_at, with up to 30 seconds skew tolerance for the active state only and no tolerance for terminal states. 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 NOT vary response timing, payload size, or headers in a way that distinguishes the two cases. 3.7. Error Responses Mission Status responses use the following symbols, mapped to HTTP status codes. ok, terminated, and suspended are successful outcomes returned with a signed Mission Status Response; the remaining symbols are hard errors. The body of a hard error is a JSON object [RFC8259]. +==============+======+=============================================+ | Symbol | HTTP | Description | +==============+======+=============================================+ | ok | 200 | Mission found and visible. | +--------------+------+---------------------------------------------+ | unauthorized | 401 | Request not authenticated. | +--------------+------+---------------------------------------------+ | not_found | 404 | Reference does not exist | | | | OR is not visible. | +--------------+------+---------------------------------------------+ | terminated | 200 | Mission is revoked, | | | | completed, or expired. | +--------------+------+---------------------------------------------+ | suspended | 200 | Mission is suspended. | +--------------+------+---------------------------------------------+ | rate_limited | 429 | Consumer is rate-limited. | +--------------+------+---------------------------------------------+ | unavailable | 503 | AS temporarily cannot | | | | serve status. | +--------------+------+---------------------------------------------+ Table 1 Terminal and suspended states return HTTP 200 with the signed Mission Status Response carrying state. Hard errors (unauthorized, not_found, rate_limited, unavailable) return the matching HTTP status with a JSON body. Note the distinction between the two access failures: unauthorized (401) means the request carried no valid authentication, whereas a request that is authenticated but not authorized for the referenced Mission returns not_found (404), never 401, 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, error_description, and nonce, and 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. 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, origin, authority_hash, and (from the Mission origin) the lifecycle state, together with the caller-authorization, minimization, and origin-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 origin 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 standard introspection_signing_alg_values_supported metadata [RFC8414]. * When the responding AS is the Mission origin, the projection MAY additionally carry expires_at, an [RFC8259] string 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 expires_at is absent (for example a non-origin 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, expires_at, and, on the dedicated response, mission_expiry) 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": 1797840000, "exp": 1797840060, "active": true, "client_id": "s6BhdRkqt3", "sub": "user_3p2q8mN1a0kV7tR", "scope": "openid", "mission": { "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-", "origin": "https://as.example.com", "authority_hash": "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ", "state": "active", "expires_at": "2026-11-02T08:15:00Z" } } 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 7) 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 base profile gates on active. 5.1. Operations The endpoint accepts authenticated POST requests with a form- urlencoded body: mission: REQUIRED. A string. The canonical mission_id. operation: REQUIRED. A string. One of revoke, suspend, resume, complete. reason: OPTIONAL. A string. A human-readable reason recorded in audit, maximum 1024 characters. nonce: REQUIRED. A string. A client-generated nonce. The 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. 5.2. Authentication The lifecycle endpoint uses the same authentication mechanisms as the Mission Status endpoint (Section 3.2): mTLS, DPoP-bound bearer, or private-key JWT, discovered through the AS's existing OAuth client- authentication metadata [RFC8414]. 5.3. Authorization The AS authorizes lifecycle operations against deployment policy; this document does not standardize the policy. 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. 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.4. Worked Example 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=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 AS sets aud to the authenticated requester and MAY omit authorization_details (a lifecycle confirmation reports state, not audience-scoped authority); sub is the authenticated requesting client, as for any Mission Status Response, while the human actor behind the operation is recorded only in the 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": "https://erp.example.com", "sub": "client_erp-recon-agent", "nonce": "nonce_8Y3vN0sM6tP1xR9bQ5", "iat": 1797843200, "exp": 1797843260, "mission": { "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-", "origin": "https://as.example.com", "authority_hash": "sha-256:l3KvZ4mP5x0wQrR6tY2nD9bM7sX1cF8gH2vJ4kE5pNQ", "state": "revoked", "expires_at": "2026-11-02T09:11:40Z", "mission_expiry": "2026-12-31T23:59:59Z" } } The AS records the operation, actor, time, and any reason in its audit log; the response confirms the outcome through the updated state. 5.5. Idempotency Lifecycle operations MUST be idempotent on the pair (mission, operation). A repeated request that does not change state returns success without side effect, returning the current Mission Status Response. 5.6. 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 invoke [RFC7009] token revocation for specific outstanding tokens when it knows their jti. [RFC7009] alone does NOT revoke a Mission; the lifecycle endpoint is the authoritative Mission state change. 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 7), 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. 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. 7. 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_lifecycle_endpoint: OPTIONAL. A string containing a URL. The URL of the Mission Lifecycle endpoint (Section 5). Present when the AS supports it. mission_max_stale_seconds: OPTIONAL. An integer. The maximum tolerated interval, in seconds, for revocation propagation (Section 6). 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. 7.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_lifecycle_endpoint": "https://as.example.com/as/mission/lifecycle", "mission_max_stale_seconds": 60 } 8. 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. 8.1. Mission Status Enumeration Per the anti-oracle property (Section 3.6), the AS MUST NOT let a caller distinguish an unknown mission_id from a known-but- unauthorized one at the Status or Lifecycle endpoint. The error shape of Section 3.7 mitigates this by requiring identical body content, identical HTTP status, and timing- and size-invariance between the two cases. An implementation that leaks the distinction exposes the Mission space to enumeration. 8.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.expires_at, is detectable by signature verification and by verifying the bindings; a consumer MUST verify all six checks of Section 3.4 before honoring a response. A response cached and replayed by the same caller within mission.expires_at is equivalent to a fresh response; a consumer MUST NOT use a cached response after mission.expires_at, with the skew tolerance of Section 3.5. 8.3. Mission Status Denial of Service The Status endpoint 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. 8.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 11) and a JWS [RFC7515], because [RFC9701] does not apply to a lookup keyed by mission_id. Implementations MUST NOT use [RFC9701] for the dedicated operation, and MUST NOT accept an unsigned response from the dedicated Mission Status operation in place of the signed form it requires. 8.5. Signing-Key Retention for Audit The AS signs Mission Status and Lifecycle responses with a key from its jwks_uri. The AS MUST retain the public JWK for every kid it has signed such a response under, indexed by kid, for at least the Mission record retention period (even after the key is rotated out of the live jwks_uri), so an archived application/mission-status- response+jwt remains verifiable for audit and dispute. The AS MAY expose retired verification keys through a deployment-defined audit interface but MUST NOT serve them as active keys at jwks_uri. 8.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. 9. 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. 9.1. Status and Lifecycle as Disclosure Surfaces The Mission Status operation (Section 3) and the introspection projection (Section 4) disclose Mission state, the authority_hash, and the audience-scoped authorization_details to the authenticated, authorized requester. 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 other audiences (Section 3.4). 9.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. 10. Conformance An implementation conforms to the issuance profile [I-D.draft-mcguinness-oauth-mission] first. 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 of Section 3.2, the anti-oracle property (Section 3.6), and the error shape of Section 3.7; and advertise mission_status_endpoint. * *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 base profile gates on non-active state, and advertise mission_lifecycle_endpoint. * *Revocation propagation*: advertise mission_max_stale_seconds and size Mission-bound access-token TTLs to it (Section 6). 11. IANA Considerations This document requests IANA actions for OAuth AS metadata members and a media type. It defines no new registry: the authentication-method value space is a closed set defined inline. 11.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 7. * mission_status_endpoint * mission_lifecycle_endpoint * mission_max_stale_seconds 11.2. Media Type Registration IANA is requested to register one media type per [RFC6838]. 11.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 8 * 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 11.3. Well-Known URI This document registers no new Well-Known URI. The metadata members of Section 7 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", Work in Progress, Internet-Draft, draft-mcguinness- oauth-mission, 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . [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, . [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, . Informative References [I-D.draft-mcguinness-oauth-mission-signals] McGuinness, K., "Mission Lifecycle Signals for OAuth 2.0", Work in Progress, Internet-Draft, draft-mcguinness-oauth- mission-signals, 2026, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [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, . Author's Address Karl McGuinness Independent Email: public@karlmcguinness.com