The Mission is the Missing Abstraction for Agents made the conceptual case. This post adds the Mission as a first-class OAuth artifact distinct from authority. The Runtime Enforcement Profile adds the runtime enforcement layer on top. Least-Privilege MCP Tool Calls Need a Mission applies the full stack to MCP.

Abstract

On the spine: Part 3 specifies the Mission and Authority steps on the OAuth substrate. The Intent step is generic (any Shaper, per Part 2); the Enforcement step is substrate-independent (per Part 6).

This profile makes the Mission a first-class OAuth artifact distinct from authority. The client submits structured Mission Intent. The Authorization Server validates and renders it, records the Approved Mission with integrity anchors, derives the authorization_details, and binds issuance, refresh, and exchange to that record. The design composes with existing OAuth rather than redefining its grant types or token formats.

Mission Intent describes the task. Authorization Details describe approved authority. Tokens carry that authority and a reference to the Mission that governs it.

Introduction

Part 1 makes the conceptual case: OAuth has no first-class object for the task that authority belongs to. This profile is the smallest OAuth wire surface that gives that object a name, a structured input, and a place to live.

The profile introduces Mission Intent as the structured request (the Mission Shape) and the Approved Mission as the AS-side record that satisfies the litmus test. Mission Intent is not authority. Authority is derived from an Approved Mission. Tokens carry a handle back to the Mission they were derived from.

The Mission-Bound OAuth architecture describes the broader destination. This profile defines the smallest OAuth wire surface needed to reach it.

Why RAR Is Not Enough

The most natural OAuth-side objection to this profile is that RFC 9396 Rich Authorization Requests already gives OAuth a typed structure for fine-grained authorization. It is the right wire-level surface for derived authority. This profile uses it. So why does Mission-Bound Authorization exist at all?

RAR carries authority. It does not carry a task. This profile builds on RAR; it does not replace it. The answer is what RAR alone does not provide that the Mission litmus test requires.

Duration. RAR describes fine-grained authority within an authorization transaction. It does not create a durable task object that survives authorization codes, access tokens, refreshes, and exchanges.

Identity. A RAR authorization_details array has no identifier. Two RAR-bound tokens issued ten minutes apart for the same task have no shared reference. The litmus property “identified” requires mission.id and mission.origin; RAR does not give one.

Task distinct from authority. In RAR, the client requests authorization_details and the AS may grant a subset. RAR does not separately represent the user-understood task from which that authority was derived. Mission Intent is the task proposal; the Authority Set is the approved authority. proposal_hash and authority_hash commit them separately.

Lifecycle. RAR has no state machine for the underlying task. Token or grant revocation does not create a durable task lifecycle that can be suspended, completed, or superseded.

Integrity anchoring. RAR does not specify a canonical hash over the approved request, nor over the rendering the user saw. Audit cannot prove “the user approved exactly this typed object” by comparing arrays heuristically. proposal_hash, authority_hash, and consent_rendering_hash do this work.

Cross-AS continuity. Two authorization domains can issue RAR-constrained credentials for the same task without sharing a task identifier. The Mission binding supplies that reference, using a canonical or audience-pairwise identifier resolvable at mission.origin.

Resource derivation from intent. Plain RAR clients submit authorization_details directly. This profile inverts that: the client submits Mission Intent (a user-language task), and the AS derives authorization_details against client registration, resource metadata, and deployment policy. The user approves the rendered Mission Intent plus the AS-derived authority. The derivation step is what RAR alone does not specify.

How this profile uses RAR. RAR is the OAuth authority projection. The AS derives authorization_details from the Approved Mission and binds issued credentials to the Mission record. RAR supplies the typed authority shape; the Mission supplies durable governance around it.

The short version: RAR expresses authority. The Mission governs the task that authority serves.

Profile at a Glance

The profile adds one governance loop to OAuth:

• Capture intent as a structured mission_intent parameter submitted through PAR.
• Record the validated proposal and, after consent, activate it as the Approved Mission.
• Anchor approved intent, effective authority, and the consent disclosure with separate hashes.
• Derive authorization_details from the Approved Mission.
• Bind each derived artifact to the Mission through mission.id and mission.origin.
• Gate refresh, exchange, and assertion issuance on Mission state; introspection reports that state.
• Terminate the Mission independently of token expiry.

The five-surface Core covers Mission Intent, the Mission record, derived authority, the mission claim, and the Mission-state gate. Cross-AS projection, lifecycle events, and same-IdP chain continuation compose with that Core. Runtime per-action enforcement remains in Part 6.

Design Goals

This profile:

• Captures user intent as a structured, reviewable object.
• Separates intent from authority.
• Provides an integrity anchor for the approved Mission so audit can verify what the user actually approved.
• Binds derived tokens back to the Mission they came from.
• Composes with existing OAuth: PAR, RAR, Token Exchange, JWT access tokens, introspection, and revocation.

This profile does not:

• Define permissions, scopes, or resource semantics.
• Define tool invocation or execution plans.
• Redefine OAuth’s base delegation semantics. This profile only constrains delegated artifacts to Mission bounds and preserves actor context where an adopted profile supplies it.
• Define a universal approval workflow or governance policy. It defines composition points for approval, deferred processing, and expansion.
• Replace Identity Chaining or ID-JAG. This profile defines only the Mission binding and an optional same-IdP continuation extension around those protocols.
• Define runtime per-action enforcement. It composes with the Runtime Enforcement Profile.

The irreducible Core is deliberately small. This post also specifies adjacent lifecycle, expansion, introspection, event, and cross-AS composition features so their relationship to Core is explicit. Runtime per-action evaluation remains a separate profile.

Mission Intent

The Mission Intent object is a structured request submitted by the client at authorization time. It is submitted as a top-level OAuth request parameter, analogous to (and distinct from) authorization_details. The client typically submits Mission Intent through PAR (RFC 9126).

A Mission Intent has five required fields:

• goal (string). A human-readable description of the desired outcome.
• objects (array of strings). Business-level entities the mission concerns. Objects are intentionally distinct from OAuth resources.
• constraints (array of strings). Requirements, limitations, or conditions that shape mission execution.
• success_criteria (array of strings). Observable outcomes indicating successful mission completion.
• mission_expiry (RFC 3339 timestamp). Hard ceiling on the Mission’s validity. Derived authority cannot outlast it.

Example:

1
2
3
4
5
6
7

{
  "goal": "Prepare the Q2 board packet",
  "objects": ["Q2 financials", "sales pipeline", "board presentation"],
  "constraints": ["require user approval before sending"],
  "success_criteria": ["presentation drafted", "approval obtained"],
  "mission_expiry": "2026-07-15T18:00:00Z"
}

The fields are intentionally domain-language. They describe the user’s task in a form the user or an approver can read. The base profile assigns no interoperable machine semantics to the strings in objects or constraints. A deployment MAY interpret them through registered mappings, resource metadata, or a purpose-specific profile during authority derivation; otherwise they remain disclosure and audit inputs rather than enforceable identifiers.

A profile MAY add optional fields. A purpose URI registered with the OAuth client at registration time is a common addition, useful when the AS validates the proposal against the client’s registered purpose class. Deployment-defined context fields (for example, classification, tenant, max_budget) are another common addition, where the AS enforces understood values as hard bounds during derivation.

The minimum JSON Schema for Mission Intent that the AS publishes at mission_intent_schema_uri:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://as.example.com/.well-known/mission-intent-schema",
  "title": "Mission Intent",
  "type": "object",
  "required": ["goal", "objects", "constraints", "success_criteria", "mission_expiry"],
  "additionalProperties": true,
  "properties": {
    "goal": {
      "type": "string",
      "minLength": 1,
      "maxLength": 2048
    },
    "objects": {
      "type": "array",
      "items": { "type": "string", "minLength": 1, "maxLength": 256 },
      "minItems": 1
    },
    "constraints": {
      "type": "array",
      "items": { "type": "string", "minLength": 1, "maxLength": 512 }
    },
    "success_criteria": {
      "type": "array",
      "items": { "type": "string", "minLength": 1, "maxLength": 512 },
      "minItems": 1
    },
    "mission_expiry": {
      "type": "string",
      "format": "date-time"
    },
    "purpose": {
      "type": "string",
      "format": "uri"
    },
    "context": {
      "type": "object",
      "additionalProperties": true
    }
  }
}

