---
title: "The Mission Framework"
date: "2026-06-06T19:00:00-07:00"
lastmod: "2026-06-06T19:00:00-07:00"
description: "The substrate-neutral framework behind mission-bound authorization: a verb spine from propose to analyze, two enforcement chokepoints that are strictly stronger together, three bindings including the AS-optional Mission Authority Server and AAuth, and the division between fundamental principles and their accidental OAuth realization."
summary: "OAuth is the flagship binding because it is deployment reality, but the model does not depend on it. This advanced companion to the architecture series zooms out to the framework the profiles realize. A verb spine of nine verbs from propose to analyze, each owned by named documents. The fundamental-versus-accidental test: which ideas survive if OAuth disappears, and the answer is nearly all of them. Two chokepoints, issuance gating and runtime enforcement, that are strictly stronger together. And the pattern space of three bindings, the OAuth core, the standalone Mission Authority Server, and AAuth, with the portable Mandate as evidence across all of them."
slug: "the-mission-framework-and-the-blueprint"
tags:
  - "OAuth"
  - "Authorization"
  - "Agentic Identity"
  - "Mission-Bound Authorization"
  - "Intent-Based Authorization"
  - "AuthZEN"
  - "Internet-Draft"
---


{{< spine steps="intent,mission,authority,enforcement" >}}

{{< tldr >}}

- **The move.** The OAuth profiles are one binding of a substrate-neutral model, organized along a [verb spine](#the-framework-oauth-carries) from propose to analyze. The model survives a substrate change, which is the test of a framework rather than a feature, and the [AAuth binding](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-aauth.html) is the existence proof.
- **Fundamental versus accidental.** Which ideas survive if OAuth disappears? Nearly all of them: the layer, the laws, the vocabulary, the approved task with an integrity-anchored record, approval evidence, runtime containment. What is accidental is the realization: PAR, RAR, the claim names, the wire shapes.
- **Two chokepoints.** Issuance gating at the token layer and runtime enforcement at the action layer are strictly stronger together: a gap in PEP coverage is still bounded at the token layer, and an outstanding token is still stopped at the action layer.
- **The card analogy.** The network standard: what makes any bank's card work at any merchant. ([Where the analogy breaks](/notes/agents-need-a-corporate-card-not-a-blank-check/#where-the-analogy-breaks).)
- **The laws.** The framework restates all [five laws of delegated authority](/series/mission-bound-authorization/#the-five-laws-of-delegated-authority) beyond OAuth, and separates the fundamental principles from their accidental OAuth realization.
- **Specs (editor's copies).** [An Architecture for Mission-Bound Authorization](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-architecture.html) (the front door), [Mission Security Model](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-security-model.html), [Mission Authority Server](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-authority-server.html), [Mission Mandate](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-mandate.html), [Mission-Bound Authorization for AAuth](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-aauth.html), [Mission Substrate Requirements](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-substrate.html).

**Where this sits.** The advanced companion to the [architecture series](/series/mission-bound-authorization/): substrate independence, the bindings, and the pattern space, for architects and spec readers. Read [The Mission](/notes/the-mission-is-the-missing-abstraction/) first.

**Reading path.** ~8 minutes start to finish. Read in order.

{{< /tldr >}}

# Overview

The Mission is the durable, approval-backed record of the task ([The Mission Is the Missing Abstraction](/notes/the-mission-is-the-missing-abstraction/)), and the [Building Mission-Bound Authorization](/series/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](/notes/adopting-mission-bound-authorization/) and come back. The maturity and status claims here are as of July 2026, and the [Reference](/notes/mission-bound-authorization-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](https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/) 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](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-authority-server.html) as a peer binding, and an [AAuth binding](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-aauth.html) that hosts AAuth's native mission concept at its Person Server, with [Substrate Requirements](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-substrate.html) consolidating what any further binding must provide. The [Architecture document](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-architecture.html) 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](/notes/the-mission-is-the-missing-abstraction/), practice [approval integrity](/notes/mission-approval-integrity/) |
| **Authority projection** | Carries that authority onto instances, credentials, domains, and delegates without ever exceeding it | Authority | practice [delegation](/notes/mission-sub-agents-and-delegation/) |
| **Authority containment** | Checks every consequential action against the approved purpose at the point of use | Enforcement | practice [runtime enforcement](/notes/mission-bound-runtime-enforcement-profile/) |
| **Authority continuity** | Keeps reliance conditioned on the current state of the task, across time and across the runtime | Lifecycle and runtime | practice [lifecycle](/notes/mission-lifecycle-and-change/) and [agent runtime](/notes/mission-agent-runtime-and-audit/) |

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](/notes/mission-approval-integrity/) |
| Approve and record | How does a proposal become a committed, integrity-anchored Mission? | The issuance core, Consent Evidence, Deferred Approval | [The Mission](/notes/the-mission-is-the-missing-abstraction/), [approval integrity](/notes/mission-approval-integrity/) |
| Govern | How is state observed, changed, widened, and retired? | Status, Signals, Expansion, Completion | [Lifecycle](/notes/mission-lifecycle-and-change/) |
| Enforce each action | Is this concrete action allowed under the current Mission? | Runtime contract, AuthZEN binding | [Runtime enforcement](/notes/mission-bound-runtime-enforcement-profile/) |
| Run and wind down | Does the runtime stop when the Mission does, and what unwinds? | Harness, Orchestration | [Agent runtime](/notes/mission-agent-runtime-and-audit/) |
| Delegate | How does authority narrow across actors and instances? | The core's act chain, Child Delegation, Offline Attenuation | [Delegation](/notes/mission-sub-agents-and-delegation/) |
| Project | How is one Mission honored in another trust domain? | Cross-Domain Projection | [Delegation](/notes/mission-sub-agents-and-delegation/#crossing-authorization-domains) |
| Prove | What can a third party verify about what was approved and done? | Consent Evidence, Mandate, Audit Transparency | [Approval integrity](/notes/mission-approval-integrity/), [agent runtime](/notes/mission-agent-runtime-and-audit/), and below |
| Analyze | What must be trusted, and what breaks when each component is compromised? | Security Model | The [Reference's adversary model](/notes/mission-bound-authorization-reference/#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](/series/mission-bound-authorization/#the-five-laws-of-delegated-authority). 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](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-architecture.html) 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](https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-architecture.html#deployment) 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](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-authority-server.html)** (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](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-mandate.html)** (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](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-oauth-mission-cross-domain.html), one Mission honored in another trust domain through a single-hop, audience-scoped cross-domain grant. [Mission-Bound Authority](/notes/mission-sub-agents-and-delegation/#crossing-authorization-domains) 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](/notes/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.