This document is a working item for iterating on the architecture before drafting one or more IETF Internet-Drafts. The current working name is draft-mcguinness-oauth-mission-bound-authorization.

This is a RFC: an end-to-end architecture proposal published to gather feedback before the work is split into standards-track core pieces, companion specs, or deployment profiles.

It is intentionally a superset architecture document. It describes the full model, even where different parts may eventually be standardized separately or left as implementation guidance.

The goal is to make the design legible enough for identity and OAuth practitioners to react to the whole system before the work is narrowed into concrete drafts. If the architecture holds up, the likely next step is to split it into a smaller core OAuth draft plus companion profiles.

If you want the shortest version of the argument, it is this:

• OAuth is good at point-in-time authorization.
• Agents need authority that survives across token lifetimes.
• That authority needs purpose, lifecycle, delegation bounds, and independent termination.
• Mission-Bound OAuth proposes a durable Mission object at the Authorization Server to provide that layer.

If you want the shortest version of what is new here, it is this:

• a Mission is a durable delegated-authority object at the AS, not just another token claim
• tokens derive from the Mission; they do not define it
• Mission lifecycle is independent of token lifetime
• Mission state can terminate execution because the business purpose ended, not only because a token expired
• Mission-Bound OAuth is designed to fit existing OAuth, policy, gateway, and FGA deployments rather than replace them

If you are skimming, read these sections first:

• Introduction for the problem and core claim
• Architecture Overview for the model in one pass
• Worked Example: Scheduling Assistant for the end-to-end flow
• Deployment Pattern Examples for how this fits gateways, RS policy, and FGA
• Practical Limits and Realistic Claim for where this architecture can fail
• Open Questions for what is genuinely unresolved

What this is not:

• not a claim that OAuth should become a workflow engine
• not a replacement for AuthZEN, FGA, MCP, or GNAP
• not a universal policy language
• not a promise of perfect real-time termination
• not a requirement that every resource server become Mission-aware on day one

Introduction

OAuth is good at issuing tokens that represent authorization at a moment in time for a client, audience, and scope. Agentic systems need something stronger and longer-lived than that, but also more bounded than standing credentials.

An agent may:

• interpret a user prompt
• plan a multi-step mission
• call multiple APIs over time
• delegate sub-tasks to other software components
• resume work after pauses or human approvals

Standard OAuth primitives do not directly model the delegated authority that makes those actions legitimate as a coherent whole. Access tokens are audience-bound and short-lived by design. Refresh tokens extend continuity, but they do not encode mission purpose, delegation boundaries, or lifecycle state in a way that an authorization server can govern as a first-class artifact.

The core design objective is therefore:

represent agent authority as an approved, bounded, persistent authorization context tied to mission purpose and lifecycle, rather than as raw credential possession.

This is closer to power-of-attorney than to passport-style authentication.

OAuth is increasingly being used in environments where software does more than make a single API call on behalf of a user. Agents plan, pause, resume, delegate, and cross service boundaries. That creates a gap between what existing OAuth tokens represent and what operators actually need to control.

What is missing is not another broad token. What is missing is a durable, governable authority object for a delegated mission:

• approved once
• constrained over time
• checked again at each derivation step
• revocable independently of token expiry
• understandable across audit, policy, and delegation boundaries

Mission-Bound OAuth is an attempt to define that object and show how OAuth can use it without abandoning its existing model. In the terminology of the Power of Attorney series, the Mission is the architecture and protocol evolution of what the series called an Execution Mandate.

The practical claim is intentionally narrow. This RFC is not arguing that OAuth should become a workflow engine, or that Mission-Bound OAuth solves all of agent security. The claim is that a durable Mission object at the AS would let existing OAuth deployments govern delegated machine authority more safely than token-only patterns do today.

Terminology and Roles

Key Terms

The design currently assumes the following logical roles:

Some deployments may collapse these roles. The protocol should not assume they are always distinct implementations.

 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
42
43

                     +----------+
                     |   User   |
                     +---+--+---+
                         |  |
              interprets |  | (may serve
              prompt     |  |  as Approver)
                         v  |
              +----------+--+   +----------+
              |Orchestration |  | Approver |
              |    Layer     |  +----+-----+
              +------+-------+       |
                     |               |
          proposal   |          approval /
          submission |          attenuation
                     |               |
                     +-------+-------+
                             |
                             v
                   +---------+---------+
                   | Authorization     |<------>[PDP]
                   |     Server        |
                   +---------+---------+
                             |
               OAuth auth + token exchange
                             |
                             v
                   +---------+---------+
                   |   Agent Client    |
                   +---------+---------+
                             |
                 mission-bound access token
                             |
                             v
                   +---------+---------+
                   |  Resource Server  |
                   +----+----------+---+
                        |          |
           cross-domain |    introspect (optional)
                        v          v
               +--------+--+  +---+-----------+
               |Resource    |  |Authorization  |
               |Auth Server |  |    Server     |
               +-----------+  +---------------+

Subject and Actor Model

IAM readers will reasonably ask “who is who?” because Mission-Bound OAuth spans multiple identity and authority roles that normal OAuth deployments often blur together.

At minimum, the model should distinguish:

• subject: the principal on whose behalf authority is being exercised
• client: the OAuth client or orchestration layer requesting tokens and Mission operations
• agent runtime: the software component performing planning or execution for the client
• active actor: the component currently using a derived token at a given hop
• approver: the principal or policy authority that can approve, attenuate, suspend, resume, or revoke a Mission

The clean mapping is:

• sub identifies the subject on whose behalf the Mission exists
• client_id identifies the registered client or orchestration layer
• act represents the active delegated actor chain for token-based delegation
• Mission audit events capture the approver or administrative actor that changed Mission state

This matters because approval authority, delegated execution, and audit attribution are different concerns. They should not collapse into a single identifier model.

Background and Related Work

This document does not appear in a vacuum. It builds on a line of argument developed in the three-part series You Don’t Give Agents Credentials. You Grant Them Power of Attorney:

• Agents Don’t Need Your Passport. They Need Your Authority frames the structural gap: identity, access control, and delegation can all work correctly while no layer asks whether a delegated mission should still be running at all.
• From Passports to Power of Attorney introduces the authority-governance model behind this work: purpose, scope, conditions, lifecycle, and delegation as a governed artifact rather than something implied by credentials.
• Governing the Stay, Not Just the Entry explains why revocation, continuous evaluation, and business-event termination have to be first-class if delegated machine authority is to remain governable over time.

The series used the term Execution Mandate for that governed artifact. This RFC uses Mission as the protocol-facing term, but the underlying idea is the same: delegated machine authority must be represented as a governed object, not inferred from token possession alone.

This architecture also sits alongside adjacent work in the identity and authorization ecosystem:

• RFC 9396: OAuth 2.0 Rich Authorization Requests for structured authorization input at token issuance time.
• RFC 8693: OAuth 2.0 Token Exchange for downstream token derivation and delegation checkpoints.
• RFC 9635: GNAP as the cleaner-sheet alternative to extending OAuth for richer delegated authorization semantics.
• OpenID Authorization API 1.0 as the current AuthZEN decision interface for PDP/PEP integration.
• OpenID Shared Signals Framework 1.0 and OpenID Continuous Access Evaluation Profile 1.0 for state change propagation and event-driven termination.
• Model Context Protocol for tool and context discovery above the authority layer.
• OAuth 2.0 Transaction Tokens for context propagation in trusted domains.
• NIST NCCoE Software and AI Agent Identity and Authorization as evidence that this problem space is active and recognized outside vendor marketing.

Mission-Bound OAuth is intended to complement, not replace, these efforts. The claim is narrower: existing OAuth and policy building blocks still leave a gap around durable delegated mission governance, and that gap becomes visible once agents operate beyond point-in-time authorization decisions.

The existing authorization landscape provides two models, each useful in its domain:

OAuth scopes represent flat permissions at a point in time. They are well-understood, widely deployed, and appropriate for single-request authorization. They have no lifecycle concept and no Mission identity.

Rich Authorization Requests (RAR, RFC 9396) extend scopes with structured permission objects. They allow richer description of what a token permits at a specific audience. They remain point-in-time: each token request is independent. RAR does not define a persistent authority object, so any deployment that wants one invents private, non-interoperable semantics to do so. Mission-Bound OAuth is standardizing what a well-designed agentic RAR deployment would build anyway, and making that persistent authority model interoperable across implementations.

Mission-Bound OAuth introduces a third model: durable, governed, lifecycle-aware authority for a Mission that outlives any individual token.

The critical properties that distinguish a Mission from the existing models:

• A Mission is created once, before token issuance, through an approval process.
• It persists as a first-class artifact at the Authorization Server across the entire Mission lifecycle.
• Tokens derive authority from the Mission; the Mission does not derive from tokens.
• The Mission can be suspended or terminated independently of whether any token is currently valid.
• Termination can be triggered by a business event, not only by a clock.
• Audit trails attach to the Mission, not to individual tokens, giving a complete record of delegated execution.

A token answers “is this request permitted right now?” A Mission answers “should this delegated mission be running at all?” These are different questions and the existing stack has no standard answer to the second.

The word “durable” is the load-bearing term. A refresh token is also durable in the sense that it persists, but it is a credential artifact, not a governed authority artifact. A Mission is the authoritative record of purpose, constraints, and lifecycle state that governs every token the mission will ever produce.

Architecture Overview

Mission-Bound OAuth introduces a new authorization object, the Mission, maintained by the AS.

A Mission is the authoritative record of:

• what mission purpose was approved
• what bounded authority region the mission is allowed to operate within
• what constraints, selectors, and predicates govern runtime decisions
• how long the authority lasts
• whether delegation is allowed
• what lifecycle state the mission is in

OAuth tokens do not replace the Mission. They derive authority from it and reference it using a projected Mission reference.

The AS remains the system of record for mission state and evaluates that state before issuing, refreshing, or exchanging tokens.

From Intent to Enforceable Authority

The most important architectural question is how an open-ended user request becomes something a system can actually enforce.

For open-world agents, the answer cannot be:

• interpret the prompt
• guess the exact future API calls
• whitelist them up front

That only works in tightly closed execution patterns. It does not work well when agents can discover tools dynamically, plan adaptively, encounter new resources at runtime, or operate across large enterprise systems.

The architecture therefore needs an intermediate pipeline:

1. intent input: prompt, plan, Model Context Protocol (MCP) tool context, and surrounding mission context
2. mission proposal: a candidate authority description for the task
3. constraint shaping: templates, policy, approval, attenuation, and business rules narrow the proposal
4. compiled authority model: the Mission becomes a machine-evaluable authority region
5. runtime decision inputs: issuance, exchange, gateway, and RS checks evaluate requests against that region

This is the real architectural job of a Mission. It is not just a label attached to a token. It is the compilation boundary between ambiguous intent and enforceable delegated authority.

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

prompt / plan / MCP context
  |
  v
Mission Proposal
  |
  v
templates + policy + approval + attenuation
  |
  v
Approved Mission
  |
  v
Mission Authority Model
  |
  +-> token issuance / refresh
  +-> token exchange
  +-> gateway / RS checks
  +-> audit / eventing

That boundary is especially important for open-world agents:

• they may not know all resources in advance
• they may discover tools at runtime
• they may need to adapt plans based on what they find
• but they still need bounded authority

Mission-Bound OAuth provides that bounded authority model without requiring every future action to be enumerated up front.

Authority Compilation Boundary

If Missions are the bridge from open-world intent to enforceable authority, then the architecture needs to say where that bridge is built.

There are at least three plausible models:

• AS-owned compilation: the Authorization Server itself compiles proposals, templates, policy bindings, and approval outputs into the authoritative Mission representation
• mission-management service compilation: a separate control-plane service compiles the Mission and the AS consumes the result as authoritative input for OAuth processing
• hybrid compilation: a management service produces an intermediate form and the AS performs final normalization or binding at approval and issuance time

The current bias is that the AS must remain authoritative for the Mission representation that governs token issuance, refresh, exchange, and lifecycle, even if upstream authoring and compilation are delegated to another component.

That gives the architecture a clean trust boundary:

• authoring may happen elsewhere
• proposal shaping may happen elsewhere
• policy evaluation may be externalized
• but the AS remains authoritative for the Mission artifact that OAuth relies on

Mission management service trust: when a separate mission-management service compiles Missions and submits them to the AS, the AS MUST NOT accept the proposed authority model as-is without independent validation. Compromise of the mission-management service must not be equivalent to compromise of Mission governance.

The required trust model:

• the mission-management service signs proposed authority-model artifacts using a key registered with the AS at service registration time
• the AS verifies the signature before accepting any proposed Mission Authority Model artifact
• the AS re-derives and re-validates all policy-bound predicates (lifecycle bounds, delegation limits, purpose class authorization) against its own registered policy at the time of acceptance, regardless of what the submitted artifact asserts
• the AS is the final authority for the Mission Authority Model stored at the AS; a submitted artifact is a proposal input, not an authoritative record

This means a compromised mission-management service can submit invalid proposals, which the AS will reject, but cannot unilaterally create an authorized Mission Authority Model.

Mission Artifact Stack

The architecture is easier to reason about if the different Mission-shaped artifacts are named explicitly.

The relationship between these artifacts is:

1
2
3
4

Mission Proposal
-> Approved Mission
-> Mission Authority Model
-> projected artifacts for tokens, introspection, assertions, and audit

Another view of the same stack is:

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

authoring
  Mission Proposal
      |
      v
governance
  Approved Mission
      |
      v
enforcement
  Mission Authority Model
      |
      +-> token claims
      +-> introspection
      +-> assertions
      +-> audit events

The AS should remain authoritative for the Approved Mission and the Mission Authority Model forms that govern OAuth processing, even if proposal authoring and compilation are delegated to adjacent services.

Concrete Compiled Authority Example

To make the compilation concept concrete, consider how the scheduling example compiles from proposal inputs into a machine-evaluable authority region.

Authoring-time inputs:

• intent envelope: schedule_meeting for participant Dana, next week
• template: schedule_meeting with default constraints
• approval attenuation: limit to EU region, no executive calendars, max 15 minutes duration

The AS-internal Mission Authority Model record (uses mission_id; enforcement points receive the signed JWS artifact below, which uses mission_ref in place of mission_id):

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

{
  "mission_id": "m_92f341aa",
  "purpose": "urn:example.com:mission:schedule-meeting",
  "authority_model": {
    "allowed_resources": [
      { "type": "calendar.event", "selector": "user-manageable-calendars" },
      { "type": "crm.account_note", "selector": "accounts-owned-by-requesting-team" }
    ],
    "allowed_operations": [
      { "group": "calendar.schedule" },
      { "group": "crm.record_activity" }
    ],
    "constraints": [
      { "type": "jurisdiction", "value": "EU" },
      { "type": "business_process", "value": "meeting-coordination" },
      { "type": "exclusion", "resource_attribute": "calendar.is_executive", "value": true }
    ],
    "delegation": { "allowed": true, "max_depth": 0 },
    "lifecycle": { "expires_at": 1773069300, "state": "active" }
  }
}

The signed JWS artifact distributed to enforcement points (PDP evaluation inputs, gateways, mission-aware RSes). mission_id is replaced by mission_ref; expires_at uses NumericDate per JWT conventions (RFC 7519 Section 2); version enables cache invalidation:

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

{
  "mission_ref": "mr_7M9Qx2",
  "version": 1,
  "purpose": "urn:example.com:mission:schedule-meeting",
  "authority_model": {
    "allowed_resources": [
      { "type": "calendar.event", "selector": "user-manageable-calendars" },
      { "type": "crm.account_note", "selector": "accounts-owned-by-requesting-team" }
    ],
    "allowed_operations": [
      { "group": "calendar.schedule" },
      { "group": "crm.record_activity" }
    ],
    "constraints": [
      { "type": "jurisdiction", "value": "EU" },
      { "type": "business_process", "value": "meeting-coordination" },
      { "type": "exclusion", "resource_attribute": "calendar.is_executive", "value": true }
    ],
    "delegation": { "allowed": true, "max_depth": 0 },
    "lifecycle": { "expires_at": 1773069300, "state": "active" }
  }
}

This authority-model form is what the AS evaluates at token exchange time, what a gateway queries at request time, and what an AuthZEN-compatible policy decision point (PDP) uses to answer “is this action on this resource permitted under this mission right now?” The agent does not need to re-enumerate its intended actions; the authority model is the evaluable boundary for whatever the agent discovers at runtime. The scheduling scenario’s mission_id (m_92f341aa) maps to protocol-facing mission_ref (mr_7M9Qx2); this separation illustrates the AS-internal/protocol-boundary distinction normatively defined in the Mission Identifier and Mission Reference section.

Architecture Layers

This architecture is intentionally broader than a single OAuth extension. It is easier to reason about if split into layers.

The point of this document is to show how the whole system works end to end. It is not a claim that every layer belongs in one standards-track document.

Candidate Spec Decomposition

This architecture should not be treated as a single protocol surface. The likely standards decomposition is:

• a core OAuth extension for Mission reference, lifecycle-aware issuance, and exchange
• a mission management specification or profile for proposals, approval, attenuation, and retrieval
• a cross-domain profile for mission assertions and trust between authorization domains
• deployment guidance for gateways, RS behavior, policy integration, and eventing

This split matters because the end-to-end architecture is broader than what should probably go into a single OAuth specification.

Design Principle

Agents may interpret prompts, but they do not grant authority.

Authority exists only after a Mission has been proposed, reviewed, and approved. This separation is central to the architecture:

• prompt interpretation is probabilistic
• authority grant is governed
• mission approval is the trust boundary between the two

End-to-End Flow

The intended flow is:

1
2
3
4
5
6
7
8

prompt
-> intent interpretation
-> mission proposal
-> approval / attenuation
-> mission created
-> OAuth authorization referencing mission_ref
-> access token issuance
-> token exchange for downstream APIs

Viewed by trust boundary, the same path looks like:

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

[agent / client]
  |
  | prompt, plan, MCP context
  v
[mission management]
  |
  | proposal, approval, attenuation
  v
[authorization server]
  |
  | mission-bound token
  | mission-aware token exchange
  v
[gateway / resource servers]
  |
  | resource operations, audit, policy checks
  v
[mission lifecycle state]
  active -> suspended / completed / revoked / expired

This makes the Mission the stable authority artifact across otherwise separate OAuth transactions.

An end-to-end deployment may therefore involve three linked phases:

1. Interpretation phase: prompts or plans become structured candidate authority
2. Governance phase: candidate authority is approved, attenuated, or denied
3. OAuth execution phase: approved Mission state is referenced by tokens and enforced over time

Relationship and External Data Sources

The architecture now relies on relationship predicates such as:

• accounts owned by the requesting team
• participants connected to the approved Mission
• calendars the subject is allowed to manage
• records in a specific business process stage