additionalProperties: true is deliberate: deployments and ecosystem profiles add optional extension fields (such as tool_manifest from the Runtime Enforcement Profile Tool Binding Optional Module). A deployment that publishes a stricter schema MAY constrain extensions through its $id. Validators MUST reject Mission Intent submissions that fail the published schema; this profile requires the AS to validate before rendering.

A base catalog of context keys with stable semantics for budget, duration, call counts, assurance level, risk tier, geo bounds, and data classification is defined in the companion Mission-Bound OAuth Extensions: Common Constraints Catalog. Core deployments MAY use the catalog or define their own context keys; the unknown-constraint rule below applies to every key not in the catalog or otherwise registered.

Mission Extraction

Mission Intent MAY be generated from natural language instructions by a Mission Shaper. The Mission Shaper is the component that transforms an unstructured user goal into a Mission Intent object. Implementations vary: LLMs that read a user prompt, rules engines that interpret a workflow trigger, forms-based UIs that collect structured input, workflow builders, or hybrids.

For example, a Shaper can turn “Prepare the Q2 board packet using finance and sales data; ask me before sending it” into the Mission Intent shown above.

Mission extraction SHOULD preserve user intent and constraints, avoid inventing permissions or resources, and surface ambiguity rather than guessing. Mission extraction MUST NOT issue authority, derive scopes, or derive access tokens. The output is a proposal only. Trust enters the system only when the Authorization Server validates the proposal and the user consents to a rendered version.

The Mission Shaper Profile (Part 2 of this series) specifies the Shaper’s input/output contract, the discovery sources it consumes, the tool-and-action binding step that closes manifest drift at extraction time, the structured ambiguity protocol, and the Shaper Trace. This profile requires the rules above; the Shaper profile defines what a conformant Shaper does to satisfy them.

Why the Shaper Is Client-Side

Part 2 gives the substrate-neutral argument: trust boundary, integrity-anchor semantics, ontology locality, and Shaper diversity all keep the Shaper in the orchestrator. The OAuth-specific consequence is that mission_intent arrives at PAR as a structured proposal the AS validates; the AS does not perform prompt-to-Intent extraction itself, and the user remains the final disambiguator on the rendered post-validation Mission Intent.

Terminology

• Mission: the durable governance object for one approved task. When discussing the pre-approval input, this profile uses Mission Intent; when emphasizing that consent has completed, it uses Approved Mission.
• Mission Intent: the structured request object the client submits at authorization time (goal, objects, constraints, success_criteria, mission_expiry). Submitted as a top-level OAuth request parameter, distinct from authorization_details. Mission Intent is not authority.
• Mission Shaper: the component that transforms a natural-language instruction into a Mission Intent object. May be an LLM, a rules engine, a workflow builder, a form, or a hybrid.
• Approved Mission: the active governance object produced after the Authorization Server validates Mission Intent and the user approves the rendered task and authority.
• Mission record: the AS-side lifecycle record for the pending proposal or Approved Mission, including identifier, state, integrity anchors, and audit context.
• Derived authority (the Authority step on the spine): the authorization_details, scopes, and access tokens derived from an Approved Mission. Distinct from Mission Intent. The Authority step lives in OAuth’s existing surface. The substrate-neutral container for these projections is the Authority Set, defined in Part 5; OAuth-only deployments may use the AS-derived authorization_details array as their single-substrate Authority Set. This profile uses “derived authority” rather than “Mission Authority” to avoid collision with the Mission Authority Server server role defined in Part 5.
• mission claim: the JWT claim that binds a derived token back to the Mission record. Object containing id (Mission identifier) and origin (the state-authority issuer URI; the originating AS in the default topology or the MAS in Part 5).
• proposal_hash: base64url-encoded SHA-256 digest of the JCS-canonical form (RFC 8785) of the approved Mission Intent. Stable for the Mission’s lifetime. The integrity anchor for audit.
• authority_hash: base64url-encoded SHA-256 digest of the JCS-canonical AS-derived authorization_details. Commits the Mission to the maximum OAuth authority actually granted.
• consent_rendering_hash: base64url-encoded SHA-256 digest of the JCS-canonical consent disclosure object containing the approved intent, effective authority, locale, template version, and material notices.
• resource_access: the generic per-resource RAR type (resource, actions, constraints) that the AS derives from an Approved Mission, alongside any deployment-specific RAR types.
• 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 defines four PDP deployment modes (AS-hosted, RS-hosted, tenant governance, federated). This profile 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 Intent (via the Mission Shaper) and submits it to the AS.
• 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 key history: the audit record of sender-constraint keys used for credentials under the Mission. Credential keys may rotate without changing approved authority; delegated actors receive their own narrowed, key-bound credentials.

A note on where the Mission record lives. This profile uses the originating OAuth AS as the default Mission state authority. The Mission Authority Server Profile defines a topology where a MAS owns the Mission record and a substrate-neutral Authority Set, while the OAuth AS becomes an authorized projection issuer. In that topology, mission.origin identifies the MAS, credential introspection remains with the credential issuer, and Mission Status comes from the MAS. The integrity-anchor semantics remain the same, but OAuth-specific authorization_details become one projection of the MAS Authority Set.

Composition Context

AAuth is the agent-native substrate. Signed agent requests, PS-mediated approval, mission-aware choreography, and native interaction surfaces. AAuth already defines its own native Mission. This profile is the OAuth-side wire spec; Mission-Bound AAuth Composition Profile (Part 4) defines how the governance model composes with AAuth’s native Mission, and Part 7 applies the framework to MCP across both substrates. This profile 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 close enough to compose. PAR can carry the proposed mission_intent parameter, while RAR carries the authority derived from it. 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. Transaction Tokens provide intra-trust-domain call-chain context, and their Mission carriage and cross-domain transcription are explicit follow-on MBO composition work. AuthZEN Access Request can turn eligible 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-governance system instead of unrelated protocol features.

Scope

This profile has one job: turn Mission Intent into an Approved Mission and bind every derived OAuth artifact to it.

It creates a protocol-visible link among:

• what the user meant to authorize (Mission Intent),
• what the Authorization Server approved and governs (the Approved Mission), and
• what each derived artifact is allowed to do (scopes, authorization_details, and audience).

Today, an agent can receive broad OAuth authority and rely on application logic, prompt discipline, or post-hoc audit to stay within the user’s task. Under this profile, the task becomes a governance object at the AS. The AS can gate refresh, exchange, expansion, and termination against it while existing Resource Servers continue accepting ordinary OAuth tokens.

This matters most when one task spans multiple resources or authorization domains. Each audience receives narrowed authority bound to the same Mission lineage, while privacy-sensitive deployments can use audience-pairwise Mission identifiers.

It adds five surfaces at the core, and a small set of adjacent features that compose with the core.

Core (the irreducible minimum):

A deployment that ships exactly these five surfaces reaches Conformance Level 1. The Core is what the I-D draft-mcguinness-oauth-mission-bound-minimum-profile standardizes as MUST-level.

The substrate-neutral Mission abstractions map onto OAuth wire artifacts as follows:

The left column is what every substrate must commit; the right column is the OAuth-specific surface. Part 4 maps the same concepts onto AAuth surfaces; Part 5 decouples the Mission Record into a substrate-neutral state authority.

Adjacent features also defined in this post, but composable extensions on top of Core:

Adjacent features are adopted according to deployment topology and claimed conformance level. The companion Runtime Enforcement Profile defines the additional surfaces required for Level 4 and for future Level 5 capabilities.

The five rows above are conceptual surfaces, not a count of every registry entry. The minimum wire and metadata surface also needs a grant-profile identifier, mission_intent_schema_uri, and inactive-Mission signaling at token and introspection endpoints. Deployments that use event-driven revocation additionally 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 this profile 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 Intent and resource authority on separate layers. Mission Intent is the user-facing input. The resource_access RAR type (or an ecosystem-specific RAR type) is the AS-derived output. The two cannot trade places. The AS derives authorization_details from an Approved Mission, never the other way around. This composes naturally with RAR ecosystems that will define their own resource types over time, without forcing Mission Intent to encode every resource’s authority taxonomy.

