Mission Management for OAuth 2.0

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 8 January 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

The Mission Status and Lifecycle profile [I-D.draft-mcguinness-oauth-mission-status] (the "status profile") answers "what is the state of this Mission" and changes that state, one Mission per request. Its Deferred Lifecycle Capabilities section defers two fleet-scale capabilities: Mission enumeration ("which Missions exist for this Subject, client, or state") and bulk lifecycle operations over the enumerated set. This document specifies both.¶

The two surfaces are deliberate counterparts. The status profile is consumption-plane: its callers are authorized for individual Missions, so it makes an unknown reference indistinguishable from an unauthorized one. This document is management-plane: its callers are operator consoles and incident-response tooling in the Mission Issuer's own trust domain, explicitly authorized for existence knowledge over a declared filter scope, compensated not by indistinguishability but by explicit authorization and mandatory audit of every call (Section 3.2). The surface is never agent-facing: the Agent executing a Mission has no role here (Section 3.1).¶

Both capabilities share one endpoint, one request shape, one authentication and authorization model, one signing discipline, and one audit rule; a request's operation member selects between them. Bulk operations apply the status profile's per-Mission lifecycle semantics unchanged, so this document adds no state, no transition, and no event type to the lifecycle state space. It is OPTIONAL and does not restate the issuance profile [I-D.draft-mcguinness-oauth-mission] or the status profile; a deployment that does not adopt it is unaffected.¶

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] and the status profile [I-D.draft-mcguinness-oauth-mission-status], 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 this surface with the same semantics), mission_id, the Mission record, and the Mission lifecycle states and operations. It additionally uses:¶

Management Client:

An authenticated client authorized for the Mission Management endpoint: an operator console, incident-response tooling, or administrative automation acting in the Mission Issuer's trust domain. An Agent executing a Mission is never a Management Client.¶

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 values are wrapped for display. JWT examples are shown as decoded JSON; on the wire the JWS Compact Serialization [RFC7515] applies.¶

3. Mission Management Endpoint

The Mission Issuer publishes its Mission Management endpoint URL in Authorization Server metadata (Section 10) as mission_management_endpoint. The endpoint MUST be served over TLS 1.2 or later (TLS 1.3 RECOMMENDED), following the recommendations of [RFC9325].¶

A request is an HTTPS POST whose body is a JSON object [RFC8259] sent as application/json; the structured filter does not fit the form encoding of the status profile's single-Mission operations. Every request carries:¶

operation:

REQUIRED. A string. enumerate (Section 5) or one of the status profile's lifecycle operations revoke, suspend, resume, complete, applied in bulk (Section 6).¶

filter:

REQUIRED. An object (Section 4) selecting the Missions the operation addresses.¶

nonce:

REQUIRED. A string. A client-generated nonce, unique per request within the response lifetime, echoed in the signed response. It is also the idempotency key: the AS MUST deduplicate management requests by (client, nonce) for a bounded window and, on a retransmit, MUST replay the original response rather than re-execute the request.¶

A success response is a JWS Compact Serialization [RFC7515] signed with a key published in the Mission Issuer's jwks_uri, following the status profile's signing discipline: the JWS header carries a kid and a typ of mission-management-response+jwt, the algorithm is one advertised in mission_status_signing_alg_values_supported (Section 10), and the status profile's signing-key retention rules apply. The HTTP Content-Type is application/jwt [RFC7519] with Cache-Control: no-store; the typ value is a local-use identifier defined by this document (Section 14). The signed payload carries the envelope iss, aud (the authenticated caller), sub (the acting party), nonce, iat, and exp, plus the members of Section 5.1, Section 6.1, or Section 6.3. Before honoring a response a Management Client MUST apply the status profile's response verification checks (signature, iss, aud, sub, nonce, iat/exp with up to 30 seconds skew) and MUST verify the typ.¶

Rate limits, the enumeration page maximum, and the bulk size bound are deployment-declared operational configuration; this document defines the error symbols that surface them (Section 7) but no metadata for them.¶

4. Mission Filter

The filter object selects Missions by conjunction: a Mission matches when it satisfies every member present. An empty filter matches every Mission in the caller's filter scope. The members, each OPTIONAL, match against the Mission record ([I-D.draft-mcguinness-oauth-mission], Section "Mission Record"):¶

subject:

An object with iss and sub. Matches the record's subject exactly.¶

client_id:

A string. Matches the record's client_id.¶

state:

An array of strings. Matches a Mission whose current lifecycle state equals any listed value, drawn from the issuance profile's open state space as extended by the profiles the deployment runs. The AS MUST NOT refuse a filter for carrying a state value it does not produce; such a value matches no Mission.¶

created_after, created_before:

RFC 3339 [RFC3339] date-times. Match a Mission whose created_at is strictly after, respectively strictly before, the value.¶

expiring_before:

An RFC 3339 [RFC3339] date-time. Matches a Mission whose expires_at is strictly before the value.¶

