Overview
The Mission is the durable, approval-backed record of the task (The Mission Is the Missing Abstraction), and the Building Mission-Bound Authorization series carries each of its controls at implementation depth: the approval that creates it, the authority projected from it, the enforcement that polices it, the lifecycle that governs it, and the runtime that honors its endings. This post zooms out to the framework those controls 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 July 2026, and the Reference carries the reconciliation date the series 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 the AI agent auth best practices describe is OAuth-shaped. But the object this series built is not an OAuth feature, and OAuth is no longer its only binding. The family now carries three: the OAuth core as the flagship, the standalone Mission Authority Server as a peer binding, and an AAuth binding that hosts AAuth’s native mission concept at its Person Server, with Substrate Requirements consolidating what any further binding must provide. 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 publication 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 | Approval integrity |
| Approve and record | How does a proposal become a committed, integrity-anchored Mission? | The issuance core, Consent Evidence, Deferred Approval | The Mission, approval integrity |
| Govern | How is state observed, changed, widened, and retired? | Status, Signals, Expansion, Completion | Lifecycle |
| Enforce each action | Is this concrete action allowed under the current Mission? | Runtime contract, AuthZEN binding | Runtime enforcement |
| Run and wind down | Does the runtime stop when the Mission does, and what unwinds? | Harness, Orchestration | Agent runtime |
| Delegate | How does authority narrow across actors and instances? | The core’s act chain, Child Delegation, Offline Attenuation | Delegation |
| Project | How is one Mission honored in another trust domain? | Cross-Domain Projection | Delegation |
| Prove | What can a third party verify about what was approved and done? | Consent Evidence, Mandate, Audit Transparency | Approval integrity, agent runtime, and below |
| Analyze | What must be trusted, and what breaks when each component is compromised? | Security Model | 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 series’ ideas survive if OAuth disappears. The answer is nearly all of them. The missing layer 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: the same object, laws, and lifecycle carried onto a non-OAuth substrate by swapping exactly those accidents. The strategic position, stated bluntly: OAuth is the adoption path because it is where the deployments are, AAuth may prove the cleaner native substrate, and the Mission model is built to survive either outcome. 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.
Two chokepoints, and the patterns they allow
The OAuth binding stacks two independent chokepoints, and the Architecture’s deployment patterns are combinations of them.
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. Together they are 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.
Two newer documents extend the pattern space:
- The Mission Authority Server (experimental: its PDP join is the family’s newest mechanism) is the standalone binding. A dedicated service implements the Mission Issuer role, derives no tokens, and the PDP joins each ordinary OAuth token to its Mission at the point of use. It serves the Status and lifecycle surfaces itself and is the deployment’s freshness source, and expansion and Child Mission creation ride its own submission surface with an authenticated-client binding in place of token possession. It is a peer binding with its own rationale (governance deliberately decoupled from token issuance, and one Mission Issuer can govern across many Authorization Servers) that also serves as the adoption bridge where the AS cannot yet change. The trade is explicit: Mission governance and per-action enforcement with zero AS change, at the cost of the token-layer chokepoint. Revoking a Mission in this mode stops nothing at the token layer, so enforcement rests entirely on PEP coverage.
- The Mission Mandate (advanced tier: its dependencies are ratified, and it is design to adopt when the cross-domain proof case arrives) answers that proof question. A Mission’s committed facts live on the record at its issuer, and a party outside that domain cannot verify what was approved short of a token-exchange hop or trust in the issuer’s records. The Mandate is a signed, portable, independently verifiable statement of those facts, minted by the Mission Issuer, with optional selective disclosure. The design line is the one this series has drawn everywhere: a Mandate is evidence, not a credential. Presenting one authorizes nothing.
The third extension of the pattern space is Mission Cross-Domain Projection, one Mission honored in another trust domain through a single-hop, audience-scoped cross-domain grant. Mission-Bound Authority covers it in full, because the multi-domain agent task is the common case, not the exotic one. It sits on the advanced tier rather than in the protocol MVP, with its dependencies tracked honestly: the identity-chaining work it profiles is approved and in the RFC Editor queue, and ID-JAG is a working-group document.
Where the framework leads
The framework is the map. The build order is the journey, and it is deliberately staged: crawl with the issuance core, walk with the protocol MVP on ratified substrate, run up the governed and high-assurance tiers as the deployment earns them. Adopting Mission-Bound Authorization carries that blueprint, the ecosystem to compose with, the operational surfaces you will own, and the pieces the community still has to standardize.
The so-what of the framework is what it does for the laws. It makes them portable: state them once, realize them per substrate, and hold every competing proposal to the same five.