AAuth Mission Management

3.1. Mission Identity

All requests in this specification identify exactly one target mission using:¶

{
  "approver": "https://ps.example",
  "s256": "dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk"
}

The syntax, comparison, and digest rules are those of the AAuth Mission Reference. The approver value MUST exactly equal the issuer in the metadata of the PS receiving the request. A PS MUST NOT forward a management operation to another approver and MUST NOT accept an alias for either member.¶

The pair is the sole protocol key. Implementations MAY use internal database keys, but those keys MUST NOT appear in this protocol. The PS MUST NOT require the caller to send the mission blob, and a status or tree response MUST NOT return it.¶

The Mission Reference is integrity-protected but is not a secret. Possession of it conveys no management authority.¶

3.2. State and Termination Reasons

The only protocol states are:¶

• active: the mission is in progress; and¶

• terminated: the mission has permanently ended.¶

Only active permits the PS to process a token, permission, audit, or interaction request under the mission. Once the PS commits terminated, it MUST NOT return the mission to active. A caller that needs to continue the work creates and obtains approval for a new mission.¶

This specification defines these termination reasons:¶

A Termination Reason is stored beside lifecycle data, outside the immutable mission blob. It MUST NOT be exposed as mission_status, mapped to a new state, or used to permit a later transition. A PS MAY support extension reasons. A recipient that does not recognize a reason MUST retain the terminated state and treat the reason as an opaque audit value.¶

3.3. Optional Expiry

Mission expiry is defined by AAuth Mission Expiry [I-D.draft-mcguinness-aauth-mission-expiry]: an OPTIONAL expires_at member of the approved mission blob, covered by s256, immutable in place, and enforced by the PS on every decision path. This profile does not redefine that mechanism.¶

This profile adds the observable consequences. The transition that extension requires at or after expires_at is committed with termination reason expired and attributed to the PS scheduler (Section 10). The status operation exposes the approved expiry (Section 6). An explicit terminate that races automatic expiry resolves as Section 7.3 specifies: the first committed transition wins, and the losing operation observes an idempotent outcome.¶

4.1. Extending the Mission Endpoint

All operations below use an HTTP POST [RFC9110] with a JSON body [RFC8259] to the mission_endpoint in the PS metadata. Management requests have this common shape:¶

{
  "operation": "status",
  "mission": {
    "approver": "https://ps.example",
    "s256": "dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk"
  }
}

The request MUST use Content-Type: application/json. The PS MUST reject duplicate JSON member names. Unknown members MUST be ignored unless they prevent safe processing. Unknown operations fail with unsupported_operation.¶

An Agent request MUST be signed using the AAuth HTTP Message Signatures profile [RFC9421] and MUST present its Agent Token in Signature-Key. The covered components and content integrity requirements are those of the base AAuth profile. A management request is never authorized from the Mission Reference alone.¶

This placement follows the base protocol's own definition of mission_endpoint as the URL for mission lifecycle operations, of which mission creation is one; the operations here are additional lifecycle operations at that surface. A native mission proposal carries no operation member, so the discrimination is unambiguous. The base protocol does not reserve the operation member: if a future AAuth revision defines its own operation discrimination or request-shape rules at mission_endpoint, that definition governs and this profile will align with it. A caller SHOULD confirm that an operation appears in mission_management_operations_supported (Section 4.2) before sending it, because the base protocol does not define how a PS without this profile processes an operation-shaped request.¶

4.2. Metadata

A PS supporting this specification adds the following member to its /.well-known/aauth-person.json metadata:¶

{
  "issuer": "https://ps.example",
  "mission_endpoint": "https://ps.example/mission",
  "mission_management_operations_supported": [
    "status", "terminate", "delegation_tree"
  ]
}

mission_management_operations_supported is an array of case-sensitive operation strings. The array MUST contain status and terminate for conformance to this specification. It contains delegation_tree when the PS implements Section 8. Unknown values MUST be ignored.¶

The base AAuth mission_endpoint member remains the only endpoint advertised by this profile. The base protocol also defines a mission_control_endpoint metadata member; a PS MAY retain it for a deployment-specific administrative user interface, but it MUST NOT use that member to advertise the interoperable operations defined here.¶