Those predicates depend on external systems of record. Mission evaluation may therefore depend on one or more relationship sources:

• directory or identity graph
• FGA or graph authorization system
• CRM ownership model
• business-process state system
• HR hierarchy
• tenant or organization membership directory

Mission-Bound OAuth does not replace those systems. It carries the governing Mission context that tells the PDP which relationship predicates matter for the current Mission.

Mission Data Model

Mission Object

The current model treats a Mission as a persistent authorization context. For interoperability, the eventual spec work should distinguish a minimal core from deployment-specific extensions.

The minimal interoperable core is roughly:

• mission_id
• mission_state
• mission_subject (required sub-fields: sub, iss; strongly recommended: sub_profile)
• mission_client
• created_at
• mission_exp
• delegation

Deployment-specific extensions may include:

• purpose
• structured constraints
• compiled authority graph or selector set
• enterprise approval metadata
• mission-specific attributes
• policy evaluation hints

A sketch of the object shape:

 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
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

{
  "mission_id": "m_7M9Qx2",
  "mission_state": "active",
  "mission_subject": {
    "sub": "user-123",
    "iss": "https://idp.example.com",
    "sub_profile": "user"
  },
  "mission_client": {
    "client_id": "assistant-agent"
  },
  "mission_exp": 1773072000,
  "delegation": {
    "allowed": true,
    "max_depth": 1,
    "current_depth": 0
  },
  "purpose": {
    "class": "urn:example.com:mission:schedule-meeting",
    "display": "Schedule a Meeting"
  },
  "authority_model": {
    "operation_groups": [
      "calendar.schedule",
      "crm.record_activity"
    ],
    "selectors": [
      {
        "resource_type": "calendar.event",
        "selector": "user-manageable-calendars"
      },
      {
        "resource_type": "crm.account_note",
        "selector": "accounts-owned-by-requesting-team"
      }
    ],
    "predicates": [
      {
        "type": "jurisdiction",
        "value": "EU"
      },
      {
        "type": "business_process",
        "value": "meeting-followup"
      },
      {
        "type": "exclusion",
        "resource_attribute": "calendar.is_executive",
        "value": true
      }
    ]
  },
  "constraints": {
    "max_duration": 900,
    "rate_limit": {
      "count": 10,
      "window": 60
    },
    "checkpoint_policy": "hybrid"
  },
  "created_at": "2026-03-13T09:00:00Z"
}

This example is AS-internal. mission_exp uses NumericDate format (integer seconds since Unix epoch) consistent with the JWT exp claim convention defined in RFC 7519 Section 4.1.4. created_at remains an internal timestamp field here. Protocol projections should use the explicit field formats defined for the relevant projection rather than assuming this internal object shape is emitted directly.

The AS owns this record. Tokens and exchanges are derivatives of it, not substitutes for it.

The proposal and the Mission are separate artifacts. A Mission Proposal is the requested authority object submitted for review. Approval creates an Approved Mission artifact with its own mission_id, lifecycle, authority model, and audit trail. This matters for the API surface and for governance:

• GET /mission-proposals/{proposal_id} returns the requested authority object and its review state
• GET /missions/{mission_ref} returns the approved authority artifact that governs OAuth processing
• denial and attenuation history belong to the proposal record even when no Mission is ever created

At minimum, mission_id should be opaque and unguessable. If exposed outside the AS, it should be treated as a reference handle, not as a container for semantics.

Mission Identifier and Mission Reference

The architecture is cleaner if it distinguishes the AS-internal Mission identifier from the protocol-facing Mission reference.

• mission_id: the authoritative identifier of the Mission record inside the issuing AS
• mission_ref: the projected reference handle used at protocol boundaries such as tokens, token exchange, introspection, and cross-domain assertions

In the simplest deployment, mission_ref may be a direct opaque projection derived from mission_id. In privacy-sensitive or cross-domain deployments, it often should be pairwise or otherwise distinct per boundary.

That distinction separates three concerns that would otherwise get overloaded into one value:

• record identity at the AS
• protocol selection during token exchange and introspection
• correlation visibility at resource servers or other external parties

The practical model is:

• the AS stores and governs the Mission by mission_id
• clients and downstream systems work with mission_ref
• the AS maps mission_ref back to the internal mission_id

This is the recommended direction for the eventual specs. The core protocol should standardize the existence of a projected Mission reference. Whether the claim name remains mission_id, becomes mission_ref, or is profile-dependent can still be decided later.

This distinction is normative. The mission_id MUST NOT appear in tokens, authorization requests, introspection requests or responses, cross-domain assertions, or error responses. It MUST NOT appear in any artifact distributed outside the AS boundary, including the signed Mission Authority Model JWS artifact that enforcement points receive (which MUST use mission_ref in place of mission_id). All protocol-facing and enforcement-point-facing uses MUST use mission_ref. The only contexts where mission_id may appear are: (1) AS-internal data stores and records, and (2) examples in this document that explicitly label the content as AS-internal representation.

For open-world deployments, the important part of the Mission may not be a static list of resources or operations. It may be the compiled set of selectors, predicates, relationship conditions, and policy bindings that define the bounded authority region for runtime decisions.

A Mission is not just a record of approved intent; it is the authoritative Mission Authority Model for a delegated mission.

Mission Authority Model as a Stored, Versioned Artifact

The Mission Authority Model is a stored, content-addressed artifact maintained by the AS. It is not recomputed on demand at each evaluation point. This is a deliberate architectural decision driven by audit and enforcement requirements.

The audit trail depends on replayability: the AS must be able to reconstruct exactly what authority governed any given token issuance or exchange decision. That requires a stored, versioned representation of the compiled authority at the moment of issuance. A computed-on-demand model cannot provide that guarantee because the inputs to compilation (templates, policy, registered predicates) may change between the time of issuance and the time of audit replay.

The AS always stores the Mission Authority Model for audit and issuance purposes. Distribution of that full model beyond the AS is optional and should be treated as a higher-assurance profile rather than the default deployment expectation.

In the default adoption path:

• the AS uses the Mission Authority Model internally for issuance, refresh, exchange, and lifecycle checks
• gateways and RSes use projected claims or the Mission introspection profile
• only designated high-trust enforcement points retrieve the full signed Mission Authority Model

High-assurance deployments may distribute the Mission Authority Model to trusted enforcement points rather than computing it locally:

• the AS issues the Mission Authority Model as a signed artifact alongside the Approved Mission
• enforcement points (gateways, PDPs, resource servers that do full Mission evaluation) retrieve or receive the Mission Authority Model and validate its signature
• cache staleness bounds for the Mission Authority Model at enforcement points must be policy-defined; enforcement points must re-fetch when staleness bounds are exceeded or when a revision event arrives via SSF/CAEP

When a Mission is amended or re-compiled (for example, when the AS updates a predicate in response to a business-graph change), the AS increments a version counter and issues a new signed Mission Authority Model. Enforcement points that cached a prior version must treat a version mismatch as a cache miss and re-fetch. This is the mechanism that keeps distributed enforcement consistent with the AS’s authoritative record.

Cache coordination between Mission Authority Model and introspection: enforcement points maintain two separate caches — the signed Mission Authority Model artifact and the RFC 7662 introspection response. These must be treated as coherent: a Mission Authority Model version mismatch (detected by comparing the version field in a newly fetched artifact against the cached version) MUST be treated as equivalent to an introspection cache miss, triggering a fresh introspection call before any further enforcement decision. The recommended ordering on version mismatch: (1) re-fetch Mission Authority Model, (2) re-introspect to confirm active: true and obtain current mission_state, (3) enforce against the updated artifact. An enforcement point MUST NOT apply a new Mission Authority Model version while holding a stale introspection active: true response from before the version increment.

The Mission Authority Model is an artifact the AS signs and enforcement points obtain, not a function enforcement points compute locally.

Mission Authority Model retrieval endpoint: in deployments that use distributed authority-model enforcement, enforcement points that need to obtain or refresh the Mission Authority Model do so via a dedicated endpoint at the AS. The endpoint pattern is:

1
2

GET /missions/{mission_ref}/authority-model
Authorization: Bearer <enforcement_credential>

The AS returns the signed JWS artifact. The enforcement_credential is a client credentials access token with scope mission:authority-model:read, issued to the enforcement point’s registered client identity. Enforcement points cache the artifact using standard HTTP caching semantics; the AS MUST include appropriate Cache-Control headers. The AS also pushes revision notifications via SSF when the Mission Authority Model version increments, allowing enforcement points to proactively re-fetch. An enforcement point that cannot reach the retrieval endpoint MUST fail closed: it MUST treat the Mission as if it were revoked until it can retrieve a fresh artifact.

Signing format: the Mission Authority Model is signed as a JWS (RFC 7515) JSON object using the AS’s token signing keys. The signing keys are discoverable via AS metadata (RFC 8414) under the jwks_uri field. The signed artifact MUST include the following JOSE header claims:

• typ: "mission+json" (a new media type candidate for registration)
• alg: the same algorithm family used for the AS’s access token signing (e.g., RS256, ES256)
• kid: key identifier for signature validation

The payload is the Mission Authority Model JSON object including mission_ref, version, authority_model, lifecycle, and delegation fields. Trusted internal enforcement points MAY maintain a local mapping from mission_ref to the AS-internal mission_id, but the distributed artifact itself uses only mission_ref at its protocol boundary. Enforcement points validate the JWS signature against the AS’s published jwks_uri before consuming any Mission Authority Model data. A Mission Authority Model with an invalid or unverifiable signature MUST be rejected and treated as if the Mission were revoked.

Authority Model Distribution

The architecture needs a clear trust boundary for who is allowed to receive the full Mission Authority Model versus a filtered projection.

The recommended distribution model is:

The default should be conservative:

• full Mission Authority Model distribution is for trusted enforcement points, not every resource server
• filtered introspection is the default RS-facing mechanism
• projected token claims are the minimum distribution mechanism

This is the default trust pattern for the architecture: trusted enforcement points may receive the full Mission Authority Model; resource servers default to filtered introspection or token-level projections.

This keeps the architecture aligned with its own privacy model. A deployment that distributes the full Mission Authority Model broadly should be treated as a high-assurance or tightly trusted profile, not as the default interoperability expectation.

Stable vs Dynamic Evaluation

One boundary worth making explicit is which parts of Mission evaluation are stable versus dynamic.

The reason this distinction matters is that not every denial means the Mission changed. A request may be denied because the runtime facts no longer satisfy the predicates of an otherwise unchanged Mission Authority Model.

Resource and Action Model

Simple string scopes are too weak for the authority model this architecture requires. The current direction is to use typed resources and actions.

Example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

{
  "resource": {
    "type": "calendar",
    "id": "primary"
  },
  "action": {
    "name": "create_event",
    "group": "write"
  }
}

This helps with:

• container-scoped operations
• action grouping
• object-level permissions
• extensibility over time
• compatibility with structured policy systems

This also aligns better with modern policy engines than raw space-delimited scopes.

The likely protocol consequence is that a core spec should standardize only enough structure to make policy evaluation interoperable, while leaving detailed resource taxonomies to deployment profiles.

Scaling the Resource and Operation Model

This becomes much more important in real systems than it first appears. Real deployments do not have one API and one action. They have:

• containers and objects
• object hierarchies
• bulk operations
• derived operations
• tenant boundaries
• environment-specific identifiers
• operation families that map poorly to raw OAuth scopes

A usable architecture therefore needs a model that can scale beyond flat strings such as calendar.write.

The likely shape is:

• resource type: what kind of thing is being acted on
• resource instance or selector: which thing or set of things is in scope
• action name: the concrete operation
• action group: a stable grouping used by policy and approval UX
• attributes: optional properties used for finer evaluation

A sketch:

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

{
  "resource": {
    "type": "calendar.event",
    "container": {
      "type": "calendar",
      "id": "primary"
    },
    "selector": {
      "owner": "user-123",
      "time_range": "2026-03-13/2026-03-20"
    }
  },
  "action": {
    "name": "create",
    "group": "write"
  }
}

The point is not to standardize every domain taxonomy. The point is to give Mission-Bound OAuth and related policy systems enough structure to express container-scoped authority, object-level authority, grouped approvals, and policy evaluation on typed entities.

Resource Selectors as an Abstraction

The architecture likely needs the equivalent of XPath, CSS selectors, or jQuery selectors for resources, but not as a single universal syntax.

What it needs is a resource selector abstraction: a standard place in the Mission model to describe “which resources or resource sets are in scope” without forcing every deployment into one selector language.

In practice, selectors may need to express things like:

• calendars the subject can manage
• CRM accounts owned by the current team
• documents in a folder but not under legal hold
• records in a given jurisdiction
• tickets connected to a specific business process stage

Those are not all the same kind of selection. Some are:

• attribute filters
• relationship predicates
• container-scoped selectors
• policy references
• graph traversals

The architecture should therefore treat selectors as an abstraction with multiple possible forms, for example:

1
2
3
4
5
6
7

