AAuth Mission Management

3.1. Mission Identity

The Mission Reference remains the management key for every mission this specification governs. On the wire, a request identifies its target with the {mission_s256} path segment of the mission's own control-plane URL, {mission_control_endpoint}/{mission_s256}, following the per-mission URL convention the base protocol defines at mission_endpoint.¶

The syntax, comparison, and digest rules are those of AAuth's mission identifier (Section 8.2.1 of [I-D.draft-hardt-oauth-aauth-protocol]). The approving PS is neither a request member nor a path segment: it is fixed to the identity of the PS endpoint that receives the request, so no part of the request can name another PS. A PS MUST resolve the {mission_s256} segment only among the missions it itself approved, MUST NOT forward a management operation to another PS, and MUST NOT accept an alias for either half of the reference.¶

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. Status and tree responses do not expose the mission for audit, so Section 8.2.1 of [I-D.draft-hardt-oauth-aauth-protocol], which has the PS serve the persisted blob bytes wherever it exposes the mission for audit, does not reach them; a PS that exposes the mission for audit on another surface serves those exact bytes there.¶

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 request that names the mission outside this control plane (Section 11). 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 [I-D.draft-hardt-oauth-aauth-protocol]: 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. AAuth Mission Expiry [I-D.draft-mcguinness-aauth-mission-expiry] remains an informative profile of the same native member for deployments that cite it.¶

This profile adds the observable consequences. The transition AAuth requires at or after expires_at is committed with termination reason expired and attributed to the PS scheduler (Section 10), surfaced through AAuth's mission_terminated error and mission_status rather than a separate status value. 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. The Mission Control Plane

Every operation below is an action on one mission's control-plane URL. A caller makes an HTTP POST [RFC9110] with a JSON body [RFC8259] to {mission_control_endpoint}/{mission_s256}, where mission_control_endpoint is the PS metadata member (Section 4.3) and {mission_s256} is the target mission's digest:¶

{
  "action": "status"
}

action is REQUIRED, and its value is status (Section 6), terminate (Section 7), or delegation_tree (Section 8). A PS MUST reject a request with a missing or unrecognized action with invalid_request, the same response the base protocol requires of a missing or unrecognized action at mission_endpoint. A caller SHOULD confirm that an action appears in mission_control_actions_supported (Section 4.3) before sending it.¶

The mission's identity comes from the path and from nowhere else. A request body MUST NOT carry a mission_s256 member, and a PS MUST reject a body that does with invalid_request. Response bodies continue to report mission_s256, and the replacement_s256 member of a superseded termination (Section 7) names a different mission as related evidence.¶

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

Every request MUST be authenticated as Section 5 requires for the caller's class. A signed request uses the AAuth HTTP Message Signatures profile (Section 11.3 of [I-D.draft-hardt-oauth-aauth-protocol]) [RFC9421]: its signature MUST cover @method, @authority, @path, signature-key, content-digest, and content-type, as Section 11.3.3.1 of [I-D.draft-hardt-oauth-aauth-protocol] requires on a request carrying a body to a PS endpoint, and MUST carry a created parameter within the PS's validity window (Sections 11.3.3.2 and 11.3.4 of [I-D.draft-hardt-oauth-aauth-protocol]). The signing key carries a fully specified alg, from which the PS determines the algorithm, and every party supports Ed25519 (Sections 11.3.1 and 11.3.4 of [I-D.draft-hardt-oauth-aauth-protocol]). A management operation is never authorized from the Mission Reference alone.¶

This document defines no action at the bare {mission_control_endpoint} URL. A PS MAY serve a deployment's human-facing administrative interface there, as the base protocol permits.¶

4.2. What Stays at the Mission Endpoint

mission_endpoint remains the owning agent's surface, carrying only the base protocol's three operations: proposing a mission at the bare URL, and the update and completion actions at a mission's own URL. This document defines no member and no action value at mission_endpoint.¶

4.3. Metadata

A PS supporting this specification publishes the base protocol's mission_control_endpoint and adds the following member to its /.well-known/aauth-person.json metadata:¶

{
  "issuer": "https://ps.example",
  "mission_control_endpoint": "https://ps.example/mission-control",
  "mission_control_actions_supported": [
    "status", "terminate", "delegation_tree"
  ]
}

mission_control_actions_supported is an array of case-sensitive action 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.¶

mission_control_endpoint is OPTIONAL in the base protocol and adds nothing to AAuth PS conformance, which rests on the four REQUIRED metadata fields alone (Section 11.2.2 of [I-D.draft-hardt-oauth-aauth-protocol]); the conformance it carries is to this document (Section 15). A PS that does not publish it implements no operation of this specification, whatever mission_control_actions_supported would advertise. A caller MUST resolve the endpoint from the metadata and MUST NOT construct it from mission_endpoint.¶

