---
title: "Mission-Bound OAuth MVP"
date: "2026-05-22T14:00:00-07:00"
lastmod: "2026-05-22T14:00:00-07:00"
description: "A minimum OAuth profile for agent tasks. The Authorization Server captures user-approved intent as a durable Mission record, binds every derived token to it, and gates refresh, exchange, and cross-AS derivation on Mission state. Everything else composes with existing OAuth."
summary: "The MVP adds five protocol surfaces on top of existing OAuth: a mission_intent RAR envelope, a resource_access RAR type, a Mission record at the AS, a mission claim on access tokens, and Mission-state enforcement across every derivation path. The result is durable task authority that survives token lifetimes, cross-AS fan-out, runtime escalation, and business-event termination."
slug: "mission-bound-oauth-mvp"
tags:
- "OAuth"
- "Authorization"
- "Agentic Identity"
- "Mission-Bound OAuth"
- "Intent-Based Authorization"
- "AuthZEN"
- "Internet-Draft"
series:
- "mission-bound-oauth-mvp"
---
[The Mission is the Missing Abstraction for Agents](/notes/the-mission-is-the-missing-oauth-abstraction/) made the conceptual case. This post adds the Mission as a durable governance layer to the existing OAuth stack, without waiting for a new agent-native protocol substrate. The [Runtime Enforcement Profile](/notes/mission-bound-oauth-runtime-enforcement-profile/) adds the runtime enforcement layer on top. [Least-Privilege MCP Tool Calls Need a Mission](/notes/least-privilege-mcp-tool-calls/) applies the full stack to MCP.
Mission-Bound OAuth is not one giant profile. It is a ladder. This post defines the wire-level minimum. Later profiles can add same-IdP chain continuation, portable receipts, tool manifests, purpose registries, attestation, actor revocation, and formal policy projection.
Agent workflows expose a missing OAuth layer: durable task authority.
Consider a board-packet agent. It starts with authority to read calendar context and draft documents, then discovers that it needs finance data, CRM context, and approval to publish the final packet. Today that usually becomes one of three bad patterns: broad pre-consent, repeated reauthorization prompts, or proprietary approval glue outside the authorization protocol. OAuth can mint the tokens, but it has no standard object for "the task the user approved" that survives token lifetimes, resource fan-out, runtime escalation, and business-event termination.
The [Mission-Bound OAuth architecture](/notes/mission-bound-oauth-architecture/) is intentionally broad. It describes the long-term shape: Mission objects, lifecycle states, projected artifacts, delegation, cross-domain handoff, FGA integration, audit, governance, and policy enforcement. That is the destination. It is not the first thing a working group should try to ship.
This post separates that architecture into two layers. The MVP binds OAuth tokens and derived assertions to Mission state. The optional [Runtime Enforcement Profile](/notes/mission-bound-oauth-runtime-enforcement-profile/) makes Mission authority the runtime policy input for consequential agent actions, with the Runtime Enforcement Profile defining what "consequential" means at the runtime layer. The goal is to make intent-based authorization deployable on existing OAuth infrastructure without waiting for a new agent-native protocol substrate.
The short version:
- Capture intent as structured `authorization_details`: a `mission_intent` envelope plus per-resource `resource_access` entries.
- Persist the approved intent as a Mission record at the Authorization Server.
- Put an opaque `mission` claim (with `id` and `origin`) on access tokens derived from that record.
- Gate refresh, exchange, introspection, and assertion validation on Mission state.
- Terminate the Mission independently of token expiry.
Everything else should either compose with existing OAuth work or wait for later profiles.
## Terminology
- **Mission** — the durable authority record at the AS representing what the user approved.
- **Mission Authority** — the AS in its role as the canonical source of Mission state and bounds.
- **Mission record** — the AS-side data structure holding the approved `authorization_details`, state, hashes, and audit context.
- **`mission` claim** — the JWT claim carrying `id` and `origin`, plus AS-extended fields on introspection.
- **`mission_intent`** — the RAR envelope (`purpose`, `mission_expiry`, `context`).
- **`resource_access`** — the generic per-resource RAR type (`resource`, `actions`, `constraints`).
- **PDP (Policy Decision Point)** — the component that evaluates a specific request against the Mission's approved bounds and local policy. May be co-located with the AS or run separately. The [Runtime Enforcement Profile](/notes/mission-bound-oauth-runtime-enforcement-profile/) defines four PDP deployment modes (AS-hosted, RS-hosted, tenant governance, federated). The MVP treats the PDP as one logical component without committing to a deployment shape.
- **Orchestrator** — the agent client that converts a user goal into a Mission Proposal and submits it via PAR.
- **Resource AS** — an Authorization Server at a downstream audience that accepts a Mission-bound ID-JAG and issues a local access token. Distinct from the originating AS.
- **ID-JAG** — Identity Assertion JWT Authorization Grant (`draft-ietf-oauth-identity-assertion-authz-grant`), the cross-AS form of a Mission projection.
- **Mission `cnf`** — the canonical sender-constraint key bound to the Mission record at activation, from which per-derivation token `cnf` (RFC 7800) values are derived or to which they conform. The Mission `cnf` is stable across the Mission's lifetime. Per-token `cnf` may vary (for example, on sub-agent delegation) but must trace to the Mission `cnf` or to a structured delegation under it.
In the board-packet example, the before and after:
| Stage | Without Mission binding | With the MVP |
| --- | --- | --- |
| Initial approval | The agent asks for broad document, calendar, finance, CRM, and signing access because it might need them later. | The agent submits a `mission_intent` envelope plus per-resource `resource_access` entries covering the initial document, calendar, and company-profile resources. |
| Runtime discovery | When finance data is needed, the platform either fails, prompts again through proprietary UX, or relies on standing access. | The out-of-bounds finance request becomes a requestable denial and escalation workflow. |
| Cross-AS access | Each Resource AS sees its own token request with limited task continuity. | A Mission-bound ID-JAG carries a narrowed projection tied to the same `mission.id`. |
| Completion or stop | Tokens age out independently; task state lives in application logic. | The Mission transitions state, and future refresh, exchange, and assertion validation fail. |
[AAuth](/notes/aauth-now-has-a-mission-layer/) is the cleaner agent-native direction. Signed agent requests, PS-mediated approval, mission-aware choreography, and native interaction surfaces. The AAuth stack pairs with its own Mission layer. This MVP is the OAuth-side counterpart for deployments that cannot wait for a clean-slate substrate. Part 4 of this series compares the two stacks at the operation layer. This MVP does not try to make OAuth agent-native. It defines the smallest standards-composable authority layer that lets existing OAuth deployments bind tokens to an approved task.
Why now? Because the needed pieces are finally close enough to compose. RAR and PAR can carry structured intent. JWT access tokens can carry a Mission handle. Token Exchange plus Identity Chaining can derive audience-specific artifacts, with ID-JAG for user-authenticated flows and the Transaction Token Chaining Profile for Txn-Token-rooted flows. Transaction Tokens themselves preserve intra-trust-domain call-chain context as transient projections of the durable Mission. AuthZEN Access Request can turn runtime denial into governance escalation. Introspection, revocation, and shared signals can propagate lifecycle state. The missing piece is the binding layer that makes them act like one task authority system instead of unrelated protocol features.
# Scope
The MVP has one job: turn a user's approved intent into a durable authority record that every derived token remains bound to.
That is the minimum useful version of intent-based authorization. The system does not merely ask for a bundle of scopes such as "calendar write" or "files read." It asks for authority to pursue a specific purpose, bounded by a Mission envelope plus structured per-resource authorities and an overall lifetime. The Authorization Server validates that proposed intent, renders it for approval, records the approved mandate, and ensures that every later token derivation stays inside it.
The outcome is a protocol-visible link between three things that are usually disconnected:
- what the user meant to authorize;
- what the Authorization Server approved and can later revoke; and
- what each access token, ID-JAG, sub-agent token, or exchanged token is allowed to do.
That moves the ball forward in a concrete way. Today, an agent can often receive broad OAuth authority and then rely on application logic, prompt discipline, or out-of-band audit to stay within the user's task. Under the MVP, the task itself becomes an authorization object at the AS. The AS can gate refresh, exchange, escalation, and termination against that object, while existing resource servers can continue accepting ordinary OAuth tokens.
This matters most when one task fans out across multiple resources and multiple authorization servers. A single user intent such as "prepare the quarterly board packet" might require calendar access, document access, CRM access, finance-system access, and a signing workflow, each protected by a different Resource AS. The MVP gives the originating AS a Mission record for the user's approved mandate, then lets each downstream Resource AS receive a narrowed, audience-specific assertion or token that still carries the same `mission.id`. The result is one user-approved Mission, many resource-specific tokens, and a common lifecycle gate across the whole task.
It adds five things at the core, and a small set of adjacent features that compose with the core.
**MVP Core** (the irreducible minimum):
| Addition | Where it lives | Purpose |
| --- | --- | --- |
| `mission_intent` | RAR `authorization_details` type | Mission envelope: `purpose`, `mission_expiry`, cross-cutting `context` |
| `resource_access` | RAR `authorization_details` type | Generic per-resource authority: `resource`, `actions`, `constraints`. Deployments MAY substitute ecosystem-specific RAR types where available |
| Mission record | Authorization Server | Durable authority record: state, approved intent, bounds, audit context |
| `mission` | Access-token claim (object: `id`, `origin`) | Opaque handle back to the Mission record, plus the originating AS |
| Mission-state gate | Token issuance, refresh, exchange, assertion validation, introspection | Prevents derivation when the Mission is not active |
A deployment that ships exactly these five surfaces reaches Conformance Level 1. The MVP Core is what the I-D `draft-mcguinness-oauth-mission-bound-minimum-profile` standardizes as MUST-level.
**Adjacent features** also defined in this post, but composable extensions on top of Core:
| Feature | Purpose | Conformance contribution |
| --- | --- | --- |
| Mission Expansion (successor Mission) | Authority grows by spawning a new Mission with `mission.supersedes`; original Mission cannot mutate | Stays at Level 1 |
| Mission introspection extensions (RFC 7662 extended with Mission state) | Lets RS-D audiences check Mission state per request | Level 3 |
| Cross-AS projection via ID-JAG or Txn-Token Chaining | One Mission projects to many Resource ASes | Level 2 |
| SSF/CAEP Mission state events | Event-driven lifecycle propagation | Level 3 |
| Governance inventory + Mission lifecycle operations | User-visible inventory and admin lifecycle ops; the wire shape of a management API is later work | Level 1 minimum capability, refined at higher levels |
| Resource Server tiers (RS-A through RS-D) | Per-RS adoption gradient | Spans Level 1 to Level 3 |
| Audit evidence handles (`evidence_id`, `proposal_hash`, `consent_rendering_hash`) | Cryptographic anchors for post-hoc audit | Level 1 minimum |
| Tenant binding | Multi-tenant safety | Required at every level when multi-tenant |
The MVP Core plus any subset of adjacent features is a valid deployment shape. The companion [Runtime Enforcement Profile](/notes/mission-bound-oauth-runtime-enforcement-profile/) defines what additional surfaces are needed for Levels 4 and 5.
The minimum registration surface is small: two RAR types (`mission_intent` for the envelope, `resource_access` for generic per-resource authority), one JWT claim (`mission`, an object), one grant-profile identifier, and a `mission_state` extension field on the token-endpoint error response (plus the same field on introspection) to signal inactive Mission state. Deployments that use event-driven revocation also need Mission state event identifiers, but those are not required for the minimum issuance and derivation path.
Deferred approval, AuthZEN escalation, CIBA, and SSF/CAEP are composition points the MVP already names. Mission-state introspection is part of the profile only where an AS or Resource AS chooses an introspection freshness model. Full receipt profiles, formal policy compilation, governed purpose registries, and standardized management APIs are later profiles or part of the Runtime Enforcement Profile.
The deliberate choice in this draft is to keep Mission metadata and resource authority in separate, sibling `authorization_details` entries. `mission_intent` is the envelope; `resource_access` (or an ecosystem-specific RAR type) carries per-resource authority. This composes naturally with RAR ecosystems that will define their own resource types over time, without making `mission_intent` a god-object that has to encode every resource's authority taxonomy.
RAR is the proposal format, not the lifecycle authority. Without a Mission record, approved `authorization_details` are trapped inside one authorization transaction or one issued token. The Mission record is what lets later refresh, exchange, introspection, assertion validation, and Resource AS issuance evaluate the same approved task authority over time.
## In Scope
The MVP covers:
- Mission creation from a structured authorization request.
- Mission lifecycle states: `pending_approval`, `active`, `suspended`, `revoked`, `expired`, `completed`, and `rejected`.
- Access tokens carrying the `mission` claim.
- Refresh and token exchange checking Mission state before issuing derived tokens.
- Cross-audience and cross-AS derivation using Token Exchange and ID-JAG.
- Optional introspection and SSF/CAEP propagation for Mission state.
- A user-visible inventory and revocation model for active Missions.
## Out of Scope
The MVP deliberately does not standardize:
- Mission graphs, sub-Missions, or budget delegation.
- A portable cross-domain Mission object.
- Mission template registries or global purpose URI governance.
- A standard internal Authority Model schema.
- OpenFGA, Zanzibar-style, Cedar-specific enforcement profiles, or full AuthZEN PDP policy modeling, at the MVP wire layer.
- Hard real-time revocation for resource servers that do not introspect or consume events.
- A fully standardized approval-receipt format.
Those are important, but they do not have to block the first useful protocol profile. The companion [Runtime Enforcement Profile](/notes/mission-bound-oauth-runtime-enforcement-profile/) reclaims several of these (AuthZEN PDP composition becomes normative, tool-and-action binding and portable receipts arrive as Optional Modules), and Part 4 applies the result to MCP. The "out of scope here" framing is bounded to the MVP wire layer.
## Key Use Cases
Five concrete cases the MVP newly enables. The companion [Runtime Enforcement Profile](/notes/mission-bound-oauth-runtime-enforcement-profile/) adds runtime-enforcement cases on top.
### One user intent, many Resource ASes
A board-packet agent needs calendar context, document drafting, CRM data, finance figures, and a signing workflow, each protected by a different Resource AS at a different vendor.
- **Today:** each Resource AS sees its own OAuth flow with its own approval; the user approves five times or the agent over-pre-consents; no shared task identity across the five tokens; revocation requires hunting down every token at every AS.
- **MVP delivers:** one user-approved Mission at the originating AS projects to many resource-specific tokens, all carrying the same `mission.id` and `mission.origin`. Cross-AS handoff via Token Exchange + ID-JAG preserves the Mission claim. Revocation at the originating AS terminates derivation across every audience.
- **Enabling features:** `mission_intent` envelope + `resource_access` entries, `mission` claim on access tokens and ID-JAGs, RFC 8693 Token Exchange to ID-JAG, Multi-AS Validation, `mission.origin` for cross-AS introspection.
### Mid-task scope expansion without restarting the workflow
Halfway through preparing the packet, the agent discovers it needs finance data from a Resource AS that was not in the original approval.
- **Today:** the agent either fails (and the user starts over with a broader approval up front), or the platform pops a re-prompt at exactly the wrong moment, or the agent already had standing access it should not have had.
- **MVP delivers:** the out-of-bounds denial becomes a requestable denial via AuthZEN Access Request. The deployment's approval workflow evaluates the expansion out-of-band. On approval, the AS creates a successor Mission with `mission.supersedes` pointing to the prior `mission.id`, and the prior Mission transitions to `completed`. On denial, the prior Mission stays active and finance access remains blocked under this Mission until a successor Mission is created. No restart, full audit lineage.
- **Enabling features:** `AuthZEN Access Request`, Mission Expansion path, `mission.supersedes` chain, deferred-code-style approval hold, `consent_rendering_hash` over the revised view.
### Long-running task revocation independent of token expiry
A user wants to stop an in-flight agent task. Refresh tokens have hours of life left and Resource ASes' local tokens have minutes.
- **Today:** revocation is per-token, per-AS. Stopping the agent requires hunting each AS, and access tokens stay valid until natural expiry. Application-layer task state has no connection to OAuth lifecycle.
- **MVP delivers:** Mission state is the lifecycle gate. Revoking the Mission at the originating AS terminates all future derivation. SSF/CAEP events propagate the revocation to Resource ASes that subscribe; introspection-capable RSes see the state on next check. The orchestrator's task ends because no new tokens can be derived, even if currently-issued tokens have not yet expired.
- **Enabling features:** Mission state machine (`revoked`, `suspended`, `completed`, `expired`), Mission-state-gated refresh and exchange, SSF/CAEP propagation, RFC 7009 revocation, user-visible Mission inventory.
### Deployment-defined circuit breaker on runaway agent spend
An agent hits a hallucination loop and starts burning API budget. Without a hard cap, it can rack up thousands of dollars in minutes.
- **Today:** no standardized budget primitives. Deployments invent ad-hoc extensions; spending caps live in proprietary middleware that does not compose with revocation. Discovery of overspend often happens at the invoice.
- **MVP delivers:** a standard place to carry cross-cutting Mission constraints in `mission_intent.context`, plus a rule that understood constraints become hard bounds for derivation and unknown constraints must be preserved or refused. A deployment or ecosystem can define `max_budget`, `currency`, `max_calls`, or `max_duration` semantics and have the AS enforce them at derivation time.
- **Enabling features:** `mission_intent.context`, registered or deployment-defined narrowing semantics, AS-side counters where the deployment defines them, Mission-state-gated refresh and exchange.
- **Caveat:** AS-side enforcement bounds the count of derivation events (refresh, exchange, ID-JAG issuance), not per-action API spend. The Runtime Enforcement Profile provides per-action enforcement where the underlying budget needs to be checked at the resource boundary.
### Auditable per-action provenance
A governance team needs to reconstruct what an agent did under a specific Mission: every action, every actor in the chain, and proof that the user actually approved what the agent claimed.
- **Today:** audit logs are stitched together by hand from per-Resource-AS logs. No shared task identifier across hops. No cryptographic anchor on what the user actually consented to. Sub-agent attribution depends on whether the deployment wrote it down.
- **MVP delivers:** every Mission lifecycle and derivation event produces an audit record keyed on `mission.id`, with `mission.origin`, `proposal_hash` (canonical hash of what was approved), and `consent_rendering_hash` (hash of what the user saw). Cross-AS records share the same `mission.id`, so stitching is by exact-match join, not heuristic. Sub-agent paths carry an `act` chain.
- **Enabling features:** `mission.id` + `mission.origin` (shared task identity), `proposal_hash` + `consent_rendering_hash` (cryptographic consent anchors), `evidence_id` (handle to confidential evidence), `act` chain on sub-agent paths, SSF/CAEP events.
# Authority Pipeline
Mission-Bound OAuth separates layers that are usually collapsed. Read top to bottom. Trust enters at AS validation.
```text
User prompt
↓ (LLM-driven, untrusted)
LLM-shaped intent proposal
↓ (orchestrator submits at PAR)
AS-validated Mission Proposal
↓ (user consents to rendered version)
User-approved authorization_details
↓ (AS creates Mission record + proposal_hash + consent_rendering_hash)
Mission record (the canonical authority object)
↓ (AS projects to audience-specific artifacts)
Token / ID-JAG / Txn-Token projections
↓ (PDP evaluates each consequential action)
PDP runtime decision
↓ (PDP writes per-decision evidence)
Decision evidence / receipt
```
The Mission record is the canonical authority. Tokens, ID-JAGs, and Txn-Tokens are *projections* of it. Policy decisions and receipts are *consequences* of evaluating against it. The MVP defines the upper half of this pipeline (proposal through projections); the [Runtime Enforcement Profile](/notes/mission-bound-oauth-runtime-enforcement-profile/) defines the lower half (PDP decisions and evidence).
# Conformance Ladder
Mission-Bound OAuth is designed for incremental adoption. A deployment can sit at any of these levels and gain value; higher levels add capability without invalidating lower ones.
| Level | What it delivers | Required surface |
| --- | --- | --- |
| **Level 0: OAuth-only.** | No Mission awareness. Baseline OAuth 2.0 / OIDC. | Existing OAuth deployment. |
| **Level 1: Mission-bound issuance.** | AS stores a Mission, issues Mission-bound tokens, gates refresh and exchange on Mission state. Works with RS-A audiences. | MVP Core (this post): `mission_intent` and `resource_access` RAR types, Mission record, `mission` claim, Mission-state gate. |
| **Level 2: Mission-aware Resource AS.** | A Resource AS validates Mission-bound assertions and issues narrowed local tokens. Cross-AS Mission lifecycle is preserved. | Level 1 + Multi-AS Validation rules + assertion profile (ID-JAG for user flows, Txn-Token Chaining for Txn-Token-rooted flows). |
| **Level 3: Mission-aware Resource Server.** | A Resource Server evaluates OAuth-protected requests against Mission bounds at request time. RS-B or higher. | Level 2 + Authority Model subset rule enforcement at the Resource Server or Resource AS boundary; AuthZEN Access Evaluation is a composition option, not a MVP requirement. |
| **Level 4: Full Runtime Enforcement.** | Every consequential action, including local tool calls, is evaluated against compiled Mission policy and produces decision evidence. | Level 3 + Runtime Enforcement Profile Core: compiled policy artifact, MUST-level runtime gate, requestable denial, per-decision evidence handle. |
| **Level 5: Verifiable governance.** | Portable cryptographic receipts, tool-manifest signatures, attestation-bound `cnf`, governed purpose registries, actor eviction. | Level 4 + optional modules from the Runtime Enforcement Profile (Decision Receipt, Tool Binding, Purpose Registry, Attestation, etc.). |
Not every deployment must implement Level 5 on day one. Level 1 gets AS-side intent binding and lifecycle control immediately. The other levels are opt-in maturity.
# Solution Overview
The Mission is the durable authority. Tokens are projections of it.
The basic flow:
1. The user gives an agent a goal.
2. The orchestrator turns that goal into a structured Mission Proposal and posts it to the AS through PAR as an `authorization_details` array containing a `mission_intent` envelope plus per-resource authority entries.
3. The AS validates the proposal against client registration and deployment policy, renders it for the user, and on approval creates an `active` Mission record bound to the authorization code.
4. The token endpoint issues an access token carrying the `mission` claim.
5. Refresh and exchange succeed only while the Mission remains `active`.
6. Cross-audience or cross-AS work derives ID-JAGs carrying the same `mission.id`.
7. Revocation, suspension, completion, or expiry stops future derivation even if previously issued tokens have not expired.
The interaction model has two paths, plus an out-of-band approval channel. Deferred code is the bootstrap path: if the AS cannot approve the Mission synchronously, the authorization flow can hold the Mission in `pending_approval` until user, admin, or risk review completes. AuthZEN Access Request is the escalation path: if runtime authorization discovers that the current Mission is not broad enough, the denial can become a requestable governance workflow instead of a terminal error. **In the MVP, the AuthZEN Access Request escalation is SHOULD-level. The [Runtime Enforcement Profile](/notes/mission-bound-oauth-runtime-enforcement-profile/) promotes it to MUST.** CIBA sits behind either path when the missing input is fresh out-of-band user authentication or consent. CIBA is an approval channel, not the Mission governance model.
A deployment uses CIBA when the user is not present in the orchestrator's session and needs to be reached on another device or channel. Concrete examples: an enterprise admin must approve a Mission Expansion to access financial data, but the admin is in a different timezone and reachable only through a mobile push notification; or the user authorized the original Mission on a desktop session but the agent needs fresh step-up authentication for a high-risk action and the user is now on their phone. CIBA carries the fresh authentication or consent decision back to the AS, which then completes the deferred code path or the AuthZEN Access Request workflow. CIBA does not create or modify Mission state. It carries a user-side input that the Mission lifecycle then acts on.
```mermaid
sequenceDiagram
actor U as User
participant O as Orchestrator
participant AS as Authorization Server
participant RS as Resource Server
U->>O: Prompt / goal
O->>AS: PAR with authorization_details
mission_intent + resource_access
AS->>U: Render Mission Proposal
U-->>AS: Approve
Note over AS: Create Mission record
state = active
mission.id = msn_...
AS-->>O: Authorization code
O->>AS: Token request
AS-->>O: Access token with mission claim
O->>RS: API call with access token
RS-->>O: Resource response
```
The Resource Server does not have to understand Missions on day one. A normal RS can validate audience, expiry, scope, and `authorization_details` as it already does, while the Mission gate fires at the originating AS before new tokens or ID-JAGs are minted. Mission-aware Resource AS and RS deployments can add introspection, event consumption, Cedar evaluation, or actor-receipt validation later.
The originating AS therefore has a baseline obligation: it MUST narrow issued scopes, audiences, and authorization details to the approved Mission, so even OAuth-only resource servers receive least-privilege tokens. Full request-time intent enforcement requires a resource server that understands `authorization_details`, a compiled policy, or Mission state.
# Worked Example
Before the mechanics, a concrete walkthrough. Concepts referenced here (Mission Expansion, ID-JAG, `proposal_hash`, sub-agent delegation) are defined in detail in the sections that follow; the example sets up intuition.
The user asks: "prepare the quarterly board packet and route it for approval."
Without a Mission layer, the agent platform usually has to choose between over-granting up front, interrupting the user every time a new resource appears, or wiring a proprietary approval workflow around OAuth. The token layer can answer whether the agent has `documents.read` or `finance.read`. It cannot answer whether this particular finance access is still inside the board-packet task the user approved.
With the MVP:
1. The orchestrator translates the prompt into a `mission_intent` envelope with `purpose=urn:example:mission:board-packet`, `mission_expiry=2026-06-05T12:00:00Z`, and a `context` carrying `classification=confidential`. It pairs the envelope with `resource_access` entries for calendar context, document drafting, and internal company-profile data. Each `resource_access` binds a resource to the actions and constraints that apply to it.
2. The orchestrator posts the proposal through PAR with an `idempotency_key`.
3. The AS validates the proposal against client registration and policy. If the Mission requires human, admin, or risk review, deferred code holds the Mission in `pending_approval` until the decision completes.
4. On approval, the AS creates `mission.id=msn_01HX4Y...` in `active` state, stores the approved `authorization_details` array, computes `proposal_hash` over it, and issues an access token bound to the Mission.
5. The agent drafts the packet using audience-specific tokens for the approved document and calendar resources.
6. The agent discovers that the packet needs finance data from `https://finance.example.com`, which was not in the approved `resource_access` entries. The Resource AS or PDP returns a requestable denial through AuthZEN Access Request instead of treating the denial as terminal. The orchestrator hands the denial to the deployment's approval workflow.
7. The approval workflow (out-of-band human or admin review) evaluates the requested expansion. If approved, the AS creates a successor Mission whose `mission.supersedes` points to the prior `mission.id`. Only then does the agent derive a finance token, and only under the successor Mission. If the expansion is denied, the prior Mission stays active and the finance access is permanently blocked under this Mission.
8. With finance, calendar, and document data in hand, the agent assembles the packet and needs to submit it to a signing workflow at a different Resource AS. The originating AS mints a Mission-bound ID-JAG for that audience, preserving the same Mission lineage while allowing the Resource AS to issue a local least-privilege token for the signing step.
9. The signing workflow completes and the packet is routed for distribution. The orchestrator requests Mission completion. The AS transitions the Mission to `completed` if policy accepts the completion signal.
10. Later refreshes and exchanges fail because the Mission is no longer active.
Nothing here requires every resource server to be Mission-aware at launch. The AS still gates future derivation.
# Architecture
## Conceptual Model
The Mission is the hub of the model. Tokens, ID-JAGs, and local tokens are projections of it. Tasks are the orchestrator's runtime use of those projections.
```mermaid
flowchart TB
User([User])
Orchestrator([Orchestrator])
Prompt[Prompt]
Intent[Intent envelope]
Proposal[Mission Proposal
mission_intent + resource_access]
AS([Authorization Server
Mission Authority])
Mission[("Mission record
state, proposal_hash,
consent_rendering_hash")]
Task[Task
unit of agent work]
SubAgent([Sub-agent])
Token[Access Token
+ mission claim]
IDJAG[ID-JAG
+ mission claim]
TTS([Transaction Token Service])
TxnToken[Txn-Token
mission.id, mission.origin in tctx]
ResourceAS([Resource AS])
LocalToken[Local Access Token
+ mission claim]
RS([Resource Server])
Resource[("Resource")]
User -->|goal| Orchestrator
Orchestrator -.->|shapes, LLM-driven| Prompt
Prompt -.-> Intent
Intent -.-> Proposal
Proposal -->|PAR| AS
User -->|consent on rendering| AS
AS -->|creates| Mission
Mission -->|projects| Token
Mission -->|projects via Token Exchange| IDJAG
Orchestrator -->|decomposes goal into| Task
Task -->|runs inline OR| SubAgent
SubAgent -->|requests actor token
act chain| AS
Task -->|uses| Token
Token -->|same-audience| RS
Token -->|exchange at TTS
intra-domain call chain| TTS
TTS -->|mints| TxnToken
TxnToken -->|intra-domain calls| RS
Task -->|cross-audience| IDJAG
IDJAG -->|JWT-bearer grant| ResourceAS
ResourceAS -->|issues| LocalToken
LocalToken --> RS
RS --> Resource
```
Reading the diagram:
- Dotted arrows mark the LLM-driven shaping path. Everything from Prompt through Intent to Mission Proposal is untrusted; trust enters only at PAR submission and AS validation.
- Solid arrows are trusted protocol flows. The Mission record is created after the AS validates the proposal and the user consents to the rendered version.
- Cardinality: one User goal yields one Mission (or a chain of successor Missions via Expansion); one Mission projects many tokens, ID-JAGs, Txn-Tokens, and local tokens; one Mission underwrites many Tasks; one Task can run inline in the Orchestrator or delegate to a Sub-agent through Token Exchange with an `actor_token` and an `act` chain.
- Txn-Tokens are not direct projections of the Mission. The Mission-bound access token is exchanged at a Transaction Token Service to mint Txn-Tokens whose `tctx` carries `mission.id` and `mission.origin`; the Txn-Tokens are the intra-trust-domain call-chain substrate. Crossing trust domains uses ID-JAG when the originating credential is a user-authenticated session and the Txn-Token Chaining Profile when the call chain is already Txn-Token-rooted.
- The diagram omits the PDP, audit records, SSF/CAEP events, and Mission Expansion to stay readable. Those live in State Layers, Audit and Receipts, Termination and Events, and Mission Expansion respectively.
## Roles
The MVP has four wire-level roles:
- **User**: approves the Mission.
- **Orchestrator / agent client**: converts the user's goal into a structured Mission Proposal and requests tokens.
- **Authorization Server / agent provider**: validates the proposal, stores the Mission, issues tokens, and gates derivation.
- **Resource Server / Resource AS**: validates tokens or ID-JAGs and enforces the projected authority.
The trust boundary is the AS. The prompt and any LLM-shaped interpretation are untrusted until the AS validates the proposal and the user consents to the rendered version.
Consent in this profile is AS-mediated rather than user-signed. The MVP uses an AS-stored `proposal_hash` as the integrity anchor on the user's approved intent, which keeps user-side key custody out of the deployment story. A future profile can layer user-held signing keys onto the same `proposal_hash`.
## State Layers
The MVP sits inside a layered architecture where four kinds of state have distinct owners. See [Sessions Are Not Missions](/notes/sessions-are-not-missions/) for the architectural rationale.
| Layer | Question answered | Owner |
| --- | --- | --- |
| Session state | Where can the agent continue working? | The agent runtime / harness |
| Token state | Is this credential currently usable at this protocol boundary? | The Authorization Server and Resource Server |
| Policy state | Is this particular request permitted under current rules? | The Policy Decision Point |
| Mission state | Is the delegated work still legitimate? | The Authorization Server, acting as Mission Authority |
The MVP defines the Mission state surface and the wire artifacts that let the other layers consult it. Tokens project Mission bounds across the protocol boundary. Policy evaluates specific requests against approved Mission bounds plus local rules when a deployment has a PDP. Sessions can consult Mission state on resume and before consequential work. The MVP does not standardize session state, PDP behavior, or local policy languages; it gives those layers the Mission handle, the lifecycle gate, and the introspection surface they need to do their own jobs.
The companion Runtime Enforcement Profile additionally strengthens the policy-state layer by making AuthZEN Access Evaluation a normative requirement for every consequential agent action, including non-OAuth tool invocations and side-effecting calls.
## Wire Interop Requirements
The profile is small but still needs a minimum interoperability contract. These rules are the line between a Mission-bound token and a token that merely carries a Mission-shaped correlation handle:
- The originating AS MUST narrow issued `scope`, `aud`, and `authorization_details` to the approved Mission bounds.
- Every derived token or assertion MUST preserve the `mission` claim and MUST NOT exceed the Mission `expiry`.
- Every derived `authorization_details` entry MUST be a subset of an approved entry of the same `type`, evaluated by that type's subset rule (see Authority Model). Known constraints MUST be preserved or narrowed; unknown constraints MUST be preserved or cause refusal. Constraints MUST NOT be silently dropped during derivation.
- A Resource AS that issues a local access token from a Mission-bound ID-JAG MUST bind that local token to the same `mission.id` and `mission.origin`, either in the token or server-side.
- A Resource AS MUST apply its own local authorization policy before issuing local tokens. A Mission-bound ID-JAG is evidence of approved user intent and bounded upstream authority. It is not a command to grant local access.
- A multi-tenant AS or Resource AS MUST bind tenant or organization context into Mission-bound artifacts per the Tenant Binding section.
## Multi-AS Validation
When a Mission crosses AS boundaries, the downstream Resource AS has to validate both the assertion issuer and the Mission authority. The chaining framework is [OAuth Identity Chaining](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/). MBO supports three assertion profiles on top of that framework, distinguished by the JWT `typ` header, the originating credential, and whether the chain is direct, same-IdP continuation, or Txn-Token-rooted:
- **[ID-JAG](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/)** (`typ: oauth-id-jag+jwt`). The subject token is an OpenID Connect ID Token or SAML 2.0 assertion. Use this when the Mission was bootstrapped from a user-authenticated session and the originating AS is the user's IdP.
- **Chain Continuation Assertion** (`typ: oauth-chain-continuation+jwt`, proposed). The subject token is a short-lived, sender-constrained assertion from a trusted chain authority that says an existing same-IdP chain may continue under the same Mission. Use this when SaaS1 calls SaaS2 and SaaS2 must obtain an onward ID-JAG for SaaS3 without sending the user through another interactive flow. The IdP remains the issuer of every ID-JAG and remains the authority for subject resolution at each target audience.
- **[Transaction Token Chaining Profile](https://datatracker.ietf.org/doc/draft-fletcher-transaction-token-chaining-profile/)** (`typ: txn-chain+jwt`). The subject token is a Transaction Token issued by a TTS in Trust Domain A. Use this when the Mission has been instantiated and the agent is mid-task, with Txn-Tokens carrying `mission.id` and `mission.origin` in `tctx`. The exact `tctx` shape, audience policy, and Mission claims transcription are candidate composition points for a follow-on profile.
All three profiles preserve `mission.id` and `mission.origin`, and all require the accepting AS to validate issuer trust (Trust Framework, Domain-Authorized Issuer Discovery, or equivalent) before accepting the assertion.
The Resource AS MUST NOT blindly trust `mission.origin` from an arbitrary assertion. It accepts a Mission origin only when it is bound to a trusted assertion issuer by local trust policy, ID-JAG issuer metadata, the Identity Assertion Trust Framework, Domain-Authorized Issuer Discovery, or an equivalent configured trust method.
Before issuing a local access token, the Resource AS has three possible freshness models:
- **Fresh assertion model.** The Resource AS accepts the ID-JAG's short lifetime as sufficient freshness. This is the MVP default.
- **Introspection model.** The Resource AS introspects Mission state at `mission.origin` before local token issuance.
- **Event-backed model.** The Resource AS relies on a current SSF/CAEP subscription from the originating AS and rejects or degrades if the event stream is not current.
The MVP requires the fresh assertion model by default. Mission-bound ID-JAGs MUST be short-lived, and the Resource AS MUST validate the assertion expiry before issuing local tokens. A deployment profile SHOULD define a concrete maximum lifetime, such as 300 seconds, based on risk and operating constraints. Deployments MAY add the introspection or event-backed model on top of (not in place of) the fresh assertion bound for higher-risk resources or audiences with stricter freshness requirements. The conservative default reflects operational simplicity: a bounded ID-JAG lifetime means staleness is bounded by ID-JAG `exp` plus local-token `exp`, without requiring synchronous introspection or event-stream infrastructure on every cross-AS hop.
Mission-state introspection across ASes should be minimal. The Resource AS needs to know whether the Mission is active, the Mission expiry, the approved `authorization_details` entries relevant to that Resource AS, and the `proposal_hash`. It does not need prompt text, full audit evidence, or entries that apply to other audiences.
A cross-AS introspection request from a Resource AS to `mission.origin`:
```http
POST /introspect HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Bearer
token=&token_type_hint=id-jag&audience=https%3A%2F%2Fdocs.example.com
```
The response carries the audience-filtered Mission view:
```json
{
"active": true,
"sub": "alice@example.com",
"aud": "https://docs.example.com",
"client_id": "agent.example.com",
"mission": {
"id": "msn_01HX4Y2P8BQ4Y3F0V0K9D6Z7M1",
"origin": "https://as.example.com",
"state": "active",
"expiry": "2026-06-05T12:00:00Z",
"purpose": "urn:example:mission:board-packet",
"proposal_hash": "fS8h4w7Z3Lq..."
},
"authorization_details": [
{
"type": "mission_intent",
"purpose": "urn:example:mission:board-packet",
"mission_expiry": "2026-06-05T12:00:00Z",
"context": { "classification": "confidential" }
},
{
"type": "resource_access",
"resource": "https://docs.example.com",
"actions": ["documents.read", "documents.write"],
"constraints": { "folder": "board-materials" }
}
]
}
```
Entries for other audiences (calendar, CRM, finance) are filtered out per the minimization rule.
## Mission Shaping
The MVP standardizes stages 3 and 4, not the entire agent-planning pipeline:
1. **Prompt.** Free text from the user. Untrusted input.
2. **Intent envelope.** Parsed structure such as purpose, candidate resources, actions, time bounds, and named participants. Still untrusted; lives in the orchestration layer.
3. **Mission Proposal.** The `authorization_details` array containing a `mission_intent` envelope plus resource authority entries such as `resource_access`.
4. **Approved Mission.** The AS-side record created after validation and consent.
The AS MUST validate the proposal against deployment policy and the OAuth client's registered authority before rendering it. The user MUST approve a human-readable rendering of the post-validation proposal; the approved Mission, not the prompt, is the authority record.
The orchestrator's output MUST be treated as untrusted for the same reason the prompt is: shaping happens in the LLM-driven layer. Trust enters at AS validation, not at proposal submission.
The MVP works with three shaping approaches; deployments MAY use any combination:
- **Scope-narrowed proposals.** The proposal MUST be a subset of the client's registered scopes, resources, and supported `authorization_details` types.
- **Tool-bounded narrowing.** The orchestrator inspects tool manifests, OpenAPI descriptions, MCP server manifests, or registered functions and proposes only the tools needed for the task. This is useful deployment practice; the MVP does not standardize tool-manifest binding (see Gaps).
- **Standing scope plus intent annotation.** Existing broad OAuth grants MAY be annotated with Mission purpose, audit context, and termination handles. This is weaker, but useful for retrofit deployments.
A fourth approach is deliberately not adopted: AS-side semantic matching of a free-form prompt against the catalog of available scopes or tools. The MVP keeps semantic interpretation in the orchestration layer and accepts only a structured proposal at PAR. An AS MUST NOT replace structured-proposal validation with prompt-based semantic matching.
This choice has a concrete consequence for the integrity anchor. [ACAP](https://datatracker.ietf.org/doc/draft-yakung-oauth-agent-attestation/) defines `att_intent` as a SHA-256 hash of the raw UTF-8 instruction text. That binds approval to the prompt the user typed. The MVP's `proposal_hash` is computed over the AS-validated, post-narrowing structured proposal: it binds approval to the typed object the AS approved, not to the prompt the LLM consumed. The contrast is load-bearing. A raw-prompt hash inherits whatever ambiguity, prompt injection, or LLM interpretation lived in the original input. A structured-proposal hash inherits the AS's deterministic validation. The MVP cannot reach the AS-validation property if it accepted the raw-prompt hash as the consent anchor.
The `purpose` URI inside `mission_intent` plays the stable, lifecycle-managed role: it is registered with the client and tied to deployment policy. `mission_expiry` and `context` on the same envelope play the runtime, session-scoped role: they bound time and cross-cutting constraints for this run. The per-resource `resource_access` entries (or ecosystem-specific RAR types) narrow the stable purpose to one approved task. The envelope and the resource authorities live as sibling entries in the same `authorization_details` array; `proposal_hash` binds them together as one approved bundle.
Mission templates, signed templates, and purpose taxonomy governance are work for later profiles.
## Mission Lifecycle
The Mission lifecycle is independent of token expiry.
The wire protocol only needs one hard distinction: `active` permits derivation, and every non-active state refuses derivation. The named non-active states are for diagnostics, audit, policy, and user/admin experience.
```mermaid
stateDiagram-v2
[*] --> pending_approval: Proposal submitted
pending_approval --> active: Approval received
pending_approval --> rejected: Approval denied
active --> suspended: User pause
or risk signal
active --> completed: Task done
active --> revoked: Termination
active --> expired: TTL elapsed
suspended --> active: Resume
suspended --> revoked: Termination
suspended --> expired: TTL elapsed
rejected --> [*]
completed --> [*]
revoked --> [*]
expired --> [*]
```
The diagram shows the MVP's current state machine. Supersession (Mission Expansion creating a successor) is not a distinct state in this diagram: the prior Mission transitions to `completed`, and the supersedence relationship is encoded through `mission.supersedes` and the SSF `superseded` event. Whether `superseded` should be promoted to a distinct terminal state is an open question; see Gaps. A Mission MAY also persist in `pending_approval` across multiple PAR submissions during a clarification handshake (see the Mid-approval clarification entry in Gaps); the state itself does not change while the orchestrator and AS negotiate.
Only `active` permits new derivation. Any other state causes token endpoints to fail with `error="invalid_grant"` and a `mission_state` extension field carrying the classifier. The `mission_state` value MUST be one of the named lifecycle states: `pending_approval`, `suspended`, `revoked`, `expired`, `completed`, or `rejected`. When the `mission.id` does not resolve at `mission.origin`, the AS MUST instead use `mission_state="mission_not_found"`. The AS MAY also include `error_uri` pointing to deployment-specific documentation about Mission lifecycle states; per RFC 6749, `error_uri` is a documentation URL, not a machine-readable classifier. Introspection returns `active: false` and MUST include `mission.state` carrying one of the same vocabulary values, plus `mission_not_found` for unresolvable IDs.
A concrete inactive-Mission error response at the token endpoint:
```http
HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
{
"error": "invalid_grant",
"mission_state": "revoked",
"error_description": "Mission msn_01HX4Y2P8BQ4Y3F0V0K9D6Z7M1 was revoked at 2026-05-30T14:12:08Z",
"error_uri": "https://docs.example.com/oauth/mission-lifecycle"
}
```
## Attestation Layers
Mission-Bound OAuth separates three questions that are often collapsed into one token:
| Layer | Question answered | Mechanism |
| --- | --- | --- |
| Token | Is this access token currently valid for this audience? | JWT access token, `cnf`, `mission` claim, normal OAuth validation |
| Authority Model | What authority did the user approve? | `authorization_details`, optionally compiled into Cedar |
| Provenance | Who approved this and which actors handled it? | Optional `actor_receipts` chain |
Deployments can start with the token layer and add stronger layers as needed. This is why the wire surface of the MVP can stay small while the architecture remains extensible.
# Detailed Solution
## Mission Proposal
The agent submits the Mission Proposal as part of the OAuth authorization request, ideally through PAR so the proposal stays off the front channel.
A representative pushed request:
```http
POST /par HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
response_type=code
&client_id=agent.example.com
&redirect_uri=https://agent.example.com/cb
&scope=mission
&code_challenge=...
&code_challenge_method=S256
&authorization_details=
```
Decoded:
```json
[
{
"type": "mission_intent",
"purpose": "urn:example:mission:board-packet",
"mission_expiry": "2026-06-05T12:00:00Z",
"context": {
"classification": "confidential"
}
},
{
"type": "resource_access",
"resource": "https://docs.example.com",
"actions": ["documents.read", "documents.write"],
"constraints": {
"folder": "board-materials"
}
},
{
"type": "resource_access",
"resource": "https://calendar.example.com",
"actions": ["calendar.events.read"],
"constraints": {
"time_window": "P30D"
}
}
]
```
The MVP defines two RAR types. `mission_intent` is the Mission envelope: `purpose` is a stable URI for the mission class (any URI per RFC 3986; profiles MAY further constrain to URN or HTTPS forms), `mission_expiry` is a hard ceiling on the entire Mission, and `context` carries cross-cutting bounds that apply uniformly across every resource authority in the same array. `resource_access` is the generic per-resource authority: `resource` identifies the protected resource, API, or resource server where the authority will be used; `actions` is the allowed action set; and `constraints` carries resource-scoped bounds. The Resource Authorization Server audience used in Token Exchange or ID-JAG issuance is resolved from that resource by local policy, client registration, RFC 9728 Protected Resource Metadata, or an ecosystem-specific RAR type that defines an explicit audience field. Resource ecosystems MAY define richer RAR types (`document_access`, `payment_initiation`, and so on); the AS validates each entry against its registered type metadata and stores the entire approved array on the Mission record. The AS may store audit context such as the prompt, plan, or other evidence, but that evidence is not carried in access tokens.
The MVP does not standardize a global catalog of `context` keys. A deployment or ecosystem RAR type can define keys such as `classification`, `assurance_level`, `risk_tier`, `max_budget`, `currency`, `max_calls`, or `geo_bound`, but their syntax and narrowing semantics must be published in type metadata or deployment configuration before they can be enforced. If an AS enforces a `context` key, it treats the approved value as a hard bound for derivation. If it does not understand the key, it preserves it or refuses the derivation under the unknown-constraint rule below.
Clients discover the schemas for `mission_intent`, `resource_access`, and any ecosystem-specific RAR types through `draft-zehavi-oauth-rar-metadata`. The AS advertises `authorization_details_types_metadata_endpoint`; the endpoint publishes JSON Schema for each supported type. Mission-aware resource servers can advertise their required authorization detail types through RFC 9728 PRM. Orchestrators use both to pre-validate proposals before asking the user to consent.
Orchestrators MAY include an `idempotency_key` on PAR. If the same client and user submit the same key within a deployment-defined window, the AS returns the prior `request_uri` instead of creating a duplicate Mission.
## Proposal Hash
The AS MUST compute `proposal_hash` as the base64url-encoded (no padding) SHA-256 digest of the canonical JSON serialization, per JCS (RFC 8785), of the entire approved `authorization_details` array (Mission envelope plus all per-resource entries). The hash MUST be taken at the moment the Mission transitions to `active` and MUST be computed over the post-narrowing array that the AS stores on the Mission record. The `proposal_hash` value MUST be stable for the lifetime of the Mission. An amendment that changes the approved array MUST create a successor Mission with its own `proposal_hash`.
When the AS narrows the proposal during validation (for example, trimming `mission_expiry` to a policy maximum or removing entries outside client registration), the narrowed array is what the user approves and is what `proposal_hash` covers. This profile requires the token response to return the narrowed `authorization_details` to the client; RFC 9396 §7 permits the AS to omit values, and the MVP profiles that point by making the narrowed return mandatory. Clients MUST treat the returned `authorization_details` as the approved bounds. Later derivation requests are evaluated against the narrowed array, not against what the client originally submitted at PAR.
A narrowed token response example. The client originally proposed a 30-day window; the AS narrowed it to 14 days:
```json
{
"access_token": "",
"token_type": "Bearer",
"expires_in": 600,
"authorization_details": [
{
"type": "mission_intent",
"purpose": "urn:example:mission:board-packet",
"mission_expiry": "2026-06-05T12:00:00Z",
"context": { "classification": "confidential" }
},
{
"type": "resource_access",
"resource": "https://calendar.example.com",
"actions": ["calendar.events.read"],
"constraints": { "time_window": "P14D" }
}
]
}
```
The AS MUST also compute `consent_rendering_hash` as the base64url-encoded (no padding) SHA-256 digest of the exact human-readable rendering material shown to the user at approval time, including localization version, normalization rules defined by the AS, and any material UI text the user saw. The AS MUST document its rendering normalization rules so an auditor can reproduce the hash. `proposal_hash` proves which structured bounds were approved; `consent_rendering_hash` proves what the user saw. Both hashes are stored on the Mission record and surfaced in audit records. `proposal_hash` is also surfaced on introspection responses. This is the minimum portable evidence handle the profile commits to; richer Mission Receipt formats are out of scope for the MVP.
## Lifetime and Audience
The proposal carries two scoping dimensions: time and audience.
`mission_expiry` is an RFC 3339 timestamp on the `mission_intent` envelope:
```json
{
"type": "mission_intent",
"purpose": "urn:example:mission:board-packet",
"mission_expiry": "2026-06-05T12:00:00Z",
"context": {
"classification": "confidential"
}
}
```
The AS enforces a maximum Mission age by deployment policy. If the proposal omits `mission_expiry`, the AS applies a default. If the proposal exceeds policy, the AS narrows the value before consent. Expiry is a hard ceiling: continuing authority requires a new Mission.
Each `resource_access.resource` contributes to the Mission's protected-resource whitelist. The AS derives the permitted Resource Authorization Server audience for cross-audience derivation from local policy, client registration, PRM, or an ecosystem-specific RAR type. Cross-audience ID-JAGs may only be minted when the requested `resource` is approved and the requested `audience` is an authorized Resource AS for that resource. The projected actions and constraints are taken from the matching `resource_access` entry. Adding resources or targeting a new Resource AS requires Mission expansion or a new Mission.
## Token Claim and Introspection
Access tokens issued under a Mission carry the `mission` claim with `id` and `origin`. Refresh tokens are bound to the Mission server-side and may carry `mission.id` if they are structured. ID Tokens do not need the `mission` claim for the MVP; deployments that add it should treat that as an explicit privacy and correlation decision.
```json
{
"iss": "https://as.example.com",
"sub": "alice@example.com",
"aud": "https://docs.example.com",
"client_id": "agent.example.com",
"scope": "documents.read documents.write",
"authorization_details": [
{
"type": "mission_intent",
"purpose": "urn:example:mission:board-packet",
"mission_expiry": "2026-06-05T12:00:00Z",
"context": {
"classification": "confidential"
}
},
{
"type": "resource_access",
"resource": "https://docs.example.com",
"actions": ["documents.read", "documents.write"],
"constraints": {
"folder": "board-materials"
}
}
],
"mission": {
"id": "msn_01HX4Y2P8BQ4Y3F0V0K9D6Z7M1",
"origin": "https://as.example.com"
},
"cnf": { "jkt": "..." },
"iat": 1716412800,
"exp": 1716416400,
"jti": "tok_..."
}
```
`mission.id` is opaque to the resource server. `mission.origin` identifies the AS where the Mission state lives, which matters after ID-JAG handoff. Mission-bound tokens MUST be sender-constrained with DPoP or mTLS confirmation (`cnf`).
Introspection returns normal RFC 7662 fields plus Mission state inside the same `mission` claim:
```json
{
"active": true,
"scope": "documents.read documents.write",
"exp": 1716416400,
"sub": "alice@example.com",
"aud": "https://docs.example.com",
"client_id": "agent.example.com",
"tenant": "example-corp",
"aud_tenant": "example-corp",
"mission": {
"id": "msn_01HX4Y2P8BQ4Y3F0V0K9D6Z7M1",
"origin": "https://as.example.com",
"state": "active",
"expiry": "2026-06-05T12:00:00Z",
"purpose": "urn:example:mission:board-packet",
"proposal_hash": "fS8h4w7Z3Lq...base64url-sha256...",
"consent_rendering_hash": "e9X2...base64url-sha256...",
"supersedes": null
}
}
```
If the Mission is not active, introspection returns `active: false` even if the token signature and expiry are otherwise valid. The response MUST include `mission.state` so the caller can distinguish a Mission-state denial from a token-validity denial. The authorization decision remains `active: false`.
The minimum Mission introspection response, for any Mission-bound token, MUST include the standard RFC 7662 fields plus a `mission` member containing at minimum:
- `id`: the opaque Mission identifier.
- `origin`: the originating AS.
- `state`: one of the named lifecycle states, or `mission_not_found` when the `mission.id` does not resolve.
When the Mission is `active`, the response MUST additionally include:
- `expiry`: the Mission's hard end-of-life timestamp.
- `purpose`: the approved `mission_intent.purpose` URI.
- `proposal_hash`: the canonical hash of the approved `authorization_details` array.
The response MAY include `consent_rendering_hash`, `supersedes`, and other Mission record fields. Cross-AS introspection responses, where a Resource AS calls back to `mission.origin`, SHOULD filter `authorization_details` to entries relevant to the requesting audience and SHOULD omit unrelated entries to minimize cross-audience disclosure.
## Authority Model
The Authority Model answers: what is this Mission allowed to do?
The Mission is not a policy language. The Mission record is the canonical authority object: a typed, AS-validated, user-approved bundle with a hash anchor and a lifecycle. Policy artifacts (Cedar, OpenFGA tuples, AuthZEN policy), token projections, and audit receipts are all *derived from* the Mission. A deployment can swap policy languages, replace the PDP, or migrate compiled-artifact formats without changing the Mission record. The Mission is the durable governance object. Everything else is a projection of it.
The MVP does not standardize the internal representation. Deployments may store the approved `authorization_details`, compile to scopes, produce AuthZEN policy, create OpenFGA tuples, compile to Cedar, or use another local policy model. The protocol requirement is only that the AS can compare requested derivations against the approved bounds.
The minimum comparison rule is structural and applies per RAR entry, per type:
- Every derived `authorization_details` entry MUST be a subset of an approved entry of the same `type`. Subset semantics come from the type's registered RAR metadata; the MVP defines them for `mission_intent` and `resource_access` below.
- **`mission_intent`.** `purpose` MUST match the approved value exactly. `mission_expiry` MUST NOT exceed the approved value. Every key in the derived `context` MUST be present in the approved `context`, and the derived value MUST imply the approved value under the constraint's narrowing semantics. Narrowing semantics for `context` fields come from registered metadata or deployment configuration.
- **`resource_access`.** The derived `resource` MUST equal the approved `resource` exactly. The derived `actions` MUST be a subset (set inclusion) of the approved `actions`. Every key in the derived `constraints` MUST be present in the approved `constraints`, and the derived value MUST imply the approved value under the constraint's narrowing semantics.
- **Unknown constraints.** A constraint is "unknown" to a participant when its narrowing semantics are not defined by registered RAR metadata or by deployment configuration. An AS or Resource AS that encounters an unknown constraint key MUST either preserve it verbatim in the derived entry (or the derived local token) or refuse the derivation with `error="invalid_authorization_details"`. Silently dropping, ignoring, or modifying an unknown constraint is forbidden.
- **Ecosystem-specific RAR types** apply their own subset rules through their registered metadata. The MVP imposes the "unknown constraints" rule above on all types regardless of source.
- **Omitted and unknown entries.** Entries omitted from the derivation request are narrowed by removal. Entries with a `type` not present in the approved Mission MUST be rejected.
That is enough for interoperable derivation. Formal policy languages are composition points, not part of the minimum profile.
If a deployment uses Cedar or another formal policy language, the AS can compile the approved `authorization_details` array (envelope plus per-resource entries) after consent and project that policy to capable Resource Servers. Clients do not submit formal policy text at PAR in the MVP. The structured `mission_intent` envelope plus `resource_access` (or ecosystem-specific) entries form the consent surface.
### Non-OAuth Actions
The structural comparison rule above governs derivation: it tells the AS whether to issue a new access token, ID-JAG, or exchanged token. It does not govern what happens inside an active Mission when an orchestrator performs a local action that is not an OAuth-protected API call: tool invocations, file writes, payment confirmations, or internal side effects.
Those actions are outside the MVP. A deployment can still use the Mission record as an input to local policy, but the wire-level MVP does not standardize PDP consultation, tool invocation checks, or per-action receipts. The Runtime Enforcement Profile below is the layer that turns Mission authority into a runtime policy gate for consequential non-OAuth actions.
## Derivation
Mission-bound authority is derived along three paths.
**Refresh, same audience.** The client uses normal refresh. The AS resolves the Mission. If it is active, the AS issues a new access token with the same `mission.id` and bounded authority. If it is not active, the AS rejects the request with `error="invalid_grant"` and a `mission_state` field carrying the current state (for example, `revoked`, `suspended`, `expired`, `completed`).
**Token Exchange to ID-JAG, cross audience or cross AS.** When the agent needs a different protected resource, possibly behind a different Resource AS, the agent provider acts as the IdP Authorization Server in ID-JAG terms. The originating AS remains the Mission authority; each downstream Resource AS receives a narrowed assertion for its own audience and resource.
1. The agent submits RFC 8693 Token Exchange with `requested_token_type=urn:ietf:params:oauth:token-type:id-jag`, the requested Resource AS `audience`, the requested protected `resource`, and the current mission-bound token as `subject_token`.
2. The agent provider checks Mission state and verifies that the requested `resource` is approved and the requested `audience` is authorized for that resource.
3. The agent provider mints an ID-JAG carrying the `mission` claim (with `id` and `origin`), the user subject appropriate for the target audience, projected authority, and any actor chain.
4. The agent presents the ID-JAG to the Resource AS using the RFC 7523 JWT-bearer grant.
5. The Resource AS validates the ID-JAG, evaluates issuer trust, confirms Mission state through freshness, introspection at `mission.origin`, or events, applies local authorization policy, and issues a local access token bound to the same `mission.id`.
```mermaid
sequenceDiagram
participant A as Agent
participant AP as Agent Provider / IdP AS
participant R as Resource AS
A->>AP: Token Exchange
requested_token_type = id-jag
audience = Resource AS
resource = protected API
Note over AP: Check Mission active
Check resource approved
Check audience authorized
AP-->>A: ID-JAG with mission claim
A->>R: JWT-bearer grant
assertion = ID-JAG
Note over R: Validate assertion
Check Mission state
R-->>A: Local access token
bound to mission.id
```
**Same-IdP chain continuation, SaaS to SaaS.** In the most important enterprise chaining case, all Resource Authorization Servers trust the same IdP for SSO and subject resolution, but each API is protected by its own Resource AS. The chain may look like `ClientA -> SaaS1/RAS1 -> SaaS2/RAS2 -> SaaS3/RAS3`. The user authenticated once at the IdP, and the IdP may use different subject identifiers at each SaaS audience. Downstream SaaS services do not know the global subject mapping; only the IdP does.
For this case, the token request shape stays the same as the direct ID-JAG request. The client swaps only the `subject_token`:
```http
grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&requested_token_type=urn:ietf:params:oauth:token-type:id-jag
&audience=https://ras3.example/
&resource=https://api3.example/
&scope=orders.read
&subject_token=
&subject_token_type=urn:ietf:params:oauth:token-type:chain-continuation+jwt
```
The Chain Continuation Assertion is not an ID-JAG and does not grant access to the API. It is the proof artifact presented to the IdP so the IdP can decide whether to issue an onward ID-JAG for the requested `audience` and `resource`. It carries the existing `mission` claim, the actor chain, authentication context, scope/resource bounds, replay protection, and sender constraint. The IdP validates the trusted issuer, Mission state, actor authority, and requested bounds, then resolves the target-audience subject and issues the onward ID-JAG. That preserves the same client contract for direct and chained calls: choose the target `audience`, `resource`, and `scope`; swap the `subject_token` based on whether the caller is starting from an interactive identity assertion or continuing an existing chain.
**Token Exchange to Transaction Token Chaining JWT Grant, cross trust domain.** When the agent is mid-task inside Trust Domain A and Txn-Tokens are already mediating intra-domain calls, the trust-domain crossing can use [Fletcher's chaining profile](https://datatracker.ietf.org/doc/draft-fletcher-transaction-token-chaining-profile/) instead of ID-JAG. The Txn-Token never leaves Trust Domain A.
1. The agent (or a workload acting on its behalf) holds a Txn-Token whose `tctx` carries `mission.id`, `mission.origin`, and optionally `proposal_hash` and the audience-relevant `authorization_details` entries.
2. The agent submits RFC 8693 Token Exchange to AS-A with `subject_token_type=urn:ietf:params:oauth:token-type:txn_token`, `subject_token=`, `audience=`, and `requested_token_type=urn:ietf:params:oauth:token-type:jwt`.
3. AS-A mints a JWT Authorization Grant with `typ: txn-chain+jwt`, transcribing the originating `txn` claim and carrying the Mission fields that a composition profile defines. Internal workload identifiers MUST NOT leak.
4. The agent presents the JWT Grant to AS-B using the RFC 7523 JWT-bearer grant.
5. AS-B validates the grant against trusted issuer policy, verifies Mission state through freshness, introspection at `mission.origin`, or events, applies local authorization policy, and issues a local access token bound to the same `mission.id`.
```mermaid
sequenceDiagram
participant A as Agent / Workload
participant AA as AS-A (Trust Domain A)
participant AB as AS-B (Trust Domain B)
Note over A: Holds Txn-Token
tctx: mission.id, mission.origin
A->>AA: Token Exchange
subject_token_type = txn_token
subject_token = Txn-Token
audience = AS-B issuer
Note over AA: Check Mission active
Check audience within bounds
AA-->>A: JWT Grant (typ: txn-chain+jwt)
txn transcribed
mission claims in txn_claims
A->>AB: JWT-bearer grant
assertion = JWT Grant
Note over AB: Validate trusted issuer
Check Mission state at mission.origin
AB-->>A: Local access token
bound to mission.id
```
The choice between these paths is driven by the originating credential and trust model, not by the target audience alone. Use direct ID-JAG when the caller can present a user-authenticated identity assertion. Use Chain Continuation Assertion when a same-IdP SaaS chain needs an onward ID-JAG and the IdP must remain the subject-resolution authority. Use the Txn-Token chaining profile when the Mission has been instantiated and intra-domain Txn-Tokens are the call-chain substrate.
**Sub-agent delegation.** The parent agent submits Token Exchange with a sub-agent Client Instance Assertion as `actor_token`. The issued ID-JAG and any access token derived from it MUST include an `act` chain. The chain follows RFC 8693 conventions: the most recent actor is the outermost `act`, with the parent's prior `act` (if any) carried as the nested `act`. The sub-agent receives only authority that is within the Mission and narrowed by the parent delegation. A Resource AS that enforces sub-agent-scoped policy MUST evaluate the full chain. Per-actor revocation keyed on the chain identity is companion work (see Gaps).
Five invariants apply to every path:
- `mission.id` is preserved under derivation.
- Mission state is checked before new authority is issued or accepted.
- Authority can narrow but cannot expand without a new approval.
- Any derived token's `exp` MUST NOT exceed Mission `expiry`. This binds access tokens, refresh tokens, and ID-JAGs to the Mission's hard end-of-life, independent of token-level TTL policy.
- Local Resource AS refresh, exchange, and introspection paths MUST preserve the Mission binding or refuse the operation.
Step-up authentication does not move the Mission state machine. If a derivation fails with RFC 9470 `insufficient_user_authentication`, the Mission remains active; only the attempted derivation fails.
## Mission Expansion
A Mission's authority cannot grow in place. Expansion creates a new Mission whose `mission.supersedes` points at the prior `mission.id`.
There are two paths:
- An out-of-bounds derivation returns a requestable denial through AuthZEN Access Request, and the approval flow creates the successor Mission.
- The agent submits a fresh `mission_intent` proposal with the expanded authority.
When expansion is approved, the prior Mission transitions to `completed` (AS-driven, not subject to the client-completion-advisory rule), and the successor Mission becomes authoritative. Existing tokens expire naturally. New derivations use the new `mission.id`. The supersedence chain through `mission.supersedes` preserves auditability across the transition. Whether `completed` should be replaced by a distinct `superseded` terminal state in a future revision is an open question; see Gaps.
## Termination and Events
Termination MUST happen at the Mission record, not only at the token layer.
Direct termination by the AS or its admin surface MUST transition the Mission to `revoked`, `suspended`, or `completed`. Future refresh and exchange MUST fail when the Mission is in any non-active state. Existing tokens MAY continue until token-level expiry unless the resource server introspects Mission state or consumes Mission state events.
Client-driven termination MAY use RFC 7009. Under the MVP, revoking a refresh token bound to a Mission MUST terminate the Mission by default. An AS MAY support per-token revocation that leaves the Mission active; in that case, the client SHOULD signal `revoke_mission=true` to terminate the Mission explicitly.
User and administrator termination MUST NOT depend on possession of a refresh token. Deployments MUST expose a Mission management surface, behind the user-visible inventory, that can revoke, suspend, resume, or complete a Mission by `mission.id`. The MVP does not standardize the wire shape of that management API (see Gaps); it requires only that the operation exist.
Client-driven completion is advisory. A client MAY request that a Mission transition to `completed`, but the AS MUST decide whether to accept the transition based on client authentication, Mission state, resource evidence, deployment policy, or user/admin action. This prevents a compromised client from using completion semantics to hide unfinished or unauthorized work.
Mission state can propagate through SSF/CAEP events:
| Event type (illustrative URI) | Meaning |
| --- | --- |
| `https://schemas.example.com/mission/activated` | Mission became active |
| `https://schemas.example.com/mission/suspended` | Mission paused |
| `https://schemas.example.com/mission/revoked` | Mission terminated |
| `https://schemas.example.com/mission/completed` | Mission finished successfully |
| `https://schemas.example.com/mission/expired` | Mission TTL elapsed |
| `https://schemas.example.com/mission/superseded` | Mission replaced by a successor |
The example URIs are placeholders. An event profile can register concrete event types later. On the SSF/CAEP wire, event types are URIs as shown. In local audit records the same events MAY be referenced by a dotted-name short form (`mission.activated`, `mission.suspended`, etc.); the mapping is one-to-one with the URI form and is a local-naming convenience, not a separate vocabulary.
# Operational Requirements
## Compliance Tiers
The MVP composes with a deep OAuth and OIDC stack: PAR, RAR, JWT access tokens, Token Exchange, ID-JAG, introspection, revocation, SSF/CAEP, AuthZEN. Adopting all of them at once is a non-starter for most identity teams. Compliance Tiers let a deployment ship intent-binding immediately and add capability over time.
Compliance Tiers are about *deployment dependencies* (which specs you need to implement). They are orthogonal to Resource Server Tiers (per-RS capability) and to the choice of profile (MVP vs Runtime Enforcement Profile). A deployment lives at a coordinate in three dimensions, not on a single ladder:
| Axis | Values | Question it answers | Scope |
| --- | --- | --- | --- |
| Compliance Tier | 1 / 2 / 3 | Which OAuth and OIDC specs do I need to implement? | Deployment-wide |
| Resource Server Tier | A / B / C / D | What can each individual RS enforce at request time? | Per Resource Server |
| Profile | MVP / Runtime Enforcement Profile | How strong are my runtime enforcement requirements? | Deployment-wide |
A "Tier-2 deployment with mixed RS-A and RS-D audiences under the MVP" means: the AS implements Tier-2 dependencies (PAR, RAR, Token Exchange, ID-JAG, JWT bearer); some RSes ignore the `mission` claim while others introspect Mission state per request; local non-OAuth action enforcement remains deployment-specific. A "Tier-3 Runtime Enforcement deployment" implements every dependency in the stack and treats the policy layer as MUST.
| Tier | Required dependencies | What it delivers |
| --- | --- | --- |
| **Tier 1: Core, single-AS.** | OAuth 2.0 + RFC 9126 PAR + RFC 9396 RAR + RFC 9068 JWT access tokens + RFC 7662 introspection + RFC 7009 revocation + RFC 9449 DPoP or RFC 8705 mTLS for sender constraint. | Mission record at the AS, structured intent, Mission-state-gated refresh and exchange, sender-constrained tokens. Works with RS-A audiences, which means the typed Mission bounds in `authorization_details` are not enforced at request time; only the AS's narrowing of scope, audience, and expiry restricts what an RS-A audience accepts. |
| **Tier 2: Distributed, multi-AS.** | Tier 1 + RFC 8693 Token Exchange + Identity Chaining + assertion profile (ID-JAG for user-authenticated flows, Transaction Token Chaining Profile for Txn-Token-rooted flows) + RFC 7523 JWT bearer + the Multi-AS Validation rules in this document. | Cross-audience and cross-AS derivation with `mission.id` preserved. The originating AS remains the Mission authority; Resource ASes receive narrowed, audience-specific assertions. |
| **Tier 3: Real-time, agentic.** | Tier 2 + RFC 8417 SET + SSF + CAEP + AuthZEN Access Request + AuthZEN Authorization API. Optionally pairs with the Runtime Enforcement Profile. | Event-driven revocation and lifecycle propagation, requestable denial and Mission Expansion as governed workflows; non-OAuth runtime policy gates are standardized only by the Runtime Enforcement Profile. |
A deployment can claim Tier-N compliance independently of which Resource Server Tiers it operates. A Tier-3 deployment with one RS-A audience still has Tier-3 properties for the rest of its surface; a Tier-2 deployment with several RS-D audiences gets stronger freshness at those audiences but does not claim Tier-3 because it lacks AuthZEN composition. The Runtime Enforcement Profile is an additional opt-in on top of Tier 3.
## Resource Server Tiers
Resource servers can adopt Mission awareness incrementally:
- **RS-A: OAuth-only.** Validates scope, audience, expiry, and sender constraint. Ignores the `mission` claim. Revocation is bounded by token expiry.
- **RS-B: Authorization-details aware.** Also validates audience-relevant `authorization_details`, especially `resource_access` or ecosystem-specific RAR entries, against the request.
- **RS-C: Policy-aware.** Evaluates Cedar or another compiled Authority Model.
- **RS-D: Mission-state aware.** Introspects Mission state per request or subscribes to SSF/CAEP events.
The Mission gate at the AS works even with RS-A, provided the AS narrows issued tokens to Mission bounds. Stronger tiers reduce overuse and revocation staleness. Request-time intent enforcement starts at RS-B; RS-A gets only AS-side narrowing and expiry-bounded revocation.
RS-A is a migration tier, not the target security model. It prevents future over-issuance at the AS, but it does not stop a still-valid access token at request time.
RS-D deployments should keep Mission-state caches short-lived unless they hold a current SSF/CAEP subscription that delivers Mission state events; in that case, the cache can persist until invalidated by an event. When introspection at `mission.origin` is unreachable, RS-D should fail closed for derivation requests and high-risk state-changing API calls. RS-D can fall back to event-derived state if a current SSF/CAEP subscription is available.
Operand provenance is complementary to Mission-state enforcement: provenance signs values back to their upstream computation, while the Mission gate bounds which calls may be attempted. That belongs in a future enforcement profile, not the MVP.
## Client and Token Constraints
The MVP is for confidential clients. Public clients should not act as Mission-bound clients. Confidential client authentication uses mechanisms such as `private_key_jwt` or mTLS at Mission-related endpoints.
Mission-bound access tokens, refresh tokens, and ID-JAGs MUST be sender-constrained. DPoP or mTLS confirmation (`cnf`) binds the token to a key. The sender-constraint key for the parent's own tokens is stable within a Mission. Rotation of the parent's own key requires a new Mission Proposal or successor Mission. Sub-agent delegation is a structured exception, not a key rotation: the parent authenticates the Token Exchange, the sub-agent instance key becomes the confirmation key on the derived tokens, and the `act` chain records which key each hop holds. The Mission `cnf` remains stable; the per-derivation `cnf` varies along the delegation chain.
Mission-bound access tokens should be short-lived by default. Stale-state risk at RS-A and RS-B audiences is bounded by token TTL because those tiers do not introspect or consume Mission state events. Deployments can use longer access-token lifetimes for RS-D audiences that introspect Mission state per request or maintain a current SSF/CAEP subscription, since those tiers have an independent invalidation path. Refresh tokens and ID-JAGs are bounded by Mission `expiry` per the Derivation invariants.
## Governance Inventory
Deployments need a user-visible inventory of active Missions. It should show:
- Non-terminal Missions for the user.
- Purpose, requesting client, authority summary, expiry, and state.
- A per-Mission revoke action.
Without this, a user can approve a Mission but has no practical way to see or stop it later.
The inventory needs a backing lifecycle operation, even if the wire API is deployment-specific. Users and administrators must be able to revoke or suspend a Mission by `mission.id` without presenting a refresh token.
## Tenant Binding
In multi-tenant deployments, tenant or organization context MUST be bound into every Mission-bound artifact so that authority approved under one tenant cannot be exercised against another.
- The approved Mission record MUST identify the tenant context in which it was approved, either as a Mission record field or inside `mission_intent.context`.
- Mission-bound access tokens, refresh tokens, and ID-JAGs MUST carry tenant context via the `tenant` and `aud_tenant` claims defined in [ID-JAG](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/), or via a tenant-scoped issuer URI for `iss` and `mission.origin`. Deployments SHOULD prefer the ID-JAG claim shape for cross-AS interoperability.
- An AS MUST reject Mission Proposal or derivation requests whose presented tenant context differs from the approved Mission's tenant.
- A Resource AS or RS MUST reject a Mission-bound token whose tenant context does not match the resource being accessed. A token approved under tenant A MUST NOT be accepted as evidence for tenant B's resources, even if the resource URI is identical.
- Introspection responses MUST carry the tenant context in the same claim shape as the corresponding access tokens.
- Cross-tenant Mission Expansion (a successor Mission targeting resources in a different tenant) MUST require fresh approval under the new tenant. Tenant boundaries cannot be crossed by attenuation alone.
## Audit and Receipts
Every Mission lifecycle and derivation event should produce an audit record:
```json
{
"mission": {
"id": "msn_01HX4Y2P8BQ4Y3F0V0K9D6Z7M1",
"origin": "https://as.example.com",
"proposal_hash": "fS8h4w7Z3Lq...base64url-sha256...",
"consent_rendering_hash": "e9X2...base64url-sha256...",
"supersedes": null
},
"event_type": "mission.activated",
"timestamp": "2026-05-22T16:21:08Z",
"actor": {
"client_id": "agent.example.com",
"sub": "alice@example.com",
"act": null
},
"prior_state": "pending_approval",
"new_state": "active",
"evidence_id": "ev_01HX4Y2P9KP5XQ..."
}
```
`evidence_id` is an opaque handle to confidential evidence such as the prompt or plan. The evidence itself MUST NOT be carried in tokens or transmitted audit records. The audit log should be append-only and integrity-protected.
Portable, third-party-verifiable provenance is companion work. A future Mission Receipt Profile could carry signed receipts per visible `act` hop and bind them to `mission.id`, `mission.origin`, `proposal_hash`, `evidence_id`, `consent_rendering_hash`, and `auth_context`. That is useful, but not required for the MVP.
# Threat Model
The MVP defends against a specific set of attacker capabilities and explicitly does not defend against others. Naming that boundary is the precondition for honest review.
## What the design defends against
- **Compromised orchestrator or client.** Mission-bound tokens are narrowed by `authorization_details`. A compromised client cannot expand its authority beyond the approved Mission bounds without obtaining a new user-approved Mission Expansion. Sender-constrained tokens (DPoP or mTLS `cnf`) prevent stolen tokens from being replayed by an unauthorized party. The `act` chain records who participated in each derivation.
- **Compromised sub-agent.** Sub-agent delegation issues new tokens with the sub-agent instance key as `cnf`. The `act` chain identifies the sub-agent. The Mission-state gate at the originating AS still applies to every derivation in the chain.
- **Compromised Resource Server.** Mission state is anchored at `mission.origin`. A compromised RS cannot extend the lifetime of a token whose Mission has been revoked. The next derivation, refresh, or introspection at the origin returns the revoked state.
- **Lossy partition.** Short cache TTLs, SSF/CAEP event propagation, and fail-closed Resource Server policy at higher Compliance Tiers bound the window during which a revoked Mission appears active to a downstream party. Deployments choose the freshness threshold appropriate to their risk posture.
- **TOCTOU drift between approval and execution.** Approval is an input to a decision, not a standing grant. The [Runtime Enforcement Profile](/notes/mission-bound-oauth-runtime-enforcement-profile/) reevaluates at execution time against current Mission state and risk posture, closing the approval-to-execution window.
## What the design does not defend against
- **Compromised originating Authorization Server.** The Mission record, `proposal_hash`, `consent_rendering_hash`, lifecycle state, and audit context all live at one AS. A compromised originating AS can backdate Missions, mint Mission-bound tokens for fabricated approvals, rotate hashes after the fact, or alter lifecycle state. The design assumes a trusted originating AS. An Optional Module that anchors `proposal_hash` to an external transparency log or signed audit channel is future work.
- **A misleading consent rendering.** The `consent_rendering_hash` binds the AS to what it displayed at consent time for future audit. It does not protect the user from an AS that renders a proposal misleadingly. Trustworthy consent UX is on the AS, not on the hash.
- **`purpose` URI squatting in deployments without a Purpose Registry.** Clients pick their own `purpose` URIs. A client can register a URI that sounds innocuous but maps to broad authority. Without the Purpose Registry Profile in scope, `purpose` is unverified attestation by the client. The AS is expected to validate proposals against the client's registered purpose URIs; an under-governed AS that accepts arbitrary purposes weakens this control.
- **A compromised Policy Decision Point.** Under the Runtime Enforcement Profile, a compromised PDP returns whatever decisions it wants. Decision evidence records enable post-hoc audit but do not prevent in-flight bad decisions. Signed PDP decisions and externally-verifiable evaluation chains are future work.
- **Prompt injection at the orchestrator's shaping step.** The LLM reasoning that drafts a Mission Proposal can be influenced by untrusted content (web pages, document attachments, tool outputs). AS validation of the proposal is the trust boundary, but the AS only enforces what client registration constrains. Client registration is the actual guardrail: a client registered to propose narrow Missions cannot have its registration bypassed by an LLM that prompts itself to ask for more. Deployments that allow loosely-bounded client registration weaken this control.
- **`context` constraint drift toward preserve-without-enforce.** The MVP says understood constraints are hard bounds and unknown constraints must be preserved or refused. An AS that claims understanding of a constraint without actually enforcing it cannot be detected at the wire layer. Self-declared AS metadata listing the enforced `context` keys is one mitigation; cross-AS attestation of enforced constraints is future work.
- **Aggregate authority across many Missions (Mission stacking).** Per-Mission audit shows each Mission in isolation. An agent that accumulates many narrow Missions across time may have aggregate authority that no single Mission grants. Deployment policy can cap concurrent or recent Mission counts per user, but the MVP does not specify this control.
- **Behavioral correlation at a single audience.** Pairwise subject identifiers per `mission.id` reduce explicit correlation across Missions at one audience. They do not reduce behavioral correlation. Timing, action shape, and resource access patterns can still link distinct Missions to one user. Deployments concerned with this exposure need additional patterns above the MVP layer.
# Privacy and Security
Mission-Bound OAuth introduces persistent records with potentially sensitive content. Baseline expectations:
- Audit context is confidential storage and MUST NOT be placed in tokens.
- `mission.id` is opaque and high entropy.
- `mission.id` and `mission.origin` are the same across every hop in a single Mission, which permits Resource ASes and audit-log readers to correlate user activity across audiences. Deployments that need stronger cross-audience unlinkability SHOULD issue audience-pairwise identifiers: the originating AS maintains a single internal Mission identifier but projects an audience-specific opaque value into each derived ID-JAG and access token. The mapping from audience-pairwise value to internal identifier MUST remain server-side at the originating AS. Cross-AS introspection MAY require explicit identifier resolution. Deployments that do not project audience-pairwise identifiers MUST document that the universal `mission.id` permits cross-audience correlation.
- `mission.origin` is itself correlation-bearing because it identifies the originating AS. Deployments under privacy-strict regimes MAY use a per-tenant or per-audience opaque issuer URI for `mission.origin`, with the trusted-issuer mapping maintained server-side.
- A single audience can correlate one user's behavior across distinct Missions using `sub` and timing. Deployments concerned with cross-Mission observability at a single audience SHOULD issue pairwise subject identifiers per `mission.id`, so the same user under two different Missions appears as two unlinked subjects at that audience. Tenant Binding addresses cross-tenant authority leakage; this is the complementary cross-Mission unlinkability control.
- `purpose` URIs are visible to every downstream Resource AS, RS, and audit record that processes a Mission-bound token. Deployments SHOULD NOT encode sensitive intent (project codenames, personnel actions, regulated-data identifiers) directly in `purpose`. When the human-readable purpose is sensitive, the AS should publish a stable but opaque URI and keep the sensitive label inside confidential audit context referenced by `evidence_id`.
- Cedar policies or other compiled policies should minimize embedded user identifiers.
- TLS is required for all Mission-related endpoints.
- SSF/CAEP events should carry Mission state changes, not prompt text or policy bodies.
- **Receipt minimization.** Audit records and receipts MUST minimize what is captured. Action parameters that contain sensitive data (personally identifiable information, financial details, regulated-data identifiers) MUST be replaced with `parameter_digest` (base64url-no-pad SHA-256 of canonical JSON of the parameters), not stored verbatim in the receipt. The full parameters are kept in confidential audit context referenced by `evidence_id`.
- **Auditor access control.** Confidential evidence (full prompt, plan, raw parameters, decision context) MUST be access-controlled separately from the portable receipt or audit record. A governance auditor presenting a receipt MAY request the linked `evidence_id` payload through a separate authenticated channel; the originating AS controls who can resolve `evidence_id` to evidence.
- **Separation of confidential evidence and portable proof.** The receipt is the portable proof of what was approved and what happened. The evidence is the confidential record of *why*. A receipt is shareable cross-domain; evidence is not. Deployments MUST NOT inline evidence into receipts, and MUST NOT use receipts as a backchannel for confidential data exfiltration.
## Lethal Trifecta Boundary
The agent lethal trifecta (private data access, untrusted content exposure, external side-effect or exfiltration authority in one execution loop) is not made safe by naming the task. The MVP's job is narrower. It prevents those authorities from becoming unbounded token derivation. Per-resource `resource_access` entries separate the three elements, derivation is short-lived and Mission-state-gated, and every derived artifact carries the same `mission.id` audit handle.
An MVP Mission can describe a task that touches all three sides of the trifecta, but it MUST NOT be treated as ambient permission to combine them freely. A safe deployment keeps the three elements separately represented:
| Trifecta element | MVP boundary |
| --- | --- |
| Private data access | Resource-specific `resource_access` entries and audience-bound tokens |
| Untrusted content exposure | Deployment-defined `mission_intent.context` constraints, confidential evidence, and RS policy |
| External side effects | Separate `resource_access` entries, short-lived derivations, and explicit Mission Expansion for out-of-bounds authority |
The MVP alone does not standardize execution-time PDP checks for non-OAuth local actions. Deployments whose Missions span all three sides of the trifecta should pair the MVP with the [Runtime Enforcement Profile](/notes/mission-bound-oauth-runtime-enforcement-profile/), which adds the Runtime Enforcement control table on top and turns the Mission into the runtime policy input so consequential actions are evaluated before execution, not only bounded at token issuance.
Main threats and mitigations:
- **Stale Mission state.** Mitigate with short-lived tokens, introspection, and SSF/CAEP invalidation.
- **Untrusted Mission origin.** A malicious assertion issuer could point `mission.origin` at a trusted AS. Mitigation: Resource ASes accept Mission origins only when bound to the trusted issuer by local policy, ID-JAG metadata, or a configured trust framework.
- **Mission identifier enumeration.** Mitigate with high-entropy identifiers, authenticated introspection, and rate limiting.
- **Policy injection from LLM output.** The LLM emits structured proposals only; the AS validates the proposal and compiles any formal policy after consent. Pinning intent at consent time with `proposal_hash` avoids relying on post-hoc reconstruction of user intent from agent behavior.
- **Silent constraint loss.** A derivation path could drop constraints it does not understand while preserving broad scopes. Mitigation: unknown constraints on any `authorization_details` entry are preserved, narrowed, or cause refusal; they are not silently ignored.
- **Downstream over-granting.** A Resource AS could treat an ID-JAG as sufficient authorization and issue broader local tokens. Mitigation: Resource ASes apply local policy and bind local tokens to Mission bounds, expiry, and tenant context.
- **Sender-constraint decoupling.** Keep sender constraints stable inside a Mission; treat key rotation as a new approval boundary.
- **Audience replay.** ID-JAG audience validation prevents assertions for one Resource AS from being used at another.
- **Confused deputy through sub-agents.** The `act` chain names the executing actor, while the Mission bounds maximum authority.
- **Audit tampering.** Use append-only, integrity-protected audit storage.
- **Long-lived Missions.** Enforce maximum Mission lifetimes by purpose and expose user revocation.
- **Cross-tenant leakage.** Include tenant context in the Authority Model and introspection policy.
# Architectural Challenges
The MVP is sophisticated for what it is, but it inherits some hard distributed-systems and security challenges that the protocol cannot eliminate. Naming them honestly is part of the spec's contract.
## State Synchronization Scale
The MVP relies on SSF/CAEP events to propagate Mission state changes across Resource ASes and Mission-aware RSes. In practice any network partition, broker outage, or replication lag means a revoked, suspended, or expired Mission may still permit valid token use for a short window. The MVP bounds this with short token TTLs and a requirement to fail closed when introspection at `mission.origin` is unreachable for state-changing operations, but the bound is operational, not cryptographic. The worst-case staleness is bounded by `min(token TTL, event lag + processing time, introspection cache TTL)`, not by zero. Deployments operating at scale must monitor event-delivery latency and tune cache and token lifetimes to their risk tolerance.
## Unknown Constraint Brittleness
The MVP requires that an AS or Resource AS encountering an unknown constraint key within a RAR entry either preserve it verbatim or refuse the derivation. This "fail-shut on unknown" rule is the right security default but creates real deployment brittleness in heterogeneous multi-vendor environments where minor RAR schema variations across vendors can trigger cascading refusals. The rule is a deployment-coordination cost, not a protocol bug; deployments operating across vendors should standardize their constraint vocabularies in advance (via RAR Metadata) or accept that unfamiliar constraints will block derivation by design. The alternative (silent drop) is worse: it converts a known refusal into a silent authority expansion.
# Standards Composition
The MVP is mostly composition. It names how existing OAuth surfaces participate in Mission state. The companion [Runtime Enforcement Profile](/notes/mission-bound-oauth-runtime-enforcement-profile/) adds composition points for runtime policy enforcement.
| Concern | Profile mechanism | Why it is needed | Composed with |
| --- | --- | --- | --- |
| Carry intent | `mission_intent` envelope plus `resource_access` (or ecosystem-specific RAR types) | Gives the AS a typed bundle to validate, render, approve, hash, and store as the Mission authority. Keeps intent out of free-text `scope`. | [RFC 9396 RAR](https://datatracker.ietf.org/doc/html/rfc9396), [RFC 9126 PAR](https://datatracker.ietf.org/doc/html/rfc9126) |
| Discover intent schema | Type metadata endpoint at the AS; RS advertises required RAR types | Lets orchestrators pre-validate proposals and discover which downstream services require Mission-bound authorization. | [draft-zehavi-oauth-rar-metadata](https://datatracker.ietf.org/doc/draft-zehavi-oauth-rar-metadata/), [RFC 9728 PRM](https://datatracker.ietf.org/doc/html/rfc9728) |
| Mission bootstrap | Authorization Code flow, with deferred code when approval cannot complete synchronously | Reuses the normal OAuth user approval path for immediate approval, while allowing the AS to keep the Mission in `pending_approval` until user, admin, risk, or assurance review completes. | [RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749), [draft-mcguinness-oauth-deferred-code-processing](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-deferred-code-processing) |
| Runtime escalation | AuthZEN requestable denial and access-request workflow (SHOULD-level) | Turns "not enough authority" into a governance workflow. Approval does not directly grant access; it becomes input to a fresh authorization decision or creates a successor Mission. | [AuthZEN Access Request](https://openid.github.io/authzen/authzen-access-request-approval-profile-1_0.html) |
| Out-of-band user contact | CIBA as an optional approval channel behind bootstrap or escalation | Lets the AS/OP contact the user asynchronously when fresh authentication or consent is needed. It does not replace Mission state, Mission expansion, or policy reevaluation. | [OpenID CIBA Core](https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html) |
| Token carries Mission handle | `mission` claim with `id` and `origin` | Binds every token or assertion back to the durable Mission record and tells downstream ASes where Mission state lives. | [RFC 9068 JWT access tokens](https://datatracker.ietf.org/doc/html/rfc9068), [RFC 9396 RAR](https://datatracker.ietf.org/doc/html/rfc9396) |
| Same-audience continuation | Mission-state-gated refresh | Prevents a long-running agent from refreshing tokens after the Mission is suspended, revoked, completed, or expired. | [RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749) |
| Cross-audience derivation | Mission-bound ID-JAG | Lets one approved Mission fan out to multiple audiences and Resource ASes without giving each hop broad standing authority. | [Identity Chaining](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/) (chaining framework), [ID-JAG](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/) (assertion profile), [RFC 8693 Token Exchange](https://datatracker.ietf.org/doc/html/rfc8693), [RFC 7523 JWT bearer](https://datatracker.ietf.org/doc/html/rfc7523) |
| Same-IdP chain continuation | Chain Continuation Assertion as Token Exchange `subject_token` for onward ID-JAG issuance | Keeps the IdP as trust anchor and subject-resolution authority when SaaS1 calls SaaS2 and SaaS2 needs an ID-JAG for SaaS3. Direct and chained calls use the same Token Exchange request shape; only the `subject_token` changes. | [RFC 8693 Token Exchange](https://datatracker.ietf.org/doc/html/rfc8693), [ID-JAG](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/), [Identity Chaining](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/) |
| Intra-domain call-chain context | Mission-bound access token exchanged at a Transaction Token Service to mint Txn-Tokens carrying `mission.id` and `mission.origin` in `tctx` | Preserves user-approved Mission authority as the durable layer above transient intra-trust-domain call-chain context. MBO is the user-approved authority; Txn-Tokens are the short-lived call-chain projections. | [Transaction Tokens](https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/) |
| Cross-trust-domain chaining of Txn-Tokens | Candidate composition with Txn-Token as `subject_token`; AS-A mints a JWT Authorization Grant (`typ: txn-chain+jwt`) for AS-B, with Mission fields transcribed by a follow-on profile | Lets a Mission-rooted Txn-Token cross trust boundaries without exposing internal workload identifiers. The Mission lifecycle stays at `mission.origin`; AS-B validates issuer trust and issues local tokens bound to the same `mission.id`. | [Transaction Token Chaining Profile](https://datatracker.ietf.org/doc/draft-fletcher-transaction-token-chaining-profile/), [Identity Chaining](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/) |
| Sub-agent delegation | `actor_token`, `act` chain on sub-agent paths, instance identity | Names the executing actor when work is delegated, while keeping the Mission as the maximum authority boundary. | [Actor Profile](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-actor-profile/), [Client Instance Assertion](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-client-instance-assertion/) |
| Issuer trust at Resource AS | Resource AS evaluates assertion issuer policy | Prevents arbitrary issuers from minting Mission-bound assertions or spoofing `mission.origin`. | [Identity Assertion Trust Framework](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-identity-assertion-trust-framework/), [Domain-Authorized Issuer Discovery](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-domain-authorized-issuer-discovery/) |
| Mission state lookup | Introspection response includes Mission state | Lets Resource ASes and Mission-aware RSes check whether a token is still authorized under the current Mission lifecycle. | [RFC 7662](https://datatracker.ietf.org/doc/html/rfc7662) |
| Mission termination | Mission lifecycle gates future derivation; token revocation can terminate the Mission | Makes stopping a task independent of waiting for every token to expire. | [RFC 7009](https://datatracker.ietf.org/doc/html/rfc7009) |
| Event-driven propagation | Mission state events | Reduces revocation staleness for downstream Resource ASes that cannot introspect on every request. | [RFC 8417 SET](https://datatracker.ietf.org/doc/html/rfc8417), [SSF](https://openid.net/specs/openid-sharedsignals-framework-1_0.html), [CAEP](https://openid.net/specs/openid-caep-1_0.html) |
| Portable provenance (optional) | Optional Mission receipt profile | Gives auditors or downstream domains portable evidence of consent and actor chain without making receipts mandatory in v1. | Future profile; can compose with [Actor Receipts](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-actor-receipts) |
The MVP does not invent a new authorization protocol. It defines a small binding layer across RAR, PAR, Token Exchange, JWT access tokens, introspection, revocation, and ID-JAG. The [Runtime Enforcement Profile](/notes/mission-bound-oauth-runtime-enforcement-profile/) layers runtime policy enforcement on top of this composition without changing it.
# Gaps and Open Issues
The MVP leaves several questions for working-group review. The companion [Runtime Enforcement Profile](/notes/mission-bound-oauth-runtime-enforcement-profile/) has its own open issues about formal policy compilation and tool-manifest binding shape.
☐ **Naming.** Is `mission` the right claim name, or would `authorization` or `mandate` fit OAuth terminology better?
☐ **`resource_access` standardization.** The MVP defines `resource_access` as a generic per-resource RAR type with `resource`, `actions`, and `constraints`. Should `resource_access` be promoted to a standalone IETF RAR type usable outside Mission-Bound OAuth, or should it stay tied to this profile? If a richer generic type emerges elsewhere (for example, the eventual outcome of `draft-chen-oauth-rar-agent-extensions`), should the MVP defer to it?
☐ **Termination default.** Should refresh-token revocation terminate the whole Mission by default, or should it default to per-token revocation?
☐ **Refresh-token coupling.** Should Mission lifetime be independent of refresh-token lifetime, or should one bound the other?
☐ **Event types.** Should Mission state event URIs live under an IETF namespace, an OpenID Foundation namespace, or deployment-specific namespaces?
☐ **Mission receipts.** Portable consent/provenance evidence is companion work. What is the smallest receipt profile that composes with the `proposal_hash` and `consent_rendering_hash` already defined here?
☐ **Mission Log retrieval.** Audit records are produced per Mission lifecycle and derivation event, but the MVP does not define how a governance team or post-incident reviewer fetches them by `mission.id` at the originating AS. Should this be an extension to RFC 7662 introspection (for example, a `mission_log=true` parameter that returns an ordered array), a separate governance read API, or strictly deployment-specific?
☐ **Mission management API.** The profile requires user/admin lifecycle operations by `mission.id`, but does not define the API. Should that API be standardized in v1 or left to deployment/admin surfaces?
☐ **Mid-approval clarification.** Today the user either approves or rejects the submitted proposal. A later profile could standardize a back-and-forth clarification handshake using a concrete wire shape on top of PAR plus Deferred Code:
1. **Pause.** The agent posts a Mission Proposal through PAR. The AS holds the Mission in `pending_approval` and the user reviews the rendering.
2. **Object.** The user rejects part of the proposal (for example, "you can read calendar events but not write them"). Rather than terminating the authorization, the AS returns a `412 Precondition Failed` (or an `error="interaction_required"` response with a `clarification_handle` field) carrying a machine-readable description of which entries or fields the user objected to.
3. **Revise.** The orchestrator submits a revised `mission_intent` array through PAR, referencing the `clarification_handle`. The new submission replaces the prior `request_uri`. The AS associates the revised proposal with the same pending Mission record.
4. **Approve.** The user sees the revised rendering. The AS computes `consent_rendering_hash` over the revised view and `proposal_hash` over the revised array, and releases the deferred code.
Deferred Code by itself is the "pause button" for OAuth: it lets the AS hold approval open while waiting for an out-of-band decision. It does not natively support "rewind and edit" of the proposal. A clarification-handshake profile would add that, and would let real human-in-the-loop negotiation happen on-the-wire instead of in deployment-specific UX glue.
☐ **Mission amendment model.** The MVP says expansion always creates a successor Mission. A later profile could allow a hybrid model: in-place version bumps for non-structural changes (extending `mission_expiry` by a small delta, tightening a constraint, narrowing an action) versus successor Missions for structural changes (adding a new `resource_access` entry, raising the budget cap, broadening tenant scope). The Mission record would carry a `version` field with an internal hash chain that the AS extends per in-place bump; successor Missions still get a new `mission.id` and a fresh `proposal_hash`. The open question is where the boundary lies and how the `proposal_hash` and consent-rendering semantics evolve under in-place bumps. Done right, this keeps the audit chain immutable while preventing database bloat from trivial extensions; done wrong, in-place mutation reopens the consent integrity question that `proposal_hash` was meant to close.
☐ **Superseded terminal state.** If expansion creates a successor Mission, should the prior Mission transition to `completed`, `revoked`, or a distinct `superseded` terminal state? A distinct state would let analytics and audit distinguish "Mission ended because the task was finished" from "Mission ended because authority was expanded."
☐ **Common `context` constraints.** The MVP defines `mission_intent.context` as the place for cross-cutting Mission bounds, but it does not standardize a common catalog. Should a later profile standardize fields such as `max_budget`, `currency`, `max_calls`, `max_duration`, `assurance_level`, `risk_tier`, geo bounds, or data-classification bounds (as in `draft-chen-oauth-rar-agent-extensions`), or leave them to ecosystem RAR types and deployment-defined `context` fields?
☐ **Per-sub-agent revocation inside an active Mission.** Today the only standardized response to a compromised sub-agent is to revoke the whole Mission, which also terminates the parent and any sibling sub-agents. Mission-wide revocation is too destructive for long-running workflows where the parent has already completed most of a multi-step task using other healthy sub-agents. A later profile could define a `revoke_actor` mechanism keyed on the compromised actor's identity at a specific `act` hop: the AS targets the `cnf` thumbprint at that hop and propagates an SSF/CAEP event (for example, `https://schemas.example.com/mission/actor-revoked` with `mission.id`, the targeted `cnf.jkt`, and the affected `act` position). Resource ASes that consume the event invalidate local tokens bound to that thumbprint; the parent orchestrator can then request a fresh sub-agent assertion under the same `mission.id` with a new `cnf` key and continue the task. The Mission state machine remains `active` throughout; only the compromised actor's tokens are evicted.
☐ **Key-compromise lifecycle event.** The Mission state machine handles user-initiated revocation, AS-initiated suspension, and natural expiry, but not "this `cnf` key is compromised." Today the response is Mission-wide revocation. A later profile could compose with CAEP `session-revoked` semantics scoped to the actor session, terminating only tokens bound to the compromised key while leaving the Mission active.
☐ **Mission Contraction.** Mission Expansion creates a successor with broader authority. The MVP has no equivalent event for shrinking authority mid-task (suspected partial compromise, scope reduction without restart). The current workaround is to suspend the Mission and create a narrower successor via the same approval surface, which preserves audit lineage but is operationally awkward. A later profile could define a Mission Contraction event whose successor reduces approved bounds while preserving the supersedence chain.
☐ **Profile compliance advertisement.** A deployment can claim "Tier-2 MVP" or "Tier-3 Runtime Enforcement" but the MVP does not define how that claim is advertised. Clients cannot discover supported profiles from `.well-known/oauth-authorization-server`. Two AS metadata fields are proposed: `mission_compliance_tiers_supported` (subset of `[1, 2, 3]`) and `mission_profiles_supported` (subset of `["mvp", "runtime_enforcement"]`). Should these be standardized in v1, or deferred to a profile-discovery companion draft?
☐ **Transaction Tokens composition (intra-domain).** `draft-ietf-oauth-transaction-tokens` (WG Last Call) defines short-lived intra-trust-domain JWTs that preserve transaction context through call chains. The MVP positions a Mission-bound access token as the durable user-approved authority layer that seeds a Transaction Token Service: the TTS mints Txn-Tokens whose `tctx` carries `mission.id` and `mission.origin`, and the Mission state at the originating AS gates whether new Txn-Tokens can be minted. Should MBO define a normative Txn-Tokens composition profile, including the exact `tctx` shape, the TTS audience policy, and the Mission-state check the TTS MUST perform before issuance? Or leave the composition to a separate draft?
☐ **Transaction Token chaining and RAR transcription (cross-domain).** Fletcher's [Transaction Token Chaining Profile](https://datatracker.ietf.org/doc/draft-fletcher-transaction-token-chaining-profile/) defines how a Txn-Token in Trust Domain A is exchanged for a JWT Authorization Grant (`typ: txn-chain+jwt`) that crosses to Trust Domain B. Appendix B of that draft notes RAR integration is future work: "a future revision MAY define how authorization_details from a Txn-Token are transcribed." MBO is a natural candidate to fill that hook by specifying how `mission_intent` and `resource_access` entries flow through the `txn_claims` object on the JWT Grant, including which entries are audience-filtered for AS-B. Should MBO contribute that transcription profile, or coordinate with the chaining-profile author?
# Standards Path
The natural shape is a single Internet-Draft, `draft-mcguinness-oauth-mission-bound-minimum-profile`, that profiles existing OAuth specs and defines the compact core surface:
- `mission_intent` RAR type (Mission envelope: `purpose`, `mission_expiry`, and deployment- or ecosystem-defined `context`).
- `resource_access` RAR type (generic per-resource authority: `resource`, `actions`, `constraints`).
- `mission` JWT claim (object with `id` and `origin` on tokens; AS extends with `state`, `expiry`, `purpose`, `proposal_hash`, `consent_rendering_hash`, `supersedes` on introspection responses).
- Chain Continuation Assertion token type for same-IdP SaaS-to-SaaS continuation, accepted only as a Token Exchange `subject_token` for onward ID-JAG issuance.
- Mission-Bound OAuth grant-profile identifier, likely `urn:ietf:params:oauth:grant-profile:mission-bound`.
- Inactive-Mission signaling at the token endpoint (`mission_state` extension field on the error response) and at introspection (`mission.state`).
- `proposal_hash` as the canonical hash of the entire approved `authorization_details` array (envelope plus resource authorities), computed using JCS (RFC 8785) and surfaced on the Mission record, introspection responses, and audit records.
- `consent_rendering_hash` as the hash of what the user actually saw at approval time, surfaced in audit and receipt-oriented artifacts.
- Minimum cross-AS validation rules binding `mission.origin` to a trusted assertion issuer and preserving Mission bounds on downstream local tokens.
The companion drafts remain independent: ID-JAG, Actor Profile, Client Instance Assertion, Deferred Code, Insufficient Claims, Target Service Discovery, RAR Metadata, Trust Framework, Domain-Authorized Issuer Discovery, and Actor Receipts.
The [Runtime Enforcement Profile](/notes/mission-bound-oauth-runtime-enforcement-profile/) describes the companion Internet-Draft `draft-mcguinness-oauth-mission-bound-runtime-enforcement-profile`, layered on top of this MVP, that adds runtime policy enforcement.
Mission-Bound OAuth as architecture is the destination. The MVP is the minimum useful step: capture intent, persist it, derive from it, and terminate it independently of token expiry.
# Standards Ask
A focused list of what this post asks of the standards community.
**Standardize now:**
- The `mission_intent` RAR envelope (`purpose`, `mission_expiry`, `context`), with context keys constrained by registered metadata or deployment configuration.
- The `resource_access` RAR type (`resource`, `actions`, `constraints`).
- The `mission` JWT claim object (`id`, `origin`) plus the AS-extended introspection shape (`state`, `expiry`, `purpose`, `proposal_hash`, `consent_rendering_hash`, `supersedes`).
- The Mission-Bound OAuth grant-profile identifier.
- Inactive-Mission signaling: `mission_state` extension field at the token endpoint, plus `mission.state` on introspection.
- `proposal_hash` (JCS-canonical SHA-256 over the approved `authorization_details` array) and `consent_rendering_hash` (SHA-256 over the rendered consent material).
- Minimum cross-AS validation rules binding `mission.origin` to a trusted assertion issuer and preserving Mission bounds on downstream local tokens.
**Compose with existing work:**
- RAR (RFC 9396), PAR (RFC 9126), JWT access tokens (RFC 9068), introspection (RFC 7662), revocation (RFC 7009), Token Exchange (RFC 8693), JWT bearer (RFC 7523), DPoP (RFC 9449), mTLS (RFC 8705).
- Identity Chaining as the cross-AS framework; ID-JAG and the Transaction Token Chaining Profile as sibling assertion profiles under it.
- Transaction Tokens for intra-trust-domain call-chain context; MBO is the durable layer above.
- CIBA as an out-of-band approval channel; SSF / CAEP for state propagation; RAR Metadata (`draft-zehavi-oauth-rar-metadata`) for type discovery.
- Companion drafts already in flight: ID-JAG, Actor Profile, Client Instance Assertion, Deferred Code, Trust Framework, Domain-Authorized Issuer Discovery, Actor Receipts.
**Defer to later profiles:**
- Mission Receipt Profile (W3C VC 2.0 substrate for portable provenance).
- Mission Management API (wire shape for user/admin lifecycle ops).
- Mid-approval Clarification Handshake (PAR + Deferred Code rewind-and-edit).
- Tool-Manifest Binding (deeper than `{uri, digest}`).
- Profile compliance advertisement (AS metadata for tier and profile discovery).
- Per-sub-agent revocation (`revoke_actor`), key-compromise lifecycle event, `superseded` terminal state, attestation-bound Mission `cnf`.
# Roadmap
The MVP is sequenced as one I-D that profiles existing OAuth specs, plus a companion family that fills out the rest of the architecture. The ordering reflects dependencies, not priorities.
## Now: shipping the MVP
The MVP draft and the companion drafts already in flight: ID-JAG, Actor Profile, Client Instance Assertion, Deferred Code, RAR Metadata, Trust Framework, Domain-Authorized Issuer Discovery, Actor Receipts. The [Runtime Enforcement Profile](/notes/mission-bound-oauth-runtime-enforcement-profile/) ships as a companion runtime-enforcement profile on the same timeline.
## Next: composition profiles that close the most-asked gaps
Each addresses one of the open issues in this post's Gaps section:
- **Mission Receipt Profile.** A signed Verifiable Credential bound to `mission.id`, `mission.origin`, `proposal_hash`, `consent_rendering_hash`, `evidence_id`, and the `act` chain. Composes with W3C VC Data Model 2.0 as the substrate.
- **Transaction Token RAR Transcription.** Fills the future-work hook in Appendix B of `draft-fletcher-transaction-token-chaining-profile` by specifying how `mission_intent` and `resource_access` flow through the JWT Grant's `txn_claims` object.
- **Mission Management API.** Wire shape for user/admin lifecycle operations keyed on `mission.id` (revoke, suspend, resume, complete).
- **Mid-approval Clarification Handshake.** PAR plus Deferred Code with `clarification_handle` semantics for "rewind and edit" of the proposal during consent.
- **Tool-Manifest Binding.** Standardized `tool_manifest` reference format on `mission_intent.context` (`{uri, digest}` minimum, signatures and version labels as extensions).
- **Profile Compliance Advertisement.** AS metadata fields `mission_compliance_tiers_supported` and `mission_profiles_supported`.
## Later: lifecycle and security extensions
- **Per-sub-agent revocation (`revoke_actor`).** SSF/CAEP event keyed on `cnf` thumbprint and `act` position; lets the parent evict a compromised sub-agent while keeping the Mission active.
- **Key-compromise lifecycle event.** CAEP composition for `cnf`-scoped revocation distinct from Mission-wide termination.
- **Superseded terminal state.** Promote `superseded` from a relationship to a distinct lifecycle state if analytics demand the distinction.
- **Attestation-bound Mission `cnf`.** RATS PTV composition for attested execution environments (`draft-anandakrishnan-rats-ptv-agent-identity`).
- **Common `context` constraint catalog.** Standardize `assurance_level`, `risk_tier`, geo bounds, and data-classification bounds on `mission_intent.context`.
## Long-term
- **Cryptographic actor-chain verification.** Extend [Actor Profile](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-actor-profile/) with a Verified Full Disclosure mode in which each `act` hop signs a commitment over the previous hop, so the chain is end-to-end verifiable for high-assurance Mission classes.
- **Post-quantum migration.** Crypto-agility for the integrity anchors (`proposal_hash`, `consent_rendering_hash`, `cnf` keys).
- **Mission federation across organizational boundaries.** Beyond the Multi-AS trust-binding rules in v1, into shared-Mission semantics across multiple originating ASes.
# Implementation Checklist
A deployment claims MVP compliance when all of the following hold. Items marked with section references point to the normative text.
**Authorization Server:**
- [ ] Accepts `mission_intent` envelope and `resource_access` entries (plus ecosystem RAR types) on `authorization_details` at PAR. (Mission Proposal)
- [ ] Validates each `authorization_details` entry against registered type metadata before rendering. (Mission Shaping)
- [ ] Renders a human-readable Mission Proposal for user approval; uses the post-validation proposal, not the original submission. (Mission Shaping)
- [ ] Creates a Mission record with a 7-state lifecycle (`pending_approval`, `active`, `suspended`, `revoked`, `expired`, `completed`, `rejected`). (Mission Lifecycle)
- [ ] Computes `proposal_hash` as base64url-no-pad SHA-256 of JCS-canonical `authorization_details` array, post-narrowing, at activation. (Proposal Hash)
- [ ] Computes `consent_rendering_hash` over the exact human-readable rendering shown to the user, with documented normalization rules. (Proposal Hash)
- [ ] Issues access tokens carrying the `mission` claim with `id` and `origin`. (Token Claim and Introspection)
- [ ] Narrows issued `scope`, `aud`, and `authorization_details` to approved Mission bounds. (Wire Interop Requirements)
- [ ] Gates refresh, token exchange, ID-JAG derivation, and introspection on Mission state. (Derivation)
- [ ] Returns `error="invalid_grant"` + `mission_state` extension field on inactive-Mission rejections at the token endpoint. (Mission Lifecycle)
- [ ] Caps Mission-bound ID-JAG `exp` at the deployment-profile maximum (recommended: 300 seconds). (Multi-AS Validation)
- [ ] Enforces understood `mission_intent.context` constraints as hard derivation bounds, and preserves or refuses unknown constraints. (Mission Proposal)
- [ ] Exposes a Mission management surface allowing user/admin revoke, suspend, resume, complete by `mission.id`. (Termination and Events)
- [ ] Binds tenant context into Mission record and issued tokens. (Tenant Binding)
**Issued tokens:**
- [ ] All Mission-bound access tokens, refresh tokens, and ID-JAGs are sender-constrained via DPoP or mTLS. (Client and Token Constraints)
- [ ] Derived-token `exp` never exceeds Mission `expiry`. (Derivation invariants)
- [ ] Sub-agent paths include an `act` chain following RFC 8693 conventions. (Derivation)
**Resource Server (RS-B minimum for Runtime Enforcement composition; RS-A acceptable for MVP):**
- [ ] Validates token signature, audience, expiry, sender constraint. (RS-A)
- [ ] Honors AS-narrowed `scope` and `authorization_details`. (RS-B)
- [ ] Rejects tokens whose tenant context does not match the resource. (Tenant Binding)
**Resource AS (for Tier 2 deployments):**
- [ ] Binds `mission.origin` to a trusted assertion issuer per local trust policy or trust framework. (Multi-AS Validation)
- [ ] Preserves `mission.id` and `mission.origin` on locally-issued tokens. (Wire Interop Requirements)
- [ ] Applies local authorization policy before issuing local tokens; does not treat an ID-JAG as a command to grant access. (Wire Interop Requirements)
**Discovery (proposed):**
- [ ] AS metadata advertises `mission_compliance_tiers_supported` (subset of `[1, 2, 3]`) and `mission_profiles_supported` (subset of `["mvp", "runtime_enforcement"]`). (See Gaps; not yet standardized.)
# References
- [RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749) — The OAuth 2.0 Authorization Framework
- [RFC 7009](https://datatracker.ietf.org/doc/html/rfc7009) — OAuth 2.0 Token Revocation
- [RFC 7523](https://datatracker.ietf.org/doc/html/rfc7523) — JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants
- [RFC 7662](https://datatracker.ietf.org/doc/html/rfc7662) — OAuth 2.0 Token Introspection
- [RFC 7800](https://datatracker.ietf.org/doc/html/rfc7800) — Proof-of-Possession Key Semantics for JWTs (`cnf`)
- [RFC 8417](https://datatracker.ietf.org/doc/html/rfc8417) — Security Event Token (SET)
- [RFC 8693](https://datatracker.ietf.org/doc/html/rfc8693) — OAuth 2.0 Token Exchange
- [RFC 8705](https://datatracker.ietf.org/doc/html/rfc8705) — OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
- [RFC 8785](https://datatracker.ietf.org/doc/html/rfc8785) — JSON Canonicalization Scheme (JCS)
- [RFC 9068](https://datatracker.ietf.org/doc/html/rfc9068) — JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
- [RFC 9126](https://datatracker.ietf.org/doc/html/rfc9126) — OAuth 2.0 Pushed Authorization Requests
- [RFC 9396](https://datatracker.ietf.org/doc/html/rfc9396) — OAuth 2.0 Rich Authorization Requests
- [RFC 9449](https://datatracker.ietf.org/doc/html/rfc9449) — OAuth 2.0 Demonstrating Proof of Possession (DPoP)
- [RFC 9470](https://datatracker.ietf.org/doc/html/rfc9470) — OAuth 2.0 Step Up Authentication Challenge Protocol
- [RFC 9728](https://datatracker.ietf.org/doc/html/rfc9728) — OAuth 2.0 Protected Resource Metadata (PRM)
- [draft-ietf-oauth-identity-chaining](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/) — OAuth Identity Chaining (chaining framework)
- [draft-ietf-oauth-identity-assertion-authz-grant](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/) — ID-JAG (assertion profile for user-authenticated flows)
- [draft-ietf-oauth-transaction-tokens](https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/) — Transaction Tokens (intra-trust-domain call-chain context)
- [draft-fletcher-transaction-token-chaining-profile](https://datatracker.ietf.org/doc/draft-fletcher-transaction-token-chaining-profile/) — Transaction Token Chaining Profile (assertion profile for Txn-Token-rooted flows)
- [AuthZEN Access Request](https://openid.github.io/authzen/authzen-access-request-approval-profile-1_0.html) — AuthZEN Access Request
- [draft-mcguinness-oauth-actor-profile](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-actor-profile/) — Actor Profile
- [draft-mcguinness-oauth-client-instance-assertion](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-client-instance-assertion/) — Client Instance Assertion
- [draft-mcguinness-oauth-deferred-code-processing](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-deferred-code-processing) — Deferred Code Processing
- [draft-mcguinness-oauth-identity-assertion-trust-framework](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-identity-assertion-trust-framework/) — Identity Assertion Trust Framework
- [draft-mcguinness-oauth-domain-authorized-issuer-discovery](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-domain-authorized-issuer-discovery/) — Domain-Authorized Issuer Discovery
- [draft-mcguinness-oauth-actor-receipts](https://datatracker.ietf.org/doc/draft-mcguinness-oauth-actor-receipts) — Actor Receipts
- [draft-zehavi-oauth-rar-metadata](https://datatracker.ietf.org/doc/draft-zehavi-oauth-rar-metadata/) — RAR Metadata
- [draft-yakung-oauth-agent-attestation](https://datatracker.ietf.org/doc/draft-yakung-oauth-agent-attestation/) — ACAP (Agent Client Attestation Profile)
- [OpenID CIBA Core 1.0](https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html)
- [OpenID Shared Signals Framework (SSF) 1.0](https://openid.net/specs/openid-sharedsignals-framework-1_0.html)
- [OpenID CAEP 1.0](https://openid.net/specs/openid-caep-1_0.html)