Overview

The Mission Is the Missing Abstraction defined the Mission as a durable governance object and gave it a deliberately small lifecycle: active, revoked, expired, with the rule that only active permits new derivation. That issuance core is complete on its own. But it observes Mission state only through one channel: the lifetime of the tokens it already issued, plus optional token introspection. A consumer that holds a Mission-bound token and nothing else has no way to ask “is this Mission still good,” and no way to be told that it stopped being good. An authorized operator who wants to pause a Mission has no standardized verb for it. A task that finishes keeps deriving its authority until a clock or a revoke stops it.

This part closes those gaps with four companion profiles, each optional, each layering on the issuance core without changing it. They are not all at the same maturity. Status is the protocol MVP’s state surface. Signals, its push complement, is experimental. Expansion and Completion sit on the advanced tier, stable design to adopt when the use case arrives, and each has a newer companion noted where it attaches (Progressive Authorization and fleet Management). They answer four questions a long-running task forces:

• Observe: how does a consumer holding only a mission_id learn the current state, and learn it promptly when it changes?
• Revoke: how does an authorized party change the state (terminate, pause, resume)?
• Grow: what happens when the task legitimately needs more authority than was approved?
• Complete: how does authority retire itself safely as the work it was granted for finishes?

The unifying move is the one the series framing names as a recurring rule. Only active permits reliance. Every state these profiles add (suspended, completed, superseded) is treated as non-active by any consumer, including one that has never heard of it. That is what lets the lifecycle grow new states without breaking the consumers that predate them. We return to it at the end, because it is the property that makes all four verbs safe.

Observe and revoke: pull and push

The kill switch from The Mission Is the Missing Abstraction is possession-independent. Revoke the Mission at the Authorization Server and no new authority derives for the task. But “no new derivation” only bites at the next derivation event. A Resource Server holding a live access token does not consult the Authorization Server on every call by default. It trusts the token until it expires. So the kill switch is only as fast as the slowest token’s remaining lifetime, unless consumers can learn the current state out of band.

There are exactly two ways to learn current state: ask for it, or be told. The suite provides both.

Status: the pull side

Mission Status and Lifecycle defines the canonical state surface the issuance core deferred: an operation keyed by mission_id alone. Token introspection answers “is this token’s authorization still good.” The Status operation answers a different question, “what is the state of this Mission,” and answers it for any consumer holding a mission_id, including an auditor or a cross-domain Resource Server that holds no token the Authorization Server issued. The consumer resolves the endpoint from the credential’s mission.issuer and asks.

The answer is signed. A Status response is a JWS, with its own media type (application/mission-status-response+jwt), carrying the mission object (id, issuer, authority_hash, state, and the Mission’s expires_at) plus, when the requester names an audience, the audience-scoped Authority Set entries relevant to it. An auditor may omit the audience and get a state-only response with no authorization_details. It is bound to the request by an echoed nonce, to the requester by aud and sub, and to a freshness window by fresh_until, which tells the consumer how long it may cache the reported state before re-checking. The signing matters because the response often outlives the call. An auditor must be able to verify, later, that the issuer really reported revoked at a given moment.

Two design choices in Status are worth pulling out because they are easy to get wrong:

• A mission_id is never a bearer capability. The endpoint authenticates the requester and authorizes it for the specific mission_id and audience. An unknown Mission and a known-but-unauthorized one return indistinguishable responses, so the Status surface cannot be turned into an enumeration oracle for the Mission space.
• The dedicated operation is not RFC 9701. Signed token introspection (RFC 9701) is scoped to token introspection and does not apply to a lookup keyed by mission_id. There is a separate, thinner story for the token-scoped case. The issuance core’s introspection projection carries the mission state, and this Status profile adds the option of returning that projection as an RFC 9701-signed response. Two surfaces, two signing stories, deliberately not conflated.

Status is also where the explicit lifecycle endpoint lives (the verbs that change state). A management endpoint, distinct from RFC 7009 token revocation, accepts authenticated revoke, suspend, resume, and complete operations and introduces two states the issuance core did not have:

• suspended: a non-terminal pause. A suspended Mission derives no tokens, but it can be resumed to active. This is the “stop, but don’t tear down” state an operator wants when something looks wrong but is not yet known to be malicious.
• completed: a terminal state recording that the task finished successfully.