5.1. 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, replacement_s256 is REQUIRED, and the PS SHOULD verify that the same Person authorized both missions before recording the relationship.¶

A Person reaches these operations through the PS's own interface, which either invokes the operation inside the PS or has its backend call the control plane as a management service (Section 5.3). Either way the PS MUST authorize the action as the authenticated Person under the rules above, MUST record that Person as the principal, and MUST NOT apply a management service's administrative privilege to it. An internal invocation is not a control-plane request, but the same authorization, atomic transition (Section 7), and logging (Section 10) duties apply to it. How the Person signs in to the interface remains the PS's own; this document defines no user login.¶

For example, a Person ends a mission from the PS's account page:¶

1. The Person signs in to the PS's interface and selects the mission.¶

2. The interface submits termination as an explicit action, protected against cross-site submission by the interface itself (Section 13.5).¶

3. The interface invokes termination inside the PS, or its backend signs a control-plane terminate request as a registered management service and conveys the Person's identity over its trusted channel.¶

4. The PS binds the Person to the person the mission represents, authorizes reason revoked for that Person and mission, and runs the atomic transition.¶

5. The mission log records the Person as principal and the interface as the channel.¶

5.2. Administrator

The PS MAY authorize a human administrator, authenticated through the PS's own administrative channel with a phishing-resistant, sender-constrained mechanism appropriate to the deployment, bound to the tenant or person population the administrator governs. 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 action. 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.¶

5.3. Management Service

A management service authenticates with the AAuth HTTP Message Signatures profile [RFC9421], signing under the jwks_uri scheme of HTTP Signature Keys [I-D.draft-hardt-httpbis-signature-key], the scheme Section 11.3.2 of [I-D.draft-hardt-oauth-aauth-protocol] requires of a PS, AS, AP, or resource signing in its own right. The id parameter is the service's HTTPS identifier, dwk names the well-known metadata document the service publishes under a deployment-chosen name, and kid selects the key. That document MUST contain issuer, equal to id, and jwks_uri, and the PS resolves the key by the discovery procedure of Section 3.6 of [I-D.draft-hardt-httpbis-signature-key]. The PS MUST hold a deployment-local registration of the service's id and dwk as a management identity; this specification adds no discovery surface for management identities. An Agent MUST NOT use this scheme; the base protocol already forbids it to agents (Section 11.3.2 of [I-D.draft-hardt-oauth-aauth-protocol]).¶

A management service is subject to the administrative rules above: least-privilege scoping, a separate privilege for delegation data, administrative limited to the administrator role, and the recorded principal, role, decision, and purpose on every successful request.¶

A management service can act for a human, as the PS's own interface backend does for the Person (Section 5.1). For such a call the PS MUST authorize the action as that human under the human's own caller rules, MUST record the human as the principal and the service as the channel, and MUST NOT apply the service's administrative privilege. How the service conveys the human's identity is a deployment trust relationship this document does not define, and the PS relies on it only for a service it registers for that purpose.¶

5.4. Owning Agent

Whether the control plane admits the Owning Agent is a PS decision. The base protocol describes the control plane as the surface for parties other than the owning agent, and gives the owning agent no base operation that terminates a mission.¶

Where a PS admits the Owning Agent at the control plane, that agent MAY read status for its own mission and MAY terminate its own mission with reason revoked, and the PS MAY expose the delegation tree for that mission to it. The agent authenticates exactly as at other AAuth PS endpoints: it presents its Agent Token with Signature-Key: sig=jwt, the signature MUST verify with the token-bound key, and the sub of the verified Agent Token MUST exactly match the agent member of the mission blob.¶

Where a PS does not admit the Owning Agent, that agent is an authenticated caller without authorization for the mission, and Section 9 applies to it unchanged: it receives mission_not_found. Its path to ending the work is the base protocol's completion, and this document defines no action at mission_endpoint.¶

An Agent does not directly assert completed. It uses AAuth's completion operation, 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.5. Ambient Credentials

Every action defined here is a JSON POST authenticated as this section requires, and a browser session never authenticates a control-plane request directly. A PS that serves a human-facing interface at the same origin MUST NOT let an ambient credential, such as a cookie or session a browser attaches automatically, satisfy that authentication. The interface reaches the operations through the PS (Section 5.1).¶

7.1. Request

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

{
  "action": "terminate",
  "reason": "revoked",
  "request_id": "t-4f52f8d70a514703b54ca0c677f82d67",
  "purpose": "User withdrew authorization"
}

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