In a Mission-bound request, client-supplied authorization_details are derivation hints, not the authoritative input. The AS-derived array is the authority output. The Mission record lets later refresh, exchange, introspection, assertion issuance, and Resource AS issuance refer to the same approved task over time.

In Scope

This profile 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

This profile 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 this profile 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 reclaims several of these (AuthZEN PDP composition becomes normative, tool-and-action binding and portable receipts arrive as Optional Modules), and Part 7 applies the result to MCP. The “out of scope here” framing is bounded to this profile wire layer.

Key Use Cases

Five concrete cases this profile newly enables. The companion 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.
• This profile delivers: one user-approved Mission at the originating AS projects to many resource-specific tokens, all carrying the Mission binding and mission.origin. Cross-AS handoff via Token Exchange + ID-JAG preserves that binding. Revocation at the originating AS terminates derivation across every audience.
• Enabling features: Mission Intent parameter + AS-derived 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.
• This profile 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.
• This profile 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.
• This profile delivers: a standard place to carry cross-cutting Mission constraints. The Mission Intent’s constraints field captures user-language bounds. Profile-extension context fields capture machine-actionable bounds, where understood values become hard bounds and unknown values can pass only to a known enforcement point required to enforce them; otherwise derivation fails.
• Enabling features: Mission Intent constraints and context extensions, 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 cross-hop lineage

A governance team needs to reconstruct the Mission lifecycle, credential derivations, and actors involved across authorization domains.

• Today: audit logs are stitched together from per-AS records without a shared task identifier or a cryptographic anchor on the approved task.
• This profile delivers: Mission lifecycle and derivation events share a Mission binding and integrity anchors. Cross-AS records join through the canonical identifier or pairwise resolution at mission.origin; delegated paths preserve the act chain.
• Enabling features: Mission binding + mission.origin (shared task identity), proposal_hash + authority_hash + consent_rendering_hash (cryptographic approval anchors), evidence_id (handle to confidential evidence), act chain on sub-agent paths, SSF/CAEP events.

Per-action decision evidence is added by the Runtime Enforcement Profile; it is not a claim of this OAuth profile alone.

End-to-End Pipeline

Mission-Bound OAuth separates layers that are usually collapsed. Read top to bottom. Trust enters at AS validation.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

User prompt
  ↓ (Mission Shaper, LLM-driven, untrusted)
Mission Intent (proposed)
  ↓ (orchestrator submits at PAR as a top-level mission_intent parameter)
AS-validated Mission Intent
  ↓ (user consents to rendered version)
User-approved Mission Intent
  ↓ (AS activates Mission record + proposal_hash + authority_hash + consent_rendering_hash)
Approved Mission (the canonical governance object)
  ↓ (Authority Derivation: AS derives authorization_details from the Approved Mission)
Derived authority (authorization_details, scopes)
  ↓ (AS projects to audience-specific artifacts)
Token and ID-JAG projections
  (plus proposed Txn-Token composition)
  ↓ (PDP evaluates each consequential action)
PDP runtime decision
  ↓ (PDP writes per-decision evidence)
Decision evidence / receipt

The Mission record is the canonical governance object and commits the maximum approved authority. The derived authority (authorization_details, scopes), tokens, and ID-JAGs are projections of that commitment. A future MBO composition can also place a Mission projection in Transaction Token context. Resource policy remains authoritative for whether a particular request is allowed. Policy decisions and receipts are consequences of evaluating the projection, current Mission state, and local policy. This profile defines the upper half of this pipeline (Mission Intent through projections); the Runtime Enforcement Profile defines the lower half (PDP decisions and evidence).

Solution Overview

The Mission is the durable governance object that commits maximum authority. Tokens are audience-specific projections of that commitment.

The basic flow:

1. The user gives an agent a goal.
2. The orchestrator’s Mission Shaper turns that goal into a structured Mission Intent (goal, objects, constraints, success_criteria, mission_expiry) and posts it to the AS through PAR as a top-level mission_intent request parameter.
3. The AS validates the Mission Intent against client registration and deployment policy, renders it for the user, and on approval creates an active Mission record bound to the authorization code. The AS also derives the authorization_details (typically resource_access entries) that grant the actual authority.
4. The token endpoint issues an access token carrying the mission claim and the AS-derived authorization_details.
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 binding.
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: the authorization flow can hold the Mission in pending_approval until user, admin, or risk review completes. AuthZEN Access Request is the escalation path: runtime denial becomes a requestable governance workflow instead of a terminal error. In this profile, the AuthZEN Access Request escalation is SHOULD-level. The Runtime Enforcement Profile promotes it to MUST. CIBA composes with either path when the missing input is fresh out-of-band authentication or consent; CIBA is an approval channel, not a Mission governance model.

Existing Resource Servers do not have to understand Missions on day one; ordinary OAuth validation at the RS continues to work because the originating AS narrows issued scopes, audiences, and authorization_details to the approved Mission bounds (see §Wire Interop Requirements for the normative rules). Mission-aware Resource ASes and Resource Servers add introspection, event consumption, and per-request evaluation as deployments climb the Conformance Ladder.

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 this profile:

1. The orchestrator’s Mission Shaper translates the prompt into a Mission Intent: goal of preparing the board packet, objects for board materials and calendar context, constraints including confidential classification, success_criteria for packet drafted and approval obtained, and mission_expiry=2026-09-05T12:00:00Z. The client may also include an optional purpose=urn:example:mission:board-packet for client-registration policy.
2. The orchestrator posts the Mission Intent through PAR as a top-level mission_intent parameter. A deployment may apply its own duplicate-submission protection.
3. The AS validates the Mission Intent 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 Mission Intent on the Mission record, computes proposal_hash over it, derives the authorization_details (typically resource_access entries for calendar context, document drafting, and internal company-profile data), computes authority_hash over that effective authority, and issues an access token bound to the Mission carrying the derived authority.
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 AS-derived 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.

Reading the diagram:

• Dotted arrows mark the untrusted shaping path. Mission Intent remains a proposal until AS validation and user consent.
• Solid arrows show protocol flows after validation or credential issuance; each recipient still performs its required validation. The Mission record becomes active only after the AS validates the Mission Intent 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 access tokens, ID-JAGs, 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.
• The Transaction Token branch is a proposed MBO composition, not current base-draft behavior. It would exchange a Mission-bound access token at a Transaction Token Service and place a minimized Mission projection in tctx. Crossing trust domains can use ID-JAG for user-authenticated flows or the Transaction Token Chaining Profile for a call chain already rooted in Transaction Tokens, with Mission transcription defined by follow-on work.
• 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

This profile has five wire-level roles:

• User: approves the Mission.
• Orchestrator / agent client: converts the user’s goal into a structured Mission Intent and requests tokens.
• Originating Authorization Server / agent provider: validates Mission Intent, stores the Approved Mission, derives authorization_details, issues artifacts, and gates derivation.
• Resource Authorization Server: validates a Mission-bound assertion, applies local authorization, and issues a local access token.
• Resource Server: validates access tokens and enforces the authority relevant to the concrete request.

The trust boundary is the AS. The prompt and any LLM-shaped interpretation are untrusted until the AS validates the Mission Intent and the user consents to the rendered version.

Consent in this profile is AS-mediated rather than user-signed. This profile 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

This profile sits inside a layered architecture where four kinds of state have distinct owners. See Sessions Are Not Missions for the architectural rationale.

This profile 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. This profile 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.

A Mission can outlive any single harness. When a parent agent runtime crashes, becomes unhealthy, or hands off to a different vendor’s runtime, the Mission record at mission.origin is unaffected: lifecycle, integrity anchors, and Authority Set commitment remain. A successor harness can resume work under the same mission.id by obtaining freshly derived credentials from the state authority (subject to its consumer-authentication rules) and reading current Mission Status. This profile does not specify a harness-to-harness state transfer protocol because session, plan, and execution-history state are application-level concerns; the Mission record is the durable thing across runtime failures, and the harness reconstructs its plan from agent-runtime evidence plus the Mission record on resume. Concurrent runtimes sharing one Mission MUST use the atomic counters specified in Part 6 to prevent racing consumption of bounded authority.

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. An unknown constraint may be preserved only when the next enforcement point is identified and required to enforce that exact constraint; otherwise derivation MUST be refused. Constraints MUST NOT be silently dropped.
• A Resource AS that issues a local access token from a Mission-bound ID-JAG MUST preserve its Mission binding and mission.origin, either in the token or server-side. The binding is the same mission.id by default or an audience-pairwise projection resolvable at mission.origin.
• 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. MBO composes with two different protocol roles: inputs used by the IdP for ID-JAG issuance and assertions issued for another authorization domain.

