An Architecture for 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 13 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

A Mission is a durable governance object created by an explicit approval event: the approved task, with a lifecycle. In the authority-bearing bindings, authority for the task is derived for the Mission, bound to it, and gated on its state. In AAuth, the Mission Context instead governs resource decisions at the PS without becoming their authority language. 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 maps the shared approval, reference, lifecycle-gate, and log capabilities onto that protocol's native Mission Context without importing the OAuth Authority Set ([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 several 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, and (as an experimental sketch) UMA 2.0 as authority-bearing bindings. AAuth composes at the shared Mission Context layer: approval, stable reference, lifecycle gating where the PS is on path, and governance history (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. In the OAuth model, 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, and MAY propose concrete authority alongside it; the Mission Issuer derives an Authority Set; an approval event commits them and creates the Mission.¶

In the OAuth binding, the commitment is the integrity anchors: intent_hash over the approved Mission Intent, authority_hash over the consented Authority Set, and, where the client submitted an authority proposal, proposal_hash over the submitted authorization_details array, each computed over a domain-separated, issuer-bound envelope with fixed canonicalization, so an auditor can reproduce each 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. A non-active state stops new derivation at once; authority already issued ends at the earliest of delivered revocation, a runtime or state-aware re-check, or the credential's own expiry (Section 11.10).¶

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

AAuth realizes the separation differently. Its exact-byte s256 commits the private approved mission blob, and {approver, s256} is the stable reference. The PS applies contextual governance using that blob and the ordered mission log; scopes, resource tokens, Resource and Access Server policy, and optionally R3 carry deterministic resource authorization. AAuth does not add the OAuth Authority Set or its two anchors, and its native lifecycle remains exactly active or terminated.¶

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, or a new grant protocol. Rich Authorization Requests [RFC9396] and kindred mechanisms already fill the authority-expression role; the family leaves that to them (Section 4). The same restraint holds against GNAP and the capability-system lineage (macaroons, Biscuit, UCAN, object-capability narrowing): this family composes with deployed grant protocols and attenuation primitives rather than introducing a competing one of its own; the core states the comparison ([I-D.draft-mcguinness-oauth-mission]).¶

• 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. It presumes an authority-bearing binding; under AAuth the analogous per-action control is the Person Server's contextual gate on PS-mediated paths ([I-D.draft-mcguinness-mission-aauth]).¶

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

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 OAuth model starts with authority client-proposed and enumerated at approval; an agent that discovers resources at encounter time breaks that premise, and some authorization mechanisms invert it: the resource declares its own operations and consequences. Who owns meaning, and how it reaches derivation, consent, and enforcement, is stated once as the ontology contract (Section 13).¶

Where the OAuth discovery profile consumes a self-declaration, the declaration's digest is committed with the binding evidence: an additional commitment beside the Mission's integrity anchors, 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]). AAuth can use R3 for resource-owned deterministic semantics without placing that declaration or such an additional commitment in the private mission blob.¶

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], optionally proposing concrete authority on the standard authorization_details parameter alongside it ([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, authority_hash, and, where a proposal was submitted, proposal_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 instead governs the native Mission Context through propose, clarify, approve, and the mission log; it does not emulate the AS's Authority Set or integrity anchors.¶

9. Mission Invariants

The following seven invariants define the family's portable-authority model and are stated normatively by their home documents. They apply to the OAuth binding and to companions and bindings that explicitly adopt the corresponding Authority Set capabilities. A change that would break one in those bindings is a change to that model, not to a profile.¶

The AAuth binding adopts the context-level invariants: durable approval, stable attribution, exact-byte integrity, an active-state gate at the PS, and termination. It does not adopt the OAuth Authority Set, the OAuth integrity anchors, or universal subset derivation. AAuth resource authority is decided afresh in the vocabulary and policy of each Resource or Access Server, with contextual PS governance when the PS is on path.¶

Authority serves an approved task:

No Mission-bound authority exists except by derivation for a Mission, and a Mission is created only when rooted in an approved authorization basis 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). In AAuth, only PS operations and the PS-asserted and federated authorization paths are structurally gated; identity-based and resource-managed decisions do not pass through the PS. On the gated paths the gate covers requests whose resource token carries the validated Mission Reference; a stripped reference yields a missionless request, bounded by the binding's downgrade rules ([I-D.draft-mcguinness-mission-aauth]).¶

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). AAuth's corresponding integrity property is the s256 commitment over exact mission-blob bytes, not the OAuth integrity anchors.¶