The legal transitions are narrow on purpose: suspend only from active, resume only from suspended, revoke from either, complete from active or suspended (completion is a monotonic narrowing to a terminal state and needs no derivation window, so a suspended Mission need not be resumed first). An operation against a state it is not legal from is a conflict, not a silent no-op. The endpoint refuses it rather than pretending it worked. The endpoint authorizes operations against deployment policy (typically revoke to the Subject, Approver, or an administrator; suspend/resume to administrators), and an unauthorized request gets the same not-found response shape as an unknown Mission, so the management surface is no more of an enumeration oracle than the read surface. Fleet-scale operations are deliberately out of this profile: authenticated Mission enumeration (by subject, client, state, or expiry window) and bulk lifecycle operations with a dry-run-first discipline live in the Mission Management companion, on the advanced tier.

Signals: the push side

Status answers when the consumer asks. But a high-assurance consumer that wants revocation to bite in seconds cannot afford to poll the Status endpoint on every action. That puts the Authorization Server on the hot path of every credential validation. The complement is to be told.

Mission Lifecycle Signals is a profile of the OpenID Shared Signals Framework. When the Mission Issuer commits a lifecycle transition (a revocation, expiry, suspension, completion, or the approval event that activates the Mission), it emits a signed Security Event Token, a mission.lifecycle-change event, delivered either by push (the Issuer pushes the SET to the consumer’s receiver) or by poll (the consumer fetches available SETs). A partner Resource Server subscribed to the stream learns of a cancellation seconds after it happens, well inside the remaining lifetime of any token it holds, and stops honoring the Mission.

One honesty note first. Signals is labeled experimental on the adoption ladder, and not for dependency reasons (Security Event Tokens and their delivery are ratified). Push is a latency optimization over correctly sized status polling, and the profile should earn its interface through deployment before anyone builds a hard dependency on it. The stable path is Status polling sized to the risk, with Signals adopted for evaluation where a revocation must bite in seconds.

The event carries the new state, the prior_state (except on the initial approval emission, where there is none), and a strictly monotonic per-Mission version counter. The counter is the part that makes event delivery safe against the network. Events can arrive out of order or be replayed, so the consumer applies a transition only if its version is greater than the last it applied. A stale active event for an older version cannot revive a Mission a newer revoked event already retired. And because delivery is best-effort, a consumer that cannot verify its stream, or that was down and may have missed events, treats its cached state as stale once it exceeds the Issuer’s advertised staleness bound and falls back to polling Status. A missed event is a freshness failure, never “still active.” Signals make revocation prompt. They never make it fail open.

Pull and push are not alternatives so much as two sizes of the same answer. A consumer that checks state occasionally polls Status. A consumer that needs prompt revocation subscribes to Signals and falls back to Status when the stream goes quiet. Both read the same fact, the current state, from the same authoritative issuer.

The running example. Take the series running example, the Prepare the Q3 board packet Mission, msn_01J9Z2P8BQ4Y3F0V0K9D6Z7M1 at as.example.com. The board meeting is cancelled while the agent is still drafting, so an admin revokes the Mission mid-draft at the lifecycle endpoint. A consumer holding only the mission_id (the docs Resource Server, an auditor) learns the new state without holding any token the Issuer can age out. It either asks Mission Status (pull) or receives a mission.lifecycle-change Signal carrying state: revoked (push). Either way the result is the same. query_financials, create_doc, and notify_reviewer all stop deriving at once.

Grow: expansion creates a successor

The first recurring rule of the series is that authority can only narrow. A derived or delegated token never carries more than the Mission. The subset rule enforces it at every derivation. That is a foundational safety property, but it raises an obvious question. What happens when the task legitimately needs to do something the approved Authority Set does not cover? Mid-task, the Prepare the Q3 board packet agent decides it could enrich the packet by reading CRM customer data, an authority the Approver never granted, outside the Mission’s query_financials/create_doc/notify_reviewer set entirely.

The answer is not to widen the Mission in place. A Mission’s authority is committed at one approval event by authority_hash. Widening it in place would mean the thing the user approved is no longer the thing in force, and authority_hash would no longer commit what is being used. Mission Expansion instead routes growth through a new approval that creates a successor Mission.