Inputs to the IdP for ID-JAG issuance:

• Direct identity assertion. An OpenID Connect ID Token or SAML 2.0 assertion, as defined by ID-JAG. The ID-JAG draft also permits an IdP refresh token through its refresh-token extension. An arbitrary Mission-bound access token is not an ID-JAG subject token.
• Chain Continuation Assertion (typ: oauth-chain-continuation+jwt, proposed). A short-lived, sender-constrained assertion from an IdP-trusted chain authority. It is accepted only as a Token Exchange subject_token for onward ID-JAG issuance. It is not presented to a Resource AS and grants no API access by itself.

Assertions issued for another authorization domain:

• ID-JAG (typ: oauth-id-jag+jwt). The IdP issues an audience-specific identity assertion for a Resource AS after accepting one of the inputs above.
• Transaction Token Chaining Profile (typ: txn-chain+jwt). AS-A issues a JWT Authorization Grant for AS-B from a Transaction Token used inside Trust Domain A. The exact tctx shape, audience policy, and Mission claims transcription are candidate composition points for a follow-on profile.

ID-JAGs issued under this profile preserve the Mission binding, either by carrying the canonical mission.id or an audience-pairwise projection resolvable at mission.origin, and carry mission.origin. Mission carriage in a Transaction Token Chaining JWT Grant requires the follow-on composition described above. In either case, the accepting AS validates issuer trust 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 this profile default.
• Status model. The Resource AS obtains Mission state through issuer introspection when the issuer is also the state authority, or through Mission Status when mission.origin identifies a MAS.
• Event-backed model. The Resource AS relies on a current SSF/CAEP subscription from the state authority and rejects or degrades if the event stream is not current.

This profile 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, proposal_hash, and authority_hash. It does not need prompt text, full audit evidence, or entries that apply to other audiences.

The following is an illustrative MBO extension to RFC 7662 when mission.origin is also the credential issuer. The id-jag token-type hint and audience request member are not defined by base RFC 7662. When mission.origin is a separate MAS, the Resource AS uses Mission Status instead:

1
2
3
4
5
6

POST /introspect HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Bearer <resource-as-client-credentials>

token=<id-jag-value>&token_type_hint=id-jag&audience=https%3A%2F%2Fdocs.example.com

The response carries the audience-filtered Mission view:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

{
  "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-09-05T12:00:00Z",
    "purpose": "urn:example:mission:board-packet",
    "proposal_hash": "fS8h4w7Z3Lq...",
    "authority_hash": "o2j2...base64url-sha256..."
  },
  "authorization_details": [
    {
      "type": "resource_access",
      "resource": "https://docs.example.com",
      "actions": ["documents.read", "documents.write"],
      "constraints": { "folder": "board-materials" }
    }
  ]
}

When authenticated cross-AS introspection includes authorization_details, it returns only the AS-derived entries relevant to the requesting audience. Entries for other audiences (calendar, CRM, finance) are filtered out per the minimization rule. Authorized deployments may expose selected Mission Intent fields under the mission member or through Mission Status; base RFC 7662 is not a full Mission-record retrieval API.

Mission Shaping

This profile standardizes the submitted Mission Intent and the Approved Mission, not the entire agent-planning pipeline:

1. Prompt. Free text from the user. Untrusted input.
2. Intent extraction. The Mission Shaper parses the prompt into candidate fields: goal, objects, constraints, success criteria, time bounds, and named participants. Still untrusted. Lives in the orchestration layer.
3. Mission Intent. The structured object submitted as a top-level mission_intent request parameter at PAR (goal, objects, constraints, success_criteria, mission_expiry, plus any optional profile extensions such as purpose or deployment-defined context).
4. Approved Mission. The AS-side record created after validation and consent. The AS also derives the authorization_details (typically resource_access entries) at this stage and stores them on the Mission record.

The AS MUST validate the Mission Intent 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 Mission Intent and effective authority. The Approved Mission, not the prompt, is the durable governance 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 Mission Intent submission.

This profile 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; this profile 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. This profile 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 defines att_intent as a SHA-256 hash of the raw UTF-8 instruction text. This profile’s proposal_hash instead covers the AS-validated, post-narrowing Mission Intent. The two hashes answer different questions: one binds evidence to the original instruction; the other commits the typed object approved by the AS and user. A raw-prompt hash cannot substitute for the consent anchor because it preserves the prompt’s ambiguity rather than the validated proposal.

The optional purpose URI on Mission Intent plays the stable, lifecycle-managed role. It is registered with the client and tied to deployment policy. mission_expiry and any profile-extension context fields play the runtime, session-scoped role. They bound time and cross-cutting constraints for this run. The AS-derived resource_access entries (or ecosystem-specific RAR types) narrow the approved Mission Intent into the specific OAuth authority that tokens carry. proposal_hash covers the Mission Intent; authority_hash covers the derived authorization_details stored alongside it.

Mission templates, signed templates, and purpose taxonomy governance are work for later profiles.

Mission Lifecycle

The canonical Mission lifecycle state machine is defined in Part 1’s Mission Lifecycle section. The seven states, the transitions, and the invariants apply here unchanged. This section specifies the OAuth-substrate projection.

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.

Supersession (Mission Expansion creating a successor) is not a distinct state. 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 lifecycle state causes token endpoints to fail with error="invalid_grant" and a mission_state extension field carrying one of pending_approval, suspended, revoked, expired, completed, or rejected. When the mission.id does not resolve, the endpoint uses the diagnostic value mission_not_found; it is not a lifecycle state. The AS MAY also include error_uri pointing to deployment-specific documentation. Introspection returns active: false and includes either the lifecycle state or the same diagnostic.

A concrete inactive-Mission error response at the token endpoint:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

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"
}

Validation Layers

Mission-Bound OAuth separates three questions that are often collapsed into one credential:

Deployments can start with the token layer and add stronger layers as needed. This is why the wire surface of this profile can stay small while the architecture remains extensible.

Detailed Solution

Authorization Request

The agent submits Mission Intent as part of the OAuth authorization request, ideally through PAR so the proposal stays off the front channel. mission_intent is a top-level OAuth request parameter, distinct from authorization_details.

A representative pushed request:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

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=documents.read
&code_challenge=...
&code_challenge_method=S256
&mission_intent=<url-encoded Mission Intent JSON>

Decoded Mission Intent:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

{
  "goal": "Prepare the Q2 board packet",
  "objects": ["board materials", "calendar context"],
  "constraints": [
    "confidential classification",
    "board-materials folder only",
    "calendar window of 30 days"
  ],
  "success_criteria": ["packet drafted", "calendar context gathered"],
  "mission_expiry": "2026-09-05T12:00:00Z"
}

The Mission Intent fields are domain-language. They describe the user’s task in a form the user or an approver can review. The base profile does not assign interoperable machine semantics to objects or constraints; deployment mappings may use them as inputs to Authority Derivation.

A profile MAY extend Mission Intent with optional fields. A stable purpose URI tied to client registration is a common addition. Deployment-defined context fields are another. This profile does not standardize a global catalog of keys. An understood key becomes a hard derivation bound. An unknown key can pass only to a known enforcement point required to enforce it; otherwise the AS refuses derivation.

The Authorization Server derives authorization_details from the Approved Mission. The derived array typically contains one or more resource_access entries, plus any ecosystem-specific RAR types. Each resource_access entry carries: resource identifying the protected resource, API, or resource server where the authority will be used; actions listing the allowed action set; and constraints carrying 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 derived entry against the relevant type metadata and stores the entire derived array on the Mission record alongside the approved Mission Intent. The AS may also store audit context such as the prompt, plan, or other evidence, but that evidence is not carried in access tokens.