Read against "approved" in the first invariant, the core names three authorization bases, never an eighth invariant: direct, a human's own approval; template, a dispatch drawing on a ceiling the human consented to once; and policy_drawdown, a child instance a policy adjudicates within a bound the parent's human already consented to. All three fix the same accountable human as consent_principal; they differ only in what activated this instance and what root that activation traces to (the core).¶

Read as shared capabilities rather than universal wire semantics, the bindings carry durability, attribution, and termination. Narrowing and containment require a structured-authority capability and are not baseline AAuth Mission Context properties.¶

Read on the artifact plane, the same invariants forbid authority from riding a work product an agent produces: no authority is acquired by information propagation alone, and a work product crossing into a Mission is input that the receiving Mission re-evaluates under its own Authority Set. This is a reading of the invariants above, not an eighth invariant; its normative home is the Mission Work Products companion ([I-D.draft-mcguinness-oauth-mission-work-products]).¶

Read under composition, the invariants bound one Mission's own Authority Set; they do not by themselves bound the aggregate surface a delegation tree, a cross-domain hop, or a chain of child generations reaches together. Delegation depth resets at each cross-domain hop and at each child generation, and a child's own derivation cap is independent of its parent's, so the authorized surface a body of work can reach can exceed what any single approval appears to bound. This is again a reading of the invariants above, not an eighth invariant; disclosing the composed bound at the consent surface is the cross-domain and child-delegation profiles' role ([I-D.draft-mcguinness-oauth-mission-cross-domain], [I-D.draft-mcguinness-oauth-mission-child-delegation]), and bounding aggregate consumption is the metering profile's ([I-D.draft-mcguinness-mission-metering]).¶

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). AAuth keeps the person's relationship and context at the PS and does not add this OAuth Subject tuple to the mission blob.¶

Approver:

The single accountable principal who approves the Mission; equal to the Subject for self-approval (the core's Single Accountable Approver section). In AAuth, the wire approver value names the PS, not a portable person identifier; the person reviews and approves through that PS.¶

Mission Issuer:

Validates the Mission Intent, runs the approval event, records the Mission, and owns its state. The authority-bearing 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]).¶

• 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]).¶

The OAuth and standalone authority-bearing bindings also serve 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]). The AAuth binding does not define such a view from the mission blob; deterministic resource authorization remains in scopes, resource tokens, Resource and Access Server policy, and optionally R3.¶

AAuth Person Server:

The controlling authority for the native Mission Context rather than an OAuth-style Mission Issuer. The mission blob is committed by AAuth's s256, and the PS gates PS-asserted issuance and federated brokering. It does not gate direct identity-based or resource-managed decisions ([I-D.draft-mcguinness-mission-aauth]).¶

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 shared Mission Context capabilities, while authority carriage and enforcement remain binding-dependent:¶

      Subject        Approver
          \             |
           \      approval event
            \           |
  +-------------------------------------------------------------+
  |                    Mission Control Point                    |
  | +------------+ +------------+ +------------+ +------------+ |
  | | OAuth AS:  | | Standalone | | AAuth PS:  | | UMA 2.0 AS | |
  | | Mission-   | | MAS: no    | | Mission    | | (sketch):  | |
  | | bound      | | tokens;    | | Context;   | | pushed     | |
  | | tokens     | | the PDP    | | PS paths   | | Intent;    | |
  | | gated on   | | joins to   | | gated      | | RPTs gated | |
  | | state      | | Mission    | |            | | on state   | |
  | +------------+ +------------+ +------------+ +------------+ |
  +-------|--------------|--------------|--------------|--------+
          v              v              v              v
          durable approved context and lifecycle;
       Authority Set and anchors where the binding defines them
                     |
                     | binding-specific state, context,
                     | and authority surfaces
                     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 control point (OAuth AS | MAS | AAuth PS):
               approved context, lifecycle and gating;
               anchors and authority distribution where defined
                    |                       ^
                    | 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