An expansion is an ordinary Mission creation under the issuance core (a Mission Intent submitted through Pushed Authorization Requests, leading to a fresh approval event) with one binding added. The request is bound to the predecessor’s grant (the client presents the predecessor’s refresh token), so the Issuer adjudicates a successor of a specific predecessor rather than an unrelated new Mission. The fresh consent is what supplies the broader authority. The successor’s authority comes only from its own approval. Its authority_hash commits exactly the set the Approver saw, never the predecessor’s plus a computed delta. On the successor’s activation, the predecessor transitions atomically to a terminal superseded state and derives nothing further. The successor carries a predecessor lineage member linking it back, but that member is audit context only. Like every other extra member on the mission claim, it MUST NOT grant or widen authority.

Two distinctions keep expansion honest:

• Expansion is not step-up. A request denied because authentication is too weak (an acr/amr shortfall) is satisfied by re-authentication. The Authority Set does not change. A request denied because the authority is not in the active Mission is what expansion addresses. Routing an authentication shortfall through an approval event would surface irrelevant consent and breed approval fatigue. Treating an authority shortfall as a mere re-auth would silently widen nothing. The two are not interchangeable.
• Expansion is a governance operation, not a runtime escalation. It does not undo the subset rule. It is a deliberately heavier, consent-backed path that produces a new governed object the kill switch and audit chain still cover.

For open-ended tasks where stopping the user at every step is impractical, a newer, experimental companion, Mission Progressive Authorization, builds on expansion. At the initial approval the Approver may also consent to an authority ceiling and a drawdown policy, so in-ceiling expansions can be adjudicated by policy rather than a fresh human prompt. The ceiling is broad by construction (it has to cover the open-ended task), but what stays narrow is the active authority any single Mission in the chain yields. Each successor is derived for what is actually needed at that step, independently gated and revocable. The guard is explicit. A drawdown that would grant an irreversible action, an external commitment, privileged administration, or cross-domain authority always requires fresh human approval, even within the ceiling. Progressive authorization bounds standing-authority exposure. It does not eliminate it, and it is meant to be paired with short successor lifetimes and runtime enforcement.

The running example. The Prepare the Q3 board packet Mission, msn_01J9Z2P8BQ4Y3F0V0K9D6Z7M1 at as.example.com, cannot read CRM customer data. That authority is outside its Authority Set, and the agent cannot widen the Mission in place. So it requests an expansion, a fresh approval for a successor Mission bound to the predecessor’s grant. The Approver declines. CRM access is out of policy for board-packet preparation. The result is the failsafe one. No CRM access, no successor activates, and the predecessor is untouched and still active, deriving exactly its original three entries. Had the expansion instead been approved, the successor would have activated and the predecessor would have transitioned atomically to superseded. Because it was declined, nothing supersedes anything.

Complete: discharge narrows one entry at a time

Expansion is governed growth. Completion is its narrowing counterpart. It is the more important of the two for everyday safety, because the common case is not a task that needs more authority but a task that is done with some of the authority it has. Like Expansion, it sits on the advanced tier: stable design to adopt when the use case arrives, with expires_at, revocation, and the complete verb as the simpler path until then.

The issuance core’s Mission Intent can carry success_criteria: a description of when the task is complete. In the issuance core those criteria are inert (rendered to the Approver, committed to the record, carrying no machine effect). A Mission granted authority to post journal entries “until the Q3 close is finalized” keeps deriving that authority after the close, until a clock or a revoke intervenes. Mission Completion supplies the enforceable counterpart: terminal_when, an entry-level completion condition. When the condition fires, the entry is discharged. The Authorization Server stops deriving any token carrying it, exactly as it refuses derivation for a non-active Mission.

The crucial scope detail is that discharge gates at the entry, not the Mission. A multi-resource Mission completes one entry at a time. In the running example, suppose the board meeting is not cancelled and the work finishes instead. The Prepare the Q3 board packet Mission has a query_financials read entry, a create_doc write entry, and a notify_reviewer send entry, the write and send entries each bounded terminal_when their step is done (create_doc once the packet is published, notify_reviewer once the audit committee is told). As each condition fires, the Authorization Server stops deriving that entry (a refresh returns a token carrying only what remains) while the Mission stays active so any remaining entry keeps working. Each authority retired itself the moment the task it was granted for completed. No revoke, no clock.