An example of authorization_details the AS might derive from the Mission Intent above:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

[
  {
    "type": "resource_access",
    "resource": "https://docs.example.com",
    "actions": ["documents.read", "documents.write"],
    "constraints": {
      "folder": "board-materials",
      "classification": "confidential"
    }
  },
  {
    "type": "resource_access",
    "resource": "https://calendar.example.com",
    "actions": ["calendar.events.read"],
    "constraints": {
      "time_window": "P30D"
    }
  }
]

The mapping from Mission Intent fields to derived authorization_details is deployment-specific. The AS uses client registration, the deployment’s resource ontology, and any purpose or context extensions to produce the typed authority. The Authority Derivation section below specifies what the AS MUST and MAY do during this step.

Clients discover the mission_intent schema through a profile-defined Authorization Server metadata member, mission_intent_schema_uri, whose value identifies a JSON Schema document for the top-level parameter. This field is an MBO extension because draft-zehavi-oauth-rar-metadata describes authorization_details types, not arbitrary top-level OAuth parameters. The AS separately advertises authorization_details_types_metadata_endpoint for each RAR type it may derive. Mission-aware resource servers can advertise their required authorization detail types through RFC 9728 PRM. Orchestrators use the Mission Intent schema, RAR type metadata, and PRM to pre-validate proposals before asking the user to consent.

Deployments MAY add an operational idempotency mechanism to prevent duplicate Mission creation, but this profile does not define a new PAR parameter or require reuse of a prior request_uri.

Integrity Anchors

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 approved Mission Intent (the post-narrowing form that the AS stores on the Mission record). The hash MUST be taken at the moment the Mission transitions to active. The proposal_hash value MUST be stable for the lifetime of the Mission. An amendment that changes the approved Mission Intent MUST create a successor Mission with its own proposal_hash.

The AS MUST also compute authority_hash as the base64url-encoded (no padding) SHA-256 digest of the JCS-canonical AS-derived authorization_details array that becomes the Mission’s maximum effective authority. Because JCS does not reorder arrays, the profile defines a semantic canonical order: entries are sorted by type, then resource or audience identifier, then the JCS bytes of the complete entry, unless the registered RAR type explicitly declares array order semantically significant. authority_hash MUST be computed before activation, stored on the Mission record, returned with the approved token response, and surfaced on authenticated Mission state and audit records. Any change to maximum effective authority MUST create a successor Mission.

When the AS narrows the proposal during validation (for example, trimming mission_expiry to a policy maximum, removing objects outside client registration, or tightening a constraint), the narrowed Mission Intent is what the user approves and is what proposal_hash covers. The consent rendering MUST include both that approved Mission Intent and a human-readable rendering of the AS-derived authority. The token-endpoint response MUST return the AS-derived authorization_details and authority_hash so the client knows and can verify the actual approved bounds. RFC 9396 §7 permits the AS to omit values; this profile profiles that point by making the derived-authorization_details return mandatory. Clients MUST verify authority_hash before treating the returned authorization_details as the approved bounds for runtime authority. The approved Mission Intent itself is canonical at the Mission record. An authenticated Mission read or status API MAY expose the post-narrowing fields according to requester authorization and minimization policy; base RFC 7662 introspection is not assumed to be a general Mission-record retrieval API. Later derivation requests are evaluated against the narrowed Mission Intent and the authority array committed by authority_hash, not against what the client originally submitted at PAR.

A narrowed token response example. The client originally proposed a 30-day calendar window; the AS narrowed the derived authority to 14 days during validation:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

{
  "access_token": "<token>",
  "token_type": "Bearer",
  "expires_in": 600,
  "mission": {
    "id": "msn_01HX4Y2P8BQ4Y3F0V0K9D6Z7M1",
    "origin": "https://as.example.com",
    "authority_hash": "o2j2...base64url-sha256..."
  },
  "authorization_details": [
    {
      "type": "resource_access",
      "resource": "https://calendar.example.com",
      "actions": ["calendar.events.read"],
      "constraints": { "time_window": "P14D" }
    }
  ]
}

The AS MUST also compute consent_rendering_hash over a JCS-canonical consent disclosure object, not over HTML, pixels, or implementation-dependent presentation bytes. The disclosure contains the approved Mission Intent, effective authority, locale, disclosure-template version, and material notices. The AS presents a human-readable rendering of that object and stores the canonical object for audit. proposal_hash proves which structured Mission Intent was approved. authority_hash proves the effective OAuth authority derived from it. consent_rendering_hash identifies the complete structured disclosure the AS says it presented; it does not prove that a compromised AS rendered it honestly. All three hashes are stored on the Mission record and surfaced in audit records.

Lifetime and Audience

The Mission carries two scoping dimensions: time and audience.

mission_expiry is an RFC 3339 timestamp on the Mission Intent:

1
2
3
4
5
6
7

{
  "goal": "Prepare the Q2 board packet",
  "objects": ["board materials", "calendar context"],
  "constraints": ["confidential classification"],
  "success_criteria": ["packet drafted"],
  "mission_expiry": "2026-09-05T12:00:00Z"
}

The AS enforces a maximum Mission age by deployment policy. mission_expiry is required. If it exceeds policy, the AS narrows the value before consent. Expiry is a hard ceiling. Continuing authority requires a new Mission.

Each resource_access.resource in the AS-derived authorization_details 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 part of the derived authority 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. The JWT itself does not carry the full Mission Intent; that lives on the Mission record at mission.origin and is exposed only through an authenticated, authorized Mission read or status surface. 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 this profile; deployments that add it should treat that as an explicit privacy and correlation decision.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

{
  "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": "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": 1788606000,
  "exp": 1788609600,
  "jti": "tok_..."
}

The token carries the AS-derived authorization_details plus the mission claim. The Mission Intent itself is not carried on the token. When mission.origin is the token issuer, authenticated token introspection can return Mission state. When mission.origin is an external MAS, the caller validates or introspects the token at its issuer and queries Mission Status at the MAS separately.

mission.id is opaque to the Resource Server. mission.origin identifies the state authority, which matters after ID-JAG handoff and in MAS deployments. Mission-bound tokens MUST be sender-constrained with DPoP or mTLS confirmation (cnf).

When the credential issuer is also the state authority, authenticated introspection returns normal RFC 7662 fields plus Mission state inside the mission member:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