5.1. Owning Agent

The Owning Agent is authenticated exactly as at other AAuth PS endpoints. The sub of the verified Agent Token MUST exactly match the agent member of the mission blob, and the request signature MUST verify with the token-bound key.¶

The Owning Agent MAY:¶

• read status for its mission;¶

• request its delegation tree if the PS exposes that operation to agents; and¶

• terminate its mission with reason revoked.¶

An Agent does not directly assert completed. It uses AAuth's completion interaction, after which the Person's acceptance causes the PS to terminate with reason completed. A sub-agent MUST NOT call this endpoint: AAuth requires its parent to mediate PS operations.¶

5.2. Person

The PS authenticates the Person using its normal person-facing channel. This specification does not replace the PS's account authentication or session protocol. The PS MUST bind that authenticated Person to the person represented by the mission and MUST prevent tenant or account selection from being supplied solely by the request body.¶

The Person MAY read status and delegation data, and MAY terminate with reason completed, revoked, or superseded. For superseded, the PS SHOULD require the replacement Mission Reference and verify that the same Person authorized both missions before recording the relationship.¶

5.3. Administrator and Management Service

The PS MAY authorize an administrator or management service. Such a principal MUST be authenticated using a phishing-resistant, sender-constrained mechanism appropriate to the deployment. A remote machine caller using AAuth HTTP Message Signatures MUST present a token or key reference the PS recognizes as a management identity; an Agent Token alone MUST NOT confer administrative privilege.¶

Administrative authorization MUST be least-privilege and scoped at least by tenant or person population and operation. Access to delegation data SHOULD be a separate privilege from termination. Administrative reason administrative MUST be limited to this role.¶

The PS MUST record the authenticated principal, effective role, policy decision, and declared operational purpose for every successful administrative request. It SHOULD require step-up authentication or dual control for high-blast-radius automation. This profile does not define fleet enumeration or bulk termination.¶

7.1. Request

Termination uses operation equal to terminate. It requires a request_id carrying at least 128 bits of unpredictable or collision-resistant entropy encoded as a string.¶

{
  "operation": "terminate",
  "mission": {
    "approver": "https://ps.example",
    "s256": "dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk"
  },
  "reason": "revoked",
  "request_id": "t-4f52f8d70a514703b54ca0c677f82d67",
  "purpose": "User withdrew authorization"
}

reason and request_id are REQUIRED. purpose is OPTIONAL for an Owning Agent or Person and REQUIRED for an administrator. purpose is an audit string, not executable policy, and MUST be rendered as untrusted text.¶

For superseded, a Person or administrator MAY include:¶

"replacement": {
  "approver": "https://ps.example",
  "s256": "QmV0dGVyTWlzc2lvbkRpZ2VzdFZhbHVlMTIzNDU2Nzg5MDE"
}

The replacement is related evidence, not an alternate key for the target operation. It MUST identify an already approved mission that the caller is authorized to reference. Replacement validation is subject to Section 9: a replacement that is absent, unapproved, or outside the caller's authorization fails uniformly with invalid_request, and the failure MUST NOT disclose which condition held or anything else about the referenced mission.¶

7.2. Atomic Transition

The PS performs these actions in order:¶

1. authenticate and authorize the caller;¶

2. apply expiry and read the current state under a transaction or equivalent serialization mechanism;¶

3. if active, atomically commit terminated, terminated_at, the reason, actor, and request_id to the mission log;¶

4. make that state visible to every local PS decision and issuance path;¶

5. initiate revocation of outstanding Auth Tokens as described in Section 11, without waiting for all attempts to finish; and¶

6. return the committed result and the revocation summary current at response time.¶

Step 3 is the authority-closing commit. External revocation MUST NOT be allowed to delay or roll it back. The PS MAY wait for a short, bounded set of immediate revocation results before responding, and revocation attempts MAY continue asynchronously.¶

The PS returns 200 OK with the status representation and a revocation summary:¶

{
  "mission": {
    "approver": "https://ps.example",
    "s256": "dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk"
  },
  "mission_status": "terminated",
  "terminated_at": "2026-04-10T09:12:43Z",
  "termination_reason": "revoked",
  "token_residual": {
    "tracked": 4,
    "revocation_attempted": 4,
    "revocation_confirmed": 3,
    "residual_until": "2026-04-10T10:02:00Z",
    "complete": false
  }
}

