---
title: "What Survives Without OAuth"
date: "2026-07-10T19:00:00-07:00"
lastmod: "2026-07-10T19:00:00-07:00"
description: "Part 1 of the handbook's concluding chapter: the substrate-neutral framework behind mission-bound authorization. Four functions that survive any substrate, a verb spine from propose to analyze owned by named documents, and the fundamental-versus-accidental test that separates the laws from their OAuth realization."
summary: "OAuth is the flagship binding because it is deployment reality, but the model does not depend on it. This part states the framework the profiles realize: four functions (compilation, projection, containment, continuity), a verb spine of nine verbs from propose to analyze, and the fundamental-versus-accidental test. 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."
slug: "what-survives-without-oauth"
tags:
  - "OAuth"
  - "Authorization"
  - "Agentic Identity"
  - "Mission-Bound Authorization"
  - "Internet-Draft"
series:
  - "weighing-mission-bound-authorization"
---


{{< 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.
- **The laws.** The framework restates all [five laws of delegated authority](/series/designing-mission-bound-authorization/#the-five-laws-of-delegated-authority) beyond OAuth, and separates the fundamental principles from their accidental OAuth realization.
- **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).)
- **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 Substrate Requirements](https://mcguinness.github.io/mission-bound-authorization/#go.draft-mcguinness-mission-substrate.html).

**Where this sits.** Part 1 of [the concluding chapter](/series/weighing-mission-bound-authorization/): the model beyond its bindings. [The Authority Control Plane](/notes/the-authority-control-plane/) carries where the layer sits operationally, and [The Convergence and the Wagers](/notes/the-convergence-and-the-wagers/) closes the handbook.

**Reading path.** ~5 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 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](/notes/adopting-mission-bound-authorization/) and come back. The maturity and status claims here are as of July 2026, and the [Reference](/notes/mission-based-authorization-field-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 the [AI agent auth best practices](https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/) describe is OAuth-shaped. But the object this handbook 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/from-a-request-to-an-approved-mission/) |
| **Authority projection** | Carries that authority onto instances, credentials, domains, and delegates without ever exceeding it | Authority | practice [delegation](/notes/mission-bound-authority/) |
| **Authority containment** | Checks every consequential action against the approved purpose at the point of use | Enforcement | practice [runtime enforcement](/notes/mission-bound-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](/notes/mission-lifecycle-and-change/) and [agent runtime](/notes/the-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 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 | [Approval integrity](/notes/from-a-request-to-an-approved-mission/) |
| 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/from-a-request-to-an-approved-mission/) |
| Govern | How is state observed, changed, widened, and retired? | Status (carrying completion), Signals, Expansion | [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/) |
| Run and wind down | Does the runtime stop when the Mission does, and what unwinds? | Harness, Orchestration | [Agent runtime](/notes/the-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-bound-authority/) |
| Project | How is one Mission honored in another trust domain? | Cross-Domain Projection | [Delegation](/notes/mission-bound-authority/#crossing-authorization-domains) |
| Prove | What can a third party verify about what was approved and done? | Consent Evidence, Mandate, Audit Transparency | [Approval integrity](/notes/from-a-request-to-an-approved-mission/), [agent runtime](/notes/the-agent-runtime-and-audit/), and [Part 2](/notes/the-authority-control-plane/) |
| Analyze | What must be trusted, and what breaks when each component is compromised? | Security Model | The [Reference's adversary model](/notes/mission-based-authorization-field-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 handbook's ideas survive if OAuth disappears. The answer is nearly all of them. The [missing layer and its five laws](/series/designing-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, and [the closing part](/notes/the-convergence-and-the-wagers/#aauth-the-substrate-that-grew-the-object) carries what AAuth itself did with the object. 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.

Where the model sits operationally is the next part: [The Authority Control Plane](/notes/the-authority-control-plane/), the two chokepoints, the three bindings, and the structural mapping platform engineers reach for unprompted.