11. The Mission Substrate

The binding-neutral contract is Mission Substrate Requirements ([I-D.draft-mcguinness-mission-substrate]): a contextual-governance kernel every binding provides (native reference and controller, actor binding, approved context, approval event, governance gate, bounded reliance, context propagation, and an ordered governance record) and seven optional capabilities each binding claims through its Mission Substrate Statement (Lifecycle-Gated Authorization, State-Observable, Structured Authority, Monotonic Derivation, Credential-Bound, Independently Verifiable, and Portable Evidence).¶

The companion profiles named without "oauth" are defined against the binding-neutral contract and declare, each in a Mission Substrate section of its own, the kernel functions and optional capabilities they consume. Where a companion consumes a concrete representation, it is today the issuance profile's.¶

The remainder of this section documents that instantiation: eight primitives, each with its normative home and its consumers. Every sentence mirrors a rule the named profile states normatively. None of these issuance-profile representations or stronger semantics is required verbatim by the binding-neutral kernel, although several instantiate mandatory kernel functions: the identifier and issuer realize the Mission Reference and Controller, the lifecycle realizes the governance gate, token validity participates in bounded reliance, and the audit horizon participates in the governance record.¶

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

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). One boundary is shared by agreement: the resource owns its operation semantics and consequences, while the family owns the registered cross-resource constraint vocabulary, which a resource explicitly advertises and adopts before it binds ([I-D.draft-mcguinness-oauth-mission]).¶

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 capability-binding companion ([I-D.draft-mcguinness-mission-capability-binding]).¶

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. Under the OAuth discovery composition, the declaration can be content-addressed by r3_s256 as an additional commitment beside the Mission's integrity anchors; the declared operations become candidate vocabulary that derivation narrows against. AAuth can instead use R3 as a resource-owned deterministic authorization vocabulary while the private mission blob remains contextual PS governance. R3 content addressing is not a baseline AAuth mission anchor. Home: the discovery and R3 compositions, informative.¶

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. Where a structured-authority binding commits that meaning at approval, it is enforced at use and translation never widens. 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]). In AAuth, R3 can describe deterministic resource authorization independently of mission approval; the PS considers the resource request and mission context without turning the R3 declaration into a Mission Authority Set. 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      OAuth Intent Shaping or AAuth native proposal
              (client or agent side, untrusted)
                        |
 approve      Mission control point: the OAuth AS, Mission
 and record   Authority Server, or AAuth Person Server
              contextual-governance binding
              (+ Consent Evidence, Deferred Approval)
                        |
              the Mission: durable approved context and
              lifecycle; authority anchors where defined
                        |
 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)