The counters disclose only tokens the caller is authorized to know about. complete is true only when every Tracked Auth Token is either confirmed revoked or expired and the PS knows of no untracked access mode for the mission. residual_until is the latest exp among unconfirmed Tracked Auth Tokens. It MUST be omitted when no residual is known and MUST NOT be presented as a complete bound if untracked or opaque credentials may exist.¶

7.3. Idempotency and Concurrency

The PS MUST retain the result associated with (authenticated caller, request_id) for at least 24 hours and SHOULD retain it for the mission log's lifetime. Repeating an identical request returns the original result without a second lifecycle event. Reusing a request_id with different request content fails with idempotency_conflict.¶

Termination is also semantically idempotent across request identifiers. If the mission is already terminated, an authorized caller receives its existing terminal status. The first committed reason and timestamp remain authoritative; a later request MUST NOT overwrite them. A PS MAY append an audit entry noting the later authorized request.¶

Concurrent requests are serialized. At most one request records the active-to-terminated transition. Completion, expiry, and administrative termination obey the same rule.¶

11.1. Local Gating

Immediately after the terminal commit, the PS MUST reject every new token, permission, audit, and interaction request under the Mission Reference with the AAuth mission_terminated error. It MUST stop federating resource-token requests under that mission. This is the reliable AAuth management effect because it occurs at the server that owns the mission context.¶

A Resource Token is a signed request artifact, not authority. It does not need revocation; submitting it under the terminated mission fails at the PS. Terminating a mission does not revoke the Agent Token, because the Agent identity can legitimately be used for another mission or for missionless AAuth interactions.¶

11.2. Tracking Auth Tokens

For each Auth Token it issues or provides under a mission, a conforming PS MUST retain:¶

• the Mission Reference;¶

• the token's iss and jti as a compound identity;¶

• aud and exp;¶

• the Resource revocation endpoint, when advertised; and¶

• whether the PS issued the token or obtained it through federation.¶

The PS MUST NOT key revocation by jti alone. It SHOULD also retain the AS and Resource endpoints required to retry revocation. These records are sensitive and follow Section 10.¶

11.3. Revocation Attempts

After termination, the PS SHOULD invoke each applicable AAuth revocation_endpoint with (iss, jti) for every unexpired Tracked Auth Token. In PS-asserted access, this normally means the Resource. In federated access, the PS SHOULD notify the Resource and MAY also notify the issuing AS as supported by the base AAuth protocol. Retries MUST be bounded, authenticated, rate limited, and recorded.¶

A 200 response or natural token expiry closes the tracked residual for that token. A timeout, unreachable endpoint, absent endpoint, or ambiguous result remains unconfirmed until expiry. The PS MUST NOT report successful mission-wide revocation merely because it marked its local state or contacted an AS.¶

11.4. Honest Residual Bounds

Termination is not retroactive. It cannot undo an action already performed or necessarily stop an action already accepted. A self-contained Auth Token can remain acceptable until its exp unless the Resource receives and enforces revocation. Network partitions and Resource policy therefore create an unavoidable residual window.¶

The PS can provide a time bound only for the Tracked Auth Tokens whose expiry it knows. The conservative tracked bound is the latest exp among tokens not confirmed revoked. If the PS cannot determine an expiry, it MUST report the tracked residual as unbounded rather than inventing a deadline.¶

The PS has no general visibility or control over:¶

• identity-based access where a Resource authorizes the Agent directly;¶

• an opaque AAuth-Access token issued in resource-managed access;¶

• a Resource that ignored AAuth-Mission;¶

• credentials or side effects acquired outside AAuth; or¶

• a downstream call made without returning through this PS.¶

Where any such path was possible, the PS MUST mark mission-wide revocation completeness as false or unknown. Deployment documentation MUST state which AAuth access modes are covered, the maximum configured Auth Token lifetime, whether Resources implement revocation, retry policy, and the worst-case residual expected under partition. Risky deployments SHOULD use short Auth Token lifetimes and action-time Resource checks in addition to PS gating.¶