For superseded, the request MUST include the replacement:¶

"replacement_s256": "UewCpFZHMZtpxPwRETXY81ouxt724qQPkaNOJKjbd2E"

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; it is validated before, and committed in, the atomic transition. A superseded request without replacement_s256 fails with invalid_request as a missing member. Replacement validation is subject to Section 9: a replacement that is unresolvable, 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, request_id, and, for superseded, the validated replacement_s256 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 full status representation (Section 6), whose token_residual member is the revocation summary:¶

{
  "mission_s256": "dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk",
  "mission_status": "terminated",
  "approved_at": "2026-04-07T14:30:00Z",
  "expires_at": "2026-04-14T14:30:00Z",
  "terminated_at": "2026-04-10T09:12:43Z",
  "termination_reason": "revoked",
  "observed_at": "2026-04-10T09:12:44Z",
  "fresh_until": "2026-04-10T09:13:14Z",
  "token_residual": {
    "tracked": 4,
    "revocation_attempted": 4,
    "revocation_confirmed": 3,
    "residual_until": "2026-04-10T10:02:00Z",
    "complete": false
  }
}

token_residual contains tracked, revocation_attempted, and revocation_confirmed, each a non-negative integer, and the boolean complete, all REQUIRED, and residual_until, an RFC 3339 date-time [RFC3339], when a residual is known. The counters disclose only tokens the caller is authorized to know about. The counters count Tracked Credentials, so a Person Token counts like an Auth Token. complete is true only when every Tracked Credential is either confirmed revoked or expired and the PS knows of no untracked access mode for the mission; it is false while any Person Token is live and unconfirmed, and never follows from Auth Tokens alone. complete covers every Tracked Credential, including any the counters withhold from the caller. A credential whose recipient advertises no revocation endpoint, or whose revocation outcome is unknown, stays unconfirmed until its exp. residual_until is the latest exp among unconfirmed Tracked Credentials. 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 outcome of a terminate request under (authenticated caller, request_id) for at least 24 hours and SHOULD retain it for the mission log's lifetime. Two requests are equivalent when they have the same authenticated caller, are made to the same PS and the same {mission_s256} path target, and carry JSON bodies that are equal as parsed values: member order does not matter, and any difference in reason, purpose, replacement_s256, or another member, including an unrecognized one, makes them different. Reusing a request_id for a request that is not equivalent, including one addressed to another mission, fails with idempotency_conflict.¶

An equivalent request is a replay. It creates no second lifecycle event and initiates no revocation. Its response repeats the committed receipt exactly, namely mission_s256, mission_status, terminated_at, and termination_reason, and reports the rest of the status representation, including observed_at, fresh_until, and token_residual, as of the replay. A client therefore distinguishes the original outcome from the current observation.¶

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 request that names the mission, at any PS endpoint other than this control plane, with the AAuth mission_terminated error (Sections 8.6 and 8.8 of [I-D.draft-hardt-oauth-aauth-protocol]). A request names the mission through a mission_s256 parameter, as a person token request can (Section 7.1 of [I-D.draft-hardt-oauth-aauth-protocol]); through a token carrying mission_s256, whether a resource token, presented token, or upstream token; or through the mission's own URL at mission_endpoint, for an update or completion. The PS 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 Credentials

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

• the Mission Reference;¶

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

• aud and exp;¶

• the revocation endpoint of the Resource in aud, when advertised;¶

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

• for a Person Token, each AS the PS presented it to, as Section 7.1 of [I-D.draft-hardt-oauth-aauth-protocol] requires; and¶

• for a federated or chained credential, the presented or upstream token it derives from.¶

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 revoke every unexpired Tracked Credential, as Section 11.12.4 of [I-D.draft-hardt-oauth-aauth-protocol] recommends when a PS revokes a mission. Each revocation is a signed POST of {jti, exp} to the recipient's revocation_endpoint, with exp taken from the PS's record of that token. The PS signs as a server under the jwks_uri scheme, with its issuer as id and aauth-person.json as dwk, and the signature covers content-digest and content-type (Sections 11.3.2 and 11.12.1 of [I-D.draft-hardt-oauth-aauth-protocol]). The recipient takes the issuer from the signature, so the PS revokes only tokens it issued.¶