{
  "active": true,
  "scope": "documents.read documents.write",
  "exp": 1788609600,
  "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-09-05T12:00:00Z",
    "purpose": "urn:example:mission:board-packet",
    "proposal_hash": "fS8h4w7Z3Lq...base64url-sha256...",
    "authority_hash": "o2j2...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.

For a Mission-bound token introspected at an issuer that also owns Mission state, the response MUST include the standard RFC 7662 fields plus a mission member containing at minimum:

• id: the opaque Mission identifier.
• origin: the state-authority issuer URI.
• state: one of the named lifecycle states. An unresolved identifier is reported separately with the diagnostic mission_not_found.

When the Mission is active, the response MUST additionally include:

• expiry: the Mission’s hard end-of-life timestamp (from the approved Mission Intent’s mission_expiry).
• proposal_hash: the canonical hash of the approved Mission Intent.
• authority_hash: the canonical hash of the AS-derived authorization_details that defines the Mission’s maximum effective authority.

If the approved Mission Intent carries an optional purpose URI, the response SHOULD include it. The response MAY include consent_rendering_hash, supersedes, and authorized Mission fields. Cross-AS responses MUST filter Mission fields and authorization_details to the requesting audience. When mission.origin is a MAS rather than the credential issuer, the caller validates the credential at its issuer and obtains this governance view through Mission Status.

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 governance object: a typed, AS-validated, user-approved bundle with integrity anchors and a lifecycle. It commits the maximum approved authority but does not override Resource Server policy. Policy artifacts (Cedar, OpenFGA tuples, or another deployment representation), token projections, and audit evidence 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.

This profile does not standardize the internal representation. Deployments may store the approved Mission Intent plus the AS-derived authorization_details, compile to scopes, create OpenFGA tuples, compile to Cedar, or use another local policy model. AuthZEN can carry evaluation requests and responses without defining that policy language. The protocol requirement is only that the AS can compare requested derivations against the approved bounds.

Authority Derivation

Mission Intent is user-language. authorization_details are protocol-language. The AS derives the second from the first at approval time. This is where the deployment’s ontology lives. “Q2 financials” in the Mission Intent’s objects maps to one or more resource_access.resource URIs at finance systems registered to this client. “require user approval before sending” in constraints maps to a constraint on the derived actions for any send-class operation, or to a deployment-defined context value.

This profile does not standardize the derivation algorithm. In single-vendor closed-world deployments, the AS knows the resource ontology and can derive directly. In open-world deployments, the AS MAY delegate validation to the Resource AS, accept client-submitted hints, or use registered mappings. Derivation MUST be reproducible over a versioned input set: the approved Mission Intent, requester registration, resource metadata, policy versions, and any trusted Resource-AS response used in the decision. Those versions or digests are retained with the Mission record so the resulting authority can be reconstructed.

The Authorization Server stores both the approved Mission Intent and the derived authorization_details on the Mission record. proposal_hash commits to the approved user-language input. authority_hash commits to the OAuth-conformant output that token issuance, refresh, exchange, assertion validation, and runtime policy compilation evaluate against.

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. This profile defines them for resource_access below; ecosystem-specific RAR types apply their own subset rules through their registered metadata.
• Mission Intent bounds apply across all derivations. mission_expiry is a hard ceiling: no derived token may have exp beyond it. If the approved Mission Intent carries an optional purpose URI, the AS uses it for client-registration policy checks at derivation time. Constraints in the Mission Intent (the user-language list) are not parsed for subset evaluation; they are inputs to the original Authority Derivation step.
• 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” when its narrowing and enforcement semantics are not defined by registered metadata or deployment configuration. A participant MAY preserve it verbatim only when the next enforcement point is identified and required to enforce that exact key and value. Otherwise it MUST refuse 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. This profile 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’s derived authorization_details 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 Mission Intent plus the AS-derived authorization_details after consent and project that policy to capable Resource Servers. Clients do not submit formal policy text at PAR in this profile. The Mission Intent parameter plus the AS-derived resource_access (or ecosystem-specific) entries form the consent surface.

Delegated Authority Validation

In open-world deployments where the AS does not know the resource’s domain ontology, the AS MAY delegate domain-semantics validation to a Resource AS that owns the operation. The Shaper-supplied source-bound hints (source_uri, operation_ref, source_digest from Part 2) become input to the handshake. The full wire shape (AS-to-Resource-AS request and response, delegated_validation_endpoint PRM advertisement, freshness window, drift handling) is specified in the companion Mission-Bound OAuth Extensions: Delegated Authority Validation. Core deployments without open-world tool discovery do not need this extension.

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 this profile. A deployment can still use the Mission record as an input to local policy, but the wire-level OAuth profile does not standardize PDP consultation, tool invocation checks, or per-action evidence. The separate Runtime Enforcement Profile 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 starts from a user-authenticated identity assertion and needs a protected resource behind a 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 an ID-JAG-supported identity assertion as subject_token (an OpenID Connect ID Token or SAML 2.0 assertion; an IdP refresh token MAY be used when the ID-JAG refresh-token extension is supported).
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 assertion freshness, authenticated status, or events, applies local authorization policy, and issues a local access token preserving the assertion’s Mission binding.

Same-IdP chain continuation and Transaction Token Chaining. Two additional derivation paths compose with Core when the originating credential or trust topology requires them: the Chain Continuation Assertion as a Token Exchange subject_token for onward ID-JAG issuance when a same-IdP SaaS chain (ClientA → SaaS1 → SaaS2 → SaaS3) needs the IdP to remain the subject-resolution authority, and the Transaction Token Chaining JWT Grant for cross-trust-domain handoff when intra-domain Txn-Tokens are the call-chain substrate. Both are specified in the companion Mission-Bound OAuth Extensions: they preserve the Mission binding across hops without changing the Core direct-ID-JAG request shape, and the choice between paths is driven by the originating credential and trust model rather than the target audience alone.

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).

The same mission.id rides the parent token, the Token Exchange, and the sub-agent token. The cnf thumbprint changes per actor, so a compromised sub-agent key cannot replay as the parent. The act chain identifies which actor performed the call without changing the underlying Mission authority. Per-actor revocation keyed on cnf thumbprint is companion work; today, sub-agent compromise still requires whole-Mission revocation.

Mitigations for nested act chain size at deep delegation (bounded delegation depth with switch to opaque reference tokens, act_chain_digest summarization, flat-array PDP projection) are specified in the companion Mission-Bound OAuth Extensions: Token Size at Depth. Core deployments with shallow delegation (3–4 hops) do not need these mitigations.

Five invariants apply to every path:

• The Mission binding is preserved under derivation. By default this is the same mission.id; privacy-sensitive deployments MAY carry an audience-pairwise projection that mission.origin can resolve to the canonical Mission.
• Mission state is checked before new authority is issued or accepted.
• Authority can narrow but cannot expand without a new approval.
• Any derived credential with an exp claim MUST NOT exceed Mission expiry. Refresh credentials, including opaque refresh tokens, MUST become unusable for new issuance at Mission expiry.
• 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.

This is a deliberate constraint, not a limitation. proposal_hash, authority_hash, and consent_rendering_hash commit a specific approved tuple. A mutable Mission whose authority evolved over its lifetime would have to either rehash on every change (breaking the immutable audit anchor) or carry every prior commitment (making the Mission record unbounded and audit reconstruction non-deterministic). A hierarchical Mission tree with conditional capabilities faces the same tradeoff. The successor-Mission model preserves the immutable hash at each step and keeps the supersedence chain available through mission.supersedes for audit reconstruction. The cost is one additional Mission record per expansion; the benefit is that “what did the user actually approve at each point in time” is always answerable from the audit chain without replaying mutation history.

Approval fatigue is mitigated by the deployment-policy-driven approval workflow, not by relaxing the hash commitment. The AuthZEN Access Request profile supports user, administrator, risk-engine, and policy-based approval; trivial pivots inside permissive deployment classes can be auto-approved without a human round-trip while still creating a successor Mission for audit. Material expansions, by design, require the original approver back in the loop. The deployment chooses where the human-in-the-loop boundary lies through registration policy and approval-workflow configuration.

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 proposing the expanded authority.

When expansion is approved, activation of the successor and termination of the prior Mission MUST be atomic from the state authority’s perspective. The prior Mission transitions to completed (AS-driven, not subject to the client-completion-advisory rule), and new derivations use the successor mission.id. Existing tokens continue only at tiers that rely on token expiry alone; Mission-aware introspection or event consumers reject them once the prior Mission becomes inactive. Whether completed should become a distinct superseded state is an open question.

The wire shape for the requestable-denial path:

The successor Mission is the only authoritative bearer of expanded authority. Derivations under msn_prior after expansion fail because msn_prior is completed. Denials leave the prior Mission untouched, and the same out-of-bounds request will continue to be refused until a different expansion is approved.

Concurrent Expansion

When multiple sub-agents trigger Mission Expansion requests simultaneously, the state authority reconciles proposals deterministically. The reconciliation rules (idempotent collapse on identical proposals, sequential serialization for non-overlapping, rejection on conflict, in-flight expansion lock) are specified in the companion Mission-Bound OAuth Extensions: Concurrent Mission Expansion. The pipelining halt on an expansion request is by design: expanding user-approved authority requires a decision from an approver; concurrent reconciliation ensures simultaneous requests resolve to one outcome rather than racing to create conflicting successor Missions.

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.

RFC 7009 revokes the presented token and, where supported, its associated grant or token family according to issuer policy. It MUST NOT implicitly terminate the whole Mission unless the issuer has explicitly documented that behavior. Mission-wide termination uses the Mission management surface by mission.id; a future binding may define an explicit OAuth signal.

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. This profile 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:

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.

Conformance

Part 8 defines the substrate-neutral Conformance Ladder, Resource Server Tiers, and Compliance Tiers. This OAuth profile supplies the following capabilities:

