Mission Status and Lifecycle for OAuth 2.0

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 core's external-surface convention ([I-D.draft-mcguinness-oauth-mission]).¶

audience:

CONDITIONAL. A string. The audience identifier of the requesting consumer. An authorized non-RS consumer (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.¶

3.2. Authentication

The request MUST be authenticated. The AS MUST support at least one of the following; the client MUST use exactly one 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_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 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 Mission Status operation therefore uses a new media type and a JWS, not [RFC9701] (see Section 8.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",
    "expires_at":  "2026-12-31T23:59:59Z",
    "fresh_until": "2026-11-02T08:15:00Z"
  },
  "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: 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. The authoritative state space is the issuance profile's ([I-D.draft-mcguinness-oauth-mission], Section "Mission Lifecycle and Gating"): the core 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 (superseded for an expanded predecessor ([I-D.draft-mcguinness-oauth-mission-expansion]); cascaded for a cascade-terminated Child Mission ([I-D.draft-mcguinness-oauth-mission-child-delegation])). A consumer applies the issuance profile's forward-compatibility rule: only active permits reliance, and every other value, recognized or not, is non-active.¶

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

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

• 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. 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 signature against a current jwks_uri entry for the issuer 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), or on (mission_id, requester identifier) for a state-only response, until mission.fresh_until. Consumers MUST NOT use a cached response after mission.fresh_until. 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. This 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; it MUST NOT exceed the AS's advertised mission_max_stale_seconds (Section 7). A suspended Mission may be resumed to active, so a consumer MUST NOT extend reliance on a cached suspended (or any non-active) response beyond mission.fresh_until.¶

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, and 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):¶

terminated is not a mission.state value; it names any terminal non-active state, including companion-defined terminal states, and is not a closed list. 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]). A consumer applies 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):¶

Success outcomes return HTTP 200 with the signed Mission Status Response carrying state. Wire 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.¶

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 core's external-surface convention ([I-D.draft-mcguinness-oauth-mission]).¶

operation:

REQUIRED. A string. One of revoke, suspend, resume, complete.¶

reason:

OPTIONAL. A string. A human-readable reason recorded in audit, maximum 1024 characters.¶

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

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

A suspend MAY carry suspend_until with a REQUIRED on_expiry. When suspend_until 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.¶

5.2. Legal Transitions

An operation is legal only from the source states below. The terminal states (revoked, expired, completed, and the companion-defined terminal states superseded and cascaded) accept no operation.¶

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

A request for an operation against a state it is not legal from MUST be refused as a conflict (Section 5.7); the AS MUST NOT treat it as a no-op. Re-requesting an operation that has already reached its resulting state (for example, revoke on an already-revoked Mission) is idempotent and succeeds without a state change. A Mission that reaches its expires_at transitions to expired independently of this endpoint, from active or suspended.¶

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 operations of Section 5.2. Only active permits derivation; every other state is non-deriving.¶

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. The superseded and cascaded rows are companion-defined: 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, DPoP-bound bearer, or private-key JWT, discovered through the AS's existing OAuth client-authentication metadata [RFC8414].¶

5.5. Authorization

The AS authorizes lifecycle operations against deployment policy. This document sets the minimum authorization semantics per authenticating mechanism (Section 3.2) and leaves finer policy deployment-defined. When a sender-constrained access token (DPoP-bound [RFC9449] or mTLS-bound [RFC8705]) authenticates the call, the token's sub is the acting party, and the token MUST carry a lifecycle authorization: a mission_lifecycle scope or an equivalent deployment-defined grant. The AS MUST record the acting party and SHOULD reflect it in the signed response's audit surface (for example in 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.¶

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 sub is the acting party, the authenticated requesting client; the AS records the 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",
    "expires_at":  "2026-12-31T23:59:59Z",
    "fresh_until": "2026-11-02T09:11:40Z"
  }
}

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

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
&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",
    "suspend_until": "2026-11-09T08:15:00Z",
    "on_expiry": "revoke",
    "expires_at":  "2026-12-31T23:59:59Z",
    "fresh_until": "2026-11-02T08:35:00Z"
  }
}

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. The AS MUST deduplicate lifecycle requests by the pair (mission, nonce) for a bounded window and, on a retransmit carrying a nonce already seen for that mission, MUST replay the original response rather than re-execute the operation. 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.¶

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. This applies only when the operation is legal from the current state and has already reached its resulting state (Section 5.2).¶

An operation that is not legal from the current state (for example, resume on a Mission that was never suspended, or any operation on a terminal state) is a conflict, not an idempotent no-op. The AS MUST refuse it with HTTP 409 and a JSON body whose error symbol is conflict, leaving the Mission state unchanged.¶

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

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 or retiring a single Authority Set entry, is not defined here.¶

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.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_signing_alg_values_supported": ["ES256"],
  "mission_lifecycle_endpoint":
    "https://as.example.com/as/mission/lifecycle",
  "mission_max_stale_seconds": 60
}

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

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

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

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

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

• mission_lifecycle_endpoint¶

• mission_max_stale_seconds¶

11.2. Media Type Registration

IANA is requested to register one media type per [RFC6838].¶

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

Normative References

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

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

[RFC2119]

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

[RFC3339]

Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/rfc/rfc3339>.

[RFC6838]

Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/rfc/rfc6838>.

[RFC7009]

Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, August 2013, <https://www.rfc-editor.org/rfc/rfc7009>.

[RFC7515]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/rfc/rfc7515>.

[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, <https://www.rfc-editor.org/rfc/rfc7523>.

[RFC7662]

Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, <https://www.rfc-editor.org/rfc/rfc7662>.

[RFC8174]

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

[RFC8259]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/rfc/rfc8259>.

[RFC8414]

Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, <https://www.rfc-editor.org/rfc/rfc8414>.

[RFC8705]

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

[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, <https://www.rfc-editor.org/rfc/rfc9325>.

[RFC9449]

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

[RFC9701]

Lodderstedt, T., Ed. and V. Dzhuvinov, "JSON Web Token (JWT) Response for OAuth Token Introspection", RFC 9701, DOI 10.17487/RFC9701, January 2025, <https://www.rfc-editor.org/rfc/rfc9701>.

Informative References

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

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

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

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

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

McGuinness, K., "Mission Cross-Domain Projection for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-cross-domain.html>.

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

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

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

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

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

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

[RFC9110]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.

[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, <https://www.rfc-editor.org/rfc/rfc9700>.