The base AAuth text sometimes describes this action as revoking a mission. In this profile, "revoke the mission" means the single, permanent transition to terminated with Termination Reason revoked. It is not a distinct revoked state and does not invoke an OAuth token revocation or status protocol for the mission itself.¶

13.1. Reference Substitution and Cross-PS Confusion

An attacker can substitute a known s256 or send a reference for a different PS. Exact pair comparison, the local approver check, signature verification, and authorization against the resolved mission are all mandatory. Neither member is interpreted as a fetch URL. The PS never retrieves a mission from a caller-selected location.¶

13.2. Request Replay

A termination replay is safe only if its content is bound to the signature and its idempotency rules are enforced. The request body MUST have content integrity under the AAuth HTTP Message Signatures profile. The PS enforces signature freshness and nonce/replay policy as defined by AAuth and binds request_id to authenticated caller and exact content. Logging a repeated request must not overwrite the first reason or create a false second transition.¶

13.3. Compromised Agents

A compromised Owning Agent can terminate its own mission, causing denial of service. It cannot gain authority by doing so and cannot reactivate the mission, choose administrative reasons, or manage another mission. The Person can create a newly approved mission after recovery. Because an Agent request for completion still requires Person acceptance, compromise cannot falsely record completed through this endpoint.¶

13.4. Administrative Blast Radius

Administrative credentials can terminate many missions even though this profile exposes only single-mission operations. A PS MUST scope them, rate limit them, protect them with sender constraint, and audit their use. Management automation SHOULD require a declared purpose and SHOULD use approval or dual control appropriate to its potential blast radius. The endpoint MUST NOT infer administrative authority from an Agent's domain or parent_agent relationship.¶

13.5. Races and Failures

The local terminal commit precedes external revocation. Transactional state evaluation prevents a token request racing with termination from being issued after the commit. Implementations MUST ensure every local decision path consults the same authoritative state or a cache whose failure behavior is fail closed. Expiry is checked synchronously so a failed scheduler cannot keep a mission active.¶

External failures do not restore the mission. Revocation retries are durable work and survive PS restarts. A Resource that needs a stronger cutoff cannot rely only on cached status or token expiry; it needs an action-time decision or effective revocation mechanism.¶

13.6. Log Integrity

The mission log influences future governance and is security-critical. The PS MUST prevent Agents and ordinary operators from rewriting or reordering it. Sequence allocation, durable storage, authenticated actor attribution, backup, and restricted access are required. This document does not require a public transparency mechanism, but a PS MAY add tamper-evident storage or signed checkpoints.¶

13.7. Delegation-Tree Limits

The returned tree is based on PS observations, not global execution. Treating it as complete evidence can hide identity-based, opaque-token, or off-path activity. Consumers MUST preserve the distinction between page completeness and observational completeness. Token act claims and parent_agent values are accepted only after their normal AAuth verification; unverified caller assertions never create edges.¶

13.8. Transport

All operations use HTTPS and the TLS requirements of [I-D.draft-hardt-oauth-aauth-protocol] and [RFC9325]. Responses SHOULD carry cache controls preventing shared caching. Management clients MUST validate the PS metadata issuer and endpoint origin before sending references or credentials.¶

16.1. Normative References

[I-D.draft-hardt-oauth-aauth-protocol]

Hardt, D., "AAuth Protocol", Work in Progress, Internet-Draft, draft-hardt-oauth-aauth-protocol-10, 2026, <https://datatracker.ietf.org/doc/draft-hardt-oauth-aauth-protocol/10/>.

[I-D.draft-mcguinness-aauth-mission-expiry]

McGuinness, K., "AAuth Mission Expiry", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-aauth-mission-expiry.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>.

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

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

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

[RFC9421]

Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, <https://www.rfc-editor.org/rfc/rfc9421>.

[RFC9457]

Nottingham, M., Wilde, E., and S. Dalal, "Problem Details for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023, <https://www.rfc-editor.org/rfc/rfc9457>.

16.2. Informative References

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

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

[I-D.draft-mcguinness-mission-security-model]

McGuinness, K., "Mission Security Model", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-security-model.html>.