• Level 1: Mission-bound issuance using mission_intent, the Mission record, derived authority, the mission claim, and Mission-state-gated derivation.
• Level 2: Mission-aware projection across same-AS audiences and, where needed, across AS boundaries using ID-JAG and the Multi-AS Validation rules. Transaction Token Mission carriage remains follow-on work.
• Level 3: RS-C enforcement of Mission state and audience-relevant authority.
• Level 4: The Runtime Enforcement Profile Core.
• Level 5: Level 4 plus interoperable specifications for each claimed verifiable-governance capability.

The Mission Authority Server Profile is an independent topology choice available at any level.

Operational Requirements

OAuth-side dependencies by Conformance level

This profile composes with a deep OAuth and OIDC stack: PAR, RAR, JWT access tokens, Token Exchange, ID-JAG, introspection, revocation, SSF/CAEP, AuthZEN. The substrate-neutral Conformance Ladder, Compliance Tiers, and Resource Server Tiers are defined in Part 8: Mission-Bound Authorization Conformance. The OAuth-side dependencies needed to claim each Compliance Tier are:

A deployment claims a Conformance Ladder level, a Compliance Tier, and a per-RS Resource Server Tier as complementary coordinates subject to Part 8’s consistency rules. See Part 8 for the coordinate framing, the Resource Server Tiers (RS-A through RS-D), and the cross-substrate mapping.

OAuth-substrate notes on each RS Tier:

• RS-A: Token-only. Validates scope, audience, expiry, signature, and sender constraint. Ignores the mission claim. Mission invalidation is bounded by token expiry.
• RS-B: Mission-state aware. Also resolves the Mission binding and refuses inactive Missions using an authenticated status response, a bounded cache, or current events. It does not yet evaluate per-request Authority Set entries.
• RS-C: Authority-aware. Also enforces the audience-relevant authorization_details or Authority Set projection against the concrete request.
• RS-D: PDP-evaluated. Consults a PDP for every consequential request under the Runtime Enforcement contract and records per-decision evidence.

The Mission gate at the AS works even with RS-A audiences, provided the AS narrows issued tokens to Mission bounds. RS-B reduces lifecycle staleness, RS-C adds request-time authority enforcement, and RS-D adds the full PDP contract.

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 in this profile.

Client and Token Constraints

Mission-bound clients may be confidential or public where the underlying OAuth flow permits them. Public clients MUST use the applicable OAuth security profile, including Authorization Code with PKCE and exact redirect URI matching. Operations that require client authentication, such as privileged lifecycle administration or some Token Exchange deployments, remain limited to clients that can satisfy that endpoint’s authentication policy.

Mission-bound access tokens, refresh tokens, and ID-JAGs MUST be sender-constrained when the selected credential profile supports sender constraint. DPoP or mTLS confirmation (cnf) binds the credential to a key. Routine key rotation does not change user-approved authority and MUST NOT require a new Mission. The AS authenticates the rotation under deployment policy, records it in audit, and binds newly issued credentials to the replacement key. Sub-agent delegation remains distinct: the delegated actor receives a narrowed credential bound to its own key and is represented in the actor chain.

Mission-bound access tokens should be short-lived by default. Stale-state risk at RS-A audiences is bounded by token TTL because that tier does not consume Mission state. RS-B through RS-D have an independent invalidation path through authenticated Mission Status, bounded cache, or current events, subject to their published freshness policy. 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 constraints.
• Mission-bound access tokens, refresh tokens, and ID-JAGs MUST carry tenant context via the tenant and aud_tenant claims defined in ID-JAG, 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 Intent submissions 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:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