15. Mission Deployment Patterns

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

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. The authority-bearing bindings name their level separately from their binding. An AAuth deployment instead reports the Mission Context capabilities and resource access modes it actually uses; selecting the AAuth binding does not by itself satisfy structured-authority, subset, portable-evidence, or runtime proof obligations.¶

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 AAuth distinction is access-mode dependent: PS-asserted and federated access have a PS lifecycle gate for new authorization; identity-based and resource-managed access do not. Its native auth token is Mission-referenced, not the strong Mission-bound credential defined by the OAuth core.¶

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 a structured-authority binding issues Mission-bound credentials, 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 binding without credential-carried authority (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.¶

The nearest AAuth comparison, stated as capabilities rather than a level: native approval, exact-byte commitment, active or terminated state, and the ordered mission log. The possession-independent issuance cutoff applies only to PS-asserted and federated requests whose resource token carries the validated Mission Reference; no Authority Set or subset proof is implied.¶

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

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

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

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

19. Mission Requirements

The requirements the family answers are stated implementation-neutrally; each names its answering documents by short form (Section 20). They stand on their own as a checklist, but conformance is capability- layered rather than measured by resemblance to the OAuth wire model ([I-D.draft-mcguinness-mission-substrate]).¶

A design provides the shared Mission Context capabilities when the first four properties, a compact restatement of the substrate contract's kernel ([I-D.draft-mcguinness-mission-substrate]), hold:¶

1. An approved task context: the task is durable and explicitly approved rather than only a session or token.¶

2. Stable binding and integrity: a native reference binds the controlling authority, acting actor, and immutable approved context, or a verifiable commitment to that context, and propagation or correlation rules carry the reference across parties without conferring authority.¶

3. Lifecycle gate with a reliance bound: only an active context supports new governed decisions at the binding's declared control point, and no decision or artifact outlives both its stated bound and the transition that ends the context.¶

4. Governance history: decisions and interactions are correlated to the stable reference in an ordered audit or governance record.¶

A design additionally provides structured-authority capabilities when two more properties hold:¶

1. Deterministic authority representation: credentials or decisions carry authority that an identified enforcement point can evaluate.¶

2. Monotonic derivation: derived and delegated authority only narrows, and widening requires a fresh approval or a drawdown already bounded by an approved ceiling.¶

A design provides Runtime-Enforced Mission capabilities when two further properties 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.¶

AAuth supplies the first four natively (its expires_at member carries the reliance bound), with its lifecycle gate scoped to PS endpoints and PS-mediated paths carrying the validated reference. The OAuth core supplies the structured-authority layer as well. Runtime and portable evidence remain separately claimed capabilities; the requirements below unpack the family mechanisms without implying every binding implements every one.¶

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 Mission Context binding: the Person Server as controlling authority, the exact-byte mission blob under AAuth's s256 commitment, native {approver, s256} propagation, and active-state gating on PS endpoints and the PS-asserted and federated paths. It defines no OAuth Authority Set or additional AAuth wire members.¶

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

oauth-mission-template:

Experimental: one consent to a task template's ceiling; each dispatch instantiates an ordinary Mission from it by policy, at machine speed, bounded by its own derived Authority Set and never exceeding the ceiling.¶

Lifecycle:¶

Status is the OAuth 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. AAuth keeps its native two-state lifecycle and uses mission-aauth-management for its corresponding status, termination, expiry, and delegation-tree surface. The expiry bound is AAuth's own expires_at, profiled by the expiry document ([I-D.draft-mcguinness-aauth-mission-expiry]).¶

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

mission-aauth-management:

AAuth-native status, permanent termination, optional expiry, and delegation-tree queries at the Person Server, keyed only by {approver, s256} and preserving AAuth's active and terminated states.¶

aauth-mission-expiry:

Profile of AAuth's expires_at mission lifetime bound (RFC 3339 precision, skew documentation, prompt termination). The base protocol enforces the bound on every Person Server decision path and caps every token carrying mission_s256; the AAuth binding requires the member on every mission.¶

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: the AuthZEN request and response mapping and the denial classification.¶

mission-runtime-evidence:

The binding-neutral Decision Evidence, Execution Evidence, and Refusal Record objects a decision-API binding's PDP and PEP emit, their integrity envelope, and retention.¶

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-capability-binding:

Binds an approved catalog-sourced entry (an MCP tool, an OpenAPI operation) to its capability source at derivation and refuses on drift at decision time, with the AuthZEN MCP profile's (COAZ) mapping for MCP deployments.¶

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

Work products:¶

oauth-mission-work-products:

Experimental: work-product provenance, attribution and not authority, and the non-transitive Mission-to-Mission handoff rule; a work product crossing into a Mission is input, re-evaluated under the receiver's Authority Set.¶

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

The AAuth binding's privacy posture is its own ([I-D.draft-mcguinness-mission-aauth]): the private mission blob never leaves the agent and the Person Server, the stable {approver, s256} reference is a correlation handle across every resource that sees it, and the mission log concentrates a detailed activity history at the Person Server, with the binding's minimization and retention duties applying there.¶

23. IANA Considerations

This document makes no IANA request.¶

24. Informative References

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

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

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

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

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

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

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

McGuinness, K., "Mission Audit Transparency", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-audit.html>.

[I-D.draft-mcguinness-mission-authority-server]

McGuinness, K., "Mission Authority Server", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-authority-server.html>.

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

McGuinness, K., "Mission-Bound Runtime Enforcement: AuthZEN Profile", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-authzen.html>.

[I-D.draft-mcguinness-mission-capability-binding]

McGuinness, K., "Mission Capability Binding", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-capability-binding.html>.

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

McGuinness, K., "Mission Open-World Discovery", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-discovery.html>.

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

McGuinness, K., "Mission-Aware Agent Harnesses", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-harness.html>.

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

McGuinness, K., "Mission Mandate", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-mandate.html>.

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

McGuinness, K., "Mission Consumption Metering", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-metering.html>.

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

McGuinness, K., "Mission Orchestration and Unwinding", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-orchestration.html>.

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

McGuinness, K., "Mission-Bound Runtime Enforcement", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-runtime.html>.

[I-D.draft-mcguinness-mission-runtime-evidence]

McGuinness, K., "Mission Runtime Evidence", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-runtime-evidence.html>.

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

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

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

McGuinness, K., "Mission Intent Shaping", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-shaping.html>.

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

McGuinness, K., "Mission Substrate Requirements", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-substrate.html>.

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

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

[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, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-ai-agent-instance-00>.

[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, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-client-instance-assertion-01>.

[I-D.draft-mcguinness-oauth-id-continuation-assertion]

McGuinness, K., "Identity Continuation Assertion for OAuth 2.0 Token Exchange", 2026, <https://datatracker.ietf.org/doc/draft-mcguinness-oauth-id-continuation-assertion/>.

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

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

[I-D.draft-mcguinness-oauth-mission-approval]

McGuinness, K., "Mission Deferred Approval for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-approval.html>.

[I-D.draft-mcguinness-oauth-mission-attenuation]

McGuinness, K., "Mission Offline Attenuation for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-attenuation.html>.

[I-D.draft-mcguinness-oauth-mission-child-delegation]

McGuinness, K., "Mission Child Delegation for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-child-delegation.html>.

[I-D.draft-mcguinness-oauth-mission-consent-evidence]

McGuinness, K., "Mission Consent Evidence for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-consent-evidence.html>.

[I-D.draft-mcguinness-oauth-mission-containment]

McGuinness, K., "Mission Containment for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-containment.html>.

[I-D.draft-mcguinness-oauth-mission-continuation]

McGuinness, K., "Mission Continuation: Authorization Continuity for Mission-Bound Authorization", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-continuation.html>.

[I-D.draft-mcguinness-oauth-mission-cross-domain]

McGuinness, K., "Mission Cross-Domain Projection for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-cross-domain.html>.

[I-D.draft-mcguinness-oauth-mission-expansion]

McGuinness, K., "Mission Expansion for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-expansion.html>.

[I-D.draft-mcguinness-oauth-mission-issuance-grant]

McGuinness, K., "Mission Issuance Grant for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-issuance-grant.html>.

[I-D.draft-mcguinness-oauth-mission-management]

McGuinness, K., "Mission Management for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-management.html>.

[I-D.draft-mcguinness-oauth-mission-progressive]

McGuinness, K., "Mission Progressive Authorization for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-progressive.html>.

[I-D.draft-mcguinness-oauth-mission-signals]

McGuinness, K., "Mission Lifecycle Signals for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-signals.html>.

[I-D.draft-mcguinness-oauth-mission-status]

McGuinness, K., "Mission Status and Lifecycle for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-status.html>.

[I-D.draft-mcguinness-oauth-mission-work-products]

McGuinness, K., "Mission Work Products", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-work-products.html>.

[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-06, 9 August 2026, <https://datatracker.ietf.org/doc/html/draft-zehavi-oauth-rar-metadata-06>.

[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, <https://datatracker.ietf.org/doc/html/draft-zhu-oauth-async-delegation-05>.

[RFC6749]

Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/rfc/rfc6749>.

[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, <https://www.rfc-editor.org/rfc/rfc8693>.

[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, <https://www.rfc-editor.org/rfc/rfc9126>.

[RFC9396]

Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, <https://www.rfc-editor.org/rfc/rfc9396>.

[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, <https://www.rfc-editor.org/rfc/rfc9943>.

Acknowledgments

This document is part of the Mission-Bound Authorization work and maps the structure that its profiles establish individually.¶

Author's Address