parent:

A string, a Mission Identifier. Matches the Child Missions whose parent lineage member names it ([I-D.draft-mcguinness-oauth-mission-child-delegation]): direct children only. A caller walks a delegation tree level by level.¶

The AS MUST refuse a filter carrying an unrecognized member with invalid_request, so a filter is never silently broader than the caller intended.¶

5. Mission Enumeration

The enumerate operation answers "which Missions exist" for the caller's filter, returning signed pages of Mission summaries. In addition to the common members (Section 3), the request carries:¶

purpose:

REQUIRED. A string, maximum 1024 characters. The operator's reason for the query (for example a ticket or case identifier), recorded in audit (Section 3.2).¶

cursor:

OPTIONAL. A string. An opaque pagination cursor from a prior response.¶

limit:

OPTIONAL. A positive integer. The AS returns at most the smaller of limit and its deployment-declared page maximum, and applies the maximum when limit is absent.¶

POST /as/mission/manage HTTP/1.1
Host: as.example.com
Content-Type: application/json
Authorization: DPoP eyJhbGciOiJFUzI1NiIsImtpZCI6...
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2Iiwi...

{
  "operation": "enumerate",
  "filter": {
    "subject": { "iss": "https://idp.example.com",
                 "sub": "user_3p2q8mN1a0kV7tR" },
    "state": ["active"]
  },
  "purpose": "IR-4192: credential compromise triage",
  "limit": 50,
  "nonce": "nonce_M4kR8vT2nQ7xB5sW"
}

{
  "iss": "https://as.example.com",
  "aud": "client_secops-console",
  "sub": "client_secops-console",
  "nonce": "nonce_M4kR8vT2nQ7xB5sW",
  "iat": 1793611740,
  "exp": 1793611800,
  "missions": [
    { "id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
      "state": "active",
      "subject": { "iss": "https://idp.example.com",
                   "sub": "user_3p2q8mN1a0kV7tR" },
      "client_id": "s6BhdRkqt3",
      "created_at": "2026-10-15T14:32:11Z",
      "expires_at": "2026-12-31T23:59:59Z" }
  ]
}

6. Bulk Mission Lifecycle

A bulk request applies one lifecycle operation of the status profile (revoke, suspend, resume, complete) to every Mission a filter matches, in two steps: a REQUIRED dry run returning the match count and a bulk token pinning the evaluated membership, then an execute presenting that token. In addition to the common members (Section 3), the request carries:¶

mode:

REQUIRED. A string, dry_run or execute.¶

bulk_token:

CONDITIONAL. A string. REQUIRED when mode is execute; MUST NOT be sent otherwise.¶

reason:

REQUIRED. A string, maximum 1024 characters. Recorded in audit (Section 3.2) and applied as each per-Mission transition's reason under the status profile, so it surfaces in per-Mission audit and, where signals run, in each emitted event ([I-D.draft-mcguinness-oauth-mission-signals]).¶

suspend_until, on_expiry:

OPTIONAL and CONDITIONAL respectively, valid only when operation is suspend, with the status profile's semantics, applied uniformly to every Mission in the set.¶

The AS MAY declare a bound on the evaluated set size and refuse a dry run whose match count exceeds it with filter_too_broad (Section 7); the caller narrows the filter (for example with created_after) and retries.¶

{
  "operation": "revoke",
  "filter": {
    "subject": { "iss": "https://idp.example.com",
                 "sub": "user_3p2q8mN1a0kV7tR" }
  },
  "mode": "dry_run",
  "reason": "IR-4192: subject credential compromise",
  "nonce": "nonce_P9sB3xV7mK1tR6qZ"
}

{
  "iss": "https://as.example.com",
  "aud": "client_secops-console",
  "sub": "client_secops-console",
  "nonce": "nonce_P9sB3xV7mK1tR6qZ",
  "iat": 1793611800,
  "exp": 1793611860,
  "operation": "revoke",
  "match_count": 3,
  "bulk_token": "blk_7Nq4xW2rT9mK5vB8sD1zA6pY3cE0hJfL",
  "bulk_token_expires_at": "2026-11-02T09:45:00Z"
}

{
  "iss": "https://as.example.com",
  "aud": "client_secops-console",
  "sub": "client_secops-console",
  "nonce": "nonce_W2tN6bQ9kX4mV8rS",
  "iat": 1793611980,
  "exp": 1793612040,
  "operation": "revoke",
  "results": [
    { "mission_id": "msn_8RfX2Lqv9TqMv4z7sA2bN1k0YpEdHc9-",
      "outcome": "applied" },
    { "mission_id": "msn_6VbT1yHn4RwQk9x3zE8sC5j2MpDfL0G-",
      "outcome": "already_terminal" },
    { "mission_id": "msn_0JpW3xEr8KtNb5v2qC7mD4h1YsAgF9L-",
      "outcome": "error",
      "detail": "state store timeout" }
  ]
}