The PS revokes a Person Token at the Resource named in its aud and at each AS it presented the token to (Section 11.12.2 of [I-D.draft-hardt-oauth-aauth-protocol]). In PS authorization (three-party), the PS revokes an Auth Token it issued at the Resource it was issued for. In federated authorization (four-party), the AS issued the Auth Token, so the PS instead revokes the Person Token it presented to that AS, known from the issuance record that Section 7.1 of [I-D.draft-hardt-oauth-aauth-protocol] requires, and the AS revokes the Auth Tokens it issued against that Person Token (Sections 11.12.2 and 11.12.4 of [I-D.draft-hardt-oauth-aauth-protocol]). Retries MUST be bounded, authenticated, rate limited, and recorded. A repeated revocation is idempotent: the recipient records nothing new, re-attempts each downstream revocation that did not succeed, and reports the current outcome (Section 11.12.3 of [I-D.draft-hardt-oauth-aauth-protocol]).¶

A revocation is confirmed, for revocation_confirmed and complete (Section 7), only by an outcome that names the Tracked Credential's own recipients:¶

• a Person Token is confirmed when the Resource in its aud and each AS it was presented to have each answered 200;¶

• an Auth Token the PS revoked at the Resource it was issued for is confirmed by that Resource's 200, which has nothing downstream and carries an empty body; and¶

• an Auth Token an AS issued is confirmed only by a downstream entry, in the AS's 200 to the Person Token revocation, whose recipient is the token's aud and which carries no error.¶

An absent body, an absent downstream member, or a downstream array with no entry for the token's aud reports nothing about that token, which stays unconfirmed (Section 11.12.3 of [I-D.draft-hardt-oauth-aauth-protocol]). A 200 says the recipient recorded the revocation and finished its cascade, not that it held a record of the token: AAuth defines no not-found response. Natural expiry also closes the tracked residual for a token.¶

A 202 is pending: the PS polls the pending URL with a signed GET under the same identity, honoring Retry-After, until the terminal response (Section 11.12.3 of [I-D.draft-hardt-oauth-aauth-protocol]). Every other outcome leaves the token unconfirmed until a later attempt is confirmed or its exp passes:¶

• a downstream entry with revocation_unsupported or revocation_unavailable leaves the Auth Tokens at its recipient honored; after revocation_unavailable, the PS can revoke again later;¶

• rate_limited (429) carries a Retry-After interval the PS waits before retrying;¶

• unsupported_iss (403) means the recipient does not accept revocations from this PS and honors the token until its exp; and¶

• a timeout, an unreachable or absent endpoint, a 5xx, or an unparseable response establishes nothing.¶

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 Person Token or Auth Token can remain acceptable until its exp unless the Resource receives and enforces revocation. At a Resource that serves person identity access, holding a Person Token is effectively access (Section 7.1.1 of [I-D.draft-hardt-oauth-aauth-protocol]), so a live Person Token is part of the residual. Network partitions and Resource policy therefore create an unavoidable residual window.¶

The PS can provide a time bound only for the Tracked Credentials whose expiry it knows. The conservative tracked bound is the latest exp among Tracked Credentials not confirmed revoked, Person Tokens included. 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:¶

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

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

• a Resource that violated the base protocol's mission_s256 copy rule;¶

• 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 Person Token and Auth Token lifetimes, whether Resources implement revocation, retry policy, and the worst-case residual expected under partition. Risky deployments SHOULD use short Person Token and 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 mission_s256 value in the request path, including one issued by a different PS. Exact digest comparison, resolving mission_s256 only within this PS's own approved-mission store, signature verification, and authorization against the resolved mission are all mandatory. Because the target is a path segment, the @path covered component of the base signature profile binds it to the signature, so a captured signature cannot be redirected at another mission. mission_s256 is not 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

Where a PS admits the Owning Agent at the control plane, 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. Person Interfaces

A PS interface that reaches these operations carries web-session risks the signed control plane does not. What makes a Person's action explicit is the interface's own protection against cross-site submission, which the PS that serves the interface validates; the control plane's refusal of ambient credentials does not protect the interface itself. The PS binds each action to the Person authenticated when the action is taken and to the person the mission represents, never to an account or tenant selected in the request, so switching accounts or tenants mid-session cannot redirect it. A session established before the Person's authorization changed carries no earlier authorization forward: the PS evaluates authorization at the action. A backend that calls as a management service for the Person could otherwise apply its own administrative privilege, a confused deputy; the PS authorizes such a call as the Person and never under the service's privilege (Section 5.3).¶

13.6. 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.7. 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.8. Delegation-Tree Limits

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

13.9. 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-httpbis-signature-key]

Hardt, D. and T. Meunier, "HTTP Signature Keys", Work in Progress, Internet-Draft, draft-hardt-httpbis-signature-key-09, 13 September 2026, <https://datatracker.ietf.org/doc/html/draft-hardt-httpbis-signature-key-09>.

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

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

[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-aauth-mission-expiry]

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

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