Network Working Group K. McGuinness Internet-Draft Independent Intended status: Informational 7 August 2026 Expires: 8 February 2027 An Architecture for Mission-Bound Authorization draft-mcguinness-mission-architecture-latest Abstract A Mission is a durable, approval-backed governance object for authorization: the approved task, with a lifecycle, that authority is derived for, bound to, and gated on. It is not a new way to express authority. Read as one system, the Mission model defines a delegated-authority layer: authentication says who is acting, and entitlement governance says what a principal may hold; this layer governs the approved task itself. It exists because the authority an Approver consents to is a capability envelope, not a task script, and the gap between that envelope and what a run actually does is where agent risk lives; the family's mechanisms exist to narrow that gap. This document is the structural view: the object and its invariants, a Mission's life end to end, the roles and substrate, the verb spine the profiles form, the deployment patterns, the assurance levels a deployment claims, and the requirements the family answers. It is Informational: it defines no protocol, object, or requirement, and every mechanism it names is defined by the profile it points to. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://mcguinness.github.io/mission-bound-authorization/draft- mcguinness-mission-architecture.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- mcguinness-mission-architecture/. Source for this draft and an issue tracker can be found at https://github.com/mcguinness/mission-bound-authorization. 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 February 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 2. Status: An Informational Architecture 3. Conventions and Terminology 4. The Mission 5. Non-Goals 6. The Reference Architecture 6.1. The Five Packages 7. The Capability Envelope 8. A Mission's Life 9. Mission Invariants 10. Mission Roles and Components 10.1. The Actor Chain 10.2. Three Objects, Three Lifecycles 10.3. Swarm Execution: Multiplication, Not Delegation 11. The Mission Substrate 11.1. The Mission Identifier and Issuer 11.2. The Lifecycle State Space 11.3. The Authority Set Representation 11.4. The Integrity-Anchor Envelope 11.5. Token Classes 11.6. The Mission-Bound Credential 11.7. Issuer Key Material 11.8. The Audit Horizon 11.9. Approval Fidelity 11.10. The Validity Model 11.11. The Binding Checklist 11.12. Error Surfaces 12. The Authority Derivation Boundary 13. The Ontology Contract 14. The Mission Verbs 14.1. Propose 14.2. Approve and Record 14.3. Govern 14.4. Enforce Each Action 14.5. Run and Wind Down 14.6. Delegate 14.7. Project 14.8. Continue 14.9. Prove 14.10. Analyze 15. Mission Deployment Patterns 15.1. Binding Security Architectures 15.2. Entry Ramps by Estate 16. Mission Assurance Levels 16.1. Assurance Claims 17. The Mission Deployment Profile 18. Prevention, Detection, and Residue 18.1. The Containment Matrix 19. Mission Requirements 19.1. Context and Intent 19.2. Consent and Approval 19.3. Lifecycle 19.4. Delegated, Projected, and Enforced Execution 20. Mission Document Map 21. Security Considerations 22. Privacy Considerations 23. IANA Considerations 24. Informative References Acknowledgments Author's Address 1. Introduction A Mission is a durable governance object created by an explicit approval event: the approved task, with a lifecycle. Authority for the task is derived for the Mission, bound to it, and gated on its state. The Mission is not a new way to express authority: Rich Authorization Requests [RFC9396] and kindred mechanisms express authority, and the Mission is the approved task that authority serves. The object fills a gap current practice pays for daily: an estate that cannot size authority to a task compensates with read-only scoping, a human executing every write, or permanently fenced pilots, and the Mission is the representation those controls substitute for. The model is deliberately decomposed: a core profile (the "issuance profile", [I-D.draft-mcguinness-oauth-mission], here "the core") defines the object and its OAuth 2.0 [RFC6749] binding, a standalone binding hosts the same object without changing an existing Authorization Server ([I-D.draft-mcguinness-mission-authority-server]), an AAuth binding gives that protocol's native mission concept the model's structure and lifecycle ([I-D.draft-mcguinness-mission-aauth]), and optional companions layer approval, lifecycle, enforcement, runtime, delegation, and proof capabilities on top. The decomposition keeps each interface small but spreads the structure across many documents and four bindings; this document is the single structural view. Read as one system, the family defines a *delegated-authority layer*, with OAuth 2.0, the standalone Mission Authority Server, AAuth, and (as an experimental sketch) UMA 2.0 as peer bindings into it (Section 4). It defines no protocol, no object, and no requirement. It is a map, not the territory: every mechanism named points at the profile that normatively defines it, and where this document and a profile appear to differ, the profile governs. 2. Status: An Informational Architecture This document is Informational. It establishes no conformance class and defines no new mechanism, claim, or wire format. Its boundary with the Mission Security Model ([I-D.draft-mcguinness-mission-security-model]) is deliberate: this document describes components, interfaces, and data flows; the security model describes the trusted base and how each component's compromise degrades the guarantees. Each profile's own Security Considerations remain normative over both. 3. Conventions and Terminology Where this document uses words like "must" or "should," they carry their ordinary English meaning and describe what a referenced profile establishes, not a requirement this document places. Terms are the core's ([I-D.draft-mcguinness-oauth-mission]); Policy Enforcement Point (PEP), Policy Decision Point (PDP), and consequential action are the runtime profile's ([I-D.draft-mcguinness-mission-runtime]); Mission Authority Server (MAS) is defined by [I-D.draft-mcguinness-mission-authority-server]; the AAuth binding is defined by [I-D.draft-mcguinness-mission-aauth]. 4. The Mission OAuth 2.0 issues access tokens for individual resource requests; it has no durable, approved artifact for the larger task a client pursues on a user's behalf. That matters for AI agents: given a mission (book the trip, reconcile the ledger), an agent takes many actions across many resources over a long time, spawning sub-agents and surviving restarts, and independently issued tokens cannot express the approved task, its boundary, or its end (the core's Introduction). The family separates the task from the authority. The Mission is the approved task, with a lifecycle; the Authority Set is the concrete authority (resources, actions, constraints) derived for it. A Mission is not another authorization_details type: it is the durable, approval-backed object an Authority Set is derived for and gated by (the core's Why a New Object section). A client proposes a Mission Intent; the Mission Issuer derives an Authority Set for it; an approval event commits both and creates the Mission. The commitment is two integrity anchors, intent_hash over the approved Mission Intent and authority_hash over the consented Authority Set, each computed over a domain-separated, issuer-bound envelope with fixed canonicalization, so an auditor can reproduce either digest from the record alone (the core's Mission Approval, Integrity Anchors, and Canonicalization Rules sections). The record is immutable except for its state (the Mission Record section). The core lifecycle states are active, revoked, and expired, and only active permits issuance or continued reliance. Companions add states (suspended, completed, superseded, cascaded), and one rule keeps that safe without a registry: a consumer treats every state other than the exact value active, including one it does not recognize, as non-active, so an unrecognized state fails safe (the core's Mission Lifecycle and Gating section). The Mission model is the beginning of a distinct layer. Authentication and token issuance answer who is acting and what a single credential carries; governance of standing entitlements answers what a principal should hold over time. Neither governs the approved task a delegate performs on a principal's behalf: its bounded authority, its lifecycle, the per-action check, and the evidence that binds back to it. That is the delegated-authority layer this family defines, composing with the layers below rather than replacing them, and the Mission Authority Server ([I-D.draft-mcguinness-mission-authority-server]) is its binding-independent control plane across an estate, whichever party issues a given token. The control-plane vocabulary is exact, not loose: * the issuer side holds desired state (the record, its authority, its lifecycle and state version), reconciles it (gating, the ceiling review, evidence reconciliation), and distributes bounded authority (policy views, status, the management surface); * tokens and the PEP/PDP boundary are the layer's data plane; and * Status and Signals are the channel between the two. The plane the layer governs is authority, never operations: how an agent runs stays with the harness and the orchestrator. 5. Non-Goals The model's boundary is deliberate. The family does not define: * *A new authority format.* Rich Authorization Requests [RFC9396] and kindred mechanisms already fill that role; the family leaves expressing authority to them (Section 4). * *A policy language.* The PDP evaluates the Mission's Authority Set, constraints, and state; how a deployment authors policy beyond them is local ([I-D.draft-mcguinness-mission-runtime]). * *Entitlement governance.* What standing access a principal should hold over time belongs to existing governance layers; the delegated-authority layer composes with them (Section 4). * *Agent identity and deployment governance.* Who the agent is, its concrete instance, and its approved behavioral version belong to the deployment's agent IAM and change governance; the family authenticates against and consumes those facts without defining them (Section 10.2). * *An agent framework.* The harness constrains the execution environment's relationship to Mission state; it does not say how an agent plans, reasons, or calls tools ([I-D.draft-mcguinness-mission-harness]). * *Semantic derivation.* Whether a derived Authority Set is the right reading of the task is committed and auditable, not standardized (Section 12). * *Agent trustworthiness.* The family bounds what a compromised or injected agent can do; it does not make the agent trustworthy ([I-D.draft-mcguinness-mission-security-model]). 6. The Reference Architecture The family is a menu, but a reader should meet it as a meal. Four stacks, each containing the previous, are the shapes deployments actually take, and the second is the reference: *Protocol core*: the issuance profile alone: the standardizable primitive (approved, anchored, state-gated Missions), Mission- substrate conformance (Section 19), no per-action control. *Reference security architecture*: core plus runtime enforcement, its AuthZEN binding, and a freshness source (the Runtime-Enforced level, Section 16). This is the architecture this document means when it says a Mission is enforced, and the one an evaluation should picture by default. *Recommended agent architecture*: the reference architecture plus Consent Evidence and the harness (the Governed Agent level): what a deployment running autonomous AI agents should build. *High-assurance architecture*: the recommended architecture plus mediated custody, no unmediated path, action-bound approval, active freshness, and agent-isolated approval rendering (the High- Assurance Agent level). 6.1. The Five Packages Independent of how the drafts are cut for standardization, the system decomposes into five architecture packages; the document map (Section 20) names every draft, and each belongs to one package: 1. *Mission Control*: the object, approval (including deferred and revision), lifecycle, status and signals, expansion, completion, management. 2. *Authority Distribution*: the four issuer bindings, the issuance grant, cross-domain projection, child delegation, offline attenuation. 3. *Runtime Enforcement*: the runtime contract, the AuthZEN binding, parameter binding, custody, metering. 4. *Agent Execution Governance*: the harness, orchestration, shaping, discovery. 5. *Evidence and Accountability*: consent evidence, the Mandate, audit transparency, and the decision and execution evidence the runtime package produces. A product architect deploys packages; a standards reviewer reads drafts; the two views name the same system. 7. The Capability Envelope One tension organizes the whole family. A Mission commits its authority and intent once, at approval, but an agent's work is open- ended: the actions a task will take are not known when it is approved. "Reconcile Q3 invoices" must authorize reading any invoice and posting any adjustment under the cap, because the specific ones cannot be enumerated in advance. So the Authority Set an Approver consents to is a *capability envelope, not a task specification*, and the gap between that envelope and what a given run actually does is where agent risk lives. The family's mechanisms are levers that narrow that gap: * constraint-bounding and the subset rule shrink the envelope at issuance; * runtime enforcement checks each action against it at the point of use; * action-bound approval re-consents the highest-consequence actions with their concrete parameters; * progressive authorization trades many increment approvals for one bounded ceiling; * metering caps cumulative consumption; and * completion retires authority as the task finishes. No single lever closes the gap; a deployment composes the ones its risk warrants (Section 16), and the verbs of Section 14 organize the levers by the question each answers. The levers share one strategy: they convert semantic risk into structural signals. A policy decision point is never asked to judge whether content is harmful; provenance (the harness taint context), composition (the quarantine pattern), egress enumeration and volume bounds, separation of duty, and re-consent turn that question into facts a decision can gate on. A content evaluator a deployment adds composes as Resource policy at the decision point and only ever narrows. The stance beneath the levers is *survivable incorrectness*: the agent is probabilistic, so the family never bets on the model being right and builds so that wrong is survivable, on two arms. The action arm is this envelope and its levers, wire-backed, with in- flight work unwinding through recorded reversibility classes ([I-D.draft-mcguinness-mission-orchestration]). The input arm is *least exposure*: everything the agent sees can steer it and everything it holds can leak, so a Mission budgets disclosure as well as authority, and mediated custody generalizes from credentials to context. The arms differ in maturity, and the difference is stated rather than blurred: the exposure arm's enforceable edges are the harness taint rule, egress mediation, and catalog filtering ([I-D.draft-mcguinness-mission-harness], [I-D.draft-mcguinness-mission-runtime], [I-D.draft-mcguinness-mission-authzen]), while its interior, retrieval, memory, and context assembly scoped to the Mission, has no interoperable form yet and is deployment discipline, declared in the Deployment Profile (Section 17) rather than claimed. The envelope meets its hardest case in the open world. The family inherits OAuth's ontology, authority client-proposed and enumerated at approval; an agent that discovers resources at encounter time breaks that premise, and some substrates invert it outright: the resource declares its own operations and consequences, and that declaration is the semantic material approval needs (the AAuth binding composes one such substrate, [I-D.draft-mcguinness-mission-aauth]). Who owns meaning, and how it reaches derivation, consent, and enforcement, is stated once as the ontology contract (Section 13). Where the resource self-declares, the declaration's digest is committed with the binding evidence: a third commitment beside intent_hash and authority_hash, recording what the resource claimed to be at the moment authority bound to it. The rest of the encounter, its routing through drawdown, catalog binding, projection, or fresh approval, and its identity pinning and floors, is the discovery companion's contract ([I-D.draft-mcguinness-mission-discovery]). 8. A Mission's Life The structure is easiest to see by following one Mission end to end under the OAuth binding: an operator gives an agent the task "reconcile Q3 invoices." 1. *Propose.* The client shapes the request into a structured Mission Intent, untrusted by construction, and submits it in a Pushed Authorization Request [RFC9126] ([I-D.draft-mcguinness-mission-shaping]; the core). 2. *Approve and record.* The Authorization Server derives an Authority Set (read invoices, post adjustments under a cap), discloses it, and the Approver approves. The approval event commits intent_hash and authority_hash and creates the Mission, active with an expiry; Consent Evidence commits what was shown ([I-D.draft-mcguinness-oauth-mission-consent-evidence]). 3. *Issue.* Tokens are derived under the subset rule, carry the mission claim, and derivation and refresh are refused once the Mission leaves active (the core). 4. *Enforce.* Before each consequential action (posting an adjustment), the PEP obtains a PDP permit bound to the action's concrete parameters and to current Mission state ([I-D.draft-mcguinness-mission-runtime], [I-D.draft-mcguinness-mission-authzen]). 5. *Delegate.* A sub-agent that verifies ledger entries receives a child Mission with strictly narrower authority and lineage ([I-D.draft-mcguinness-oauth-mission-child-delegation]). 6. *Govern.* Consumers observe state through Status and Signals; growth requires an approved successor ([I-D.draft-mcguinness-oauth-mission-expansion]), and entries retire as their work completes ([I-D.draft-mcguinness-oauth-mission-status]). 7. *Stop.* Revocation or expiry turns every gate at once: issuance refuses, the PDP denies, the harness pauses bound sessions and queues, and the orchestrator unwinds in-flight work ([I-D.draft-mcguinness-mission-harness], [I-D.draft-mcguinness-mission-orchestration]). 8. *Prove.* The record, anchors, evidence, and receipts let an auditor reconstruct what was approved, shown, decided, and done, and a Mandate carries the committed facts to parties outside the deployment ([I-D.draft-mcguinness-mission-mandate], [I-D.draft-mcguinness-mission-audit]). The approval-to-permit path in sequence: Approver Agent AS PEP/PDP RS | | | | | | | 1 Mission | | | | | Intent (PAR) | | | | |---------------->| | | | 2 disclose and approve | | | |<--------------------------->| | | | | Mission active:| | | | | intent_hash, | | | | | authority_hash | | | | | 3 Mission-bound | | | | | token | | | | |<----------------| | | | | 4 action, token, parameters | | | |------------------------------>| | | | | 5 state and | | | | | authority | | | | |<----------->| | | | | | 6 permit, | | | | | evidence | | | 7 permitted action executes |----------->| Under the standalone binding the same life runs with ordinary tokens and the Mission Join in place of step 3's claim carriage (Section 15); under the AAuth binding the Person Server plays the AS role for its native missions. 9. Mission Invariants Seven invariants hold across every profile and binding; each is stated normatively by its home document and consumed everywhere else. A change that would break one is a change to the model, not to a profile. *Authority serves an approved task*: No Mission-bound authority exists except by derivation for a Mission, and a Mission is created only by an explicit approval event that commits intent_hash and authority_hash (the core). Fields an agent can influence shape authority only through the pre-approval derivation the Approver consents to; once the Mission is approved they are inert and never derive, widen, or gate authority. *Only active permits*: Issuance, refresh, and reliance require the exact state active; every other state, including an unrecognized one, fails safe (the core's Mission Lifecycle and Gating section). *Authority only narrows*: Derived tokens, delegated child Missions, attenuated tokens, and cross-domain projections carry subsets; widening exists only as an approved successor: a fresh approval ([I-D.draft-mcguinness-oauth-mission-expansion]), or policy drawdown within a ceiling a human pre-consented ([I-D.draft-mcguinness-oauth-mission-progressive]). *Revocation is possession-independent*: A Mission ends by a state change at its issuer, not by finding and destroying credentials; outstanding credentials meet the issuance gate, the runtime re- check, or their own expiry, whichever comes first (Section 11.10). *Attribution is carried, never inferred*: Each role in the actor chain travels in its own construct, and the evidence layer records them together; no role is derived from another (Section 10.1). This invariant scopes the actor chain. The credential-to-Mission association is itself a carried fact only where a binding carries the mission claim; under the standalone binding the PDP's join establishes it by inference, bounded by that binding's join assurance (Section 15). *Enforcement fails closed; inert surfaces fail safe*: A PDP that cannot establish state or authority within the published staleness bound denies, and a consumer that cannot refresh state treats its cache as unreliable rather than as permission ([I-D.draft-mcguinness-mission-runtime]). *Anchors commit; they do not prove semantics*: The integrity anchors prove what was approved and committed, not that the derivation was the right reading of the task (Section 12). Read substrate-neutrally, the invariants carry the five laws the companion handbook names for the layer: durability, attribution, narrowing, termination, and containment. 10. Mission Roles and Components For each component: what it does, what it holds, and which document specifies it. What its compromise costs is the security model's subject ([I-D.draft-mcguinness-mission-security-model]). Agent (client): Proposes the Mission Intent and executes the task; in the OAuth binding it holds derived Mission-bound tokens; outside the trusted base and assumed compromisable ([I-D.draft-mcguinness-oauth-mission]). A deployment may authenticate concrete agent instances under the client-instance-assertion profile and its AI-agent profile ([I-D.draft-mcguinness-oauth-client-instance-assertion], [I-D.draft-mcguinness-oauth-ai-agent-instance]), which sharpens delegation chains, joins, and evidence attribution to instance granularity without touching the Mission model. Subject: The user or system on whose behalf the Mission is approved, an (iss, sub) pair recorded immutably at approval (the core). Approver: The single accountable principal who approves the Mission; equal to the Subject for self-approval (the core's Single Accountable Approver section). Mission Issuer: Validates the Mission Intent, runs the approval event, records the Mission, and owns its state. Four bindings host it: * OAuth Authorization Server: every derived token carries the mission claim, and issuance and refresh are gated on Mission state ([I-D.draft-mcguinness-oauth-mission]). * Mission Authority Server: the same record, anchors, and lifecycle without issuing tokens; the PDP joins ordinary credentials to the Mission at the point of use ([I-D.draft-mcguinness-mission-authority-server]). * AAuth Person Server: the mission blob carries the record under AAuth's s256 commitment, and the Person Server issues or gates every auth token, so issuance gating holds ([I-D.draft-mcguinness-mission-aauth]). * UMA 2.0 Authorization Server (experimental sketch): the pushed Mission Intent rides UMA claims pushing, the resource owner's decision fills UMA's authorization assessment, and RPT issuance is gated on state ([I-D.draft-mcguinness-mission-uma]). Under every binding the Issuer also serves audience-scoped policy views, the authority-distribution artifact the runtime and MAS profiles define ([I-D.draft-mcguinness-mission-runtime], [I-D.draft-mcguinness-mission-authority-server]). Resource Server: The protected resource. In the OAuth binding it enforces statelessly from the token and can check the mission claim (the core's Resource Server Enforcement section); in the standalone binding the token carries no Mission signal, and Mission properties reach it only through the enforcement path. PEP and PDP: The PEP sits at the last controllable boundary before an action and obtains a permit for each consequential action; under mediated custody it, not the agent, holds the sender- constraint key. The PDP evaluates the action against the Mission's authority, constraints, actor chain, and current state, and fails closed ([I-D.draft-mcguinness-mission-runtime], [I-D.draft-mcguinness-mission-authzen]); in the standalone binding it also verifies the subject and client join (the MAS's Mission Join section). Agent harness: Hosts the agent; binds sessions, task graphs, queues, cached tool connections, and sub-agent handles to Mission state; establishes the environment with no unmediated path to mediated actions ([I-D.draft-mcguinness-mission-harness]). Orchestrator: Assigns each workflow step a reversibility class, records an unwind plan before dispatch, and compensates in-flight work when a Mission stops ([I-D.draft-mcguinness-mission-orchestration]). Transparency Service: An append-only SCITT log [RFC9943] that registers Mission evidence as Signed Statements and issues receipts verifiable offline ([I-D.draft-mcguinness-mission-audit]). Verifiers: Parties outside the deployment that check Mission facts without a token exchange: Mandate verifiers confirm what was approved ([I-D.draft-mcguinness-mission-mandate]); evidence consumers check consent, decision, and execution evidence against the anchors and receipts ([I-D.draft-mcguinness-oauth-mission-consent-evidence], [I-D.draft-mcguinness-mission-authzen]). The bindings converge on one object, and enforcement draws on it regardless of binding: Subject Approver \ | \ approval event \ | +-------------------------------------------------------------+ | Mission Issuer | | +------------+ +------------+ +------------+ +------------+ | | | OAuth AS: | | Standalone | | AAuth PS: | | UMA 2.0 AS | | | | Mission- | | MAS: no | | native | | (sketch): | | | | bound | | tokens; | | missions; | | pushed | | | | tokens | | the PDP | | auth | | Intent; | | | | gated on | | joins to | | tokens | | RPTs gated | | | | state | | Mission | | gated | | on state | | | +------------+ +------------+ +------------+ +------------+ | +-------|--------------|--------------|--------------|--------+ v v v v the Mission: intent_hash, authority_hash, lifecycle state | | state and authority (claim, | introspection, Status, Signals) v Agent ------> PEP ----------> PDP (harness, | <- permit - orchestrator) v Resource Server Grouped as planes rather than parts, the same components form the delegated-authority layer of Section 4, with the evidence surface crossing all of them: control Mission Issuer (OAuth AS | MAS | AAuth PS): record, anchors, lifecycle, status, authority distribution, management | ^ | state, authority | evidence v | enforcement PEP and PDP: a permit per consequential action, parameter binding, custody | ^ | mediated actions | outcomes v | execution harness, agent, orchestrator: sessions, sub-agents, queues, unwinding evidence Consent Evidence, decision and execution (crossing) evidence, Mission Receipts, the Mandate, audit transparency 10.1. The Actor Chain One material action splits across these roles, and the family keeps each distinct and attributable rather than collapsing them into one "agent" identity: Principal: the Subject, the token sub (the core). Accountable approver: the Approver, committed at the approval event (the core). Intent generator: the shaper, with Shaping Evidence recording what it emitted ([I-D.draft-mcguinness-mission-shaping]). Authorizer: the Mission Issuer at issuance (the core); the PDP per action ([I-D.draft-mcguinness-mission-runtime]). Approved agent: the OAuth client, client_id on every derived token (the core). Executing delegate: the outermost act actor (the core's Delegation section). Credential holder: the mediating PEP under mediated custody ([I-D.draft-mcguinness-mission-runtime]). Capability executor: the executor of the capability source binding ([I-D.draft-mcguinness-mission-authzen]). Downstream identity: the audience-scoped token and the cross-domain local subject ([I-D.draft-mcguinness-oauth-mission-cross-domain]). Attribution survives because no role is inferred from another: each is carried by its own construct, and the evidence layer records them together, in runtime evidence and the Mission Receipt ([I-D.draft-mcguinness-mission-runtime]), Consent Evidence, and the audit feed. The chain is actor lineage, not authority lineage. An act chain records who acted through whom; it does not carry what task was approved, how authority narrowed at each derivation, whether the task remains active, or which parameter constraints bind. Those travel in the Mission's own constructs: the anchors, the Authority Set, the lifecycle state, and Child Mission lineage ([I-D.draft-mcguinness-oauth-mission-child-delegation]). Reading an actor chain as authorization provenance is the gap the Mission's lineage exists to close. 10.2. Three Objects, Three Lifecycles A deployment that runs agents under both an agent identity system and this family governs three distinct objects. Each has its own owner, lifecycle, and revocation, and the model stays clean only while none absorbs another's job: Agent identity (who is acting): The logical agent and, where the instance profiles are deployed, the concrete instance (Section 10). Owned by the deployment's agent IAM, a registry or directory outside this family, and consumed as the client_id, the instance assertion, and verified instance claims. Agent Deployment (what is running): The approved behavioral version of the agent: its code, model, system prompt, tool allowlist, data scope, and runtime configuration. Owned by the deployment's change governance; a change to any of these is a new Agent Deployment, and which changes require re-approving standing Missions is policy that governance records. A Mission may be pinned to a named Agent Deployment where the deployment defines that control. This object is distinct from the Mission Deployment Profile (Section 17), which is the estate's published claims manifest, not a property of an agent. Mission (why the authority exists): This family's object: the approved task, its Authority Set, and its lifecycle. An agent registry is a complementary dependency, not part of the Mission system. Where one exists, the Mission Issuer and the PDP consume a small, stable slice of it: * the agent identifier and its owner, * current status and revocation state, * the approved Agent Deployment, * eligibility bounds (what the registry permits the agent to be approved for, a derivation input, never a grant), and * risk tier. Registry state is a state source like any other: the consuming decision point treats it under the runtime profile's freshness discipline, with a declared staleness bound, failing closed when it cannot be established ([I-D.draft-mcguinness-mission-runtime]). Authorization composes conjunctively across the three lifecycles: a decision may depend on agent state, Mission state, and credential validity, and each gates independently. A valid credential never overrides a revoked agent or a non-active Mission, and a live agent under an active Mission still fails on an expired credential. The assurance levels add binding strength in the same order a deployment adds it: authority is issued to an authenticated client; instance assertion pins the concrete instance; sender-constraint keys pin possession; attested runtimes pin the execution environment; and an Agent Deployment pin holds the behavioral version (Section 16). The division of labor with agent IAM is one sentence: agent identity preserves who is acting, and the Mission preserves why their authority exists. The registry and workload identity authenticate an approved agent instance; the Mission and its derived Authority Set say what sanctioned work that instance carries; per-hop credentials narrow; the runtime layer enforces each action and parameter; and the evidence layer joins what was approved, decided, and done. 10.3. Swarm Execution: Multiplication, Not Delegation One composition of the three objects recurs often enough to name. A Mission pinned to an Agent Deployment through the core's controls.agent_deployment ([I-D.draft-mcguinness-oauth-mission]), executed concurrently by N attested instances of that Deployment, is multiplication, not delegation: no act hop, no Child Mission, no attenuation chain, because authority never moves between principals. Late binding is attestation: an instance joins the work by authenticating as the pinned Deployment under the instance profiles ([I-D.draft-mcguinness-oauth-client-instance-assertion], [I-D.draft-mcguinness-oauth-ai-agent-instance]), not by receiving a credential from a peer. The invariant is class-grain authorization, instance-grain attribution: the class, the Agent Deployment projected as client_id, is an authorization subject, never an attribution subject, and attribution stays per-instance through the instance substrate, which forbids a sender-constraint key shared across a client's instances. The core's controls.max_derivations is the explicit fan-out ceiling, and consumption bounds attach at Mission grain, so a swarm shares one budget ([I-D.draft-mcguinness-mission-metering]). The decision ladder: * The same principal exercising the same authority concurrently is the swarm: more attested instances of the pinned Deployment deriving under one Mission, no new construct. * A different principal acting inline is a delegated token with an act hop (the core's Delegation Within a Mission section). * A durable sub-agent needing its own lifecycle, approval, or audit identity is a Child Mission ([I-D.draft-mcguinness-oauth-mission-child-delegation]). * Offline narrowing is attenuation ([I-D.draft-mcguinness-oauth-mission-attenuation]). 11. The Mission Substrate The companion profiles named without "oauth" are defined against the Mission model's substrate primitives rather than against OAuth mechanics; each names what it consumes in a Mission Substrate section of its own. This section consolidates that interface: eight primitives, each with its normative home and its consumers. Every sentence mirrors a rule the named profile states normatively. 11.1. The Mission Identifier and Issuer An opaque, non-reused Mission Identifier with at least 128 bits of entropy and no semantic content, plus issuer, the issuer URL of the approving Mission Issuer; together they name exactly one Mission. Home: the core's Mission Record and Mission Identifier Format sections. Consumed by every companion: enforcement decisions, evidence, harness bindings, the state surfaces, the audit statement subject, and the Mandate all key on it. 11.2. The Lifecycle State Space The states of Section 4, open to companion-defined states, with the only-active rule, fail-safe unrecognized states, and a freshness source with a stated staleness bound. Home: the state space and the only-active rule are the core's (its Mission Lifecycle and Gating section); the freshness mechanisms and staleness bounds are the status and runtime profiles'; Status and Signals add the observation surfaces. Consumed by the runtime layer (per-class re-check, fail closed on staleness), the harness (pause, suppress, terminate), the orchestrator (the unwind trigger), and the Mandate (state only as of minting). 11.3. The Authority Set Representation An array of authorization details entries ([RFC9396] in the OAuth binding), each naming a resource, actions, and constraints, governed by the subset rule (derived or delegated authority is never broader) and the Common Constraints vocabulary (registered names with fixed subset and intersection rules). Home: the core's Mission Authority section, with its Subset Rule and Common Constraints subsections. Consumed by the runtime layer and AuthZEN binding (evaluation), the MAS (served to the PDP), Expansion and Completion (growth and retirement), Child Delegation and Offline Attenuation (narrowing), Consent Evidence (rendering), and the Mandate (optional carriage). 11.4. The Integrity-Anchor Envelope A committed object is hashed over an envelope domain-separated by typ and issuer-bound by iss, canonicalized by fixed rules, and encoded with an algorithm prefix a verifier recognizes or rejects; the typ space is an extension point for new committed objects. These are *commitment anchors*, not enforcement proofs (Section 12): a narrowed-token Resource Server enforces the authority it receives rather than reconstructing authority from a hash of a full set it does not hold ([I-D.draft-mcguinness-mission-security-model]). Home: the core's Integrity Anchors and Canonicalization Rules sections, with the extension rule in its Extensibility section. Consumed by Consent Evidence (consent_rendering_hash), Shaping (Shaping Evidence), the runtime layer and AuthZEN binding (mission- policy-view), Orchestration (unwind_plan_hash), the Mandate (the encoded digest form), and Audit Transparency (the committed evidence types it registers). 11.5. Token Classes "Mission-bound" is a specific claim. This document names three token shapes descriptively, so a weak one is not read as the strong one; the names below are this document's own, and the properties the strong class requires are the core's: * a *Mission-referenced token* carries a Mission identifier only; * a *Mission-derived token* carries authority derived from an active Mission; and * a *Mission-bound token* is Mission-derived and additionally active-state gated, subset-constrained, and refresh-gated, the properties the core's conformance rule requires. Only the third earns the term: a mission claim alone is a reference, not Mission-bound authorization. The family reserves "Mission-bound" for that class. 11.6. The Mission-Bound Credential A credential carrying the mission claim (id, issuer, authority_hash) and Mission-derived authorization details, issued only while the Mission is active. Home: the core's Mission-Bound Access Tokens and The Mission Claim sections. This is the binding-dependent primitive, and it is exactly where the bindings split. The OAuth and AAuth bindings provide it (the AAuth auth token carries the mission claim under per-request signature coverage, [I-D.draft-mcguinness-mission-aauth]); the standalone binding does not: the MAS's Mission Substrate section states that a MAS provides every other primitive unchanged and provides neither this credential nor issuance gating ([I-D.draft-mcguinness-mission-authority-server]). The seam is the runtime profile's Mission binding establishment step ([I-D.draft-mcguinness-mission-runtime]): the credential carries the Mission reference where the binding provides one, and a binding without it supplies an externally established reference, verified under a join the binding defines, which the MAS profiles as its Mission Join. Offline Attenuation attenuates this credential and the token-carriage aspects of delegation ride it, so both require it; the companions that need a credential-to-Mission association (the runtime layer and the harness) route through the binding establishment step, which is what makes the standalone binding possible. The issuance-grant companion ([I-D.draft-mcguinness-oauth-mission-issuance-grant]) composes the two: the standalone Mission Issuer mints a Mission Issuance Grant that a consuming Authorization Server redeems for Mission-bound tokens, providing this primitive compositely. 11.7. Issuer Key Material The Mission Issuer's signing keys, resolvable from the issuer by the verifiers of its signed artifacts; across a rotation each key identifier's verification key stays resolvable while artifacts signed under it remain within the audit horizon. Home: the core's Signing and Key Rotation section. Consumed by the verifiers of Mission-bound credentials under full provision, Consent Evidence, the Mandate, the signed state surfaces, and Audit Transparency. 11.8. The Audit Horizon The deployment-declared retention window for the Mission record and its evidence: at least the Mission's lifetime plus a declared post- terminal period. Home: the core's Mission Record section. Consumed by Consent Evidence, runtime evidence, and Audit Transparency for retention; by the MAS for record retention; and by the security model's retention analysis. 11.9. Approval Fidelity The approval event's fidelity: whatever a binding's native ceremony, it authenticates the Approver, establishes the Subject, derives and renders the Authority Set for consent, computes the anchors over the consented set and the approved Intent, and creates the record in active atomically with the decision. Home: the core's Mission Approval section. Consumed by Consent Evidence, which binds to this event, and by every downstream guarantee that assumes the anchors, the gating, and the record. 11.10. The Validity Model Five validity horizons govern reliance, each with its own setter, checker, and consequence; implementations most often err by conflating them: Token exp: set by the issuer AS, capped by the Mission's expires_at; checked by every consumer of the token. Past it the credential is dead and refresh re-enters the issuance gate. Mission state and expires_at: set by the Mission Issuer; checked at the issuance gate, by the PDP, and by state consumers. Off active, derivation stops and consequential actions refuse. fresh_until: set by the status responder; checked by status consumers. Past it a cached state report may not be relied on and is re-fetched. Permit window: set by the PDP; checked by the executing PEP. Past it the permit is void and a new decision is required. Action-approval freshness: set by the approval surface; checked by the PDP. Past it an action-bound approval no longer authorizes the action it named. The horizons compose by minimum: reliance at any moment requires every applicable horizon to be open, and no horizon substitutes for another. The horizons also give the deployment its freshness dial, and the TTL-only end of that dial is a first-class posture, not a fallback. A deployment that relies on lifetimes alone verifies with local cryptography and a clock: no state source, no freshness discipline, no availability coupling, and a worst-case exposure equal to the lifetime by construction. That posture is the right choice at action grain, where an artifact lives seconds to minutes and no revocation can land inside its window, and for short missions; the family's own short-lived artifacts (the permit, the cross-domain grant, the Join Assertion) already sit at this end. What a lifetime cannot do is suspend, complete, or kill now, which is the task-grain residue the Mission's state carries. The two ends are one mechanism seen from opposite sides: a lifetime relocates the freshness check from the verification path to the issuance path, so every re-issuance is the policy re-check, which is the family's gates-new-derivation-only rule in its other reading. A deployment states where it sits on the dial through its bounded-revocation claim (Section 16.1): a TTL-only posture claims the lifetime as its bound, honestly and with no state surface. The runtime profile prices each position, source by source, in its state and freshness section ([I-D.draft-mcguinness-mission-runtime]). 11.11. The Binding Checklist For a new binding this checklist is now normatively stated by Mission Substrate Requirements ([I-D.draft-mcguinness-mission-substrate]); this section remains the informative summary, and the existing bindings remain authoritative for themselves. Another mission-based protocol hosts the substrate-neutral profiles unchanged when it satisfies Mission Substrate Requirements ([I-D.draft-mcguinness-mission-substrate]), whose contract is the primitives above: * the identifier and issuer, * the state space and only-active rule, * the Authority Set and subset rule, * the anchor envelope, * the audit horizon, * resolvable issuer keys, and * approval fidelity, with the Mission-bound credential optional (a substrate that omits it composes as the standalone binding does). The per-profile Mission Substrate sections remain the authoritative per-consumer statements of this interface. 11.12. Error Surfaces The family has three error surfaces, each owned once. OAuth endpoints return OAuth error codes, owned by the core ([I-D.draft-mcguinness-oauth-mission]). Lifecycle surfaces, including management, return the status profile's JSON error body (error, error_description, nonce) ([I-D.draft-mcguinness-oauth-mission-status], [I-D.draft-mcguinness-oauth-mission-management]). MAS-native surfaces return the MAS error object, which adds error_reason and omits the nonce ([I-D.draft-mcguinness-mission-authority-server]). AuthZEN denial reasons are not a fourth surface: they ride the decision response ([I-D.draft-mcguinness-mission-authzen]). Where the same symbol exists as both an OAuth error code and a wire-body symbol (invalid_request), the envelope it arrives in disambiguates. Registration posture is likewise deliberate per artifact class: OAuth-facing parameters and media types register with IANA, evidence media types defer registration until cross-domain interoperability demands it, and each profile states which posture it takes. 12. The Authority Derivation Boundary Deriving the Authority Set from the Mission Intent is the semantic heart of the model and the one step the family deliberately does not standardize. The consequence is a trust boundary worth stating plainly: interoperability begins at the committed result, not at the Intent. A Mission Intent has no portable semantics; two conforming Authorization Servers can derive different Authority Sets from the same Intent, and audit can establish what was derived (against intent_hash and policy_version), never whether it was the right reading of the task. A deployment whose partners must reason about its derivations can publish a derivation policy identifier and test fixtures that pin Intent-to-Authority-Set outcomes, making the local policy reviewable even though it does not travel. Narrowing mode ([I-D.draft-mcguinness-oauth-mission]) is the checkable path: where the client supplies candidate authority, derivation is a subset of it and reproducible, which is the closest the family comes to portable derivation. The ceiling the derivation narrows against is itself a composition, not a single object. The derived Authority Set sits inside every authority source that bounds the task: the issuer's derivation policy, the Approver's own authority (an approval grants nothing the Approver could not grant), and, at enforcement time, the resource owner's and deployment's live policy at the decision point. The derivation step intersects the first two and commits the result; the runtime contract re-checks the rest on every action, which is why a permit is never implied by the Authority Set alone. A deployment adding further sources (a tenant boundary, an environment-specific floor) adds them as derivation-policy inputs or as decision-point policy, never as agent-negotiated widening. The derivation modes rank by how portable their result is: +==========================+=================================+ | Derivation mode | Portability status | +==========================+=================================+ | Client proposes concrete | Interoperable default | | authority; AS narrows | | +--------------------------+---------------------------------+ | AS derives from | Profile-specific | | structured Intent fields | | +--------------------------+---------------------------------+ | AS derives from free | Local, non-portable unless | | text | profiled | +--------------------------+---------------------------------+ | LLM-assisted derivation | Advisory unless a deterministic | | | policy commits the output | +--------------------------+---------------------------------+ Table 1 A deployment seeking interoperable authority uses the first; free- text and model-assisted derivation are local policy unless a profile pins them with a published policy identifier, version, and test fixtures. 13. The Ontology Contract The derivation boundary settles who commits authority; this section settles who owns what an operation means. The ownership statement is one sentence: the resource owns the ontology, its operations, its constraint semantics, and their consequences, while derivation, consent rendering, and enforcement consume that meaning without owning it, and no layer invents meaning it does not own. The consuming contract is equally short: meaning binds at approval, is enforced at the point of use, and any translation between the resource's vocabulary and another party's is trusted, verified, or separately approved, never a place where authority widens (Section 11.9). Resource-owned meaning reaches the three consuming layers through five mechanisms, each normative in its own home and composing as one contract: Common Constraints: The registered constraint vocabulary every conforming party evaluates identically, with the mission_constraints_supported protected-resource metadata member advertising which constraints a resource enforces. Home: the issuance profile ([I-D.draft-mcguinness-oauth-mission]). Capability-source binding: Catalog-sourced capability definitions (an MCP tool, an OpenAPI operation) content-digested at derivation and refused on drift at decision time, so the meaning authority bound to is the meaning enforced. Home: the AuthZEN binding ([I-D.draft-mcguinness-mission-authzen]). Operation Profiles: The per-operation statement of normalization and binding rules, carrying resource-declared operation semantics such as idempotency, reversibility, and lease requirements into parameter binding. Home: the runtime profile ([I-D.draft-mcguinness-mission-runtime]). The encounter contract: What is submitted, adjudicated, and recorded when an agent meets a resource the approval could not enumerate, so meaning that arrives late still binds before use. Home: the discovery companion ([I-D.draft-mcguinness-mission-discovery]). Resource-Declared Semantics: The full inversion: the resource publishes its operations, their human meaning, and their consequences, content-addressed by r3_s256 as a third commitment beside intent_hash and authority_hash, and consent composes the resource's own words. The declaration is not consent material alone; it returns to authority. The declared operations are the candidate vocabulary derivation narrows against, the issuer adjudicates the encounter against the Mission's Authority Set or a pre-consented ceiling, and the derived authority records the declaration's digest, so the Authority Set remembers which version of the resource's meaning it was derived under and enforcement refuses on declaration drift. Home: the AAuth binding, informative ([I-D.draft-mcguinness-mission-aauth]). Behind the five mechanisms sits one direction axis, and the direction is chosen per encounter, not fixed by binding. The family inherits OAuth's client-proposed default: the client names the authority it wants and the resource's meaning arrives through metadata, catalogs, and profiles (Section 7). Resource-Declared Semantics is the inversion, where the resource speaks first and approval consumes its declaration, and it is valid under every binding: the fundamentals, meaning bound at approval, enforced at use, translation never widening, hold in both directions. Under the OAuth binding the resource-declared direction runs entirely through seams the family already has: the encounter contract routes the declaration ([I-D.draft-mcguinness-mission-discovery]), narrowing-mode derivation consumes the declared operations as candidate vocabulary ([I-D.draft-mcguinness-oauth-mission]), consent composes the resource-authored material, and the declaration's digest rides the derived authority (the progressive companion's resource_declaration_digest, [I-D.draft-mcguinness-oauth-mission-progressive]). The AAuth binding's R3 composition is the worked example of the full inversion, not its only home. Proposed RAR-type metadata ([I-D.draft-zehavi-oauth-rar-metadata]), a resource publishing the authorization_details types and fields it understands, is the OAuth- native descriptive surface the direction builds on. Both directions close the same loop: the meaning source's digest becomes part of the derived authority. A catalog-sourced capability pins its source_digest; a resource declaration pins r3_s256; in each case the Authority Set carries the version of the meaning it was derived under, and the point of use compares against the meaning in force. Meaning is not consulted at approval and assumed at enforcement; it is committed at approval and re-verified at use. The contract's failure mode is already normative in each home: a consumer that cannot resolve an operation's meaning, a constraint it cannot evaluate, a drifted capability definition, an unrecognized declaration, refuses rather than guesses. Meaning, like state, fails closed. The contract has a dual, and the two statements carry equal force. The resource owns what an action means; the Mission owns why it is happening and where the undertaking stands, and that context exists nowhere else in the stack. A resource evaluates each request at perfect local resolution and zero task resolution: it can price every consequence its ontology names and cannot see the undertaking the request belongs to. This is the context asymmetry, and a risk decision composes both sides of it: semantics without purpose prices every delete the same, and purpose without semantics cannot read the call. "Delete database" in isolation is indistinguishable from catastrophe. "Delete database" inside an approved migration whose copy steps already completed is a priced, checkable step. The only place that judgment is possible is where Decision and Execution Evidence join on the Mission's identity, because that join is the undertaking's recorded history and no resource-local view contains it. The runtime profile names the mechanism: sequence-aware evaluation over the undertaking's history is an optional decision input, guarded so that history informs a decision and never widens one ([I-D.draft-mcguinness-mission-runtime]). 14. The Mission Verbs The family organizes along a verb spine: each verb answers one question, sits on one trust boundary, and is owned by named documents; the levers of Section 7 sort onto this spine by the question each answers. propose Intent Shaping (client side, untrusted) | approve Mission Issuer: the OAuth AS, Mission and record Authority Server, or AAuth Person Server binding (+ Consent Evidence, Deferred Approval) | the Mission: intent_hash, authority_hash, lifecycle state | govern Status (pull), Signals (push), Expansion (widen), Completion (retire) | enforce Runtime contract -> AuthZEN binding: each action a PDP permit before every consequential action | run and Harness (continuity is not authority), wind down Orchestration (unwind in-flight work) delegate Child Delegation, Offline Attenuation project Cross-Domain Projection (a Mission honored in another trust domain) continue Mission Continuation (authorization continuity over ICA, async delegation, and cross-domain transports) prove Consent Evidence, Mandate, Audit analyze Security Model (the trusted base) 14.1. Propose The question: how does a user's request become a candidate Mission Intent? The boundary: the client side; output is untrusted until the Mission Issuer validates and narrows it. Owner: Intent Shaping ([I-D.draft-mcguinness-mission-shaping]); the proposal enters via Pushed Authorization Requests [RFC9126], the MAS submission endpoint, or the AAuth Person Server's mission endpoint. 14.2. Approve and Record The question: how does a proposed task become an approved, committed Mission? The boundary: the Mission Issuer's own; the approval event is where trust is created. Owners: the four bindings ([I-D.draft-mcguinness-oauth-mission], [I-D.draft-mcguinness-mission-authority-server], [I-D.draft-mcguinness-mission-aauth], [I-D.draft-mcguinness-mission-uma]), Consent Evidence ([I-D.draft-mcguinness-oauth-mission-consent-evidence]) committing the disclosure shown to the Approver, and Deferred Approval ([I-D.draft-mcguinness-oauth-mission-approval]), the OAuth binding's asynchronous path, with an experimental companion adding an in-review narrowing negotiation; the standalone and AAuth bindings are natively asynchronous. Where the experimental progressive authorization companion is used, the initial approval also consents an authority ceiling for later staged widening ([I-D.draft-mcguinness-oauth-mission-progressive]). Who holds the deciding side is a spectrum, not a species: the approval event requires an accountable principal deciding against committed inputs before any authority exists, and the proposer is never the approver. A deterministic, versioned policy can approve at machine speed within a ceiling a human consented to (policy approves the instance because a human approved the policy, with policy_version keeping that chain re-checkable), while a model's generated judgment is never the sole authority for granting or widening: a generated approver reading attacker-influenced proposals is itself an injection surface. The high-consequence classes stay on a fresh human decision, per the progressive profile's prohibited set ([I-D.draft-mcguinness-oauth-mission-progressive]). 14.3. Govern The question: how do consumers observe Mission state, and how does authority grow or retire mid-task? The boundary: between the issuer and every consumer relying on state. Owners: Status, the signed pull surface with a lifecycle endpoint and per-entry completion discharge ([I-D.draft-mcguinness-oauth-mission-status]); Signals, the push complement ([I-D.draft-mcguinness-oauth-mission-signals]); Expansion, widening only via an approved successor ([I-D.draft-mcguinness-oauth-mission-expansion]); Containment, event- triggered monotonic narrowing of a live Mission's effective authority ([I-D.draft-mcguinness-oauth-mission-containment]); Management, fleet enumeration and bulk lifecycle for operators ([I-D.draft-mcguinness-oauth-mission-management]); and Discovery, experimental, binding encountered resources within a pre-consented ceiling ([I-D.draft-mcguinness-mission-discovery]). 14.4. Enforce Each Action The question: is this specific action, with these parameters, permitted under this Mission now? The boundary: the last controllable point between agent and resource. Owners: the runtime profile, the decision contract with parameter binding, custody, and fail-closed behavior ([I-D.draft-mcguinness-mission-runtime]); its AuthZEN binding, the concrete decision API and evidence objects ([I-D.draft-mcguinness-mission-authzen]). 14.5. Run and Wind Down The question: how does governed work start, persist, pause, and unwind when Mission state changes? The boundary: the operator's execution environment around the agent. Owners: the harness, binding session continuity to Mission state ([I-D.draft-mcguinness-mission-harness]); Orchestration, unwinding in-flight work through reversibility classes and recorded unwind plans ([I-D.draft-mcguinness-mission-orchestration]). 14.6. Delegate The question: how does authority reach a sub-agent without widening? The boundary: between principals acting under one approval. Owners: Child Delegation, child Missions with lineage, strict-subset authority, and cascade revocation ([I-D.draft-mcguinness-oauth-mission-child-delegation]); Offline Attenuation, narrower Mission-bound tokens minted off the issuer's hot path ([I-D.draft-mcguinness-oauth-mission-attenuation]). Offline attenuation requires the runtime enforcement layer: its kill switch is the runtime state re-check. Both build on the actor chain of the core's Delegation Within a Mission section. The chooser: the core's token-exchange delegation for an execution hop living and dying with the parent's lifecycle; a Child Mission when the delegate needs its own lifecycle, approval, or audit identity; attenuation, experimental, only where offline minting is the constraint. 14.7. Project The question: how is one Mission honored in another trust domain? The boundary: a trust boundary the origin does not control, where the verifier holds no session with the issuer. Owner: Cross-Domain Projection, a single-hop grant that carries the Mission's identifier, issuer, and authority hash into a partner domain unchanged, where a Resource AS mints a local token bounded by the projected authority ([I-D.draft-mcguinness-oauth-mission-cross-domain]). Projection preserves authority across the boundary rather than narrowing it to a sub-actor, which is why it is a distinct verb from Delegate; downstream revocation latency is the local token lifetime. 14.8. Continue The question: how does a Mission's authorization continue, under the same approval and constraints, when the acting identity must be re- established at each hop or after the original credential is gone? The boundary: the seam between authorization continuity, which the Mission owns, and identity continuity, which a transport carries. Owner: Mission Continuation ([I-D.draft-mcguinness-oauth-mission-continuation]), the authorization-continuity profile, which keeps three easily conflated things apart. Identity continuity, who is acting and how that identity legitimately continues, rides a transport rather than this profile: Identity Continuation ([I-D.draft-mcguinness-oauth-id-continuation-assertion]) for a short- lived, sender-constrained hop within a domain; async delegation ([I-D.draft-zhu-oauth-async-delegation]) for a long-running, disconnected task; and the cross-domain grant ([I-D.draft-mcguinness-oauth-mission-cross-domain]) across a trust boundary. Authorization continuity, what work remains authorized under which constraints on whose approval, is the Mission's: every continued grant derives a subset of the Mission's Authority Set, is state-gated at issuance, is bounded by the Mission's expiry, and ends when the Mission goes terminal. Execution-time evidence records, against the Mission, what was done at each continued hop. The load- bearing invariant is that a continuation handle grants nothing: it names an accepted hop, and every continued grant re-passes the Mission's active gate, so continuity is never authority, the rule the harness already applies to session continuity ([I-D.draft-mcguinness-mission-harness]). Continue is therefore distinct from Delegate, which narrows authority to a sub-actor, and it uses the Project verb's cross-domain grant as one transport rather than replacing it. 14.9. Prove The question: what can a party outside the deployment verify about what was approved and done? The boundary: across trust domains and time; the verifier holds no session with the issuer. Owners: Consent Evidence ([I-D.draft-mcguinness-oauth-mission-consent-evidence]); the Mandate, a signed, portable statement that authorizes nothing ([I-D.draft-mcguinness-mission-mandate]); the Mission Receipt, portable evidence of an action taken under a Mission ([I-D.draft-mcguinness-mission-runtime]); Audit Transparency, the append-only evidence log ([I-D.draft-mcguinness-mission-audit]). 14.10. Analyze The question: which components must be trusted, and what does each one's compromise cost? The boundary: the whole system. Owner: the Mission Security Model ([I-D.draft-mcguinness-mission-security-model]). 15. Mission Deployment Patterns 15.1. Binding Security Architectures The bindings share one object but are not one security system: each is a distinct architecture with its own trust assumptions, cutoff behavior, and failure modes, and a deployment names its architecture, not only its binding. Three architectures cover the four bindings: * *credential-carried*: the credential itself names the Mission and issuance is gated (the OAuth AS, the UMA AS, and AAuth's PS- asserted mode); * *PDP-joined*: credentials are ordinary and a join establishes the association at the decision point (the standalone MAS, and AAuth's Reference-only mode); and * *authority-native*: the substrate's own mission concept carries the model (AAuth). The differences that decide a design: +============+=========+==========+==============+================+ |Property |OAuth AS |MAS |AAuth PS | UMA AS | | | | | | (sketch) | +============+=========+==========+==============+================+ |Credential |yes |no |yes (native | yes (claim or | |carries the |(mission | |reference) | introspection) | |Mission |claim) | | | | +------------+---------+----------+--------------+----------------+ |Issuance |yes |no (the |yes | yes | |gated on | |issuance | | | |state | |grant | | | | | |restores | | | | | |it per | | | | | |consuming | | | | | |AS) | | | +------------+---------+----------+--------------+----------------+ |Runtime PDP |no |yes |no | no (per-use | |required for|(issuance|(runtime | | introspection | |a kill |gate |is the | | cuts off) | |switch |exists; |only | | | | |runtime |cutoff) | | | | |tightens)| | | | +------------+---------+----------+--------------+----------------+ |Join |no |yes |in Reference- | no | |ambiguity | |(bounded |only mode | | |possible | |by join | | | | | |assurance)| | | +------------+---------+----------+--------------+----------------+ |Revocation |token |runtime |auth-token | next | |latency |lifetime,|and status|lifetime plus | introspection | |source |status, |only |status | | | |or | | | | | |runtime | | | | +------------+---------+----------+--------------+----------------+ |Offline |partial |limited |blob-private; | JWT RPTs | |Mission |(claims |(join |Mandate | partial; | |verification|verify; |assertion)|supplies it | opaque RPTs | | |state | | | none | | |does not)| | | | +------------+---------+----------+--------------+----------------+ Table 2 The table is the one-page answer to a question the object-level framing invites: a MAS deployment does not provide AS-native semantics because both hold the same Mission, and a reader comparing deployments compares architectures first. The OAuth binding stacks two independent chokepoints. Issuance gating acts at the token layer: a revoked or expired Mission stops all further derivation and refresh, and short-lived tokens age out. Runtime enforcement acts at the action layer: each consequential action is re-checked against current state at the point of use. Issuance gating plus runtime enforcement is strictly stronger than either alone: a gap in PEP coverage is still bounded at the token layer, and an outstanding token is still stopped at the action layer. The AAuth binding composes the same two chokepoints: the Person Server issues or gates every auth token, so issuance gating holds at the PS, and per-action enforcement runs under the runtime composition the AAuth profile defines ([I-D.draft-mcguinness-mission-aauth]). Per-action enforcement is budgeted, not blanket: only consequential actions are gated, the common-case decision is a local evaluation against a materialized policy view whose network cost is paid per freshness window, and only the high-consequence classes are required by the runtime profile to hold a synchronous gate (the runtime profile's deployment considerations, [I-D.draft-mcguinness-mission-runtime]). The composition is an overlay, not a substrate swap: a deployment mediates the paths where the high-consequence classes live and lets every other resource ride lifetime-bounded reliance (Section 16), token lifetimes sized to the tolerated staleness, with no state evaluation at the resource. The standalone mode trades the token-layer kill switch for zero Authorization Server changes. A MAS creates, approves, and serves Missions while tokens remain ordinary; the PDP joins credentials to Missions, and the MAS is the freshness source. The cost is structural: no mission claim travels, revoking a Mission stops nothing at the token layer, and enforcement rests entirely on PEP coverage, so a token exercised outside that coverage is ungoverned (the MAS's Limitations section). The upgrade path is the issuance profile; the record, anchors, and lifecycle carry over unchanged. Between the two sits the issuance join ([I-D.draft-mcguinness-oauth-mission-issuance-grant]): the MAS remains the Mission Issuer while estate Authorization Servers redeem Mission Issuance Grants for Mission-bound, state-gated tokens, restoring the token-layer chokepoint without moving approval. 15.2. Entry Ramps by Estate Which chokepoint a deployment builds first is decided by the estate it already runs, not by preference. The core's issuance ramp assumes an Authorization Server that supports pushed authorization requests, rich authorization requests, and JWT access tokens; the standalone ramp assumes none of that and trades it for PEP coverage. By starting condition: +=============+==========+=====================================================+ |Estate |Entry ramp|Day-one delta | |starting | | | |condition | | | +=============+==========+=====================================================+ |AS |Issuance |AS adds intent intake, derivation, approval, record, | |changeable; |profile |and gating; scope-only Resource Servers and clients | |PAR, RAR, and|(the core)|continue unchanged | |JWT access | | | |tokens in | | | |place | | | +-------------+----------+-----------------------------------------------------+ |AS |MAS first;|A MAS beside the AS; nothing else changes | |changeable; |the core | | |RAR absent or|once the | | |tokens opaque|AS gains | | | |the token | | | |plane | | +-------------+----------+-----------------------------------------------------+ |AS cannot |Standalone|Records and approvals first; enforcement arrives with| |change |MAS, phase|PEP/PDP coverage | |(shared, |by phase | | |third-party, | | | |SaaS) | | | +-------------+----------+-----------------------------------------------------+ |Many |MAS as |Each AS adds grant redemption only | |Authorization|estate |([I-D.draft-mcguinness-oauth-mission-issuance-grant])| |Servers, one |control | | |governance |plane; | | |point |issuance | | | |join per | | | |consuming | | | |AS | | +-------------+----------+-----------------------------------------------------+ |No PEP/PDP |Issuance |Lifetime-bounded reliance (short tokens, gated | |over |profile |refresh); the runtime overlay added later, where the | |consequential|where the |high-consequence classes live | |paths |AS allows;| | | |runtime | | | |layer next| | +-------------+----------+-----------------------------------------------------+ Table 3 Every row shares the record, anchors, and lifecycle, so a ramp is an entry point, not a fork: Missions carry unchanged from any row to the rows a deployment adopts later. One ramp cuts across the rows: the *short mission*. A Mission whose expires_at sits minutes out, run in records mode with lifetime- bounded reliance, is a durable approval record with TTL-grade operational cost: audit, anchors, and bounded exposure with no state surface anywhere (Section 11.10). A deployment can adopt the family this way first, per task, and add state surfaces only where missions grow long enough to need suspend, complete, or kill-now. In sequence, the standalone mode runs submit, poll, approve, join, permit: Client MAS Approver PEP/PDP | | | | | 1 submit Intent | | | |------------------->| | | | 2 202 pending | | | |<-------------------| | | | | 3 disclose | | | |----------------->| | | | 4 approve | | | |<-----------------| | | | Mission active | | | 5 poll | | | |------------------->| | | | 6 approved, | | | | mission_id | | | |<-------------------| | | | 7 action, token, | | | | Mission ref | | | |--------------------------------------------------->| | | 8 signed status: | | | | active | | | |<------------------------------| | |------------------------------>| | | | 9 join; | | | | evaluate | | 10 permit | | | |<---------------------------------------------------| The token in step 7 is an ordinary OAuth token from the unchanged AS; steps 8 through 10 are the Mission Join and the runtime decision (the MAS's Mission Join section), and the MAS's staged walkthrough of the same flow is its end-to-end appendix ([I-D.draft-mcguinness-mission-authority-server]). The quarantine pattern removes a leg of the injection-to-exfiltration chain instead of gating it: no single Mission ever holds untrusted input and an egress path at once. * Work that ingests untrusted content runs under a Mission with no external-communication or external-commitment authority. * Work that communicates externally runs under a separate Mission whose inputs are the quarantined product. * The crossing between them, a human review or a deterministic transformation, is recorded as evidence, under the harness taint policy ([I-D.draft-mcguinness-mission-harness]) and, where claimed, the runtime profile's trifecta containment ([I-D.draft-mcguinness-mission-runtime]). Where the separation must hold within one Mission, the metering profile's exclusivity control ([I-D.draft-mcguinness-mission-metering]) latches read-and-egress apart under a single approval. The *standing-agent pattern* governs the agent whose work never ends. The agent stands; the authority cycles: the standing thing is a charter, a Mission with a consented authority ceiling and drawdown policy ([I-D.draft-mcguinness-oauth-mission-progressive], experimental), and the working thing is the bounded Mission each unit of work draws under it, as an in-ceiling successor or a policy- approved Child Mission ([I-D.draft-mcguinness-oauth-mission-child-delegation]), each expiring and discharging as its unit completes ([I-D.draft-mcguinness-oauth-mission-status]). The progressive profile's prohibited set keeps the high-consequence classes on a fresh human approval inside the ceiling, and its Ceiling Review bounds the chain in time with an evidence-rendering renewal. Without the progressive profile the same pattern runs as ordinary, freshly approved unit Missions with deferred approval ([I-D.draft-mcguinness-oauth-mission-approval]) absorbing the volume: the experimental profile changes the unit economics, not the governance shape. 16. Mission Assurance Levels Two questions get asked of a Mission deployment: what to deploy for a goal, and what guarantee it has earned. They share one progression, so this document states a single set of levels, each carrying both facets, the document set and the proof obligations, and names them so a deployment, a procurement, or a review can cite one level. The levels are guidance, not a conformance class; every companion is optional and states its own scoped conformance. Because the family's strongest properties are deployment properties, not protocol properties (complete PEP placement, a trusted freshness source, and credential custody are things a deployment does, not things a token proves), a level is a claim, verifiable in the sense the runtime profile fixes ([I-D.draft-mcguinness-mission-runtime]), not a label: a deployment states the highest level it has earned in its Enforcement Scope Statement, and a consumer treats an unstated or unproven level as not claimed. The levels build on one another: a deployment adopts recording and governing the approved task (Baseline Issuance), then per-action enforcement (Runtime-Enforced), then full agent safety (Governed and High-Assurance Agent), advancing to the level its risk warrants and stopping there. A level is a dependency bundle: which documents a deployment runs, in adoption order. What a deployment can prove is the orthogonal claims axis (Section 16.1), and the proof obligations noted with each level below are the claims that become available at that level, not properties the level name itself asserts; the claims, not the level, are what a relying party compares. The levels are one axis; the *binding* is an orthogonal one. Every level is reachable under any of the Mission Issuer bindings (the OAuth Authorization Server, the standalone Mission Authority Server, the AAuth Person Server, or the experimental UMA 2.0 Authorization Server), and a deployment names its binding separately from its level; what a level grants varies with what the binding provides. The standalone MAS binding is the case that matters most: it provides the Mission record, lifecycle, and authority but no Mission-bound credential and no issuance gating, so under it the kill switch is the runtime layer alone, not the token gate, and a deployment states that. Binding is not a level. The levels, cumulative: *Baseline Issuance*: the approved, anchored Mission record and its lifecycle: authority derived and committed at the approval event with the integrity anchors (the core). Where the binding issues credentials (full provision), issuance is bounded by the subset rule and gated on Mission state, which grants task-bound, auditable authority and a possession- independent kill switch at the issuance gate; it grants no per- action control, and outstanding tokens run to their own expiry. Sized deliberately, that expiry is the level's revocation bound: *lifetime-bounded reliance*, access-token lifetimes no longer than the deployment's tolerated staleness ([I-D.draft-mcguinness-oauth-mission-status]), gives a quantified cutoff, revocation within one token lifetime, with no Resource Server changes and no status traffic; expiry is a state check performed by the clock. Revocation latency is a number, not a level: what the higher levels add is per-action enforcement, parameter binding, and evidence, not a faster clock. Under a partial-provision binding (the standalone MAS), Baseline grants governance and audit; no kill switch of any kind exists until a freshness surface (the half-step) and runtime enforcement (the next level) arrive, and a deployment states that; the issuance join ([I-D.draft-mcguinness-oauth-mission-issuance-grant]) restores gated issuance at each consuming Authorization Server, and Baseline with it. Proof obligations: the anchored approval and, where credentials are issued, the subset rule. A deployment that adds only a freshness surface, Mission Status or introspection with a published staleness bound ([I-D.draft-mcguinness-oauth-mission-status]), gains state-aware reliance, a revocation cutoff within that bound, without per- action enforcement: a half-step into the next level, not a level of its own. *Runtime-Enforced*: adds a PEP/PDP decision on every consequential action, a trusted state source with a published staleness bound, parameter binding, and runtime evidence ([I-D.draft-mcguinness-mission-runtime] and its AuthZEN binding). Grants per-action enforcement and revocation bounded, for gated classes, by the staleness bound plus the permit window plus the class's execution bound, and by token lifetime for ungated paths. This is the smallest deployment that turns a Mission from governed issuance into action-time defense, and every normative dependency it needs is ratified; it is a substantial build, not a wedge, and a deployment sizes the effort from the runtime profile's conformance section rather than from this level's one-line summary. Proof obligations: PEP-placement completeness and the declared freshness source and bound. Documents: Baseline plus runtime, its AuthZEN binding, and a freshness source. *Governed Agent* (recommended for AI agents): adds Consent Evidence and the harness, growing with Child Delegation, Expansion, Orchestration, and Discovery (experimental, with Progressive) as needed. Grants consent-rendering evidence and session-continuity discipline. Documents: Runtime-Enforced plus consent-evidence and the harness. *High-Assurance Agent*: adds the guarantees that resist a compromised agent. Two named claims live at this level, each with proof obligations the runtime profile fixes. *Agent-compromise-resistant enforcement*: mediated (gateway) credential custody, a declared-and-audited path scope, action- bound approval for the high-consequence classes, an active- freshness state source, and approval disclosures rendered by a component isolated from the agent, so a compromised agent cannot unilaterally take a high-consequence action for which it does not hold a mediated credential. *Trifecta containment*: least exposure, the harness taint rule enforced as a mandatory requirement of the harness profile, with pre-consented egress to Approver-named destinations as its one carve-out, and full mediation of the external-communication and external-commitment classes with the egress-channel enumeration, so an injected agent cannot egress on the strength of untrusted content alone. These are named high bars, never implied by basic adoption; a deployment can bind its Enforcement Scope Statement to execution- environment attestation so a claim is technical rather than organizational ([I-D.draft-mcguinness-mission-runtime], [I-D.draft-mcguinness-mission-harness]). Read as an adoption ladder, each level makes a broader class of agent work defensible to grant. The mapping is informative: the action classes are the runtime profile's ([I-D.draft-mcguinness-mission-runtime]), resource policy remains authoritative for its own objects, and what a level grants varies with the binding; the Mission Deployment Profile (Section 17) is where a deployment states its own mediated_action_classes and exclusions. +==================+===========================================+ | Level | What a deployment can defensibly grant | +==================+===========================================+ | Baseline | Consequential reads that are attributable | | Issuance | and killable at the issuance gate: the | | | governed pilot | +------------------+-------------------------------------------+ | Runtime-Enforced | Consequential writes inside approved | | | bounds, reversible under the deployment's | | | own authority | +------------------+-------------------------------------------+ | Governed Agent | Unattended operation and delegation, with | | | approval evidence behind every grant | +------------------+-------------------------------------------+ | High-Assurance | The high-consequence classes | | Agent | ([I-D.draft-mcguinness-mission-runtime]), | | | under mediated custody and action-bound | | | approval | +------------------+-------------------------------------------+ Table 4 Every level above Baseline Issuance also carries the cross-cutting obligations its mechanisms imply: * operation-profile normalization where duration or parameter digests are metered ([I-D.draft-mcguinness-mission-metering], [I-D.draft-mcguinness-mission-authzen]); * evidence retention for the audit horizon; and * a registration schedule where audit transparency is run ([I-D.draft-mcguinness-mission-audit]). The evidence levels are accountability, not prevention: they make what was recorded tamper-evident, not what was perceived true or what was never recorded present. 16.1. Assurance Claims The levels are the adoption ladder: what a deployment has built, in the order deployments build it. What a deployment can prove is an orthogonal axis, claimed as named *assurance claims*, each with a proof obligation an existing profile fixes, and listed in the Deployment Profile (Section 17) rather than implied by a level: * *Approved-record integrity*: the anchors reproduce from the record alone (the core's integrity anchors). * *Bounded revocation latency*: the published staleness bound plus the permit window and the class's execution bound ([I-D.draft-mcguinness-mission-runtime]). * *Action-time enforcement*: PEP coverage for the Enforcement Scope Statement's mediated set, and nothing outside it. * *Parameter-bound enforcement*: permits bound to concrete parameters for the classes claimed. * *Transaction-grade execution*: the runtime profile's transaction- assurance tier machinery (single-use permits, leases, outcome reconciliation) for the classes claimed ([I-D.draft-mcguinness-mission-runtime]). * *Compromise-resistant custody* and *trifecta containment*: the two named High-Assurance claims, unchanged (Section 16). Two deployments at the same level under different bindings can hold different claims; the MAS modes are the worked case ([I-D.draft-mcguinness-mission-authority-server]). The claims, not the level, are what a relying party compares. 17. The Mission Deployment Profile The Mission Assurance Levels (Section 16) name what to deploy, and the assurance claims (Section 16.1) name what may be proven; a claim is only checkable if a deployment states, concretely, what it enforces and what it leaves outside the boundary. The *Mission Deployment Profile* is that system-level artifact: the published composition of the per-layer statements the profiles themselves demand (the runtime profile's Enforcement Scope Statement, the harness environment statement, the MAS mapping contract, the Resource Server coverage split, the transparency-service topology and schedule, and the progressive profile's bounds and ceiling-review cadence, each where its profile is run), composed into one object an auditor, a procurement, or a security review can read. It is one artifact, not a second one: each fact's owning profile governs its meaning and normative force, and this document fixes no serialization. A machine-readable manifest schema, with stable claim identifiers and validation rules, is deferred family work; until it exists, the shape below is illustrative and the per-profile statements are the checkable form. Its distinguishing field is residual_risks: the profile is not credible unless it states, in the same object as its guarantees, what it does not cover. An illustrative shape: { "profile": "mission-governed-agent-runtime", "assurance_level": "high-assurance-agent", "mission_issuer": "https://as.example.com", "state_sources": [ { "type": "status_endpoint", "max_staleness_seconds": 30 } ], "issuance": { "binding": "oauth-core", "mission_claim_required": true, "refresh_gated_on_active_state": true }, "runtime": { "pdp": "authzen", "pep_locations": ["tool-gateway", "browser-action-proxy"], "mediated_action_classes": [ "irreversible_action", "external_commitment", "external_communication", "privileged_administration" ], "action_bound_approval_classes": [ "irreversible_action", "privileged_administration" ], "unmediated_exclusions": [ "internal_reasoning", "local_cache_read" ] }, "credential_custody": { "held_by": "pep", "sender_constrained": true, "key_generated_in_pep": true, "agent_receives_bearer_token": false }, "approval_rendering": { "rendered_by": "agent-isolated-component" }, "harness": { "subagent_inheritance": "explicit_delegation_only", "resume_requires_active_state": true, "cached_credentials_revalidated": true, "secondary_egress_enumerated": true }, "exposure": { "taint_rule": "enforced", "egress_channels_enumerated": true }, "standing_charters": { "ceiling_review_cadence_days": 90, "per_drawdown_bound": "single_entry_delta", "drawdown_rate_bound_per_chain_per_hour": 60 }, "resource_servers": { "authorization_details_enforcing": ["https://erp.example.com"], "scope_projection_only": ["https://mail.example.com"], "constraint_enforcement_for_scope_only": "runtime_pep" }, "evidence": { "decision_evidence": true, "execution_evidence": true, "retention_days": 365, "field_classification": "evidence-schema-v2", "evidence_access_audited": true, "erasure_policy": "erasure-records", "transparency": { "service_operator": "third_party", "monitor": "sec-ops", "registration_time_bound_seconds": 3600 } }, "residual_risks": [ "unmediated local reasoning is outside enforcement", "revocation latency up to 30 seconds", "PEP compromise is not prevented", "per-entry constraints reach scope-only resources only via the PEP", "long-term memory and provider model context are not Mission-scoped exposure points" ] } The evidence member carries the deployment's evidence-handling posture beside its guarantees: the field-classification scheme its records use, whether access to Mission evidence is itself audited, and the erasure policy that pairs retention with deletion accountability ([I-D.draft-mcguinness-mission-audit]). Two deployments that both "support Mission" but publish different Deployment Profiles provide different security properties, and the profile is what makes that difference legible. A deployment claiming a level (Section 16) states it here and lists the residuals that level leaves. 18. Prevention, Detection, and Residue Each layer earns a specific property and leaves a specific residue. Stated as a table so a claim cannot be read as more than it is: +==============+=====================+============+==============+ | Mechanism | Prevents | Detects | Does not | | | | | solve | +==============+=====================+============+==============+ | Core | over-issuance | the | action-time | | issuance | beyond the approved | approved | misuse | | | authority; issuance | authority | within scope | | | after revocation or | (anchored) | | | | expiry | | | +--------------+---------------------+------------+--------------+ | Runtime | an unauthorized | each PDP/ | actions on | | enforcement | action on a | PEP | an | | | mediated path | decision | unmediated | | | | (evidence) | path | +--------------+---------------------+------------+--------------+ | Consent | silent divergence | the | whether a | | Evidence | between what was | rendered | human | | | shown and what was | disclosure | perceived or | | | committed | | understood | | | | | it | +--------------+---------------------+------------+--------------+ | Audit | undetectable log | the | a producer | | Transparency | tampering or | evidence | logging a | | | omission (under | timeline | false record | | | expected | | | | | registration) | | | +--------------+---------------------+------------+--------------+ | Mandate | reliance on | portable | authority | | | unverifiable | Mission | (it grants | | | committed facts | facts | none) | +--------------+---------------------+------------+--------------+ Table 5 The pattern is uniform: the family commits and checks what a party was shown, decided, or did; it does not make the human attentive, the producer honest, or the unmediated path disappear. Those are the residues the Mission Assurance Levels (Section 16) and the security model make a deployment state rather than assume, and the exposure arm (Section 7) carries the same honesty in the other direction. 18.1. The Containment Matrix Mission termination is one control in a larger containment surface. Each kill has a different blast radius, and an incident responder needs the whole matrix: +==========+=============+=======================================================+ |Control |Stops |Home | +==========+=============+=======================================================+ |Capability|one |the issuer-held containment overlay | |kill |capability |([I-D.draft-mcguinness-oauth-mission-containment]) | | |within one | | | |Mission, with| | | |the body of | | | |work still | | | |running | | +----------+-------------+-------------------------------------------------------+ |Mission |one body of |the core's revocation; cascades to Child Missions | |kill |work, across |([I-D.draft-mcguinness-oauth-mission-child-delegation])| | |every | | | |resource and | | | |derived | | | |credential | | +----------+-------------+-------------------------------------------------------+ |Agent kill|all work by |the deployment's agent IAM (Section 10.2) | | |one agent, | | | |across its | | | |Missions | | +----------+-------------+-------------------------------------------------------+ |Agent |every |the deployment's change governance (Section 10.2) | |Deployment|instance | | |kill |running a | | | |compromised | | | |version | | +----------+-------------+-------------------------------------------------------+ |Credential|credentials |the binding's substrate, where it supports revocation; | |kill |already |otherwise expiry (Section 11.10) | | |issued | | +----------+-------------+-------------------------------------------------------+ |Workload |the running |the platform | |kill |compute | | | |itself | | +----------+-------------+-------------------------------------------------------+ |Egress |the |gateway and network controls | |kill |communication| | | |path | | +----------+-------------+-------------------------------------------------------+ Table 6 Mission termination participates in incident response; it does not replace it. Revoking the Mission stops issuance at once and stops mediated actions within the staleness bound (Section 11.10), but it terminates no process and closes no network path. The converse holds too: killing a workload leaves the Mission active and its authority derivable to a replacement instance unless the Mission is also revoked. A deployment's incident runbook names which of these controls exist and who may pull each. 19. Mission Requirements The requirements the family answers, stated implementation-neutrally; each names its answering documents by short form (Section 20). They stand on their own: a reader evaluating another design can use them as a checklist. The litmus splits at the family's own conformance seam, because the family itself defines conformant deployments at two strengths (Section 16). A design provides *Mission-substrate conformance*, the bar the Baseline Issuance level and every binding meets ([I-D.draft-mcguinness-mission-substrate]), when the first four properties hold: 1. *An approved task object*: the task is a durable, explicitly approved object rather than a session or a token, and its intent and derived authority are integrity-committed at approval. 2. *Authority derived from the task*: credentials and decisions derive from that object, never minted independently of it. 3. *Narrow-only delegation*: derived and delegated authority only narrows, and widening exists only as a fresh approval. 4. *Observable lifecycle state*: the object's current state is observable and gates issuance and reliance; only active permits, and unrecognized states fail safe. A design provides *Runtime-Enforced Mission conformance*, the bar a design claiming action-time defense meets, when two more hold: 1. *Per-action runtime enforcement*: consequential actions are checkable against the object at the point of use. 2. *Evidence that joins*: what was approved, shown, decided, and done is reconstructible from evidence joined on the object's identity. A design that relaxes one of the first four is not Mission-based in this family's sense. A design that holds the first four but not all six is Mission-based at issuance strength, which is what a Baseline deployment is, and claims nothing about action-time defense; the requirements below unpack all six. 19.1. Context and Intent * *R1*: The task an agent pursues is a durable, structured, approved object (oauth-mission; mission-authority-server). * *R2*: The task and its derived authority are integrity-committed at approval, reproducible from the record alone (oauth-mission). * *R3*: Task proposals are untrusted input: fields the agent can influence never derive, widen, or gate authority (oauth-mission; mission-shaping). 19.2. Consent and Approval * *R4*: The derived authority is disclosed to the Approver before it takes effect, and the approval covers it (oauth-mission). * *R5*: A single accountable Approver is recorded immutably on the object (oauth-mission). * *R6*: What was shown at approval is committed and reconstructible by an auditor (oauth-mission-consent-evidence). * *R7*: Approval can be asynchronous, and any in-review negotiation only narrows (oauth-mission-approval; the experimental oauth- mission-approval-revision). 19.3. Lifecycle * *R8*: Reliance is gated on task state: only active permits it, and unrecognized states fail safe (oauth-mission). * *R9*: Revocation is independent of credential possession, and state changes propagate by pull or push (oauth-mission; oauth- mission-status; oauth-mission-signals). * *R10*: A task can be suspended and resumed without being terminated (oauth-mission-status). * *R11*: Authority widens only through a fresh approval that creates a successor (oauth-mission-expansion). * *R12*: Authority retires per entry when the work an entry served is done (oauth-mission-status). 19.4. Delegated, Projected, and Enforced Execution * *R13*: Derived and delegated authority only narrows (oauth- mission; oauth-mission-attenuation). * *R14*: Sub-agents receive authority by explicit delegation with lineage, fan-out control, and cascade revocation, never by session ancestry (oauth-mission-child-delegation). * *R15*: Each consequential action is checked at the point of use, the permit bound to the concrete parameters (mission-runtime; mission-authzen). * *R16*: When a task stops, governed work stops with it and in- flight work unwinds safely (mission-harness; mission- orchestration). * *R17*: Task evidence is tamper-evident and verifiable outside the deployment (mission-audit; mission-mandate). * *R18*: A Mission's committed facts and authority are honorable in another trust domain without widening, and verification needs no session with the issuer (oauth-mission-cross-domain; mission- mandate). 20. Mission Document Map One line per document, grouped as the family groups them; the short form drops the draft-mcguinness- prefix. The naming encodes a boundary: profiles extending the Authorization Server's own surfaces keep "oauth" in their names; profiles defined against the substrate of Section 11 are named without it. This document is named without it because the architecture is substrate-neutral by construction. Maturity is a dependency boundary. A Standards-Track profile never depends normatively on an experimental one: the experimental profiles (tagged below) extend the stable interface only through its declared seams, the controls extension of the core and the coordinated- extension rules of the evidence objects, and a Standards-Track document cites them informatively at most. An experimental profile that stabilizes crosses the boundary by reclassification, not by a stable document absorbing a dependency. *The model and its bindings:* oauth-mission: The core issuance profile: the Mission, the approval event and anchors, the mission claim, the subset rule, state-gated issuance. mission-authority-server: The standalone Mission Issuer and the PDP join of ordinary credentials to Missions. oauth-mission-issuance-grant: The issuance join: MAS-minted grants an estate Authorization Server redeems at its token endpoint for Mission-bound, state-gated tokens. mission-aauth: The AAuth binding: the Person Server as Mission Issuer, the mission blob as the record under AAuth's s256 commitment, issuance gating at the token endpoint. mission-uma: Experimental sketch. The UMA 2.0 binding: the pushed Mission Intent rides claims pushing, the resource owner's decision fills UMA's authorization assessment, the RPT is the Mission-bound credential, and the PCT is continuity that is never authority; the first binding authored against the substrate contract. mission-substrate: Normative requirements on any further binding of the model; the existing bindings and the core are unchanged by it. *Approval time:* mission-shaping: Client-side shaping of a user's request into a candidate Mission Intent, as untrusted proposal. oauth-mission-consent-evidence: The consent_rendering_hash anchor and signed evidence of what the Approver was shown, with the translation floor and Disclosure Interrogation that keep the approval surface readable and questionable. oauth-mission-approval: Asynchronous approval over the deferred substrate. oauth-mission-approval-revision: Experimental: in-review narrowing revision of a deferred proposal. *Lifecycle:* Status is the lifecycle suite's root document (state reading, including the swarm-scale Status List, lifecycle verbs, and completion), with Signals (the push channel) and Management (the operator plane) as its satellites. oauth-mission-status: The signed pull surface and the lifecycle endpoint, with suspended and completed, and per-entry discharge via the terminal_when constraint. oauth-mission-signals: A signed event per lifecycle transition, push or poll. oauth-mission-expansion: Widening through an approved successor Mission. oauth-mission-containment: Event-triggered, monotonic narrowing of a live Mission's effective authority, with restoration only through an approved successor. oauth-mission-progressive: Experimental: policy-adjudicated expansion within a pre-consented ceiling. mission-discovery: Experimental: the open-world encounter as a governed operation: identity pinning, ceiling adjudication with the lying-resource and tainted-session floors, Discovery Evidence. oauth-mission-management: Fleet enumeration and bulk lifecycle operations for operators and incident response; dry-run-first, per-Mission semantics. oauth-mission-cross-domain: Single-hop projection of a Mission to another trust domain via the cross-domain grant. oauth-mission-continuation: The authorization-continuity profile: a Mission continues its authorization over identity-continuity transports (Identity Continuation, async delegation, cross- domain), state-gated, with the invariant that a continuation handle grants nothing. oauth-id-continuation-assertion: A continuation transport: a short- lived token-exchange subject token yielding an ID-JAG for an intra-domain hop, bound to a Mission's authorization by mission- continuation. *Runtime enforcement:* mission-runtime: The per-action decision contract: parameter binding, custody, fail-closed behavior. mission-authzen: The concrete decision-API binding and its Decision and Execution Evidence objects. mission-metering: Experimental: cumulative consumption bounds and the metering that enforces them. *Agent runtime:* mission-harness: Binding sessions, queues, and sub-agent handles to Mission state; the mediated environment. mission-orchestration: Experimental: reversibility classes, unwind plans, and compensation after a stop. *Sub-agents:* oauth-mission-child-delegation: Child Missions with lineage, strict- subset authority, cascade revocation. oauth-mission-attenuation: Experimental: narrower Mission-bound tokens minted offline; the kill switch preserved by runtime re- check. *Proof and portability:* mission-mandate: A signed, portable statement of a Mission's committed facts; evidence, not a credential. mission-audit: Registration of Mission evidence in a SCITT Transparency Service; receipts verifiable offline. *Security model:* mission-security-model: The trusted base in one view: what each component must achieve and what its compromise costs. 21. Security Considerations This document introduces no mechanism and therefore no new security considerations. The consolidated trusted base and compromise analysis are the Mission Security Model's ([I-D.draft-mcguinness-mission-security-model]), and each profile's own Security Considerations remain normative. 22. Privacy Considerations The privacy properties of the Mission record and the Mission Intent are the core's ([I-D.draft-mcguinness-oauth-mission]) and each adopted profile's; this document describes them and adds no data element of its own. The core's Privacy Considerations cover Mission Identifier correlation, token payload disclosure, and Intent retention, with the audit profile's erasure record as the transparency-side mechanism ([I-D.draft-mcguinness-mission-audit]). The status profile's anti-oracle property bounds what its status surfaces disclose ([I-D.draft-mcguinness-oauth-mission-status]). 23. IANA Considerations This document makes no IANA request. 24. Informative References [I-D.draft-mcguinness-mission-aauth] McGuinness, K., "Mission-Bound Authorization for AAuth", 2026, . [I-D.draft-mcguinness-mission-audit] McGuinness, K., "Mission Audit Transparency", 2026, . [I-D.draft-mcguinness-mission-authority-server] McGuinness, K., "Mission Authority Server", 2026, . [I-D.draft-mcguinness-mission-authzen] McGuinness, K., "Mission-Bound Runtime Enforcement: AuthZEN Profile", 2026, . [I-D.draft-mcguinness-mission-discovery] McGuinness, K., "Mission Open-World Discovery", 2026, . [I-D.draft-mcguinness-mission-harness] McGuinness, K., "Mission-Aware Agent Harnesses", 2026, . [I-D.draft-mcguinness-mission-mandate] McGuinness, K., "Mission Mandate", 2026, . [I-D.draft-mcguinness-mission-metering] McGuinness, K., "Mission Consumption Metering", 2026, . [I-D.draft-mcguinness-mission-orchestration] McGuinness, K., "Mission Orchestration and Unwinding", 2026, . [I-D.draft-mcguinness-mission-runtime] McGuinness, K., "Mission-Bound Runtime Enforcement", 2026, . [I-D.draft-mcguinness-mission-security-model] McGuinness, K., "Mission Security Model", 2026, . [I-D.draft-mcguinness-mission-shaping] McGuinness, K., "Mission Intent Shaping", 2026, . [I-D.draft-mcguinness-mission-substrate] McGuinness, K., "Mission Substrate Requirements", 2026, . [I-D.draft-mcguinness-mission-uma] McGuinness, K., "Mission-Bound Authorization for UMA 2.0", 2026, . [I-D.draft-mcguinness-oauth-ai-agent-instance] McGuinness, K., "OAuth 2.0 AI Agent Instance Profile", Work in Progress, Internet-Draft, draft-mcguinness-oauth- ai-agent-instance-00, 4 July 2026, . [I-D.draft-mcguinness-oauth-client-instance-assertion] McGuinness, K., "OAuth 2.0 Client Instance Assertion", Work in Progress, Internet-Draft, draft-mcguinness-oauth- client-instance-assertion-01, 24 June 2026, . [I-D.draft-mcguinness-oauth-id-continuation-assertion] McGuinness, K., "Identity Continuation Assertion for OAuth 2.0 Token Exchange", 2026, . [I-D.draft-mcguinness-oauth-mission] McGuinness, K., "Mission-Bound Authorization for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-approval] McGuinness, K., "Mission Deferred Approval for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-attenuation] McGuinness, K., "Mission Offline Attenuation for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-child-delegation] McGuinness, K., "Mission Child Delegation for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-consent-evidence] McGuinness, K., "Mission Consent Evidence for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-containment] McGuinness, K., "Mission Containment for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-continuation] McGuinness, K., "Mission Continuation: Authorization Continuity for Mission-Bound Authorization", 2026, . [I-D.draft-mcguinness-oauth-mission-cross-domain] McGuinness, K., "Mission Cross-Domain Projection for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-expansion] McGuinness, K., "Mission Expansion for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-issuance-grant] McGuinness, K., "Mission Issuance Grant for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-management] McGuinness, K., "Mission Management for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-progressive] McGuinness, K., "Mission Progressive Authorization for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-signals] McGuinness, K., "Mission Lifecycle Signals for OAuth 2.0", 2026, . [I-D.draft-mcguinness-oauth-mission-status] McGuinness, K., "Mission Status and Lifecycle for OAuth 2.0", 2026, . [I-D.draft-zehavi-oauth-rar-metadata] Zehavi, Y., "OAuth 2.0 RAR Metadata and Error Remediation", Work in Progress, Internet-Draft, draft- zehavi-oauth-rar-metadata-05, 4 July 2026, . [I-D.draft-zhu-oauth-async-delegation] Zhu, L. and Z. Berg, "Delegated Refresh Tokens for OAuth 2.0 Token Exchange", Work in Progress, Internet-Draft, draft-zhu-oauth-async-delegation-05, 3 August 2026, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, . [RFC9126] Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", RFC 9126, DOI 10.17487/RFC9126, September 2021, . [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, . [RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, June 2026, . Acknowledgments This document is part of the Mission-Bound Authorization work and maps the structure that its profiles establish individually. Author's Address Karl McGuinness Independent Email: public@karlmcguinness.com