This is distinct from the complete lifecycle verb of the Status profile, and the two should not be blurred. complete is a Mission-level terminal transition to the completed state, driven by an authorized party at the lifecycle endpoint. terminal_when discharge is entry-level. The Mission stays active and keeps deriving its other entries. A deployment that tracks Mission-level completion may move a Mission to completed once all its entries are discharged, but Completion does not require it. One is “the whole task is finished.” The other is “this part of the authority is spent.”

What makes entry-level discharge safe to expose to an adversarial agent is that it is monotonic. Discharge can only remove an entry’s authority. It can never widen the entry or the Mission. So a prompt-injected agent has nothing to gain from it. The worst it can do is spend its own authority sooner, which is not an attack. That single property is why discharge composes cleanly with the subset rule (a derived entry carries its parent’s conditions unchanged and may only add more, making it discharge sooner) and why an Authorization Server that cannot determine whether a condition has fired fails closed, treating the entry as possibly discharged and withholding issuance rather than risking authority for a task that may have ended. Like the kill switch, completion is built so that uncertainty resolves toward less authority, never more.

The rule that makes it safe

The four verbs add three new states to the lifecycle The Mission Is the Missing Abstraction began with. The state diagram now looks like this:

A growing state machine is a liability if every consumer must be upgraded in lockstep to recognize each new state. The Mission lifecycle avoids that with the rule the series framing states as one of its two invariants, and which the Reference’s lifecycle-states section records for the core:

Only active permits reliance. A consumer treats every other value, recognized or not, as non-active.

This is why the new states fail safe. A Resource Server that predates the Status profile has never heard of suspended. When it sees one (in a Status response, in an introspection projection, in a Signals event), it does not need to understand it. It only needs to observe that the value is not active, and refuse. A consumer that predates Expansion treats superseded the same way. The forward-compatibility rule turns “I don’t recognize this state” into “this Mission is not live,” which is precisely the safe interpretation. New lifecycle states therefore extend the system without a flag day.

The one place this “ignore what you don’t recognize” instinct flips is Completion’s terminal_when, and the difference is worth being precise about. A new state value is safe to ignore because an unrecognized state is treated as non-active. Ignoring it fails closed. But terminal_when is a member, not a state, and it is mandatory to understand. It is essential narrowing a consumer cannot infer from the rest of the entry, so ignoring it would let a discharged entry keep being narrowed, projected, or enforced, failing open. A consumer that does not recognize terminal_when therefore MUST fail closed for that entry. It MUST NOT narrow, delegate, audience-project, or rely on it. Unknown state value, treat as non-active. Unknown terminal_when, refuse the entry. Both resolve toward less authority, by opposite handling.

The same instinct runs through every profile in this part, each resolving uncertainty toward less authority:

• Status treats a missing freshness window as “don’t cache” (re-check rather than rely on a stale state).
• Signals treats a missed event as a freshness failure that triggers a fallback poll, never as “still active.”
• Expansion never widens authority without a fresh consent, and supersession is terminal. There is no implicit rollback that resurrects a predecessor’s authority.
• Completion discharges monotonically and withholds issuance when discharge status is unknown.

That is the through-line. The Mission Is the Missing Abstraction made revocation possession-independent. This part makes the current state itself a first-class surface (observable by pull and push, changeable by authorized parties, growable only through fresh approval, and shrinkable safely as work finishes) without ever giving a consumer a way to read uncertainty as permission.

Where this sits in the series

Lifecycle and change is the layer that keeps the Mission true over time. It does not enforce actions. That is Mission-Bound Runtime Enforcement, which consumes the state these profiles expose. Every PDP decision is conditioned on current Mission state, and Status is how the PDP learns it promptly, with Signals accelerating and Completion narrowing what there is to learn. It does not handle fan-out. Mission-Bound Authority covers Child Missions and the cascaded state that Status and Signals forward-reference but do not define. And it does not record the transitions for audit. The Agent Runtime and Audit makes every lifecycle change tamper-evident.

The approval event of The Mission Is the Missing Abstraction and the approval-time integrity of From a Request to an Approved Mission establish what was approved. This part keeps that approval honest as the task runs. A Mission that is revoked stops being relied on, a Mission that grows does so under a fresh approval, and a Mission whose work is done retires its own authority. Observe, revoke, grow, complete. Four verbs that turn a one-time approval into a governed lifecycle.