{
  "mission": {
    "id": "msn_01HX4Y2P8BQ4Y3F0V0K9D6Z7M1",
    "origin": "https://as.example.com",
    "proposal_hash": "fS8h4w7Z3Lq...base64url-sha256...",
    "authority_hash": "o2j2...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.

The Mission record is the join key. Every audit-relevant artifact links back to it:

Cross-AS records join through the canonical mission.id or through authorized pairwise-identifier resolution at mission.origin. Confidential evidence is referenced by evidence_id and never travels in tokens or transmitted audit records, so a log dump that fans out across audiences can be joined without exposing prompts or raw parameters.

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, authority_hash, evidence_id, consent_rendering_hash, and auth_context. That is useful, but not required for this profile.

Threat Model

This profile 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 obtain broader authority through a conformant derivation path without new approval, but it can misuse authority already issued to it. Sender constraint limits replay by parties that do not possess the bound key; it does not help when the client or key itself is compromised.
• 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. A conformant RS cannot obtain new authority after revocation, but a compromised RS can ignore token and Mission checks and misuse data or operations it controls. That server compromise is outside the protocol’s prevention boundary.
• 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 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, authority_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 the integrity hashes 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 Intent can be influenced by untrusted content (web pages, document attachments, tool outputs). AS validation of the Mission Intent 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. Understood constraints are hard bounds. Unknown constraints can pass only to a known enforcement point required to enforce them; otherwise derivation fails. An AS that falsely claims understanding still cannot be detected at the wire layer. Metadata listing enforced keys is one mitigation; cross-AS attestation 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 this profile 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 this profile 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.origin is preserved across every hop. The default profile also preserves the canonical mission.id, which permits Resource ASes and audit-log readers to correlate activity across audiences. Deployments that need stronger cross-audience unlinkability SHOULD issue audience-pairwise Mission identifiers: the originating AS maintains one canonical internal identifier but projects an audience-specific opaque value into each derived ID-JAG and access token. The mapping MUST remain server-side at the originating AS. Cross-AS introspection and authorized audit joins then require explicit identifier resolution. Deployments that use the canonical mission.id on the wire MUST document its cross-audience correlation property.
• Request-pairwise identifiers are a stronger privacy tier than audience-pairwise. A deployment whose threat model includes a single audience joining records across calls within one Mission MAY project a fresh opaque identifier on each derived credential. The state authority retains the canonical-to-projection map server-side; audit reconstruction at any audience then requires authoritative resolution at mission.origin for every record join. The trade is privacy strength against per-call resolution overhead. Suitable for high-assurance Missions where intra-audience behavioral correlation is itself the threat model; not a default because of audit-join cost. The Resource Server still validates Mission state and audience-relevant authority via authenticated Mission Status, so request-pairwise identifiers do not weaken enforcement.
• mission.origin is itself correlation-bearing because it identifies the state authority. Privacy-sensitive deployments can use legitimate tenant-specific issuer aliases that publish verifiable metadata; arbitrary opaque aliases that cannot be authenticated are unsafe.
• A single audience can correlate one user’s behavior across distinct Missions using sub and timing. Mission-pairwise subject identifiers are possible only where the authorization and account model can tolerate a distinct subject per Mission; they are an advanced deployment choice, not a baseline recommendation.
• 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.
• Evidence minimization. Audit records SHOULD store parameter digests rather than raw sensitive parameters. Full parameters, when operationally required, belong in separately access-controlled evidence referenced by evidence_id. Portable receipt rules are defined only by a receipt profile.

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. This profile’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 a Mission audit handle that is either canonical or resolvable at mission.origin.

A Mission under this profile 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:

This profile 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 this profile with the 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 pass only to an identified enforcement point required to enforce them; otherwise derivation fails.
• 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. Authenticate and audit key rotation without treating routine cryptographic maintenance as authority expansion.
• 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

This profile 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

Mission state can reach downstream parties through token expiry, synchronous status checks, cached status, or events. The effective revocation window depends on the decision path each audience actually uses; there is no universal min(...) formula. An offline RS is bounded by token lifetime, a polling RS by cache policy and outage behavior, and an event-driven RS by event lag plus its fallback policy. Deployments MUST document and monitor the worst-case bound for each audience.

Unknown Constraint Brittleness

This profile permits pass-through of an unknown constraint only when the next identified enforcement point is required to enforce the exact value; otherwise derivation fails. This fail-shut rule creates real deployment brittleness in heterogeneous environments, but silent drop would create an authority expansion. Cross-vendor deployments therefore need coordinated constraint vocabularies and RAR Metadata before they can derive reliably.

Standards Composition

This profile is mostly composition. It names how existing OAuth surfaces participate in Mission state. The companion Runtime Enforcement Profile adds composition points for runtime policy enforcement.

This profile 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 layers runtime policy enforcement on top of this composition without changing it.

Gaps and Open Issues

This profile leaves several questions for working-group review. The companion 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. This profile 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 this profile defer to it?

☐ 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, authority_hash, and consent_rendering_hash already defined here?

☐ Mission Log retrieval. Audit records are produced per Mission lifecycle and derivation event, but this profile 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 Intent 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 through PAR, referencing the clarification_handle. The new submission replaces the prior request_uri. The AS associates the revised Mission Intent with the same pending Mission record.
4. Approve. The user sees the revised intent and effective-authority rendering. The AS computes proposal_hash over the revised Mission Intent, derives the effective authorization_details, computes authority_hash, computes consent_rendering_hash over the revised view, 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. This profile 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 Constraints Catalog standardization. The companion Mission-Bound OAuth Extensions: Common Constraints Catalog defines a base catalog covering max_budget, max_calls, max_duration, assurance_level, risk_tier, geo_bounds, and data_classification. Future work includes IANA registration, a formal extension mechanism, and convergence with adjacent drafts (e.g., draft-chen-oauth-rar-agent-extensions) so cross-vendor deployments can reuse the same keys.

☐ 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. This profile 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 OAuth profile” or “Tier-3 Runtime Enforcement” but this profile 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 defines short-lived intra-trust-domain JWTs that preserve transaction context through call chains and is awaiting RFC publication. This profile positions a Mission-bound access token as the durable user-approved authority layer that could seed a Transaction Token Service. A normative composition still needs to define the exact tctx shape, audience policy, and Mission-state check.

☐ Transaction Token chaining and RAR transcription (cross-domain). Fletcher’s 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 the Mission handle and the AS-derived 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 top-level OAuth request parameter (Mission Intent object: goal, objects, constraints, success_criteria, mission_expiry, with optional profile extensions for purpose and deployment-defined fields).
• mission_intent_schema_uri Authorization Server metadata for discovering the JSON Schema of that top-level parameter.
• resource_access RAR type (AS-derived 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, authority_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 approved Mission Intent, computed using JCS (RFC 8785) and surfaced on the Mission record, introspection responses, and audit records.
• authority_hash as the canonical hash of the AS-derived authorization_details, computed using JCS and surfaced on the Mission record, approved token response, introspection responses, and audit records.
• consent_rendering_hash as the hash of the canonical structured consent disclosure used to produce the approval view, 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 describes the companion Internet-Draft draft-mcguinness-oauth-mission-bound-runtime-enforcement-profile, layered on top of this profile, that adds runtime policy enforcement.

Mission-Bound OAuth as architecture is the destination. This profile 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 top-level OAuth request parameter (Mission Intent object: goal, objects, constraints, success_criteria, mission_expiry), with constraint keys constrained by registered metadata or deployment configuration, and a profile extension point for fields such as purpose.
• The mission_intent_schema_uri Authorization Server metadata member, separate from RAR type metadata.
• The AS-derived 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, authority_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 Mission Intent), authority_hash (JCS-canonical SHA-256 over effective authorization_details), and consent_rendering_hash (JCS-canonical SHA-256 over the structured consent disclosure).
• The Chain Continuation Assertion token type and validation rules, accepted only by an IdP as a Token Exchange input for onward ID-JAG issuance.
• 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, and attestation-bound sender context.

Roadmap

This profile 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 this profile

This profile 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 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, authority_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 the Mission handle and the AS-derived 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 constraints ({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 sender context. RATS PTV composition that binds credential keys or authenticated execution context to attested environments (draft-anandakrishnan-rats-ptv-agent-identity).
• Common constraints catalog. Standardize assurance_level, risk_tier, geo bounds, and data-classification bounds on Mission Intent constraints.

Long-term

• Cryptographic actor-chain verification. Extend 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, authority_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.

Migration Story

The Stage 0–5 adoption sequence for incremental deployment — Shadow Mission, refresh gating, authority narrowing, per-RS uptake, cross-AS continuity, plus common back-compat hazards and the board-packet worked example across stages — is specified in the companion Mission-Bound OAuth Extensions: Migration Story. Each adoption stage delivers value on its own and maps explicitly onto Conformance Ladder levels.

Implementation Checklist

A deployment claims Profile compliance when all of the following hold. Items marked with section references point to the normative text.

Authorization Server:

• Accepts mission_intent as a top-level OAuth request parameter at PAR. Accepts ecosystem-specific RAR types on authorization_details only as derivation hints; treats the AS-derived array as authoritative. (Authorization Request)
• Publishes and validates Mission Intent against the schema identified by mission_intent_schema_uri. (Mission Extraction)
• Renders the validated Mission Intent (post-narrowing) for user approval, not the original submission. The Approved Mission is the record produced after the user consents. (Mission Extraction)
• Derives the AS-issued resource_access entries (or ecosystem RAR types) from the Approved Mission and stores them on the Mission record. (Authority Derivation)
• 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 the JCS-canonical user-approved Mission Intent at activation. (Integrity Anchors)
• Computes authority_hash as base64url-no-pad SHA-256 of JCS-canonical AS-derived authorization_details, returns it with the approved authority, and rejects in-place authority changes. (Integrity Anchors)
• Builds and stores the canonical consent disclosure object containing the approved Mission Intent, effective authority, locale, template version, and material notices; renders that object for approval; and computes consent_rendering_hash over its JCS-canonical form. (Integrity Anchors)
• 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, and ID-JAG issuance on Mission state; introspection reports inactive state as active: false. (Derivation; Token Claim and Introspection)
• 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 constraints as hard derivation bounds; passes unknown constraints only to a known enforcement point required to enforce them, otherwise refuses. (Authority Derivation)
• 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:

• Mission-bound access tokens are sender-constrained via DPoP or mTLS. Refresh credentials remain bound to the same client/key, and ID-JAG sender constraint is applied when the selected assertion profile supports it. (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:

• Every in-scope RS validates token signature, audience, expiry, and sender constraint. (RS-A)
• An RS-C claim additionally requires enforcement of audience-relevant scope and authorization_details against the concrete request.
• An RS-D claim additionally requires the Runtime Enforcement PDP contract.
• 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: The OAuth 2.0 Authorization Framework
• RFC 7009: OAuth 2.0 Token Revocation
• RFC 7523: JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants
• RFC 7662: OAuth 2.0 Token Introspection
• RFC 7800: Proof-of-Possession Key Semantics for JWTs (cnf)
• RFC 8417: Security Event Token (SET)
• RFC 8693: OAuth 2.0 Token Exchange
• RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
• RFC 8785: JSON Canonicalization Scheme (JCS)
• RFC 9068: JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
• RFC 9126: OAuth 2.0 Pushed Authorization Requests
• RFC 9396: OAuth 2.0 Rich Authorization Requests
• RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP)
• RFC 9470: OAuth 2.0 Step Up Authentication Challenge Protocol
• RFC 9728: OAuth 2.0 Protected Resource Metadata (PRM)
• draft-ietf-oauth-identity-chaining: OAuth Identity Chaining (chaining framework)
• draft-ietf-oauth-identity-assertion-authz-grant: ID-JAG (assertion profile for user-authenticated flows)
• draft-ietf-oauth-transaction-tokens: Transaction Tokens (intra-trust-domain call-chain context)
• draft-fletcher-transaction-token-chaining-profile: Transaction Token Chaining Profile (assertion profile for Txn-Token-rooted flows)
• AuthZEN Access Request: AuthZEN Access Request
• draft-mcguinness-oauth-actor-profile: Actor Profile
• draft-mcguinness-oauth-client-instance-assertion: Client Instance Assertion
• draft-mcguinness-oauth-deferred-code-processing: Deferred Code Processing
• draft-mcguinness-oauth-identity-assertion-trust-framework: Identity Assertion Trust Framework
• draft-mcguinness-oauth-domain-authorized-issuer-discovery: Domain-Authorized Issuer Discovery
• draft-mcguinness-oauth-actor-receipts: Actor Receipts
• draft-zehavi-oauth-rar-metadata: RAR Metadata
• draft-yakung-oauth-agent-attestation: ACAP (Agent Client Attestation Profile)
• OpenID CIBA Core 1.0
• OpenID Shared Signals Framework (SSF) 1.0
• OpenID CAEP 1.0