7. Error Responses

A wire error returns the matching HTTP status with a JSON object [RFC8259] body carrying error, error_description, and nonce, as in the status profile. Per-Mission conditions during a bulk execute are manifest outcomes (Section 6.3), never wire errors. The codes:¶

For rate_limited, the response SHOULD include a Retry-After header [RFC9110] and a retry_after body member in seconds.¶

8. Incident Response Patterns

This section is non-normative. Common incident shapes compose the two operations directly:¶

• Compromised Subject. Filter subject, enumerate to triage, then bulk revoke (the worked examples above).¶

• Decommissioned client. Filter client_id, bulk revoke; every Mission the retired Agent submitted stops deriving.¶

• Key or approval-surface compromise. Filter created_after and created_before around the compromise window, bulk revoke; every Mission approved while the surface was suspect is terminated, regardless of Subject or client.¶

• Suspend-first triage. Bulk suspend with suspend_until and on_expiry of revoke, investigate, then selectively resume individual Missions through the status profile's lifecycle endpoint; anything not affirmatively cleared revokes itself at the deadline.¶

What bulk revocation does and does not stop is the security model's revocation-to-action latency table ([I-D.draft-mcguinness-mission-security-model]): each revocation stops new derivation at commit, while tokens already derived persist until the tightest propagation layer the deployment runs cuts them off. Bulk management changes how many Missions one request can stop, not how fast any one revocation propagates.¶

9. Deferred Management Capabilities

Approver transfer, re-anchoring a Mission's consent to a different accountable party, 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. Cross-issuer enumeration, one query spanning Missions held by multiple Mission Issuers, is not defined here; a Management Client queries each issuer it is authorized for separately.¶

10. Authorization Server Metadata

An AS that serves the Mission Management endpoint advertises it in its Authorization Server metadata [RFC8414]:¶

mission_management_endpoint:

OPTIONAL. A string containing a URL. The URL of the Mission Management endpoint (Section 3). Present when the AS serves it.¶

Because management responses reuse the status profile's signing discipline, an AS that publishes mission_management_endpoint MUST also publish mission_status_signing_alg_values_supported ([I-D.draft-mcguinness-oauth-mission-status]).¶

A standalone Mission Issuer (a Mission Authority Server [I-D.draft-mcguinness-mission-authority-server]) MAY serve this surface and, when it does, carries the same member with the same semantics in its discovery document; Section 14 registers the member in the Mission Authority Server Metadata registry.¶

11. Security Considerations

The security considerations of the issuance profile [I-D.draft-mcguinness-oauth-mission] and the status profile [I-D.draft-mcguinness-oauth-mission-status] apply. This section covers what is specific to fleet-scale management.¶

12. Privacy Considerations

The privacy considerations of the issuance and status profiles apply. This section covers what is specific to enumeration.¶

An enumeration response is PII-bearing by construction: each summary row ties a Subject identifier to an Agent, a lifecycle state, and activity timing, and a page of rows profiles a person's delegated activity. Minimization is structural: the summary shape of Section 5.1 excludes the Mission Intent and the Authority Set, and the filter-scope authorization of Section 3.2 bounds each Management Client to the population it demonstrably needs. A deployment SHOULD grant tenant-wide filter scopes only to incident-response roles.¶

The audit records of Section 3.2 are doubly sensitive: they carry the Subject identifiers of the Missions touched, and they record which operator investigated which person, when, and why. Deployments MUST treat them as PII sinks under the issuance profile's privacy rules, retain them for at least the audit horizon of the Missions they concern ([I-D.draft-mcguinness-oauth-mission]), and restrict read access to them at least as tightly as the management surface itself.¶

13. Conformance

This document is OPTIONAL. An implementation that claims it conforms in one of two roles.¶

A Management-capable Mission Issuer serves the Mission Management endpoint over the authentication and authorization of Section 3.1 and Section 3.2 with signed responses per Section 3; serves enumerate (Section 5) and the bulk lifecycle operations (Section 6) with dry-run-then-execute and the bulk token bindings of Section 6.1; applies bulk transitions per Mission under the status profile's lifecycle semantics, emitting per-Mission evidence and signals (Section 6.2); audit-logs every management request per Section 3.2; and advertises mission_management_endpoint (Section 10).¶

A Management Client authenticates per Section 3.1; sends the REQUIRED purpose or reason on every request, identifying the operator task rather than a fixed placeholder; obtains a fresh dry run for every execute, surfacing the match_count to the deciding operator or decision point before executing; and executes only bulk tokens from dry runs it itself requested.¶

An implementation that supports neither role is unaffected and remains a conforming issuance or status profile implementation.¶

14. IANA Considerations

Acknowledgments

The author thanks the implementers and reviewers of the Mission-Bound Authorization work for the incident-response experience that shaped this surface.¶

References

Author's Address