{
  "resource_type": "crm.account_note",
  "selector": {
    "kind": "relationship",
    "relation": "accounts-owned-by-requesting-team"
  }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

{
  "resource_type": "calendar.event",
  "selector": {
    "kind": "attribute_filter",
    "where": {
      "calendar.owner": "user-123",
      "calendar.region": "EU"
    }
  }
}

1
2
3
4
5
6
7

{
  "resource_type": "document",
  "selector": {
    "kind": "policy_ref",
    "ref": "policy://missions/docs/editable-by-subject-team"
  }
}

This keeps the model flexible enough for AuthZEN, Cedar, Rego, FGA, and deployment-specific policy systems without prematurely standardizing a single resource query language.

The important standardization boundary is not the selector syntax. It is the existence of a selector slot in the Mission model and the expectation that Mission Authority Models may carry resource selectors, not just literal resource IDs or flat allowlists.

Key Abstraction Slots

Resource selectors are not the only place where the architecture needs a stable slot without prematurely standardizing a full language.

Several parts of the Mission model have the same shape:

• the architecture needs a place to carry meaning
• deployments will want different underlying syntaxes or policy engines
• the first spec should standardize the slot and its role before trying to standardize every semantic language

The main abstraction slots are:

This is an important discipline for the eventual specs. If Mission-Bound OAuth tries to standardize all of these semantic languages in one step, it will become too broad to be practical. If it names none of them, deployments will fill the gaps with incompatible private conventions.

The practical middle ground is:

• standardize the slots and processing checkpoints first
• standardize only the smallest common structures needed for interoperability
• leave richer selector, predicate, and explanation languages to profiles or adjacent specifications

Mission Lifecycle

Proposal Lifecycle vs Mission Lifecycle

The Mission Proposal and the Mission are separate artifacts with separate lifecycles. The Mission Proposal lifecycle governs what happens before an authorized Mission exists:

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

         +---------+
         | pending |<-- proposal submitted
         +----+----+
              |
    +---------+---------+
    |                   |
  approve           deny / timeout
    |                   |
    v                   v
+---------+         +----------+   +----------+
| Mission |         | denied   |   | expired  |
| created |         +----------+   +----------+
+---------+         (terminal)     (terminal)

denied is the terminal state when a proposal is explicitly rejected by the approver. expired is the terminal state when the proposal approval window elapses without a decision. Both are terminal on the proposal object. Neither creates a Mission. Denial and timeout history are retained on the proposal record for audit even when no Mission is ever created.

The Mission lifecycle begins at activation and is independent of the proposal lifecycle:

Mission Lifecycle

The current lifecycle model is:

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

                                 task done /
                                 client signals /
                                 business event
                       +--------+     |
           +---------->| active |-----+-------> completed
           |           +---+----+
        resume             |
           |    suspend / anomaly / precondition change
           |               |
           |               v
           |         +-----------+
           +---------|  suspended|
                     +-----+-----+
                           |
                    revoke / expire
                           |
              +------------+------------+
              |                         |
              v                         v
          +---------+             +---------+
          | revoked |             | expired |
          +---------+             +---------+

Missions are created in active state when a proposal is approved. For policy-auto-approved missions, activation is immediate. There is no Mission-level pending state; pending is a proposal lifecycle concept.

Valid terminal states are completed, revoked, and expired. suspended is not terminal: it requires an explicit resumption event to return to active, or a revocation or expiry event to terminate.

In the architecture, lifecycle enforcement applies before:

• authorization code issuance
• access token issuance
• refresh token use
• token exchange
• delegation events

The important property is that mission authority can be suspended or terminated independently of token possession.

Terminal state invariant: The states completed, revoked, and expired are terminal. An AS MUST NOT accept any lifecycle transition request targeting a Mission in a terminal state. A completed or revoked Mission cannot be resumed, re-activated, or amended.

completed vs revoked semantics: both states block all further token issuance, refresh, and exchange. The behavioral difference is in the error code returned and in audit interpretation. mission_completed is returned when the Mission ended normally (purpose achieved or business event signaled completion). mission_revoked is returned when the Mission was terminated by an authorized party before purpose was achieved or due to policy enforcement. Clients receiving mission_completed know the mission succeeded; clients receiving mission_revoked know it was externally terminated. Both require a new Mission for any further execution.

Lifecycle Ownership

Mission lifecycle transitions are IAM governance actions and should not be left implicit.

The transition model should distinguish who is allowed to perform which action:

• proposal submitter / client: may request creation and may signal completion when permitted by policy
• subject: may approve, deny, or revoke Missions that are acting on their behalf when policy allows
• administrator: may approve, attenuate, suspend, resume, revoke, or terminate Missions within administrative scope
• policy engine: may auto-approve, suspend, or revoke according to registered rules
• business event processor: may transition a Mission to completed or revoked when declared terminal conditions are met

At a minimum, the architecture should assume:

• creation authority does not imply approval authority
• execution authority does not imply expansion authority
• suspension and revocation are privileged lifecycle actions
• business-event termination is authorized only when the Mission declared that event source as authoritative

Suspended state deserves explicit treatment. Suspension is not revocation. It is a temporary hold on execution, typically triggered when a human review is required mid-mission, an anomaly is detected, or a precondition the mission depended on changes. When a mission is suspended:

• token exchange is denied until the mission returns to active
• in-flight requests that have already received tokens run to their token expiry unless active invalidation is applied
• the agent should receive a structured error from the exchange endpoint indicating the suspension, not a generic rejection
• resumption is authorized by the same class of principals that can approve the original Mission: the subject (for user-delegated Missions), an administrator within scope, or a policy engine that declared the suspension condition resolved
• the resumption API follows the same endpoint pattern as approval: POST /mission-proposals/{proposal_id}/approval for pending Missions maps to a POST /missions/{mission_ref}/resume for suspended Missions, requiring the same authentication and authorization as the original approval action
• the AS re-evaluates the Compiled Mission’s validity at resumption time; if conditions have materially changed during suspension (for example, a key policy predicate is no longer satisfiable), the AS MAY decline resumption and transition to revoked instead
• the AS MUST emit a mission.resumed audit event on successful resumption
• Maximum suspension duration: a suspended Mission MUST NOT remain suspended indefinitely. The AS MUST enforce a maximum suspension window that is either: (a) declared in the Mission Authority Model at approval time (max_suspension_seconds), or (b) a deployment-default suspension limit defined in AS policy. When the maximum suspension window elapses without a resumption event, the AS MUST automatically transition the Mission to revoked and MUST emit a mission.revoked audit event with reason suspension_timeout. Deployments MUST configure an explicit maximum suspension window. An unbounded suspension window is not permitted, as it produces orphaned authority objects with indeterminate audit trails.

Suspension is the primary mechanism for human-in-the-loop intervention after execution has started. Its behavior, error codes, and resumption flow should be normatively defined in the core spec rather than left to implementation.

Business event termination is the mechanism that closes the gap the series identified. The CFO scenario (agent still pulling financials at 2:05 PM, five minutes after the board approved the presentation) fails because business completion events do not flow into the authority layer. Mission-Bound OAuth addresses this by making business events first-class inputs to Mission lifecycle transitions.

A Mission may define terminal conditions tied to business events: a procurement program is cancelled, a renewal conversation closes, a task is marked complete in a ticketing system. When those events fire, the Mission transitions to completed or revoked regardless of how much time remains on the clock. The mechanism for delivering those events is SSF/CAEP, described in the operational model section.

This is the architecture’s continuous authority evaluation loop: authority is re-evaluated not only at issuance and exchange time, but also when external events change whether the Mission should continue at all. The point is not only to stop future token issuance, but to give enforcement points enough signal to halt execution that is no longer authorized to continue.

Refresh token and in-flight token behavior must be addressed explicitly. Refresh tokens issued under a Mission are derivatives of that Mission, not independent credentials. The AS MUST record the mission_id associated with any refresh token at the time of issuance. This association is an AS-internal record and MUST NOT rely on the client to supply it at refresh time. When a Mission transitions to revoked, suspended, or any terminal state, the AS MUST immediately invalidate all refresh tokens associated with that mission_id using RFC 7009 token revocation semantics. This applies regardless of the refresh token’s remaining lifetime. Allowing a client to exchange a Mission-linked refresh token for a new access token after Mission revocation defeats the lifecycle guarantee the architecture is designed to provide.

For already-issued short-lived access tokens still in the client’s possession when a Mission terminates, the architecture cannot retroactively invalidate bearer tokens without active revocation infrastructure. The recommended approach is twofold: keep access token lifetimes short to minimize the exposure window, and emit a CAEP termination event to enforcement point subscribers who can block the token at a gateway or policy enforcement layer. Deployments that require immediate invalidation for all in-flight tokens should use DPoP or mTLS so a stolen or post-revocation token cannot be used without the bound key.

Mission lifecycle error codes must be normatively defined in the core spec. When token exchange or refresh fails due to Mission state, the AS should return a structured error that allows the agent to take a meaningful action rather than treating all rejections identically.

These values appear in the error parameter of the token error response per RFC 6749 Section 5.2, with a mission_ref field in the error response body echoing back the projected Mission reference the client passed. The error response uses mission_ref, not the AS-internal mission_id, because the client has no visibility into the internal identifier. The distinction between mission_suspended (temporary, agent waits) and mission_revoked (permanent, agent stops) is operationally critical and must not be collapsed into a single error code.

Structured error detail for mission_authority_exceeded: this error code alone is insufficient for client recovery because the agent cannot determine which constraint check failed without additional information. When returning mission_authority_exceeded, the AS SHOULD include a mission_error_detail object in the error response body:

1
2
3
4
5
6
7
8

{
  "error": "mission_authority_exceeded",
  "mission_ref": "mr_7M9Qx2",
  "mission_error_detail": {
    "constraint_violated": "resource_type",
    "detail": "resource type 'finance.report' is not in the compiled authority region"
  }
}

The constraint_violated field uses one of the following machine-readable values:

• resource_type: the requested resource type is outside the compiled authority
• operation_group: the requested operation is outside the compiled authority
• relationship_predicate: a relationship constraint failed (e.g., the account is not owned by the requesting team)
• compliance_constraint: a compliance or jurisdiction constraint failed
• lifecycle_constraint: a lifecycle-based authority condition in the compiled authority region failed (e.g., the business process stage is not in the approved set, or a time-window constraint in the compiled authority has elapsed). This value is ONLY used within mission_error_detail for mission_authority_exceeded responses. It does not overlap with the Mission lifecycle state error codes (mission_suspended, mission_revoked, mission_expired) which are returned as top-level error values, not as constraint_violated values.

The detail field is a human-readable diagnostic string intended for logging, administrative display, and debugging. It MUST NOT be machine-parsed; its format is not normative and may change between AS versions. Clients MUST NOT implement logic that branches on the content of the detail field. The AS SHOULD provide the detail string in the language indicated by the request’s Accept-Language header when that header is present. Only constraint_violated is the machine-readable discrimination signal; detail is explanatory context for human operators.

These values allow the agent to determine whether to abort, request a Mission expansion, or attempt a different resource.

Revocation Semantics Across Derivatives

Mission revocation has to be stronger than “stop issuing new tokens.”

Three derivative classes matter operationally:

• refreshable credentials: refresh tokens and equivalent long-lived token derivation handles
• new exchanges: token exchange requests for new audiences or delegation hops
• already-issued short-lived access tokens: existing audience-bound tokens still in circulation

The expected behavior is:

• Mission revocation or suspension immediately blocks refresh and exchange
• associated refresh tokens are revoked or made unusable
• already-issued short-lived access tokens remain usable only until expiry unless active invalidation infrastructure blocks them earlier
• high-assurance deployments use sender-constraining plus gateway or event-driven invalidation to reduce the post-revocation exposure window

This makes the lifecycle story operationally honest: Mission governance is authoritative, but immediate stop across all already-issued tokens still depends on the enforcement profile.

Mission amendment and narrowing are distinct from expansion and require an explicit position. The architecture currently defines expansion (adding within existing bounds) as a first-class operation via expansion proposals. The inverse, narrowing an active Mission’s authority region, shortening its expiry, or reducing delegation depth, is not yet defined. The two candidate models are: (1) a formal Mission amendment endpoint where authorized principals can tighten constraints on an active Mission without revocation; (2) revocation and re-issuance as the only path for any structural change. The revocation + re-issuance model avoids consistency problems between the AS’s Mission record and any cached compiled authority at enforcement points. The amendment model is operationally more convenient for long-running Missions. This is an open design question for feedback.

OIDC session lifecycle and Mission lifecycle: for user-delegated Missions, when a user’s OIDC session is revoked (CAEP session_revoked event, logout, or device credential revocation), active Missions for that user should be affected. The natural default is suspension: all active user-delegated Missions for the revoked session are suspended, giving the orchestration layer an opportunity to cleanly unwind in-flight execution before the Missions are terminated. Deployments with stricter requirements may choose immediate revocation. Regardless, the session-to-Mission propagation behavior should be defined explicitly per deployment profile rather than left to AS-specific behavior.

Concurrent Missions

The architecture assumes concurrent active Missions are permitted. A client may hold multiple active Missions for the same user simultaneously, each representing a distinct delegated workflow running in parallel.

Concurrent Missions reflect how real agentic deployments work: an assistant agent may be executing a “schedule meeting” workflow while simultaneously running a “prepare expense report” workflow for the same user. Requiring the first to complete before the second can be authorized would unnecessarily serialize independent workflows and force agents to queue tasks rather than interleave them.

The security goal is to avoid implicit Mission selection while also reducing how much fragile bookkeeping the client must do.

The preferred runtime model is:

• each primary mission-bound orchestration token is bound to exactly one mission_ref
• the orchestration layer keeps one in-flight mission-bound token per active Mission
• token exchange requests either echo that mission_ref explicitly or omit it when the subject token is already uniquely bound to one Mission

The AS does not infer Mission context from the requested resource. It infers only from the subject token when that token is already uniquely bound to one Mission. If the client supplies an explicit mission_ref, the AS MUST compare it to the subject token’s bound Mission reference and reject the request on mismatch. If the subject token does not uniquely identify one Mission and the request omits mission_ref, the AS returns mission_ref_required.

This is the safer adoption model:

• the client does not have to maintain a separate out-of-band Mission lookup table for every exchange
• the AS remains authoritative for Mission binding
• accidental Mission-context swaps become detectable server-side rather than silently becoming application bugs

A request that references the wrong Mission for a given resource is rejected with mission_authority_exceeded or invalid_grant, depending on whether the failure is an authority-envelope violation or a Mission-binding mismatch.

Mission Audit Trail

Every Mission state transition should produce a signed audit event as a first-class artifact:

• mission.created
• mission.activated
• mission.delegated (with delegation target and depth)
• mission.suspended (with reason)
• mission.resumed
• mission.expanded (with prior and updated authority region)
• mission.completed
• mission.revoked (with revoking principal and reason)
• mission.expired

This event log is a compliance artifact that is independent of access logs, token rotation cycles, and AS internal state. It survives token rotation cycles that would otherwise erase execution history. Audit events should be signed by the AS and should include both mission_id (for AS-internal correlation) and mission_ref (for cross-boundary audit correlation), the transition timestamp, the triggering principal, and the triggering event (clock, business event, user action, or policy signal). External auditors and cross-domain audit systems cannot resolve the AS-internal mission_id; the mission_ref is the portable correlation handle that links audit records across the AS, resource servers, gateways, and downstream domains. Positioning the audit trail as a produced artifact, not just a logged side effect, is what makes delegated execution attributable and reviewable.

OAuth Protocol Integration

Worked Example: Scheduling Assistant

To make the architecture less abstract, consider a scheduling assistant that can use Calendar, Email, and CRM tools.

The user says:

Schedule lunch with Dana next week, send the invite, and log the follow-up in Salesforce.

Step 0: User authentication

For user-delegated missions, the user must be authenticated before a Mission can be created on their behalf. The auth-first model is the primary pattern: the user authenticates at the IdP via an OIDC flow, and the resulting authenticated session provides the identity context the orchestration layer uses when submitting the Mission proposal. The proposal carries the authenticated user’s subject identifier, and the AS validates that the orchestration layer’s client_id is registered to propose missions on behalf of that user.

The approval step may be separate from authentication (the user approves a pending proposal through an asynchronous consent interaction) or collapsed with it (a combined authenticate-and-approve screen). Either path produces the same outcome: an Approved Mission with a verified mission_subject.

For headless missions, this step is replaced by client credential authentication at the orchestration layer with no interactive user authentication required.

Step 1: Tool discovery and planning

The agent uses MCP to discover available tools and their schemas:

• calendar availability search
• calendar event creation
• email send
• CRM note creation

MCP helps the agent understand what actions are possible and what parameters are needed. It does not grant authority to use any of them.

Step 2: Prompt interpretation and proposal creation

The agent interprets the prompt into an Intent Envelope and a candidate Mission Proposal:

 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

{
  "purpose": {
    "class": "urn:example.com:mission:schedule-meeting",
    "display": "Schedule Lunch with Dana"
  },
  "template_id": "schedule_meeting",
  "subject": {
    "sub": "user-123",
    "iss": "https://idp.example.com"
  },
  "candidate_authority": {
    "resource_types": ["calendar.event", "crm.account_note"],
    "operation_groups": ["calendar.schedule", "crm.record_activity"],
    "constraints": {
      "relationship": "accounts-owned-by-requesting-team",
      "business_process": "meeting-followup",
      "region": "EU"
    }
  },
  "parameters": {
    "participant": "Dana",
    "time_window": "next week"
  },
  "display": {
    "title": "Schedule a Meeting",
    "description": "The assistant will find availability and create a lunch meeting with Dana next week, send the invite, and log a CRM note.",
    "actions": ["Check calendar availability", "Create calendar event with Dana", "Send email invitation", "Log CRM note"],
    "constraints": ["EU data only", "Expires in 15 minutes"]
  }
}

The proposal is then submitted to the mission-management layer:

1

POST /mission-proposals

Step 3: Approval and attenuation

The AS or associated control-plane service evaluates the proposal. A user, enterprise policy, or administrator may attenuate it before approval.

For example, policy might allow:

• meeting-related scheduling actions for calendars the user is allowed to manage
• invite sending only to participants connected to the approved meeting mission
• CRM note creation only for accounts owned by the current team
• execution only within a 15-minute mission lifetime
• no further delegation beyond the assistant runtime
• processing only in approved regional and compliance boundaries

The result is an approved Mission record at the AS, which is then projected into protocol-facing flows through a mission_ref.

Step 4: Policy evaluation with AuthZEN

At approval time, and again later during token derivation, the AS may act as a Policy Enforcement Point (PEP) and call an AuthZEN-compatible PDP.

Conceptually, the question is no longer just “is Calendar on the allowlist?” It is closer to:

 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

{
  "subject": {
    "type": "client",
    "id": "assistant-agent"
  },
  "action": {
    "name": "create_event",
    "group": "write"
  },
  "resource": {
    "type": "calendar.event",
    "container": {
      "type": "calendar",
      "id": "primary"
    }
  },
  "context": {
    "mission_ref": "mr_7M9Qx2",
    "purpose": "urn:example.com:mission:schedule-meeting",
    "mission_state": "active",
    "relationship": {
      "participant_in_mission": true
    },
    "business_process": {
      "type": "meeting-coordination",
      "stage": "scheduling"
    },
    "compliance": {
      "region": "EU"
    }
  }
}

Mission-Bound OAuth defines when those checks happen. AuthZEN provides one way to externalize the decision.

Step 5: OAuth authorization and mission-bound token issuance

Once approved, the client starts OAuth authorization referencing the Mission, preferably through authorization_details:

1
2
3
4
5
6
7
8

{
  "authorization_details": [
    {
      "type": "mission",
      "mission_ref": "mr_7M9Qx2"
    }
  ]
}

The authorization request should be submitted via Pushed Authorization Request (PAR, RFC 9126). PAR keeps the Mission reference, delegation state, and any additional context out of browser redirect URIs and server logs.

The AS issues a mission-bound token that carries a projected Mission reference but is not itself a portable mission credential.

Step 6: Token exchange for resource-specific APIs

When the agent actually needs to call Calendar, it uses token exchange. The AS checks:

• the Mission is still active
• the target calendar resource falls inside the Mission’s compiled authority region
• the requested operation fits the Mission constraints
• delegation depth has not been exceeded

The AS then issues a Calendar-specific token carrying a projected Mission reference.

The same process happens again for Email and CRM. This is where mission continuity is preserved without issuing one overly broad token up front, and without requiring the system to pre-enumerate every exact object the agent may touch.

Step 7: Request-time enforcement

At request time:

• a baseline Resource Server may simply validate the access token and log a projected Mission reference
• a gateway may query policy using Mission-derived context
• a mission-aware RS may use introspection or token claims to apply additional checks

This gives a deployment several enforcement points without requiring every backend service to understand the full Mission object.

Step 8: Mission completion or revocation

When the task completes, or if the user or enterprise revokes it, the Mission state changes.

After that:

• further token exchange fails
• refresh or re-issuance tied to the Mission fails
• already-issued short-lived tokens expire naturally or are cut short through eventing and revocation mechanisms

That is the core difference from ordinary token-centric patterns: the authority object survives across token lifetimes, and can also end independently of them.

OAuth Protocol Details

Once approved, OAuth requests reference the Mission.

Provisional primary path: RAR-based embedding

The preferred direction is to reference an approved Mission through authorization_details:

1
2
3
4
5
6
7
8

{
  "authorization_details": [
    {
      "type": "mission",
      "mission_ref": "mr_7M9Qx2"
    }
  ]
}

This reuses an existing OAuth extension point and frames the Mission reference as structured authorization input, which seems more likely to be acceptable to OAuth practitioners.

The "mission" type identifier requires IANA registration under the Authorization Details Types registry established by RFC 9396 Section 10. The identifier name is a candidate proposed for community feedback and is subject to change before any formal registration is made. Feedback on whether "mission" is the right name for this registry entry is one of the explicit questions for this blog RFC.

Transport: PAR as the default

Authorization requests carrying a mission reference should be submitted via Pushed Authorization Request (PAR, RFC 9126) by default. PAR submits the request body over server-to-server TLS before the browser redirect, keeping mission_ref, purpose parameters, and delegation state out of browser redirect URIs, referrer headers, and server logs. For any deployment that takes Mission-Bound OAuth seriously as a security primitive, PAR should be treated as a baseline requirement rather than an optional hardening measure.

For interactive user-delegated Mission flows, PKCE (RFC 7636) is required for public and native clients. For confidential clients using PAR with private_key_jwt or client_secret authentication, PKCE is strongly recommended but not required, because the authorization code is already bound to an authenticated client credential. This aligns with RFC 9700 (OAuth 2.0 Security Best Current Practice). PAR remains required as a baseline for all client types regardless of PKCE applicability.

Mission reference binding at authorization code issuance: when the AS receives a PAR request containing authorization_details with a mission_ref, the AS MUST bind that Mission reference to the resulting authorization code at the time the code is issued. At code exchange time, the client MUST NOT be permitted to present a different mission_ref than the one bound to the authorization code. If the code exchange request includes authorization_details with a different mission_ref, the AS MUST reject the request with invalid_grant. This prevents an adversary from substituting a lower-authority Mission reference for a higher-authority one at the final issuance step. The AS-bound Mission reference from the PAR step governs the issued access token regardless of what the client submits at code exchange.

Artifact binding: the authorization code, the resulting primary mission-bound access token, and any refresh token issued from that code SHOULD all be bound to the same Mission version at issuance time. The AS should retain an internal binding record linking:

• authorization code -> mission_ref
• primary access token jti -> mission_id
• refresh token handle -> mission_id
• Approved Mission version -> Mission Authority Model version

These bindings make substitution, replay, and audit reconstruction failures easier to detect and prevent.

Authorization request parameter: not recommended

A mission_ref query parameter on the authorization redirect (GET /authorize?mission_ref=...) is not a viable alternative for production deployments. Mission references appearing in redirect URIs are exposed in browser history, referrer headers, and server logs. PAR was specifically designed to eliminate this exposure. Deployments MUST use PAR for all Mission-referencing authorization requests. The GET parameter form MUST NOT be used.

Mission-Bound Token Model

An access token issued under Mission-Bound OAuth is still an audience-specific OAuth access token. It is not a portable mission credential. Its special property is that it is derived from an active Mission and can carry a reference to that Mission.

Initial mission-bound token audience: the primary mission-bound access token issued at Step 5 (the OAuth authorization flow, before any token exchange) is an orchestration-layer credential. Its aud value is the orchestration layer’s registered resource URI or the orchestration layer’s client_id. This is a deployment requirement: the orchestration layer MUST be registered as an OAuth resource at the AS with a discoverable resource URI, OR the AS must support client_id as a valid aud value for the primary mission-bound token. The deployment profile MUST specify which model is used. Using client_id as aud is simpler and avoids requiring a separate resource registration for the orchestration layer; using a resource URI is more consistent with RFC 8707 audience binding conventions and is the recommended approach for multi-tenant or cross-domain deployments. Either way, the primary token is not intended for direct RS consumption. RSes receive mission-authority by way of audience-specific tokens produced through subsequent token exchange, each of which carries a mission_ref but targets a specific RS audience. This separates the mission-authority credential (held by the orchestration layer) from resource-access credentials (consumed by RSes and gateways).

The Mission reference may appear:

• inside the access token as a mission_ref or profile-equivalent claim
• in introspection metadata
• in exchange inputs and outputs
• in audit and event streams

The AS needs to validate Mission state before every downstream issuance decision.

A Mission reference is useful for continuity, but over-exposing it creates privacy and linkability costs.

The provisional standardized claim name for the projected Mission reference in tokens is mission_ref. This is consistent with the IANA registration candidate in the JWT Claims Registry section of this document. The AS-internal identifier remains mission_id and is never exposed at protocol boundaries. The claim name mission_ref is proposed for community feedback and may be adjusted before formal registration, but within this document it is used consistently as the normative name.

Possession of mission_ref alone grants no authority. Every use of mission_ref MUST be bound to an authenticated client context and, where token-based authority is being exercised, to the sender-constrained token or token-derived subject through which the request is made.

Composition with audience-bound tokens

When a mission-bound token is issued for a specific resource, it is still an audience-specific access token. The Mission reference claim is additive: it appears alongside, not instead of, the standard audience-specific token claims. The AS composes both: the token is valid for the target audience AND references the Mission from which its authority derives.

This means a mission-bound calendar token and a mission-bound CRM token produced from the same Mission may carry the same or different projected Mission references depending on deployment policy. They still derive from the same internal Mission, but the externally visible handle may be audience-specific. That is how the architecture balances continuity with privacy.

Sender Constraining

Sender constraining is a core requirement for Mission-Bound OAuth, not optional hardening.

Without it, Mission-reference continuity becomes replay continuity. A stolen mission-bearing token carries both the audience-specific access permissions and a durable handle that links the token to a broader mission authority chain.

DPoP (RFC 9449) or mutual TLS (mTLS, RFC 8705) binding should be stated as a baseline expectation for any mission-bearing token, including both the primary mission-bound access tokens and any tokens produced by mission-scoped exchange. A deployment profile that does not require sender constraining should make that gap explicit and acknowledge the replay risk it accepts.

Mission Introspection

Mission introspection is defined as an extension of OAuth Token Introspection (RFC 7662) rather than a new endpoint, to allow reuse of existing introspection client libraries and authorization infrastructure.

A Mission-aware AS MUST support Mission introspection at its RFC 7662 introspection endpoint by accepting a mission_ref value as the token parameter:

1
2
3
4
5

POST /introspect
Content-Type: application/x-www-form-urlencoded
Authorization: Bearer <introspection_access_token>

token=mr_7M9Qx2&token_type_hint=mission_ref

The AS recognizes the mission_ref token type hint and returns Mission state as additional fields in the standard RFC 7662 introspection response:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

{
  "active": true,
  "mission_state": "active",
  "purpose": "urn:example.com:mission:schedule-meeting",
  "exp": 1773072000,
  "delegation": { "max_depth": 1, "current_depth": 0 },
  "authority_model": {
    "allowed_operations": ["calendar.schedule", "crm.record_activity"],
    "constraints": { "region": "EU" }
  }
}

Introspection response tiering: the authority_model field in the introspection response exposes high-value Mission enforcement data and MUST NOT be returned to all introspection callers. The AS MUST require the introspection client to present an access token with scope mission:introspect:authority (or an equivalent deployment-defined scope) to receive the authority_model section. A caller presenting only a basic introspection credential receives active, mission_state, purpose, exp, and delegation but not authority_model. This prevents RSes that are authorized to check token validity from receiving the full authority region of every Mission they encounter.

Tenant-scoped introspection: Mission introspection MUST be tenant-scoped. The AS MUST reject introspection requests where the authenticated caller is outside the tenant or trust boundary associated with the referenced Mission unless the deployment explicitly permits that class of cross-tenant enforcement.

A new token_type_hint value mission_ref is a candidate for registration in the OAuth Token Type Hints registry. When the AS receives this hint, it MUST look up the Mission record rather than a token record. The active: false response MUST be treated as a hard block on further execution at any enforcement point. The mission_state field carries the precise semantic: suspended means execution is blocked pending resumption (the Mission may recover); revoked, completed, and expired are terminal (a new Mission is required). Enforcement points MUST consult mission_state to determine the correct agent behavior — they MUST NOT treat all active: false responses as equivalent to mission_revoked, as this would cause agents to abandon recoverable suspensions.

Introspection failure behavior: enforcement points MUST treat introspection endpoint failures (network errors, 5xx responses, or responses arriving after the enforcement point’s configured timeout) as active: false. Fail-closed behavior is required. A cached active: true response MAY be used only within a policy-defined staleness window; enforcement points MUST re-fetch when the staleness bound is exceeded or when a CAEP mission-terminated event is received. The staleness window MUST be defined explicitly in the deployment profile and MUST NOT default to unlimited.

The architectural decision is:

• the core Mission-Bound OAuth story does not require every deployment to expose Mission introspection
• deployments that want RS- or gateway-side live Mission checks should use an introspection profile
• the core protocol still needs to define what Mission state means at issuance, refresh, and exchange checkpoints even if no RS ever introspects it

Token Derivation and Exchange

Mission-Bound OAuth expects token exchange to be part of the normal mission execution path when agents call multiple downstream APIs or when one service delegates to another.

Subject token type: when the subject token is a mission-bound access token, the subject_token_type is urn:ietf:params:oauth:token-type:access_token per RFC 8693. The AS distinguishes a mission-bound AT from a plain AT by the presence of a mission_ref claim in the JWT body. A new subject_token_type URI for mission-bound tokens is not proposed; the existing access token type is sufficient.

The key rule is:

exchanged tokens may only represent authority that is still permitted by the referenced Mission at the moment of exchange.

That means token exchange must evaluate:

• Mission lifecycle state
• Mission expiry
• resource and action constraints against the compiled authority region
• delegation depth
• client identity
• any policy conditions required by the deployment

If the Mission is no longer valid, the exchange fails even if the input token itself is otherwise structurally valid.

Refresh tokens on exchange-derived tokens: RFC 8693 does not mandate that token exchange responses include refresh tokens. By default, token-exchange-derived tokens under a Mission MUST NOT include a refresh token unless the AS policy explicitly permits it for the target resource and client combination. If the AS does issue a refresh token for an exchange-derived token, the AS MUST bind that refresh token to the same mission_id as the subject token and MUST revoke it when the Mission is revoked, suspended, or completed, following the same lifecycle rules as refresh tokens issued at initial authorization. An exchange-derived refresh token MUST NOT outlive the Mission from which its authority derives.

Token Exchange Request Format

The preferred exchange model is that the subject token already identifies exactly one Mission through its mission_ref claim, and the exchange request MAY echo that Mission reference in authorization_details when the client wants explicit binding:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

POST /token
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token=<mission_bound_access_token>
&subject_token_type=urn:ietf:params:oauth:token-type:access_token
&requested_token_type=urn:ietf:params:oauth:token-type:access_token
&resource=https://calendar.example.com/
&scope=calendar.schedule
&authorization_details=[{"type":"mission","mission_ref":"mr_7M9Qx2"}]

Embedding mission_ref inside authorization_details is preferred over a standalone token exchange parameter because RFC 9396 already defines authorization_details as a valid token endpoint parameter. A standalone mission_ref parameter would require IANA registration in the OAuth Parameters registry before conformant ASes could rely on it, since RFC 8693 Section 2.1 defines a closed parameter set and unregistered parameters may be silently ignored.

The AS validates the Mission’s state, checks the requested resource and scope against that Mission’s compiled authority region, and issues a resource-specific token. The resulting token carries a mission_ref appropriate for the target audience.

Mission selection rules:

• if the subject token carries exactly one mission_ref and the exchange request omits Mission reference input, the AS MAY use the bound mission_ref from the subject token
• if the exchange request includes authorization_details with mission_ref, the AS MUST compare that value to the Mission reference bound to the subject token and reject the request on mismatch
• if the subject token does not uniquely identify one Mission and the request omits Mission reference input, the AS returns mission_ref_required

This keeps Mission selection explicit where needed, but avoids forcing well-behaved orchestration runtimes to copy the same mission_ref through every exchange hop purely for disambiguation.

Anti-confused-deputy rule: token exchange MUST validate not only the Mission but also the requesting client’s authority to derive a token for the requested target resource under that Mission. A client MUST NOT use another client’s mission-bound subject token as exchange input unless that delegation path was explicitly authorized by the Mission and represented in the delegated actor state. Possession of a structurally valid subject token is not sufficient by itself.

The cleanest delegation story is to treat delegation as a constrained form of downstream token derivation, enforced at exchange time by the AS, rather than as an informal client-side action.

Delegation Model

Delegation is in scope because many missions are not executed by a single software component end-to-end.

The act claim defined in RFC 8693 Section 4.1 identifies the current acting party in a delegated token. RFC 8693 defines act as a single JSON object, not a recursive structure. Nested act.act is not defined by RFC 8693 and is not supported by most JWT libraries.

For multi-hop delegation chains, Mission-Bound OAuth proposes a delegation_chain claim as an ordered array of actor identifiers. Index 0 is the most-recently-added actor (the current immediate delegate, matching act.sub); the last index is the originating delegating actor. The array grows at the tail as delegation chains extend. This is a proposed extension beyond RFC 8693 and is one of the explicit questions for community feedback.

A two-hop delegation example:

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

{
  "sub": "user-123",
  "sub_profile": "user",
  "act": {
    "sub": "assistant-agent",
    "sub_profile": "ai_agent"
  },
  "delegation_chain": [
    { "sub": "assistant-agent", "sub_profile": "ai_agent" },
    { "sub": "workflow-engine", "sub_profile": "service" }
  ],
  "mission_ref": "mr_7M9Qx2"
}

The act claim identifies the current actor (the immediate delegate). The delegation_chain records the full ordered chain for audit and RS policy evaluation. The AS is authoritative for the chain state; both claims are projections of that state into the token.

Whether to extend RFC 8693 with a standardized multi-hop chain representation or define a Mission-specific claim is an open question for feedback. The delegation_chain proposal is one candidate. Feedback on the claim name, structure, and whether this requires a standalone Internet-Draft is explicitly requested.

The current direction for the delegation model:

• delegation is allowed only if the Mission permits it
• each delegation event extends act (current actor) and appends to delegation_chain (full history); one delegation event is defined as one token exchange request that introduces a new actor: the AS increments current_depth by exactly one for each exchange that sets or changes the act claim in the resulting token; re-exchanges that produce a token for the same actor at the same depth do not increment current_depth
• maximum delegation depth is enforced by the AS at exchange time via an atomic increment (see Concurrency Requirements below)
• delegated actors inherit attenuated, not expanded, authority
• the AS is authoritative for delegation state; tokens carry only the minimum chain data needed for the next hop or RS policy

Offline delegation chain validation limitation: once issued, the act and delegation_chain claims in a token are immutable for the token’s lifetime. A delegation revocation at the AS does not retroactively alter these claims in already-issued tokens. Resource servers that validate delegation offline cannot detect post-issuance chain revocations. Mission-aware resource servers requiring strong delegation assurance MUST use Mission introspection rather than relying solely on token-embedded chain claims. This is an intentional design constraint of bearer token delegation and is not unique to Mission-Bound OAuth.

Resource Server Model

One important question is what a Resource Server should be able to rely on.

A practical processing model is:

• the AS enforces Mission lifecycle and delegation rules at issuance, refresh, and exchange time
• the RS continues to validate audience-specific access tokens as usual
• the RS may receive selected Mission metadata through token claims or introspection
• the RS must not be required to understand the full Mission object to remain interoperable

This keeps Mission-Bound OAuth from turning every RS into a mission engine while still allowing richer enforcement where deployments want it.

If richer RS behavior is desired, it should be profiled separately:

This is one of the most important separations in the architecture because it allows incremental deployment. Mission-Bound OAuth should still deliver value when only the AS is mission-aware.

Mission Authority and Scope Authority

Mission authority is a further constraint applied on top of scope authority, not a replacement for it. The scope model is hybrid:

• the client may request scopes as part of the authorization request, as it does today
• the AS treats client-requested scopes as inputs, not as authoritative claims
• the AS derives the final granted scopes from the Mission’s authority model, narrowing or adjusting the client’s request to match what the Mission permits
• the resulting token carries scopes that are a subset of both what the client requested and what the Mission’s authority model allows

This keeps the architecture backward compatible. A baseline RS that does not understand Mission references still receives standard OAuth scopes in the token and can enforce them as usual. The Mission adds a governed layer above scope: the AS ensures at issuance that no token carries scope authority that exceeds the Mission’s authority model, regardless of what the client requested.

The practical implication: if a client requests calendar:write but the Mission’s authority model only permits write access to user-manageable calendars during the current business process, the AS may issue a more specific scope (or a standard scope paired with constrained audience claims) reflecting the narrower authority. The AS is the final arbiter of what scope appears in the token; the client’s scope request is advisory.

Scope mapping: the mechanism by which the AS maps authority-model elements (resource type selectors, operation groups, relationship predicates) to OAuth scope strings is not standardized in this version and is implementation-specific. The normative constraint is: the AS MUST NOT issue a scope value that grants authority exceeding the Mission’s authority model. The practical implication is that baseline RSes receive AS-derived scopes that conservatively represent Mission-attenuated authority, but the exact scope string for a given authority model is determined by AS implementation and deployment configuration. Interoperable scope mapping is a subject for deployment profile work, not the core spec.

For a baseline RS that does not understand Mission references, scope remains the effective authorization floor. Mission constraints are only as effective as the enforcement points that evaluate them, which is an intentional design tradeoff that enables incremental adoption. It should be stated explicitly: the hybrid model reduces but does not eliminate the over-authorization risk at baseline RSes, because the AS-derived scope still reflects the Mission’s authority model.

Mission-Aware Client Registration

Which Mission types a client is permitted to request should be part of client registration (RFC 7591 extension). A client that has not been registered for schedule_meeting cannot request a Mission of that type, regardless of what it asserts at runtime.

Client registration metadata should include the following candidate fields:

• mission_types: an array of permitted purpose identifiers or purpose classes the client may propose; the AS rejects proposals referencing purposes not in this list
• mission_delegation_max_depth: the maximum delegation depth permitted for this client across all Mission types; defaults to 0 (no delegation) if absent
• mission_approval_mode: the required approval mode for this client’s proposals: "interactive" (user consent required), "policy_auto" (AS evaluates against registered policy at proposal time), or "pre_provisioned" (Mission type is pre-approved and activates immediately on request)
• mission_resource_categories: an optional coarse-grained filter on the resource type categories the client may reference in proposals, applied before template-level constraints

These field names are candidates for registration in the OAuth Dynamic Client Registration Metadata registry per RFC 7591 Section 3.2, not as JWT claims. Feedback on naming and structure is part of what this blog RFC is intended to surface.

This is the allow-list mechanism applied at the authorization layer. Without it, any Mission-capable client can request any Mission type and the AS has no normative basis for rejection beyond local policy. Client registration is the provisioning boundary that separates what was pre-authorized by an administrator from what a client can self-assert at runtime.

Mission Management

The prompt itself is not the authorization artifact. It is an input to interpretation and proposal creation.

The basic architectural assumptions are:

• prompts are untrusted semantic input
• interpreted intent is a proposal, not authority
• the approved Mission is the first artifact with normative authority semantics

Mapping Pipeline

The prompt-to-mission mapping process consists of:

1. Prompt interpretation
2. Intent extraction
3. Mission template selection
4. Mission proposal generation
5. Mission approval
6. OAuth authorization and token issuance

Intent Envelope

An agent or client may convert a prompt into an intermediate representation called an Intent Envelope.

Example:

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

{
  "intent_type": "schedule_meeting",
  "entities": {
    "participant": "Dana",
    "time_window": "next week"
  },
  "requested_outcomes": [
    "calendar.create_event",
    "crm.create_note"
  ],
  "risk_signals": {
    "external_communication": false,
    "financial_action": false,
    "sensitive_data": false
  },
  "confidence": 0.92
}

The Intent Envelope expresses the agent’s interpretation of the prompt. It does not itself create authority.

Mission Templates

Authorization servers or associated control-plane services may maintain a registry of mission templates representing common workflow categories.

Example template identifiers:

• schedule_meeting
• customer_followup
• expense_submission
• travel_booking

Templates may define:

• resource types and selectors
• operation groups
• default mission constraints
• delegation limits
• approval mode
• step-up or administrator approval requirements
• business-process conditions
• compliance and jurisdiction boundaries

Templates are useful because they constrain how free-form prompts become structured authority requests. They are also the appropriate level at which enterprise security and governance teams author policy, without requiring application teams to define raw resource taxonomies for every Mission type.

Minimum template schema: a Mission template is a JSON object with the following structure:

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

{
  "template_id": "schedule_meeting",
  "purpose_class": "urn:example.com:mission:schedule-meeting",
  "display_name": "Schedule a Meeting",
  "authority_model_defaults": {
    "allowed_resources": [
      { "type": "calendar.event", "selector": "user-manageable-calendars" }
    ],
    "allowed_operations": [
      { "group": "calendar.schedule" }
    ],
    "constraints": []
  },
  "delegation": {
    "allowed": false,
    "max_depth": 0
  },
  "lifecycle": {
    "max_duration_seconds": 900
  },
  "approval_mode": "interactive",
  "requires_step_up": false
}

Required fields: template_id, purpose_class, display_name, authority_model_defaults, approval_mode. Optional fields: delegation, lifecycle, requires_step_up, and deployment-specific extension fields.

Templates are registered at the AS via a template registration API (a Layer 2 management-plane capability). Clients reference a template in a proposal by template_id. The AS MUST validate that the proposal’s candidate authority is a strict subset of the template’s authority_model_defaults before approving. A proposal that exceeds the template’s authority bounds MUST be rejected.

Purpose Taxonomy

Purpose identifiers need a clearer IAM story because they drive templates, client registration, approval policy, and audit semantics.

The taxonomy distinguishes three levels:

The policy class URI is the authoritative identifier. It is what appears in mission_types client registration metadata, in AS policy rules, and in audit events. URI form is chosen because:

• it provides a namespace that avoids collisions between deployments and organizations
• it enables future standardization of well-known purpose classes without requiring a flat global string registry
• it is consistent with how OAuth, OIDC, and related specs handle stable identifiers (e.g., scope URIs, grant type URIs)

In simple single-deployment scenarios, the template identifier and policy class may be the same string. The display purpose is always separate because it is a UX artifact, not a policy artifact.

Organizations defining their own purpose classes should use domain-based URI namespaces: urn:example.com:mission:schedule-meeting or https://example.com/mission-classes/schedule-meeting. Standard or widely-shared purpose classes are a future registry concern; the architecture does not attempt to define them now.

The important property is stable policy reference. Clients, administrators, and policy engines need a URI they can register against and reason about consistently, independent of how the display label changes over time.

Tenant and Organization Boundary

Most IAM deployments are tenant- or organization-scoped. The safest default is to treat a Mission as tenant-bound unless it is explicitly projected across a federation boundary.

A Mission should at least carry:

• tenant or organization identifier
• subject tenancy
• client tenancy
• policy authority or issuer

This matters because:

• relationship predicates often depend on tenant-local graphs
• Mission introspection must not leak Mission state across tenants
• client registration and purpose classes are usually tenant-scoped
• cross-domain Mission assertions are explicit exceptions, not the default

The safest default is:

• Missions are local to one issuer and one tenant boundary
• anything that crosses that boundary does so through an explicit projected artifact and trust decision

Operationally, this means mission_ref resolution must also be tenant-scoped:

• the AS MUST reject mission_ref lookups, introspection requests, authority-model retrieval, and exchange requests that originate outside the tenant or issuer context that owns the Mission unless an explicit federation profile permits that access
• a mission_ref that is valid in one tenant MUST NOT be assumed valid or meaningful in another tenant, even if the string value collides

Proposal and Approval

Endpoint Candidates

Current endpoint candidates:

1
2
3
4
5
6

POST /mission-proposals
POST /mission-proposals/{proposal_id}/approval
GET  /mission-proposals/{proposal_id}
GET  /missions/{mission_ref}
POST /missions/{mission_ref}/resume
POST /missions/{mission_ref}/expand

The current intent is:

• POST /mission-proposals creates a Mission Proposal based on interpreted intent
• POST /mission-proposals/{proposal_id}/approval approves, rejects, or attenuates the proposal
• GET /mission-proposals/{proposal_id} returns proposal state for polling or review
• GET /missions/{mission_ref} returns the approved Mission artifact (authorization required; scoped to principals with administrative or subject authority over the Mission)
• POST /missions/{mission_ref}/resume resumes a suspended Mission; requires the same authentication and authorization as the original approval action
• POST /missions/{mission_ref}/expand submits an expansion proposal against an active Mission; see Progressive Mission Expansion

Proposal Request Schema

POST /mission-proposals accepts application/json with the following structure:

 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

{
  "purpose": {
    "class": "urn:example.com:mission:schedule-meeting",
    "display": "Schedule a Meeting with Dana"
  },
  "template_id": "schedule_meeting",
  "subject": {
    "sub": "user-123",
    "iss": "https://idp.example.com"
  },
  "candidate_authority": {
    "resource_types": ["calendar.event", "crm.account_note"],
    "operation_groups": ["calendar.schedule", "crm.record_activity"],
    "constraints": {
      "region": "EU",
      "business_process": "meeting-followup"
    }
  },
  "parameters": {
    "participant": "Dana",
    "time_window": "next week"
  },
  "delegation": {
    "allowed": false
  },
  "lifecycle": {
    "max_duration_seconds": 900
  },
  "display": {
    "title": "Schedule a Meeting",
    "description": "The assistant will check calendar availability and create a meeting with Dana.",
    "actions": ["Check your calendar for availability", "Create a calendar event with Dana"],
    "constraints": ["Expires in 15 minutes", "EU data only"]
  }
}

Required fields: purpose.class, subject, candidate_authority. Optional fields: template_id (if omitted, the AS selects a template by purpose class), parameters, delegation, lifecycle, display.

Success response (HTTP 201 Created):

1
2
3
4
5
6
7

{
  "proposal_id": "prop_Kx29Mf",
  "state": "pending",
  "created_at": 1773072000,
  "approval_uri": "https://as.example.com/mission-proposals/prop_Kx29Mf/approval",
  "status_uri": "https://as.example.com/mission-proposals/prop_Kx29Mf"
}

When the proposal is approved, GET /mission-proposals/{proposal_id} returns the updated proposal record with "state": "approved" and a mission_ref field containing the projected Mission reference for the newly activated Mission:

1
2
3
4
5
6
7
8

{
  "proposal_id": "prop_Kx29Mf",
  "state": "approved",
  "created_at": 1773072000,
  "approved_at": 1773072120,
  "mission_ref": "mr_7M9Qx2",
  "mission_uri": "https://as.example.com/missions/mr_7M9Qx2"
}

Clients MUST poll status_uri to detect approval. The AS MAY also support a callback_uri field in the proposal request body that it calls upon approval with the same response body. The mission_ref returned here is the value the client uses in subsequent authorization_details when starting the OAuth authorization flow.

Failure responses: 400 for malformed requests, 401 for unauthenticated callers, 403 for unauthorized mission types (client not registered for the requested purpose.class), 422 for proposals that exceed template bounds.

The approval step is where requested authority becomes real authority. Approval results in one of three outcomes:

• denial, with no Mission created
• attenuation, with an Approved Mission narrower than the proposal
• approval, with an Approved Mission created from the proposal

That approval may be performed by:

• the end user
• an administrator
• enterprise policy
• an external approval system
• a combination of human and policy controls

An attenuation step is explicitly in scope. The approved Mission may be narrower than the proposed one.

The proposal model should allow input from:

• a raw prompt
• an intent envelope
• a structured plan
• an MCP tool schema extraction
• a direct structured authority request

That flexibility matters because not every deployment wants the AS itself to process natural language.

Mission Proposal Authorization

Who is the authorized principal to call POST /mission-proposals is a security-critical question. The design principle that agents interpret prompts but do not grant authority needs a concrete protocol expression at the proposal endpoint.

The authorized callers and their trust levels:

• Orchestration layer or agent platform: the system that manages agent execution, acting as an authenticated OAuth client; the AS authenticates the caller by client_id using standard OAuth client authentication; the platform is trusted to submit proposals on behalf of its managed agents but not to approve them
• User session: an authenticated user may directly author or authorize a proposal through a consent flow; the AS authenticates the user through a standard OAuth authorization flow
• Administrator: an authenticated administrator acting under elevated policy authority, able to pre-approve mission types or approve proposals for regulated workflows

The agent runtime is not an authorized proposal caller. An agent should not be able to submit a proposal under its own identity without passing through an orchestration layer or authenticated user session. The proposal endpoint should reject unauthenticated or agent-self-authenticated requests.

The critical separation: proposal submission is client-authenticated at the orchestration layer. Approval is user-authenticated or policy-evaluated. These are distinct trust steps enforced by separate authorization checks at the AS. A client registered for schedule_meeting missions can propose one; only the authorized approver can activate it.

User identity binding in mission:propose tokens for user-delegated missions: a mission:propose access token obtained via client credentials allows the orchestration layer to submit proposals. But for user-delegated missions, the subject field in the proposal must be bound to a verified user identity. The AS MUST NOT accept a subject.sub claim in a proposal on the basis of the client’s self-assertion alone.

Three acceptable binding mechanisms:

1. Session-bound mission:propose token: the orchestration layer obtains the mission:propose token through an authorization code flow that authenticates the user. The AS records the authenticated user subject in the issued token. At proposal time, the AS validates that proposal.subject.sub matches the subject in the mission:propose token.

2. JWT subject assertion: the orchestration layer includes a signed JWT subject assertion in the proposal request, issued by the IdP that authenticated the user. The AS validates the assertion and binds the subject to the proposal.

3. Pre-bound session reference: the orchestration layer includes a session reference (e.g., an OIDC id_token jti or session ID) in the proposal. The AS resolves the authenticated subject from its own session store.

A mission:propose token obtained via client credentials alone MUST only be used for headless missions where no interactive user subject is involved.

For headless workflows, the orchestration layer or an administrative process is the authorized proposal submitter, and approval is delegated to policy rather than an interactive consent step.

Proposal endpoint authentication: POST /mission-proposals is a protected resource requiring an access token with scope mission:propose, issued by the AS to the orchestration layer’s client_id. The endpoint is not an OAuth grant endpoint; it does not accept client credentials directly. The AS MUST authenticate the caller as a registered OAuth client and validate that the client’s registration includes the proposed mission type in mission_types.

The grant type used to obtain the mission:propose token depends on the mission type:

• Headless missions: the orchestration layer obtains the token via the client credentials grant (RFC 6749 Section 4.4). The resulting token carries no user subject and MUST only be used for headless mission proposals. The AS MUST reject any user-delegated proposal submitted under a client-credentials-derived mission:propose token.
• User-delegated missions (Mechanism 1): the orchestration layer obtains the token via the authorization code flow that authenticates the user. The AS records the authenticated user subject in the issued token. At proposal time, the AS validates that proposal.subject.sub matches the subject bound in the mission:propose token. This is the most direct binding mechanism.
• User-delegated missions (Mechanisms 2 and 3): the orchestration layer may obtain the mission:propose token via client credentials but must supplement the proposal with either a signed JWT subject assertion (Mechanism 2) or a pre-bound session reference (Mechanism 3) to establish the user subject. The AS validates the supplemental binding independently before accepting the proposal subject claim.

The AS MUST publish the proposal endpoint URL in its authorization server metadata (RFC 8414) under a mission_proposal_endpoint metadata field. Clients discover the endpoint from AS metadata; the endpoint URL MUST NOT be hardcoded.

The following scopes are candidates for registration. Feedback on scope naming and whether per-mission-type variants (e.g., mission:propose:schedule_meeting) are preferable to umbrella scopes is an explicit question for this blog RFC.

Approval Authority Model

Approval authority also needs a clear precedence model.

The approval model should assume these authority sources, from strongest to weakest:

• hard policy deny: cannot be overridden by user approval
• administrator approval or attenuation: may grant or narrow within administrative scope
• subject approval: grants delegated authority within the limits policy and registration allow
• policy auto-approval: grants within pre-registered constraints for trusted clients

Some consequences follow:

• a user cannot approve what policy forbids
• an administrator may attenuate a Mission even if the subject would have approved a broader one
• policy auto-approval only works within pre-registered Mission classes and authority envelopes
• external approval systems act as delegated approvers; they do not bypass issuer policy

Approval UX and Consent Display

The approval step is only meaningful if the approver understands what they are approving. Structured Mission proposals with resource types, operation groups, and relationship predicates are not legible to most users.

The Mission proposal should carry a human-readable display representation alongside the machine-evaluable authority structure. This display representation is used in the approval UI, not in enforcement:

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

{
  "display": {
    "title": "Schedule a Meeting",
    "description": "The assistant will check calendar availability, create a meeting with Dana, send an email invitation, and log a CRM note. This access expires in 15 minutes.",
    "actions": [
      "Check your calendar for availability next week",
      "Create a calendar event with Dana",
      "Send an email invitation to Dana",
      "Log a follow-up note in Salesforce for Dana's account"
    ],
    "constraints": [
      "EU data only",
      "Accounts you own",
      "Expires in 15 minutes"
    ]
  }
}

The display object is the consent primitive. Users approve the display representation; the system enforces the Mission Authority Model. That alignment between what the user sees and what the system enforces is a security property, not a UX choice. Without it, the approval step is a checkbox users do not understand and the “human in the loop” guarantee is nominal.

Template-driven display validation is the mechanism that preserves this alignment. The orchestration layer may supply a candidate display object in the proposal, but the AS validates it against the selected mission template before presenting it to the approver. The validation checks that:

• every claimed action in display.actions maps to an operation group present in the authority model
• every claimed constraint in display.constraints is actually present in the authority model
• the display description does not omit material authority that the authority model grants

If the AS cannot verify alignment, it either regenerates the display from the authority model (template-driven generation) or rejects the proposal. Accepting an unverified display representation is a social engineering attack surface: a malicious or compromised orchestration layer could describe a benign operation while the authority model permits something broader. Template-driven generation or AS-side validation is therefore a security requirement, not a UX convenience.

A2UI as the Mission Interaction Layer

The plain display object is a useful minimum, but it is not the only possible interaction model.

For more agent-native deployments, A2UI is a strong fit as an optional Mission interaction layer:

• the Mission Proposal remains the authority candidate
• the Mission Authority Model remains the enforcement artifact
• A2UI becomes the rendering and interaction layer for review, clarification, attenuation, approval, suspension, and remediation flows

That is a better fit than a static display blob when the approval flow is conversational or multi-step:

• the AS may need to ask clarification questions
• the approver may want to narrow the Mission before approval
• the client may need a structured remediation or resume action after suspension
• different clients may want native UI rendering without executing arbitrary remote code

The right architectural boundary is:

• display is the minimum portable summary every deployment can support
• A2UI is an optional richer interaction profile for agent-native clients
• neither display nor A2UI is the authority itself
• the Approved Mission and Mission Authority Model remain authoritative

AAuth-like approval experiences become much easier to imagine in this model: the authorization server can drive a structured interaction surface while still keeping authority semantics at the Mission layer rather than in the UI layer.

That separation matters. If the UI protocol becomes the authority artifact, the system becomes harder to audit and explain. If the UI protocol is only a presentation and interaction surface over Mission semantics, then:

• approval remains governable
• clarification remains structured
• remediation can be standardized
• the AS can validate what is shown against what is actually enforced

The practical recommendation is therefore:

• require a simple display summary in the base architecture
• allow an A2UI interaction surface as an optional profile for richer clients
• require AS-side validation that the A2UI view, like the display view, accurately represents the authority actually being approved

Approval Evidence Artifact

From an IAM governance perspective, it is not enough to know that a Mission was approved. The system also needs to retain what the approver was actually shown.

The approval evidence artifact should include at least:

• the Approved Mission identifier and version
• the Mission Authority Model version or content hash that was approved
• the approver identity
• the approval timestamp
• the template or policy version used to generate the approval view
• the exact approved presentation view:
  • validated display object, or
  • validated A2UI interaction payload, or
  • a canonical AS-generated rendering derived from the Mission Authority Model

This matters for:

• audit replay
• human-readable explainability
• dispute resolution
• regulated approval processes

The architectural rule should be:

• approvers approve a presentation artifact
• the AS retains that approved presentation artifact as evidence
• the AS must be able to prove that the retained presentation artifact was validated against the approved Mission Authority Model
• the evidence record should carry a stable digest of the approved presentation artifact and a stable digest or version reference to the Mission Authority Model so that later auditors can verify that the rendered approval surface and the enforced authority model were the same approval event

Without that evidence layer, “human approval” is harder to defend later because the system can show what authority was enforced but not what authority was represented to the approver at decision time.

When approval is delegated to an external approval system, the external system must return enough information for the AS to preserve the same evidence standard. At minimum, it must return one of:

• the final approved presentation artifact
• a stable reference and integrity-protected hash of the approved presentation artifact
• an AS-resolvable identifier that allows the AS to retrieve the exact approved presentation artifact later

An external approval callback that returns only “approved” or “denied” without preserving the approved presentation artifact is insufficient for high-assurance or regulated approval flows.

Enterprise Approval System Integration

Many enterprises already have approval workflows: ServiceNow, Jira Service Management, enterprise HR systems, or custom approval portals. The Mission proposal and approval model should be designed to delegate to these systems rather than requiring a new approval UI.

The approval endpoint should support an async delegation model:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

POST /mission-proposals/{proposal_id}/approval
-> 202 Accepted
Location: /mission-proposals/{proposal_id}

Body:
{
  "approval_mode": "external",
  "external_system": "https://servicenow.enterprise.example/api/approval",
  "external_ticket_id": "REQ0012345",
  "callback_uri": "https://as.enterprise.example/mission-proposals/callback"
}

The AS holds the proposal in pending state, the external system delivers its decision via callback or webhook, and the AS transitions the Mission accordingly. This allows Mission-Bound OAuth to sit above existing enterprise governance infrastructure rather than replacing it. For regulated enterprises, this is the adoption path: Mission proposals become work items in the existing approval system, and the AS acts on the approval output.

Callback authentication: the approval callback endpoint (https://as.enterprise.example/mission-proposals/callback) MUST be authenticated. Unauthenticated callbacks that can transition a Mission from pending to active are a privilege escalation attack surface. Three acceptable models:

1. Callback credential: when the AS delegates approval to an external system, it issues a short-lived, audience-specific callback credential bound to the proposal_id. The external system presents this credential in the callback request. The AS validates it before accepting the approval decision.

2. Webhook signing: the external system signs callback payloads using a pre-registered key. The AS verifies the signature before processing. Key registration is part of the external system configuration at the AS.

3. AS polling: instead of receiving callbacks, the AS polls the external system for approval decisions. The AS authenticates to the external system using a registered client credential. No inbound callback endpoint is exposed.

Deployments MUST implement at least one of these models. An unauthenticated callback endpoint MUST NOT be deployed.

Callback re-validation requirement: authenticating the callback source is necessary but not sufficient. Between the time the AS delegated approval to an external system and the time the callback arrives, conditions may have changed: the proposal’s approval window may have elapsed, the subject’s organizational membership or authorization may have changed, or a hard policy deny that was not in effect at proposal time may now apply. The AS MUST re-run applicable policy checks at the time of callback receipt before transitioning the Mission to active. Specifically, the AS MUST re-validate: (1) the proposal has not expired, (2) the proposed mission type is still permitted for the requesting client, (3) no hard policy deny now applies to the subject or client. If any check fails, the AS MUST reject the callback with an appropriate error and MUST NOT activate the Mission, regardless of the callback credential’s validity. The audit event for a rejected callback MUST record the reason for rejection.

MCP Tool Metadata to Mission Proposal Mapping

Many agent deployments use MCP as the tool and context plane. MCP tool schemas expose resource types, required parameters, and operation descriptions. A standard extraction of this metadata into Mission Proposal candidate authority would give agent platforms a concrete starting point without requiring bespoke proposal generation logic per tool.

The mapping concept:

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

{
  "mcp_tool": {
    "name": "calendar_create_event",
    "description": "Creates a calendar event",
    "input_schema": {
      "calendar_id": "string",
      "title": "string",
      "attendees": ["string"],
      "start": "datetime",
      "end": "datetime"
    }
  },
  "derived_authority_candidate": {
    "resource_type": "calendar.event",
    "operation_group": "calendar.schedule",
    "required_parameters": ["calendar_id"]
  }
}

A standard extraction profile for MCP-to-Mission Proposal mapping would allow agent frameworks to auto-generate the candidate authority section of a Mission Proposal from the tools the agent has discovered, rather than requiring the agent to construct it from scratch.

But the boundary has to stay explicit:

• MCP tool names are not stable authorization identifiers
• MCP schemas are not policy vocabulary
• MCP metadata is proposal input, not authority

The extraction step is therefore a translation into Mission vocabulary, not a direct reuse of tool metadata as policy semantics. That auto-generated candidate is then attenuated through templates and policy before becoming a real proposal. This is one of the most practical things the architecture can do to lower the entry cost for agent platform developers who are already using MCP without letting tool schemas silently become the authorization model.

Handling Ambiguity

When the prompt is incomplete or ambiguous, the architecture should bias toward narrower authority:

• generate a narrower Mission Proposal
• request clarification
• request additional authority later through a new proposal

Ambiguity should reduce scope rather than expand it.

Progressive Mission Expansion

Progressive expansion is an optional capability for deployments that need open-world adaptation after a Mission has started. It is not required for the minimum viable Mission-Bound OAuth profile. Simpler deployments may choose the stricter rule: if additional authority is needed, create a new Mission rather than expanding the existing one.

When enabled, progressive expansion is the architecture’s answer to the open-world bootstrap problem. Agents may discover additional authority requirements while executing a Mission. Rather than requiring all future resources to be enumerated up front, the model allows an agent to submit a constrained expansion proposal that references the current Mission.

The key concept should be a bounded authority envelope rather than literal pre-enumeration of every future object. The parent Mission carries:

• approved resource classes and selectors
• approved operation families
• approved relationship predicates
• approved business-process and compliance bounds

An expansion is allowed when the newly requested authority can be shown to fall inside that approved envelope, even if the exact runtime object or tool was not named earlier.

That means:

• a newly discovered email tool may be acceptable if communication-with-approved-participants is already inside the parent Mission envelope
• a newly discovered CRM object may be acceptable if it matches the approved accounts-owned-by-requesting-team selector
• a new operation outside the approved operation families still requires a fresh Mission proposal and approval cycle

The envelope does not make expansion unconstrained. It simply moves the decision boundary from literal membership to policy-evaluable containment.

This should be treated as a later profile for easier adoption:

• baseline deployments can omit expansion entirely
• deployments that need open-world adaptation can add expansion once their Mission templates, policy, and audit model are stable

Containment should be evaluated across at least four dimensions:

• resource containment: the requested resource type and selector fall within an approved resource class or selector family
• operation containment: the requested action belongs to an approved operation group or operation family
• predicate containment: the request does not introduce new relationship, process-state, compliance, or jurisdiction predicates outside the approved set
• risk containment: the expansion does not exceed approved delegation depth, duration, checkpoint policy, or other execution bounds

An expansion should be considered inside the authority envelope only when all four containment checks pass. If any one of them fails, the request is outside the approved envelope and requires a new Mission proposal or new approval step.

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

{
  "parent_mission_ref": "mr_7M9Qx2",
  "requested_extension": {
    "candidate_authority": {
      "resource_types": [
        "email.message"
      ],
      "operation_groups": [
        "email.send"
      ],
      "constraints": {
        "relationship": "participants-in-approved-meeting"
      }
    },
    "display": {
      "title": "Send Meeting Invitation",
      "description": "Send an email to Dana confirming the scheduled meeting.",
      "actions": ["Send one email to Dana with meeting details"]
    }
  }
}

This directly addresses the question “what happens when the agent discovers a tool it did not know about at startup?” The answer is not necessarily a new full authorization flow with the user. It is a scoped expansion request against the existing Mission, which the AS evaluates against the original approved authority envelope. If it fits inside that envelope, the expansion is approved. If it exceeds those boundaries, a new Mission proposal or a new approval step is required.

This model keeps the user in control without requiring them to pre-enumerate every tool at consent time.

Expansion Proposal Protocol

Expansion proposals are submitted to POST /missions/{mission_ref}/expand. The endpoint requires a client credentials access token with scope mission:expand, issued to the same client_id that holds the active Mission. The parent_mission_ref in the body must match the {mission_ref} path parameter; mismatches MUST be rejected with HTTP 400.

Success response (HTTP 202 Accepted): the expansion proposal is queued for evaluation. If the AS can evaluate envelope containment synchronously, it MAY return HTTP 200 with the expansion decision inline.

1
2
3
4
5
6

{
  "expansion_id": "exp_Hq37Wz",
  "state": "pending",
  "mission_ref": "mr_7M9Qx2",
  "status_uri": "https://as.example.com/missions/mr_7M9Qx2/expansions/exp_Hq37Wz"
}

When the expansion is approved, the AS updates the Mission’s compiled authority region (incrementing the Mission version counter) and emits a mission.expanded audit event. The client discovers approval by polling status_uri. The AS MAY also support a callback_uri in the expansion request body, following the same callback authentication requirements as the enterprise approval system integration.

Expansion does not produce a new mission_ref. The existing Mission’s compiled authority region is widened; the same mission_ref governs subsequent token exchanges. After an approved expansion, enforcement points that cached the prior Mission Authority Model version MUST re-fetch, as the version counter will have incremented.

If the requested extension exceeds the authority envelope, the AS MUST return HTTP 422 with error mission_expansion_outside_envelope and a mission_error_detail object identifying which containment check failed (using the same constraint_violated vocabulary as mission_authority_exceeded). In this case the client must submit a new full Mission proposal and approval cycle.

Concurrency: concurrent expansion proposals against the same Mission version MUST be serialized. An expansion evaluated against a prior version is rejected with HTTP 409 and error mission_expansion_conflict, requiring the client to re-fetch the current Mission state and re-evaluate before resubmitting.

Headless and Service-to-Service Missions

Not all agent workflows involve interactive users. Automation pipelines, scheduled reconciliation jobs, and system-level agents operate as service clients using client credentials (RFC 6749 Section 4.4) or pre-authorized grant flows with no consent screen. Mission governance still applies to these workflows; the approval model is different.

Subject binding for headless missions: the proposal schema requires a subject field. For headless service-to-service missions, the subject is the service principal on whose behalf the automation runs, not an interactive user. Two cases apply:

• Client-as-subject: the orchestration layer is itself the subject. The subject.sub is the client’s registered service identity and subject.iss is the AS or IdP that issued the service identity. This is the appropriate model when the agent is acting on behalf of a system or process rather than a human.
• Service-identity subject: the client is acting on behalf of a distinct service identity (e.g., a batch job identity registered in a service account directory). subject.sub and subject.iss refer to that identity, and the AS validates the orchestration layer’s authority to propose Missions on behalf of that subject via client registration metadata.

If subject is omitted from a headless mission proposal, the AS MUST treat the client_id as both client and subject. Deployments that require explicit subject tracking for audit purposes SHOULD require the subject field even for headless missions.

For headless missions, the architecture provides two models:

Policy-auto-approved missions: at Mission proposal time, the AS evaluates the request against a registered policy for the client and mission type. If the client is registered for the requested mission type and the policy permits it, the AS activates the Mission immediately at creation without an interactive consent step. The audit trail records the policy evaluation as the approval event. This is appropriate for well-defined, low-risk automated workflows where a security team has pre-vetted the mission type for specific client identities.

Pre-provisioned mission types (standing mission authorizations): a security team or administrator registers approved mission types for specific service clients at provisioning time, analogous to client registration for OAuth scopes. At runtime, a service client activates a Mission of a pre-approved type by calling POST /missions/activate with the following request body:

1
2
3
4

{
  "mission_type": "urn:example.com:mission:nightly-reconciliation",
  "client_id": "reconciliation-service"
}

The endpoint requires a client credentials access token with scope mission:activate, issued to the requesting client_id. The AS validates that the mission_type is in the client’s mission_types registration with approval_mode: pre_provisioned and activates the Mission immediately. The response is HTTP 201 Created with the same body format as an approved proposal response, including mission_ref and mission_uri.

No runtime proposal or approval cycle is required. The pre-provisioned type defines the compiled authority region, delegation bounds, lifecycle constraints, and business event terminal conditions that apply to every instance of that mission type for that client. The AS MUST record the activation as an audit event (mission.created) with the registration record as the authorization evidence.

Lifecycle governance applies identically to headless missions. Business event termination, suspension, delegation bounds, and the audit trail all apply. The only difference from interactive missions is that initial activation is delegated to policy evaluation or pre-registration rather than a user consent flow.

A service client that has not been registered for a mission type cannot request one regardless of its client credentials. The registration boundary for headless clients is the same provisioning-time authority check that client registration provides for interactive clients.

Mission Authoring and Policy Authoring

One thing this architecture needs to make clearer is the difference between mission authoring and policy authoring.

Mission authoring is about describing a proposed unit of authority for a specific Mission instance:

• what the agent is trying to do
• on whose behalf it is acting
• what authority region appears necessary
• what parameters and time bounds apply

Policy authoring is about defining the standing rules that govern whether a proposed Mission is acceptable:

• which mission templates are allowed
• which authority regions, selectors, and operation groups are valid for a purpose
• when step-up or admin approval is required
• how delegation depth is bounded
• what environmental conditions change the decision

In other words:

• a Mission is an instance
• policy is what decides whether the instance is allowed, and in what form

That distinction matters operationally. It means an enterprise can let application teams define mission templates and Mission parameters without also giving them the ability to redefine global authorization policy.

Prompting as a Policy Authoring Front-End

One practical question for enterprises is whether prompting and intent systems can help close the policy-authoring gap.

The answer is yes, but only if they are treated as an authoring front-end rather than as the governance authority.

Prompting and intent are useful for:

• drafting Mission templates from business-language descriptions
• proposing operation groups, selectors, and constraint candidates
• translating messy enterprise process language into structured Mission vocabulary
• helping platform and security teams bootstrap a first policy model in domains where raw resource/action inventories are too complex to author directly

A useful mental model is:

• prompts and intent act as a semantic compiler front-end
• Mission templates and authority models are the compiled artifacts
• policy review and approval remain the governance checkpoint

In enterprise terms, that means a team might start with a policy prompt such as:

Sales assistants may prepare renewal packages for accounts owned by their team, only during active renewal stages, only in EU-hosted systems, and only for the current quarter.

The system can then generate a draft template containing:

• a purpose class
• operation groups
• resource selector families
• relationship predicates
• process-state predicates
• compliance constraints
• lifecycle defaults

That draft still needs human and policy-system review before it becomes an approved Mission template or organization policy binding.

This distinction matters because prompting can make policy authoring more legible, but it does not make policy governance optional.

The practical enterprise pattern is:

1. prompting and intent generate candidate templates or authority-model fragments
2. security and platform teams review and normalize them
3. approved templates become reusable Mission authoring inputs
4. runtime prompts only instantiate within those approved templates and authority envelopes

That is how prompting can help solve the enterprise policy-authoring gap without letting runtime language generation silently become the authorization system.

Mission Templates, Profiles, and Authoring Boundaries

In practice, large deployments will need more than raw per-request proposal JSON. They will likely need:

• reusable mission templates
• purpose catalogs
• operation groups
• resource-type definitions
• approval profiles
• organization-level policy bindings

In practice, at least three authoring layers are needed:

• runtime mission proposals created by clients or agents
• mission templates managed by platform or application teams
• authorization policy managed by security or governance teams

That separation gives a path to scale. Without it, every Mission becomes a bespoke authority object and policy quickly becomes unmanageable.

Beyond Allowlists: Constraint-Driven Mission Authoring

One of the biggest open issues in this architecture is that explicit allowlists do not scale far enough for real deployments.

It is easy to model a Mission as:

• allowed resource regions
• allowed operation groups
• max duration
• max delegation depth

That is useful, but it is not enough. Real authorization decisions often depend on constraints such as:

• jurisdiction or data residency
• compliance regime
• business process stage
• relationship to the subject or record
• organizational role
• customer or tenant boundary
• risk posture
• time, location, or execution environment

In many cases, those constraints are more important than a literal allowlist of resource names. A scheduling assistant may be allowed to create events, but not for executive calendars, not for regulated accounts, not outside a region, and not outside an approved business process.

That suggests the Mission model needs to support constraint-driven authority, not just explicit allowlists.

Missions as Guardrails for Open-World Agents

This is where Missions become more than a label. For open-world agents, the problem is not just “what exact API calls are pre-approved?” It is “what bounded space is the agent allowed to explore while still remaining safe?”

Mission-Bound OAuth can help by making the Mission the guardrail object for open-world execution:

• the agent may discover tools dynamically
• the agent may discover new candidate resources at runtime
• the agent may plan adaptively
• but every derivation still has to stay inside Mission constraints

The Mission does not need to enumerate every future action up front. Instead, it defines a bounded authority region within which planning and execution are allowed to adapt. Progressive expansion provides the escape valve for genuinely novel requirements that appear at runtime.

Why This Matters for FGA

Fine-grained authorization (FGA) has often been hard to apply to agent missions not because FGA models are weak, but because the mapping problem is too large:

• too many resources
• too many operations
• too much runtime ambiguity
• too little structure around agent intent

Missions can help unblock that by introducing a bounded intermediate layer between open-ended intent and concrete policy evaluation.

Instead of asking policy systems to solve arbitrary agent behavior directly, the system can:

1. interpret intent into a Mission Proposal
2. constrain it through templates, policy, and approval
3. compile it into an evaluable authority region
4. use FGA, AuthZEN, or policy engines to answer specific runtime questions inside that region

That makes fine-grained authorization more tractable for open-world agents because the Mission narrows the search space and carries the governing context forward.

Deployment Pattern Examples

The easiest way to understand the FGA and policy gap is to look at a few existing deployment patterns and ask what the Mission contributes in each one.

Pattern 1: Gateway Enforcement with FGA Behind It

Example: a procurement assistant can create or update vendor onboarding records for vendors in procurement cycle P-4421.

Without Missions:

• OAuth gets the agent a token for the procurement APIs
• FGA can answer object-level questions such as “may this team update vendor V-8821?”
• but nothing cleanly carries the approved purpose, procurement-cycle boundary, jurisdiction limits, or terminal conditions across the run

With Missions:

• the Mission bounds the authority region to vendor-onboarding actions in procurement cycle P-4421
• the gateway uses the projected Mission reference to fetch or cache Mission context
• the gateway asks the PDP or FGA layer whether the requested vendor record is inside the approved selectors and relationships
• when the procurement cycle closes, a business event terminates the Mission and the gateway stops forwarding further writes

What the Mission adds is not another object-level policy decision. It adds the bounded authority context that tells the gateway and FGA system which object-level questions are even legitimate to ask.

Pattern 2: Resource Server with Local Policy

Example: a CRM API already has local authorization logic and ownership checks, but now an agent is asked to “prepare renewal notes for accounts my team owns this quarter.”

Without Missions:

• the RS sees a broadly scoped token such as crm.write
• the RS can apply its normal local policy
• but it has no standard way to know whether this write is part of the approved renewal mission, whether the mission is still active, or whether the write falls inside the approved business process and time bounds

With Missions:

• the token carries a projected Mission reference
• the RS either consumes Mission-derived claims or calls the Mission introspection profile
• local policy continues to decide object-level access, but now it can combine that with Mission state, Mission purpose, and Mission constraints
• the RS can deny writes when the Mission is suspended, expired, or outside the approved renewal process even if ordinary OAuth scope would otherwise allow the call

What the Mission adds is a portable governance layer above existing RS-local authorization logic.

Pattern 3: FGA as the Runtime Decision Engine

Example: a support assistant is asked to update tickets related to incident INC-4421.

Without Missions:

• FGA can model relationships between users, teams, incidents, and tickets
• but the agent may discover relevant tickets, notes, and linked records dynamically at runtime
• the policy problem becomes open-ended because the system has no approved authority envelope for what counts as “part of this incident mission”

With Missions:

• the Mission expresses the approved authority envelope:
  • ticket and note resource types
  • incident-linked selectors
  • allowed operation groups such as ticket.update and note.append
  • process-state predicates such as “incident still active”
• FGA answers the narrower runtime questions:
  • is ticket T-5512 linked to incident INC-4421?
  • is the current team allowed to update it?
  • is the requested action inside the approved operation family?

What the Mission adds is the intermediate layer that makes open-world FGA queries tractable for agents rather than arbitrary.

Pattern 4: Mixed Estate with Mostly Legacy Resource Servers

Example: an enterprise has many legacy internal APIs behind a gateway and cannot make every backend Mission-aware.

Without Missions:

• teams either issue broad workflow tokens or build ad hoc gateway metadata
• revocation and termination are mostly tied to token lifetime
• audit correlation across the mission is inconsistent

With Missions:

• the AS becomes the authoritative Mission lifecycle control point
• token exchange gates downstream token issuance on Mission state
• the gateway can enforce Mission-aware checks for high-value operations
• legacy backends continue to validate normal tokens without understanding the full Mission model

What the Mission adds is a practical migration path: stronger authority governance at the AS and gateway without requiring every RS to adopt a new model on day one.

Across all four patterns, the recurring gap is the same:

• OAuth provides token transport and audience binding
• FGA, AuthZEN, and local policy provide object-level decisions
• the Mission provides the bounded delegated authority context that makes those decisions coherent over time

Deployment and Operational Model

Cross-Domain Mission Authority

This section is included for architectural completeness, but it should be treated as a later profile rather than a near-term core standardization target.

The single-domain and same-trust-boundary story is the part of the architecture that is ready to be pressure-tested first. Cross-domain Mission transport, trust establishment, projection rules, and revocation propagation are all materially less settled and should not block the core Mission-Bound OAuth story.

Agent missions do not stay within a single authorization domain. An agent may authenticate at an enterprise Identity Provider (IdP), execute steps against internal APIs, and then need to reach APIs governed by a partner organization or SaaS provider.

The cross-domain case has two distinct problems:

Same-IdP trust domain: multiple resource servers share a common Identity Provider. In this case, a projected Mission-bearing assertion from the originating trust domain can act as the trust anchor for downstream token exchange, with the IdP validating Mission scope before issuing assertions for each Resource AS. This is the Identity Assertion Authorization Grant (ID-JAG) pattern and it works well within an enterprise where all resource servers federate to the same IdP.

Different-IdP trust domain: the receiving AS has no trust relationship with the issuing AS. The architecture needs a portable Mission assertion that the receiving AS can validate independently.

For the cross-domain case, the Mission reference needs a portable form:

• a signed Mission assertion (analogous to how ID-JAG packages an authentication event for cross-domain use) carries the mission purpose, constraints, and subject identity in a verifiable artifact
• the receiving AS validates the assertion against the issuing AS’s published keys
• the receiving AS applies its own policy to determine whether the asserted mission scope is acceptable within its domain

The normative definition of this assertion format, filtering rules for which mission claims cross a trust boundary, and the federation trust mechanism connecting the two ASes are the open problems for the cross-domain profile. OpenID Federation is the natural trust infrastructure for the key discovery and trust chain validation. SSF/CAEP is the natural mechanism for propagating mission revocation across domains once the Mission terminates at the issuing AS.

The privacy concern applies here directly: subject identifiers in cross-domain Mission assertions may need pairwise forms, and mission semantics should be projected to only what the receiving domain needs for enforcement. A receiving AS should not receive the full compiled authority region from the issuing AS, only the subset relevant to the resources it governs.

Cross-Domain Mission Assertion: Candidate Claim Structure

A Mission assertion crossing a trust boundary is a signed JWT (JWS) with the following candidate claim set:

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

{
  "iss": "https://as.example.com",
  "sub": "user-123",
  "sub_profile": "user",
  "aud": "https://partner-as.example.org/token",
  "act": {
    "sub": "assistant-agent",
    "sub_profile": "ai_agent"
  },
  "delegation_chain": [
    { "sub": "assistant-agent", "sub_profile": "ai_agent" }
  ],
  "mission_ref": "mr_7M9Qx2",
  "purpose": "urn:example.com:mission:schedule-meeting",
  "mission_exp": 1773072000,
  "projected_authority": {
    "allowed_operations": ["calendar.schedule"],
    "constraints": { "region": "EU" }
  },
  "exp": 1773072300,
  "jti": "a8f3c91b-4d2e-4f7a-b5e6-9c0d1f2e3a4b"
}

Key projection rules:

• sub and sub_profile identify the user on whose behalf authority is asserted; pairwise subject identifiers SHOULD be used when crossing domains without an established federation agreement
• mission_ref is projected as-is or as a pairwise handle; the receiving AS maps it back to a locally-issued mission_ref for tokens it issues
• projected_authority is a filtered subset of the compiled authority region relevant to the receiving domain’s resources; the issuing AS MUST NOT include authority elements outside the receiving domain’s registered resource types
• mission_exp is the Mission’s expiry at the issuing AS; the receiving AS MUST issue tokens that do not outlive this expiry
• The assertion’s own exp SHOULD be short (e.g., 5 minutes) to limit replay; mission_exp governs the Mission’s actual authority window
• OpenID Federation is the trust infrastructure for key discovery and trust chain validation between the two ASes

Continuous Evaluation Checkpoint Model

Continuous evaluation does not mean a synchronous round-trip to the AS on every API call. That model does not scale at production volumes and creates a single point of failure when the AS is unavailable.

The recommended model is hybrid:

Synchronous Mission check before:

• token exchange for any new resource or delegation hop
• high-value or irreversible actions (defined by the Mission’s risk classification)
• any action that modifies authority scope or delegation state

Asynchronous signal-based check for:

• high-volume, low-risk, reversible operations where the Mission is assumed valid until a termination signal arrives

The AS pushes Mission state change events via the Shared Signals Framework (SSF) and Continuous Access Evaluation Protocol (CAEP). Enforcement points subscribe to these events and act on them. When a termination event fires, enforcement points block further execution at the next checkpoint.

Which action type falls into which category should be policy-defined at Mission approval time, not left to ad hoc runtime behavior. A Mission that does not specify its evaluation checkpoint policy has not fully specified its governance model.

The revocation lag window between a termination signal and its enforcement at all checkpoints must also be policy-defined. Tighter lag reduces exposure but increases availability dependency. That tradeoff should be explicit.

Business Event to Mission Termination

Business events are the terminal conditions that make the architecture real. The expired-mandate scenario (an agent still pulling sensitive data after its governing business event has closed) is not solved by better token expiry. It is solved by the procurement system publishing a “program closed” event that flows into the Mission layer and terminates the Mission independently of clock state.

The integration model:

1. At Mission approval, terminal conditions are declared: “this Mission terminates when event type procurement.program.closed is received for program PRG-4421”
2. Business systems publish state change events to an SSF event stream
3. A Mission evaluation service subscribes to that stream and evaluates incoming events against declared terminal conditions
4. When a match fires, the Mission transitions to completed or revoked and the AS stops issuing derivatives
5. A CAEP mission-terminated event propagates to subscribers so enforcement points can halt in-flight execution

For conditions that cannot be instrumented against machine-observable events, the Mission falls back to hard expiry. Even in the hard-expiry fallback, the Mission carries what tokens alone cannot: an authoritative mission record the rest of the security stack can query, a cascade revocation chain, and an audit trail attributing execution to a specific delegated purpose. As instrumentation improves, the condition model grows with it without requiring architectural changes.

Event source authentication: event sources that can trigger Mission termination are high-value attack targets. An adversary who can publish a fabricated terminal event for a known program identifier can terminate Missions they should not touch.

Event sources delivering terminal conditions MUST be pre-registered at the AS as part of Mission approval metadata. Registration includes:

• the event source identifier
• the event types the source is authorized to publish
• the SSF transmitter authentication credentials (as defined in SSF 1.0) used to authenticate the source’s event stream

The AS MUST validate that an incoming terminal event originates from a pre-registered, authenticated transmitter before transitioning a Mission. Unauthenticated terminal events MUST be discarded.

Replay protection: terminal events are high-value single-fire triggers. The AS MUST implement replay protection for terminal events:

• Each event MUST carry a unique event identifier (jti or equivalent) and a timestamp.
• The AS MUST maintain a short-lived record of processed event identifiers (at minimum, for the duration of the event stream’s configured delivery window).
• An event with a duplicate identifier or a timestamp outside the AS’s configured acceptance window MUST be discarded.
• Event timestamps MUST be monotonically non-decreasing within a single event stream; out-of-order events that predate the most recently processed event for the same program identifier MUST be rejected.

Transaction Token Integration

OAuth Transaction Tokens (Txn-Tokens, draft-ietf-oauth-transaction-tokens) are designed to propagate trusted workload identity and call context across microservice boundaries inside a single enterprise. They complement Mission-Bound OAuth by providing the in-network context propagation layer that mission-bearing access tokens are not designed for.

The architectural relationship:

• Mission-bearing access tokens govern delegated authority at the OAuth boundary: what the agent is authorized to do, under which Mission, on whose behalf. They cross trust boundaries and are validated by RSes using standard JWT validation.
• Txn-Tokens propagate workload context within a trusted service mesh: who called whom, with what initiating token, and for what transaction. They are typically scoped to a single enterprise network boundary.

A Txn-Token issued inside an enterprise may carry a mission_ref claim linking the in-flight transaction to its governing Mission. This allows internal services that do not receive the original mission-bearing access token to still have access to the Mission reference for audit, policy evaluation, or context propagation.

The integration model:

1. An external or orchestration-layer request arrives at the edge with a mission-bearing access token containing mission_ref
2. The edge service creates a Txn-Token for the internal call chain, carrying workload identity, the initiating token reference, and the mission_ref from the incoming access token
3. Internal microservices that receive only the Txn-Token can resolve Mission state via the AS introspection endpoint using the Mission introspection profile and the mission_ref the Txn-Token carries
4. Audit records from internal services carry mission_ref, linking all steps in the call chain to the governing Mission

This is the correct model for trusted-network deployments where not every internal service hop involves a full OAuth token exchange. The Txn-Token carries the Mission reference as context, not as authority. Authority for each internal service remains governed by its own policy decision, informed by the Mission context the Txn-Token provides.

The mission_ref claim in a Txn-Token should be treated as informational context, not as a delegated authority grant. The Txn-Token model does not replace Mission lifecycle enforcement: services that need to enforce Mission state must still check it via introspection, not by trusting the mission_ref claim alone.

Deployments MUST NOT silently downgrade from Mission-aware enforcement to token-only enforcement because an introspection or authority-model retrieval path is unavailable. Any fallback to weaker enforcement semantics must be an explicit deployment policy decision with documented risk, not an automatic runtime behavior.

Policy Integration

Mission-Bound OAuth is not trying to replace policy engines. Its role is to define mission authority semantics and how they integrate with OAuth.

Constraint evaluation may be delegated to a policy system such as the AuthZEN Authorization API. In that model:

• Mission-Bound OAuth defines the lifecycle and authority object
• AuthZEN evaluates whether a specific action on a specific resource is allowed under current policy

That separation matters because it keeps the architecture focused on authority semantics and processing points rather than on a single PDP technology.

Policy Conflict Precedence

IAM systems need a deterministic answer when multiple control sources disagree.

The precedence model should be:

1. issuer and tenant boundary checks
2. Mission lifecycle state
3. client registration and permitted Mission classes
4. hard policy denies
5. Mission Authority Model authority region
6. runtime relationship and environmental predicates
7. local RS or gateway policy narrowing

This means:

• if the Mission is revoked, everything stops regardless of lower-layer policy
• if registration does not permit the Mission class, approval cannot create it
• if hard policy denies a resource or action, user approval cannot override it
• if the Mission Authority Model allows a region but runtime predicates fail, the request is denied without changing the Mission
• RS and gateway policy may narrow or block execution further, but should not widen authority beyond the Mission

How AuthZEN Fits

OpenID AuthZEN fits naturally into this architecture as the decision interface between policy enforcement points and policy decision points. It does not replace Mission-Bound OAuth, and Mission-Bound OAuth does not replace it.

The clean division is:

• Mission-Bound OAuth defines the Mission authority object, lifecycle, delegation semantics, and OAuth processing checkpoints
• AuthZEN provides a way for an AS, gateway, or resource server acting as a PEP to ask whether a specific action on a specific resource is allowed under current policy

In that model:

• the AS is often a PEP at issuance and token exchange time
• a gateway may be a PEP at request time
• an RS may also be a PEP when it has sufficient context
• the PDP evaluates mission-derived context, actor context, resource context, and environmental context

That means the architecture can support both:

• embedded decisioning, where the AS evaluates policy internally
• externalized decisioning, where the AS or gateway calls an AuthZEN-compatible PDP

In more advanced deployments, the Mission may need to contribute not just literal attributes but a compiled set of constraints, selectors, and relationship predicates that the PDP can evaluate at runtime. The compiled authority example from the Authority Compilation Boundary section is the expected input to an AuthZEN-style query.

Mission Evaluation Input Model

To make the open-world model credible, the architecture needs a clearer statement of what a Mission-aware runtime decision consumes.

A Mission-aware decision input should include at least:

• actor context: client, user, delegated actor, authentication strength
• mission context: mission identifier, state, purpose, expiry, delegation state
• authority context: compiled selectors, operation groups, relationship predicates, compliance constraints
• resource context: target resource type, instance, container, attributes
• action context: requested operation, operation group, execution mode
• environment context: time, region, network, tenant, process stage

A sketch:

 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

{
  "actor": {
    "client_id": "assistant-agent",
    "subject": "user-123",
    "delegation_depth": 0
  },
  "mission": {
    "mission_ref": "mr_7M9Qx2",
    "state": "active",
    "purpose": "urn:example.com:mission:schedule-meeting",
    "exp": 1773075600
  },
  "authority": {
    "operation_groups": [
      "calendar.schedule",
      "crm.record_activity"
    ],
    "selectors": [
      "calendar:user-manageable",
      "crm:accounts-owned-by-requesting-team"
    ],
    "constraints": {
      "region": "EU",
      "business_process": "meeting-followup"
    }
  },
  "resource": {
    "type": "crm.account_note",
    "account_id": "acct_123"
  },
  "action": {
    "name": "create",
    "group": "crm.record_activity"
  },
  "environment": {
    "region": "EU",
    "workflow_stage": "post-meeting"
  }
}

Explainability and Administrative Visibility

IAM governance is not complete if a Mission can be denied, attenuated, or suspended without intelligible reasons.

At minimum, the model should support two explanation views:

• machine-readable reasons for clients and agents
• human-readable reasons for administrators, approvers, and auditors

Machine-readable reasons should identify:

• which Mission was evaluated
• which checkpoint failed
• whether the failure is temporary or terminal
• which policy or predicate class caused the denial

Human-readable reasons should identify:

• the attempted Mission action
• the governing policy or lifecycle rule
• who or what caused the state change
• what remediation path exists, if any

This is particularly important for:

• mission proposal denial
• mission attenuation
• mission suspension
• token exchange denial under mission_authority_exceeded
• cross-domain assertion rejection

How MCP Fits

The document also needs to say how MCP fits, because many agent deployments now use it as the tool and context plane.

MCP is not an authority protocol. It helps agents discover tools, exchange structured context, and invoke capabilities. In this architecture, MCP sits above Mission-Bound OAuth.

The clean relationship is:

• MCP exposes tools, schemas, and invocation surfaces to the agent
• the agent uses MCP to understand what tools exist and what inputs they need
• Mission-Bound OAuth determines whether the agent is actually authorized to use those tools in the current Mission
• OAuth tokens and token exchange provide the concrete access artifacts for the underlying APIs

MCP can be relevant in at least three places:

• tool discovery: which tools and operations are even available to plan against
• proposal construction: mapping tool schemas and operation metadata into Mission Proposal candidates
• runtime enforcement hints: attaching operation metadata that helps the AS, gateway, or PDP map a tool call to resource/action policy

The architectural boundary should be explicit: MCP is the tool-interaction layer; Mission-Bound OAuth is the delegated authority layer.

Discovery and Metadata

Any eventual spec work will need discovery metadata so clients can determine whether an AS supports Mission-Bound OAuth.

Likely areas for discovery include:

• mission proposal endpoint support
• approval endpoint support
• supported Mission reference mechanisms
• token exchange behavior
• delegation capabilities
• policy integration hints
• mission introspection endpoint

For the umbrella architecture, it is useful to distinguish:

• OAuth AS metadata for core protocol support
• mission management metadata for proposal, approval, and template features
• resource metadata for mission-aware enforcement capabilities

Security Considerations

Threat Model

The threat model is aimed at reducing:

• ghost execution: agents acting without approved Mission authority
• privilege creep: Missions accumulating more authority than was approved
• uncontrolled delegation: one actor silently widening a chain of authority
• token replay: stolen artifacts being reused outside intended conditions

Mission-Bound OAuth does not eliminate normal OAuth threats. It adds controls for mission continuity and bounded authority on top of the existing security baseline.

Security Properties to Preserve

For the proposal to be credible, it should preserve the following:

• access tokens remain audience-bound
• mission state is authoritative at the AS
• downstream issuance is denied when mission state is invalid
• delegation is explicit and bounded, represented via act (current actor) and delegation_chain (full ordered history)
• approval and execution remain separate trust steps
• policy decisions are explainable and auditable
• mission audit events are signed and independently verifiable

AS as Critical Security Infrastructure

The AS holds authoritative Mission state and Mission Authority Model artifacts for every active agent execution it governs. Compromise of the AS or its Mission store is compromise of execution governance across every Mission it controls. Hardening requirements mirror those of authorization servers generally. Mission Authority Model artifacts must be signed so enforcement points can validate them without a live callback. Fail-closed behavior is required: an unavailable AS halts token exchange and Mission introspection rather than defaulting to open. Every Mission issuance, amendment, and revocation is a first-class security event with a full audit record.

Sender Constraining Requirements

Sender-constraining using DPoP (RFC 9449) or mTLS (RFC 8705) is a baseline expectation, not optional hardening. A deployment that accepts unsigned bearer mission-bearing tokens at token exchange is accepting meaningful replay risk against a durable authority chain. At least one deployment profile should treat sender-constraining as a core assumption that applies to both primary mission-bound access tokens and any tokens produced by mission-scoped exchange.

Display Object Validation

Template-driven display validation is a security requirement, not a UX convenience. An orchestration layer that supplies a display object claiming a benign action while the compiled authority permits something broader has created a social engineering attack surface that defeats the human-in-the-loop guarantee. The AS must validate or regenerate the display object from the compiled authority before presenting it to an approver. A display object that cannot be verified against the compiled authority region must be rejected or overwritten by the AS.

Concurrency and Atomicity Requirements

Mission-Bound OAuth places the AS as the authoritative state owner for Mission lifecycle, delegation depth, and compiled authority. Under concurrent load, several AS operations must be atomic to preserve correctness guarantees.

Mission lifecycle state transitions (Issue 7.2): the AS MUST evaluate Mission lifecycle state and issue a token within the same atomic operation. A Mission suspension event and a concurrent token exchange request MUST be serialized. The AS MUST NOT issue a token for a Mission that is in suspended, revoked, completed, or expired state at the moment of issuance, regardless of the order in which the suspension and exchange requests arrived.

Delegation depth enforcement (Issue 7.3): current_depth increments MUST be performed atomically using a compare-and-increment operation. The AS MUST reject any token exchange that would result in current_depth >= max_depth at the time the increment is committed, even if the exchange request was received when current_depth appeared valid. Concurrent delegation exchanges MUST be serialized per Mission.

Concurrent expansion proposals (Issue 7.1): expansion proposals submitted concurrently against the same parent Mission MUST be serialized using the Mission’s version counter. The AS increments the version counter on each accepted expansion. A concurrent expansion proposal that was evaluated against a prior version MUST be rejected with a concurrency error, requiring the submitter to re-evaluate against the updated Mission. This prevents two independently-valid expansions from collectively exceeding the authority envelope.

CAEP-triggered Mission suspension (Issue 7.4): when the AS receives a CAEP session_revoked event for a user session, it must suspend all active Missions for that session. This suspension MUST be treated as a lifecycle state transition and MUST be serialized with any concurrent token exchange requests against the affected Missions. The AS MUST NOT issue a token for a Mission that is simultaneously being suspended by an incoming CAEP event. The implementation model is the same as for lifecycle transitions: the CAEP handler acquires the same per-Mission lock before transitioning state, and any concurrent exchange request that arrives during suspension processing receives mission_suspended.

Implementation guidance: optimistic locking with a version counter on the Mission record is the recommended implementation pattern. The AS should expose the Mission version in GET /missions/{mission_ref} responses so clients can detect version changes between reads and submissions.

Privacy Considerations

Privacy and Linkability

Mission-Bound OAuth creates a risk of durable mission correlation across APIs and domains if Mission references and attributes are exposed too broadly.

The privacy model should therefore assume:

• the projected Mission reference is opaque and unguessable
• Mission-derived claims are minimized per audience
• resource servers receive only the Mission data needed for enforcement
• introspection and token exchange avoid exposing Mission semantics unnecessarily
• cross-resource correlation is limited where possible by deployment policy or identifier strategy
• subject identifiers in cross-domain Mission assertions should use pairwise forms where appropriate

This has to be explicit, otherwise the design looks like a powerful coordination primitive but also a powerful tracking primitive.

Per-audience Mission references address the correlation concern more directly. A single visible Mission handle across multiple resource servers creates a cross-service tracking handle even when the identifier reveals no Mission semantics. RS-A and RS-B can correlate all workflow traffic using the shared handle without any explicit data-sharing agreement.

Three deployment approaches are available, each with different tradeoffs:

1. Single handle with audience-isolation policy: use one projected Mission reference but control which resource servers receive it in their access tokens via audience-specific claim filtering at the AS. Resource servers that do not need cross-Mission correlation receive tokens without the Mission reference claim.

2. Per-audience Mission references: the AS maintains one internal Mission record and maps it to per-audience handles in issued tokens, analogous to pairwise subject identifiers in OpenID Connect. Each resource server receives a different handle that the AS maps back to the internal Mission for introspection and revocation. Cross-RS correlation is possible only through the AS, not by comparing token claims directly.

3. Claim-free enforcement via introspection: the Mission reference claim is omitted from audience-specific access tokens entirely. Resource servers that need Mission state use the introspection profile with a session-scoped reference that does not expose the Mission correlation handle in tokens.

Deployments that require cross-RS audit correlation (compliance, regulated workflows) may use option 1 or 2. Deployments where cross-RS linkability is a privacy concern should prefer option 2 or 3. The architecture does not mandate a single approach, but a deployment profile should specify which model it uses and what the privacy implications are.

Retention and Governance

Enterprise IAM deployments will also care about retention classes for Mission artifacts.

Retention will likely differ for:

• Mission Proposals, including denied proposals
• Approved Missions
• Mission Authority Model representations
• Mission audit events
• cross-domain Mission assertions
• introspection records or access logs

A sensible default model is:

• Mission Proposals: retained for governance and forensic review, especially when denied or attenuated
• Approved Missions: retained for the duration of their lifecycle plus policy-defined audit retention
• Mission Authority Model representations: retained at least as long as needed for replayable audit and explainability
• Mission assertions: retained according to federation and compliance policy, usually shorter than the Mission itself

The main architectural point is that Mission governance creates artifacts with different sensitivity and retention needs. Treating them all as generic auth logs would be an enterprise design mistake.

Practical Limits and Realistic Claim

This architecture is intentionally ambitious. It is also easy to be too optimistic about where the hard parts really are. The protocol surfaces are only one part of the problem. Real deployments fail for data, governance, operational, and organizational reasons long before they fail for lack of a token claim.

Policy Authoring May Be Harder Than the Protocol

The architecture assumes enterprises can define:

• Mission templates
• operation groups
• authority envelopes
• relationship predicates
• approval policies
• business event termination conditions

In practice, many organizations struggle to maintain even scope inventories and role mappings. Mission-Bound OAuth will fail if policy authoring becomes too complex for platform teams to manage coherently.

Relationship and Business Data May Be Wrong

Much of the promise of Mission-bound enforcement depends on external data being accurate:

• who owns an account
• which calendars a user can manage
• what tenant a record belongs to
• which process stage a task is in
• whether a compliance boundary applies

If those sources are stale or inconsistent, the Mission will be evaluated incorrectly. The architecture should assume imperfect upstream systems and treat some predicates as high-assurance only when backed by reliable sources of record.

Open-World Envelopes Are Hard to Tune

The bounded authority envelope is the right model, but tuning it is difficult.

• if the envelope is too narrow, agents fail constantly and users are pushed into repeated re-approval
• if the envelope is too broad, the system recreates over-delegation with more structure but not more safety

The practical challenge is not just defining the envelope format. It is defining envelopes that are operationally usable and still meaningfully bounded.

Approval UX May Collapse into Rubber Stamping

If Mission approvals are too frequent, too technical, or too hard to understand, users and administrators will approve them mechanically. At that point, the architecture still has lifecycle and audit value, but the human-governance story becomes much weaker than the document implies.

Approval is only a security control if:

• the approver understands what is being approved
• the approval frequency is tolerable
• the attenuation path is usable in practice

The Authorization Server May Become a Bottleneck

Mission-Bound OAuth places more responsibility on the AS:

• Mission storage
• lifecycle transitions
• approval integration
• token exchange enforcement
• compiled authority evaluation or policy calls
• introspection

That increases both scaling pressure and blast radius. If the AS or its dependent policy systems become slow or unavailable, mission execution may stall. A practical deployment needs a clear resilience model, not just a correctness model.

Cross-Domain Adoption Will Likely Be Slow

The single-domain and same-trust-domain cases are the most realistic near-term targets. Cross-domain Mission assertions require:

• trust establishment
• constrained claim projection
• policy compatibility between issuers
• revocation propagation
• privacy-safe subject handling

That is possible, but not likely to arrive quickly across a broad SaaS ecosystem. The architecture should be practical about this and avoid over-claiming cross-domain near-term interoperability.

Resource and Operation Normalization May Never Fully Converge

The document assumes useful structure for:

• resource types
• selectors
• operation groups
• relationship predicates

That structure is necessary, but real ecosystems are heterogeneous. Different vendors will name and group actions differently. The practical goal is not perfect semantic portability. It is enough structure to make Mission evaluation tractable within a deployment and partially interoperable across similar deployments.

Agents Can Still Route Around Governance

Mission governance only helps if execution actually goes through Mission-aware issuance and exchange paths. In the real world, agents and automation systems often have:

• legacy service credentials
• direct backend access paths
• side-channel APIs
• cached tokens or unmanaged connectors

If those paths remain, an agent may still act outside Mission governance. This architecture is strongest when paired with credential minimization and a policy that delegated machine access must flow through Mission-aware infrastructure.

Revocation and Termination Are Not Instant

The architecture improves lifecycle control, but it does not eliminate lag:

• already-issued short-lived access tokens may remain usable until expiry
• event propagation may be delayed
• gateways may not all receive updates at the same time
• introspection may be cached or temporarily unavailable

This should be described as a bounded-exposure model, not as perfect real-time stop semantics.

Compilation May Become Proprietary

One of the strongest ideas in the document is the Mission Authority Model as the boundary between open-ended intent and enforceable authority. That is also where vendor-specific divergence is most likely.

If every implementation has a radically different compiled authority model, interoperability may collapse at the most important architectural layer. The practical response is to standardize interfaces and processing checkpoints first, and be cautious about over-standardizing the compiled representation too early.

Practical Claim

The realistic claim for Mission-Bound OAuth is not:

this architecture solves open-world agent authorization.

The realistic claim is:

this architecture gives IAM systems a governed authority object that makes bounded delegation, lifecycle control, auditability, and policy-backed token derivation materially better than token-only OAuth for agent systems.

That is strong enough to matter, and narrow enough to be credible.

Staged Adoption Path

The pragmatism intent of this work is right, but the adoption path needs to be concrete. A staged deployment model avoids the “all or nothing” objection and shows how existing infrastructure can participate without a full replacement.

An existing Okta, Auth0, or Azure AD deployment can approximate Stage 1 today with custom authorization server policy, one-Mission-per-runtime-token discipline, and a lookup table or token-bound Mission reference. That approximation does not deliver the full protocol described earlier in this RFC: it is a deployment pattern that captures the core AS-side lifecycle and exchange checks before standardized proposal APIs, PAR-based Mission authorization requests, or Mission introspection are introduced.

Stage 1 should be understood for what it is: primarily AS-side Mission governance at issuance and exchange time, not full downstream Mission-aware object-level authorization at every resource server.

This is the entry point the architecture should lead with for any team evaluating adoption.

Each stage delivers independent value. A team that deploys only Stage 1 gets the core lifecycle and revocation property. Each subsequent stage adds governance depth. This is the pragmatic path that meets the ecosystem where it is today.

Open Questions

Rather than an undifferentiated list, the open questions now fall into a few decision clusters. The priority order here reflects what seems most likely to determine whether this architecture becomes practical and spec-worthy.

Priority 1: Core Viability

These questions decide whether the core Mission-Bound OAuth idea is coherent enough to standardize at all.

• what is the minimum standard Mission schema, and what remains deployment-specific
• should Mission authority be defined as a strict constraint layered on top of scope authority
• what is the right projected Mission reference model through RFC 8693 token exchange, especially when the subject token is already bound to one Mission
• what normative error model is needed for Mission lifecycle failures at token exchange
• whether the first serious profile should require sender-constraining rather than treat it as a strong baseline expectation
• how Mission-Bound OAuth should relate to downstream capability attenuation and chaining mechanisms, such as Biscuit-style restriction-bearing tokens, without taking on that whole problem in the core Mission model
• whether mission_ref and delegation_chain should be formally proposed for registration in the IANA JSON Web Token Claims registry (RFC 7519 Section 10.1), and whether a standalone Internet-Draft is needed for the delegation_chain claim given its proposed deviation from RFC 8693 act nesting semantics

Priority 2: Open-World Practicality

These questions decide whether the architecture actually helps with adaptive agents rather than rebranding closed-world allowlists.

• how Missions should express constraint-driven authority beyond explicit allowlists
• whether a compiled graph or DAG form should exist between mission authoring and runtime enforcement
• how relationship-, process-, and jurisdiction-based constraints should be represented
• how bounded authority envelopes should be defined and tuned in practice
• whether MCP-derived tool metadata should have a standard mapping into Mission proposals

Priority 3: Governance and IAM Model

These questions decide whether the architecture works as a governance system rather than only a protocol sketch.

• how mission authoring, template authoring, and policy authoring should be separated
• whether Mission approval belongs inside the OAuth protocol family or in an adjacent management profile
• how headless and service-to-service Missions should be provisioned and activated
• whether the authorized caller model for POST /mission-proposals is the right trust boundary
• what is the right normative behavior when CAEP or session-level revocation intersects active Missions
• whether Mission amendment (narrowing scope, reducing delegation depth, shortening expiry on an active Mission) should be a first-class operation via a dedicated endpoint, or whether revocation and re-issuance is the only supported path for structural changes
• how approval evidence should be represented if approval is delegated to an external workflow or ticketing system

Priority 4: Enforcement and Resource Server Semantics

These questions decide how much of the model resource servers and gateways need to understand.

• what parts of Mission state should be exposed to resource servers
• how the Mission introspection profile should surface lifecycle and compiled authority
• whether the projected Mission reference should be single-handle, pairwise per-audience, or omitted from audience-specific access tokens
• what the baseline RS behavior should be when token scope is broader than the Mission’s compiled authority region
• whether full Mission Authority Model retrieval should remain purely a high-assurance profile or eventually become a more general interoperability mechanism
• how deployments should prevent silent downgrade from Mission-aware enforcement to token-only enforcement during outages

Priority 5: Cross-Domain and Standardization Boundary

These questions matter, but they should not block the more local single-domain story.

• how cross-domain Mission assertions should be structured and what claim set should cross a trust boundary
• whether cross-domain assertions should preserve source Mission references or map to local identifiers
• whether the staged adoption model changes what belongs in the core spec versus deployment profiles
• which parts belong in a core OAuth draft versus companion specs
• how Mission-Bound OAuth relates to GNAP and whether extending OAuth is still the right strategic choice

Lower-Level Naming and Registration Questions

These matter for a draft, but they should be downstream of the architectural decisions above.

• how discovery metadata should be named and registered
• whether the authorization_details type identifier should be "mission"
• whether the projected Mission reference should be a registered JWT claim and whether it should be string or structured
• whether mission templates should be standardized or remain deployment-local
• how much prompt-processing behavior should be specified versus treated as implementation guidance

FAQ

Is this just RAR with more state?

No. RAR structures authorization input for a token request. Mission-Bound OAuth adds a durable, lifecycle-governed authority object that survives across token issuance, exchange, suspension, revocation, and business-event termination.

Why isn’t a refresh token enough?

A refresh token extends credential continuity. It does not represent a governed authority object with purpose, lifecycle, terminal conditions, approval evidence, and bounded delegation semantics. Mission-Bound OAuth is trying to govern delegated authority, not just prolong token issuance.

Why not just use GNAP?

GNAP is the cleaner architecture for new systems. The practical bet here is that many enterprises will try to solve this inside existing OAuth infrastructure first. Mission-Bound OAuth exists to test whether that incremental path is viable.

Why isn’t AuthZEN or FGA enough by itself?

AuthZEN and FGA answer runtime authorization questions. They do not by themselves define the durable authority object that says why this execution exists, how long it should continue, when it must terminate, or what bounded envelope it may explore. The Mission is the missing middle layer between open-ended agent intent and runtime policy decisions.

What about Biscuit-style attenuation and chained restrictions?

That is a real adjacent gap, but it is not the same layer. Mission-Bound OAuth governs whether a delegated Mission should exist, continue, expand, suspend, or terminate. Biscuit-style capability tokens are more about downstream cryptographic attenuation, offline verification, and chained restriction accumulation after authority has already been granted.

The important relationship is that any downstream attenuation or chaining mechanism should remain bounded by the Mission and its authority model. Mission-Bound OAuth does not need to solve that whole problem in the first core spec, but it should leave room for separate profiles or companion work that bind attenuation-capable artifacts to mission_ref.

Isn’t this too much responsibility for the Authorization Server?

Possibly. That is a real operational risk. The architecture is practical only if there is a staged adoption path, selective externalization of policy, and a resilience model that avoids synchronous dependency on the AS for every request.

Does every deployment need Mission proposals and approval APIs?

No. The architecture includes them because they matter for the end-to-end story, but the staged adoption path explicitly allows simpler deployments to start with AS-side Mission records, provisioning-time Mission types, or admin-configured Mission activation before adopting a full management plane.

Aren’t you just inventing another policy language?

No. The architecture assumes policy languages and PDPs already exist. The Mission is the governed authority object and compiled context that makes those policy systems usable for delegated agent execution.

Is the Mission Authority Model a new universal policy language?

No. The current design is to standardize the slots, checkpoints, and protocol boundaries, not a universal selector or policy syntax. Different deployments may use different underlying policy engines and compilation strategies.

Does this require every resource server to become Mission-aware?

No. A baseline deployment can keep Mission enforcement mostly at the AS and token-exchange layer. Mission-aware gateways and RSes add stronger runtime guarantees, but they are not the only deployment model.

Why keep both mission_id and mission_ref?

Because they serve different trust boundaries. mission_id is the AS-internal authoritative identifier. mission_ref is the projected protocol-facing handle used in tokens, token exchange, introspection, audit, and cross-domain assertions. Separating them improves privacy, tenant isolation, and future cross-domain flexibility.

Why is delegation_chain needed if OAuth already has act?

act identifies the current acting party. It does not give a full ordered multi-hop history in a form that is easy to audit or evaluate across longer agent chains. delegation_chain is proposed because Mission-bound delegation is one of the main use cases here, but whether it belongs in the first core spec is still a legitimate question.

Why not let the AS infer the Mission from the requested resource?

Because implicit Mission selection is a confused-deputy risk. The safer model is that the subject token is already bound to one Mission, and the AS uses that binding or verifies an explicitly echoed mission_ref. Resource-based guessing would create ambiguity and make cross-mission mixups easier to miss.

Does this require progressive Mission expansion?

No. Expansion is now treated as an optional later capability. A simpler deployment can adopt the stricter rule: if additional authority is needed, create a new Mission.

Does this solve open-world agent authorization?

Not completely. The realistic claim is narrower: it provides a bounded authority object and a governance model that makes open-world agent execution more controllable than token-only OAuth.

Is mission_ref itself sensitive?

Yes, at least as operational metadata. It is not an authority credential by itself, but it is still a durable correlation handle. That is why the document treats projection, pairwise handles, tenant-scoping, and controlled exposure as security and privacy concerns rather than implementation details.

What happens when Mission-aware enforcement is unavailable?

The architecture prefers fail-closed behavior for Mission introspection and authority-model retrieval. It should not silently degrade into weaker token-only enforcement unless a deployment explicitly chooses that risk as policy.

Is cross-domain federation realistic in the near term?

Only in limited settings. Same-trust-domain and single-enterprise deployments are the realistic starting point. Cross-domain Mission assertions are likely a later profile, not the first thing the ecosystem will adopt.

Is this trying to turn OAuth into a workflow engine?

No. The goal is narrower: add a governed Mission object that can bind delegated authority to purpose, lifecycle, delegation bounds, and termination semantics. The workflow or agent runtime still lives elsewhere.

IANA Considerations

This section documents the IANA registration candidates proposed by Mission-Bound OAuth. All entries are provisional and subject to change based on community feedback.

OAuth Extensions Error Registry (RFC 6749 Section 11.4)

The following error codes are candidates for registration in the OAuth Extensions Error Registry:

JSON Web Token Claims Registry (RFC 7519 Section 10.1)

Claim name: mission_ref Claim description: Projected Mission reference handle. Identifies the Mission governing the token’s authority derivation. Opaque string; value is audience-specific in privacy-sensitive deployments. Change controller: IETF Specification document: draft-mcguinness-oauth-mission-bound-authorization

Claim name: delegation_chain Claim description: Ordered array of actor identity objects representing the full delegation chain. Index 0 is the current immediate delegate (matching act.sub); the last index is the originating delegating actor (the first principal to receive delegated authority for the subject). The array grows at the tail as delegation chains extend. Each element contains at minimum sub and optionally sub_profile and iss. Change controller: IETF Specification document: draft-mcguinness-oauth-mission-bound-authorization

Authorization Details Types Registry (RFC 9396 Section 10)

Type: mission Description: References an approved Mission governing the delegated authority for this authorization or token exchange request. Required fields: type (string, value "mission"), mission_ref (string, opaque projected Mission reference) Optional fields: none in the core type; deployment profiles may define extensions Change controller: IETF Specification document: draft-mcguinness-oauth-mission-bound-authorization

OAuth Parameters Registry (RFC 6749 Section 11.2)

No new standalone OAuth token endpoint parameters are proposed. Mission reference is carried via authorization_details.

OAuth Dynamic Client Registration Metadata Registry (RFC 7591 Section 3.2)

Authorization Server Metadata Registry (RFC 8414)

Mission introspection reuses the existing RFC 7662 introspection endpoint (discovered via the standard introspection_endpoint AS metadata field) with token_type_hint=mission_ref. No new introspection endpoint URI is needed.

Appendix: Expected Draft Structure

If this architecture survives feedback, I expect it to split into something like:

• a core Mission-Bound OAuth draft covering Stages 1 and the token model
• a mission management and proposal profile covering Stage 2
• a cross-domain mission assertion profile
• operational guidance for gateways, eventing, business event integration, and policy integration

That is one of the main reasons to publish this as a blog RFC first: to get feedback on where the boundaries should actually be, which parts of the staged model belong in which document, and whether the core claim is actually strong enough to justify standardization.

The goal of this work is not to turn OAuth into a workflow engine. The goal is to give OAuth a first-class way to bind delegated machine authority to an approved Mission with purpose, constraints, delegation bounds, and lifecycle.

The key claim is narrow and testable: a durable, AS-maintained Mission object that governs token derivation produces meaningfully stronger Mission governance than RAR at individual token issuance points, because it makes Mission authority independently revocable, auditable at the Mission level rather than the token level, and terminable by business events rather than only by clocks.

If that claim holds up under feedback, the next step is to extract the pieces that deserve standardization and draft them separately with narrower scope, starting with the Stage 1 core.

If you work in OAuth, IAM, policy systems, agent platforms, or enterprise security architecture, the most useful feedback is on the Priority 1 and Priority 2 questions above: whether the core Mission object is the right primitive, and whether the bounded authority envelope model is practical enough for real open-world agent systems.