Overview
The Mission is the durable, approval-backed record of the task (The Mission Is the Missing Abstraction), and the chapters before this one made the argument at every altitude: the intuition, the architecture, the wire, the outside framings. This concluding chapter zooms out to the framework those chapters realize, because the model does not depend on OAuth even though the profiles do. If you want the build order first, read Adopting Mission-Bound Authorization and come back. The maturity and status claims here are as of October 2026, and the Reference carries the reconciliation date the handbook tracks.
The framework OAuth carries
OAuth earned its place as the first substrate for one reason: it is where the deployments are. The Authorization Server already exists, the token machinery already works, and the agent identity stack that the WIMSE working group’s AI Identity Management System (AIMS) proposes as best practice is OAuth-shaped: the agent is an OAuth client, and the delegating user is the token’s subject. But the object this handbook built is not an OAuth feature, and OAuth is no longer its only binding. The family now carries five peer bindings: the OAuth binding, the first, on the most deployed infrastructure; the standalone Mission Authority Server, a controller over the OAuth Mission data model where an estate’s Authorization Servers cannot issue Mission-bound tokens; an AAuth binding that hosts AAuth’s native mission concept at its Person Server; and UMA 2.0 and GNAP sketches. The MAS imports the OAuth Mission record, so it is a peer deployment topology rather than an independent model; AAuth is the binding that shows the model does not depend on OAuth. The sketches are the first two bindings authored against Substrate Requirements, which consolidates what any further binding must provide: a contextual-governance kernel every binding supplies, and eight optional capabilities a binding claims through its Mission Substrate Statement. The OAuth binding makes no substrate-conformance claim and instead publishes an informative Mapping Assessment of itself in the same form. The Architecture document states the model on its own terms, and it is the right front door for a newcomer who wants the whole shape before any wire detail.
The coarsest map of the layer is four functions, and they survive any substrate:
| Function | What it does | Spine stage | Where |
|---|---|---|---|
| Authority compilation | Turns approved intent into bounded, integrity-anchored authority | Intent, Mission | The Mission, practice approval integrity |
| Authority projection | Carries that authority onto instances, credentials, domains, and delegates without ever exceeding it | Authority | practice delegation |
| Authority containment | Checks every consequential action against the approved purpose at the point of use | Enforcement | practice runtime enforcement |
| Authority continuity | Keeps reliance conditioned on the current state of the task, across time and across the runtime | Lifecycle and runtime | practice lifecycle and agent runtime |
These names are built to survive the Mission. If a different object wins the standards conversation, the layer still needs compilation, projection, containment, and continuity, and this handbook is a complete worked example of all four.
The finer decomposition is a verb spine. Each verb answers one question, sits on one trust boundary, and is owned by named documents:
| Verb | The question | Owned by | Where |
|---|---|---|---|
| Propose | How does a request become a candidate Mission Intent? | Intent Shaping, Intent Submission Evidence, Request Provenance | Approval integrity |
| Approve and record | How does a proposal become a committed, integrity-anchored Mission? | The five bindings (OAuth 2.0, the Mission Authority Server, AAuth, UMA 2.0, GNAP), Substrate Requirements, the Resource Access Profile, Issuance Grant, Consent Evidence, Deferred Approval, Approval Revision, Template, Approval Governance | The Mission, approval integrity |
| Govern | How is state observed, changed, widened, and retired? | Status and Lifecycle, Status List, Lifecycle Signals, Management, Entry Discharge, Expansion, Progressive Authorization, Containment, Derivation Limits, Control-Plane Consistency, Open-World Discovery, Consumption Metering, and AAuth Mission Management and Expiry | Lifecycle |
| Enforce each action | Is this concrete action allowed under the current Mission? | Mission-Bound Runtime Enforcement with its OAuth 2.0 and AuthZEN profiles, Runtime Evidence, Capability Binding, Transaction Authorization | Runtime enforcement |
| Run and wind down | Does the runtime stop when the Mission does, and what unwinds? | Agent Harnesses, Orchestration and Unwinding | Agent runtime |
| Delegate | How does authority narrow across actors and instances? | The OAuth binding’s delegated token exchange and its act chain, Child Delegation, Offline Attenuation, Cross-Organizational Delegation | Delegation |
| Project | How is one Mission honored in another trust domain? | Cross-Domain Projection, Cross-Organizational Delegation | Delegation |
| Continue | How does authorization continue when the acting identity must be re-established at the next hop, or after the original credential is gone? | Mission Continuation, with its identity-continuity transports | Delegation |
| Prove | What can a third party verify about what was approved and done? | Consent Evidence, Approved-Set Verification, Work Products, Runtime Evidence, Mandate, Audit Transparency, Evidence Envelope | Approval integrity, agent runtime, and the control plane |
| Analyze | What must be trusted, and what breaks when each component is compromised? | Security Model, the Agent Access Model mapping, the Architecture | The Reference’s adversary model |
The spine the architecture follows, Intent to Mission to Authority to Enforcement, is the temporal reading of the same map: what happens first when a request arrives. The verb spine is the structural reading: which component owns which question. Both readings survive a substrate change, which is the test of a framework rather than a feature.
Fundamental versus accidental
A sharper version of that test is to ask which of this handbook’s ideas survive if OAuth disappears. The answer is nearly all of them. The layer with no standard form and its five laws. Authority compilation, projection, containment, and continuity. The approved task with an integrity-anchored record and a lifecycle. Approval evidence. Runtime containment at the point of use. Session continuity that is never authority. Those are architectural commitments, not OAuth features.
What is accidental is the realization: PAR as the submission channel, RAR as the Authority Set serialization, the mission claim’s name, the JWS envelopes, Security Event Tokens for signals, the AuthZEN wire shape. Any of those could be swapped without touching a law. The AAuth binding is the existence proof: it carries the kernel (the approval, the Mission reference, the active-state gate, and the ordered mission log) onto a non-OAuth substrate with no new AAuth wire members, by swapping exactly those accidents. It realizes authority in AAuth’s own terms rather than a portable Authority Set: scopes, resource tokens, and optional R3, with AAuth’s two lifecycle states, active and terminated, and the Person Server’s contextual gate as the per-action control on the paths it mediates. The closing part carries what AAuth itself did with the object. That division is why the Architecture document states the model on its own terms and the bindings realize it, and it is the standard to hold any competing proposal to. An alternative that replaces the accidents is a realization. An alternative that drops a law is a gap.
The ontology direction also falls on the accidental side. On OAuth, authority is client-proposed and enumerated: the client asks in types the issuer must understand. On AAuth, the optional Rich Resource Requests (R3) companion, an exploratory individual draft (-00, September 28, 2026), inverts it, with the resource declaring its own operations, meaning, and consequences in a resource-owned vocabulary, and the resource token committing to that declaration by hash. The AAuth binding maps nothing onto R3 operations. Which party proposes the ontology is substrate. What survives is the fundamental beneath both: meaning binds at approval, is enforced at the point of use, and translation across vocabularies never widens. Authority compilation needs a vocabulary source, and the framework does not care which direction it arrives from, only that the record commits it. It is a realization, not a law.
Where the model sits operationally is the next part: The Authority Control Plane, the two chokepoints, the pattern space of bindings, and the structural mapping that platform engineers reach for unprompted.