Agent workflows expose a missing OAuth layer: durable task authority.

Consider a board-packet agent. It starts with authority to read calendar context and draft documents, then discovers that it needs finance data, CRM context, and approval to publish the final packet. Today that usually becomes one of three bad patterns: broad pre-consent, repeated reauthorization prompts, or proprietary approval glue outside the authorization protocol. OAuth can mint the tokens, but it has no standard object for “the task the user approved” that survives token lifetimes, resource fan-out, runtime escalation, and business-event termination.

The Mission-Bound OAuth architecture is intentionally broad. It describes the long-term shape: Mission objects, lifecycle states, projected artifacts, delegation, cross-domain handoff, FGA integration, audit, governance, and policy enforcement. That is the destination. It is not the first thing a working group should try to ship.

This post separates that architecture into two layers. The Minimum Profile binds OAuth tokens and derived assertions to Mission state. The optional IBAC Enforcement Profile makes Mission authority the runtime policy input for consequential agent actions. The goal is to make intent-based authorization deployable on existing OAuth infrastructure without waiting for a new agent-native protocol substrate.

The short version:

• Capture intent as structured authorization_details: a mission_intent envelope plus per-resource resource_access entries.
• Persist the approved intent as a Mission record at the Authorization Server.
• Put an opaque mission claim (with id and origin) on access tokens derived from that record.
• Gate refresh, exchange, introspection, and assertion validation on Mission state.
• Terminate the Mission independently of token expiry.

Everything else should either compose with existing OAuth work or wait for later profiles.

In the board-packet example, the before and after:

AAuth is the cleaner agent-native direction: signed agent requests, PS-mediated approval, mission-aware choreography, and native interaction surfaces. This Minimum Profile is the incremental OAuth path for deployments that cannot wait for that substrate. It does not try to make OAuth agent-native. It defines the smallest standards-composable authority layer that lets existing OAuth deployments bind tokens to an approved task.

Why now? Because the needed pieces are finally close enough to compose. RAR and PAR can carry structured intent. JWT access tokens can carry a Mission handle. Token Exchange and ID-JAG can derive audience-specific artifacts. AuthZEN Access Request can turn runtime denial into governance escalation. Introspection, revocation, and shared signals can propagate lifecycle state. The missing piece is the binding layer that makes them act like one task authority system instead of unrelated protocol features.

Scope

The Minimum Profile has one job: turn a user’s approved intent into a durable authority record that every derived token remains bound to.

That is the minimum useful version of intent-based authorization. The system does not merely ask for a bundle of scopes such as “calendar write” or “files read.” It asks for authority to pursue a specific purpose, bounded by a Mission envelope plus structured per-resource authorities and an overall lifetime. The Authorization Server validates that proposed intent, renders it for approval, records the approved mandate, and ensures that every later token derivation stays inside it.

The outcome is a protocol-visible link between three things that are usually disconnected:

• what the user meant to authorize;
• what the Authorization Server approved and can later revoke; and
• what each access token, ID-JAG, sub-agent token, or exchanged token is allowed to do.

That moves the ball forward in a concrete way. Today, an agent can often receive broad OAuth authority and then rely on application logic, prompt discipline, or out-of-band audit to stay within the user’s task. Under the Minimum Profile, the task itself becomes an authorization object at the AS. The AS can gate refresh, exchange, escalation, and termination against that object, while existing resource servers can continue accepting ordinary OAuth tokens.

This matters most when one task fans out across multiple resources and multiple authorization servers. A single user intent such as “prepare the quarterly board packet” might require calendar access, document access, CRM access, finance-system access, and a signing workflow, each protected by a different Resource AS. The Minimum Profile gives the originating AS a Mission record for the user’s approved mandate, then lets each downstream Resource AS receive a narrowed, audience-specific assertion or token that still carries the same mission.id. The result is one user-approved Mission, many resource-specific tokens, and a common lifecycle gate across the whole task.

It adds five things.

The minimum registration surface is small: two RAR types (mission_intent for the envelope, resource_access for generic per-resource authority), one JWT claim (mission, an object), one grant-profile identifier, and one error_uri (urn:ietf:params:oauth:mission-inactive) to signal inactive Mission state. Deployments that use event-driven revocation also need Mission state event identifiers, but those are not required for the minimum issuance and derivation path.

Deferred approval, AuthZEN escalation, CIBA, and SSF/CAEP are composition points the Minimum Profile already names. Mission-state introspection is part of the profile only where an AS or Resource AS chooses an introspection freshness model. Full receipt profiles, formal policy compilation, governed purpose registries, and management APIs are later profiles or part of the IBAC Enforcement Profile defined below.

The deliberate choice in this draft is to keep Mission metadata and resource authority in separate, sibling authorization_details entries. mission_intent is the envelope; resource_access (or an ecosystem-specific RAR type) carries per-resource authority. This composes naturally with RAR ecosystems that will define their own resource types over time, without making mission_intent a god-object that has to encode every resource’s authority taxonomy.

RAR is the proposal format, not the lifecycle authority. Without a Mission record, approved authorization_details are trapped inside one authorization transaction or one issued token. The Mission record is what lets later refresh, exchange, introspection, assertion validation, and Resource AS issuance evaluate the same approved task authority over time.

In Scope

The Minimum Profile covers:

• Mission creation from a structured authorization request.
• Mission lifecycle states: pending_approval, active, suspended, revoked, expired, completed, and rejected.
• Access tokens carrying the mission claim.
• Refresh and token exchange checking Mission state before issuing derived tokens.
• Cross-audience and cross-AS derivation using Token Exchange and ID-JAG.
• Optional introspection and SSF/CAEP propagation for Mission state.
• A user-visible inventory and revocation model for active Missions.

Out of Scope

The Minimum Profile deliberately does not standardize:

• Mission graphs, sub-Missions, or budget delegation.
• A portable cross-domain Mission object.
• Mission template registries or global purpose URI governance.
• A standard internal Authority Model schema.
• OpenFGA, Zanzibar-style, Cedar-specific enforcement profiles, or full AuthZEN PDP policy modeling, at the MVP wire layer.
• Hard real-time revocation for resource servers that do not introspect or consume events.
• A fully standardized approval-receipt format.

Those are important, but they do not have to block the first useful protocol profile.

Solution Overview

The Mission is the durable authority. Tokens are projections of it.

The basic flow:

1. The user gives an agent a goal.
2. The orchestrator turns that goal into a structured Mission Proposal and posts it to the AS through PAR as an authorization_details array containing a mission_intent envelope plus per-resource authority entries.
3. The AS validates the proposal against client registration and deployment policy, renders it for the user, and on approval creates an active Mission record bound to the authorization code.
4. The token endpoint issues an access token carrying the mission claim.
5. Refresh and exchange succeed only while the Mission remains active.
6. Cross-audience or cross-AS work derives ID-JAGs carrying the same mission.id.
7. Revocation, suspension, completion, or expiry stops future derivation even if previously issued tokens have not expired.

The interaction model has two paths, plus an out-of-band approval channel. Deferred code is the bootstrap path: if the AS cannot approve the Mission synchronously, the authorization flow can hold the Mission in pending_approval until user, admin, or risk review completes. AuthZEN Access Request is the escalation path: if runtime authorization discovers that the current Mission is not broad enough, the denial can become a requestable governance workflow instead of a terminal error. CIBA sits behind either path when the missing input is fresh out-of-band user authentication or consent; it is an approval channel, not the Mission governance model.

The Resource Server does not have to understand Missions on day one. A normal RS can validate audience, expiry, scope, and authorization_details as it already does, while the Mission gate fires at the originating AS before new tokens or ID-JAGs are minted. Mission-aware Resource AS and RS deployments can add introspection, event consumption, Cedar evaluation, or actor-receipt validation later.

The originating AS therefore has a baseline obligation: it MUST narrow issued scopes, audiences, and authorization details to the approved Mission, so even OAuth-only resource servers receive least-privilege tokens. Full request-time intent enforcement requires a resource server that understands authorization_details, a compiled policy, or Mission state.

Worked Example

Before the mechanics, a concrete walkthrough. Concepts referenced here (Mission Expansion, ID-JAG, proposal_hash, sub-agent delegation) are defined in detail in the sections that follow; the example sets up intuition.

The user asks: “prepare the quarterly board packet and route it for approval.”

Without a Mission layer, the agent platform usually has to choose between over-granting up front, interrupting the user every time a new resource appears, or wiring a proprietary approval workflow around OAuth. The token layer can answer whether the agent has documents.read or finance.read. It cannot answer whether this particular finance access is still inside the board-packet task the user approved.

With the Minimum Profile:

1. The orchestrator translates the prompt into a mission_intent envelope with purpose=urn:example:mission:board-packet, mission_expiry=2026-06-05T12:00:00Z, and a context carrying classification=confidential. It pairs the envelope with resource_access entries for calendar context, document drafting, and internal company-profile data. Each resource_access binds a resource to the actions and constraints that apply to it.
2. The orchestrator posts the proposal through PAR with an idempotency_key.
3. The AS validates the proposal against client registration and policy. If the Mission requires human, admin, or risk review, deferred code holds the Mission in pending_approval until the decision completes.
4. On approval, the AS creates mission.id=msn_01HX4Y... in active state, stores the approved authorization_details array, computes proposal_hash over it, and issues an access token bound to the Mission.
5. The agent drafts the packet using audience-specific tokens for the approved document and calendar resources.
6. The agent discovers that the packet needs finance data from https://finance.example.com, which was not in the approved resource_access entries. The Resource AS or PDP returns a requestable denial through AuthZEN Access Request instead of treating the denial as terminal. The orchestrator hands the denial to the deployment’s approval workflow.
7. The approval workflow (out-of-band human or admin review) evaluates the requested expansion. If approved, the AS creates a successor Mission whose mission.supersedes points to the prior mission.id. Only then does the agent derive a finance token, and only under the successor Mission. If the expansion is denied, the prior Mission stays active and the finance access is permanently blocked under this Mission.
8. With finance, calendar, and document data in hand, the agent assembles the packet and needs to submit it to a signing workflow at a different Resource AS. The originating AS mints a Mission-bound ID-JAG for that audience, preserving the same Mission lineage while allowing the Resource AS to issue a local least-privilege token for the signing step.
9. The signing workflow completes and the packet is routed for distribution. The orchestrator requests Mission completion. The AS transitions the Mission to completed if policy accepts the completion signal.
10. Later refreshes and exchanges fail because the Mission is no longer active.

Nothing here requires every resource server to be Mission-aware at launch. The AS still gates future derivation.

Architecture

Conceptual Model

The Mission is the hub of the model. Tokens, ID-JAGs, and local tokens are projections of it; Tasks are the orchestrator’s runtime use of those projections.

Reading the diagram:

• Dotted arrows mark the LLM-driven shaping path. Everything from Prompt through Intent to Mission Proposal is untrusted; trust enters only at PAR submission and AS validation.
• Solid arrows are trusted protocol flows. The Mission record is created after the AS validates the proposal and the user consents to the rendered version.
• Cardinality: one User goal yields one Mission (or a chain of successor Missions via Expansion); one Mission projects many tokens, ID-JAGs, and local tokens; one Mission underwrites many Tasks; one Task can run inline in the Orchestrator or delegate to a Sub-agent through Token Exchange with an actor_token and an act chain.
• The diagram omits the PDP, audit records, SSF/CAEP events, and Mission Expansion to stay readable. Those live in State Layers, Audit and Receipts, Termination and Events, and Mission Expansion respectively.

Roles

The Minimum Profile has four wire-level roles:

• User: approves the Mission.
• Orchestrator / agent client: converts the user’s goal into a structured Mission Proposal and requests tokens.
• Authorization Server / agent provider: validates the proposal, stores the Mission, issues tokens, and gates derivation.
• Resource Server / Resource AS: validates tokens or ID-JAGs and enforces the projected authority.

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

Consent in this profile is AS-mediated rather than user-signed. The Minimum Profile uses an AS-stored proposal_hash as the integrity anchor on the user’s approved intent, which keeps user-side key custody out of the deployment story. A future profile can layer user-held signing keys onto the same proposal_hash.

State Layers

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

The Minimum Profile defines the Mission state surface and the wire artifacts that let the other layers consult it. Tokens project Mission bounds across the protocol boundary. Policy evaluates specific requests against approved Mission bounds plus local rules when a deployment has a PDP. Sessions can consult Mission state on resume and before consequential work. The Minimum Profile does not standardize session state, PDP behavior, or local policy languages; it gives those layers the Mission handle, the lifecycle gate, and the introspection surface they need to do their own jobs.

The IBAC Enforcement Profile, defined later in this post, additionally strengthens the policy-state layer by making AuthZEN Access Evaluation a normative requirement for every consequential agent action, including non-OAuth tool invocations and side-effecting calls.

Minimum Interop Requirements

The profile is small but still needs a minimum interoperability contract. These rules are the line between a Mission-bound token and a token that merely carries a Mission-shaped correlation handle:

• The originating AS MUST narrow issued scope, aud, and authorization_details to the approved Mission bounds.
• Every derived token or assertion MUST preserve the mission claim and MUST NOT exceed the Mission expiry.
• Every derived authorization_details entry MUST be a subset of an approved entry of the same type, evaluated by that type’s subset rule (see Authority Model). Known constraints MUST be preserved or narrowed; unknown constraints MUST be preserved or cause refusal. Constraints MUST NOT be silently dropped during derivation.
• A Resource AS that issues a local access token from a Mission-bound ID-JAG MUST bind that local token to the same mission.id and mission.origin, either in the token or server-side.
• A Resource AS MUST apply its own local authorization policy before issuing local tokens. A Mission-bound ID-JAG is evidence of approved user intent and bounded upstream authority; it is not a command to grant local access.
• A multi-tenant AS or Resource AS MUST bind tenant or organization context into Mission-bound artifacts per the Tenant Binding section.

Multi-AS Validation

When a Mission crosses AS boundaries, the downstream Resource AS has to validate both the assertion issuer and the Mission authority.

The Resource AS MUST NOT blindly trust mission.origin from an arbitrary assertion. It accepts a Mission origin only when it is bound to a trusted assertion issuer by local trust policy, ID-JAG issuer metadata, the Identity Assertion Trust Framework, Domain-Authorized Issuer Discovery, or an equivalent configured trust method.

Before issuing a local access token, the Resource AS has three possible freshness models:

• Fresh assertion model. The Resource AS accepts the ID-JAG’s short lifetime as sufficient freshness. This is the Minimum Profile default.
• Introspection model. The Resource AS introspects Mission state at mission.origin before local token issuance.
• Event-backed model. The Resource AS relies on a current SSF/CAEP subscription from the originating AS and rejects or degrades if the event stream is not current.

The Minimum Profile requires the fresh assertion model by default. Mission-bound ID-JAGs MUST be short-lived, and the Resource AS MUST validate the assertion expiry before issuing local tokens. A deployment profile SHOULD define a concrete maximum lifetime, such as 300 seconds, based on risk and operating constraints. Deployments MAY add the introspection or event-backed model on top of (not in place of) the fresh assertion bound for higher-risk resources or audiences with stricter freshness requirements. The conservative default reflects operational simplicity: a bounded ID-JAG lifetime means staleness is bounded by ID-JAG exp plus local-token exp, without requiring synchronous introspection or event-stream infrastructure on every cross-AS hop.

Mission-state introspection across ASes should be minimal. The Resource AS needs to know whether the Mission is active, the Mission expiry, the approved authorization_details entries relevant to that Resource AS, and the proposal_hash. It does not need prompt text, full audit evidence, or entries that apply to other audiences.

Mission Shaping

The Minimum Profile standardizes stages 3 and 4, not the entire agent-planning pipeline:

1. Prompt. Free text from the user. Untrusted input.
2. Intent envelope. Parsed structure such as purpose, candidate resources, actions, time bounds, and named participants. Still untrusted; lives in the orchestration layer.
3. Mission Proposal. The authorization_details array containing a mission_intent envelope plus resource authority entries such as resource_access.
4. Approved Mission. The AS-side record created after validation and consent.

The AS MUST validate the proposal against deployment policy and the OAuth client’s registered authority before rendering it. The user MUST approve a human-readable rendering of the post-validation proposal; the approved Mission, not the prompt, is the authority record.

The orchestrator’s output MUST be treated as untrusted for the same reason the prompt is: shaping happens in the LLM-driven layer. Trust enters at AS validation, not at proposal submission.

The Minimum Profile works with three shaping approaches; deployments MAY use any combination:

• Scope-narrowed proposals. The proposal MUST be a subset of the client’s registered scopes, resources, and supported authorization_details types.
• Tool-bounded narrowing. The orchestrator inspects tool manifests, OpenAPI descriptions, MCP server manifests, or registered functions and proposes only the tools needed for the task. This is useful deployment practice; the Minimum Profile does not standardize tool-manifest binding (see Gaps).
• Standing scope plus intent annotation. Existing broad OAuth grants MAY be annotated with Mission purpose, audit context, and termination handles. This is weaker, but useful for retrofit deployments.

A fourth approach is deliberately not adopted: AS-side semantic matching of a free-form prompt against the catalog of available scopes or tools. The Minimum Profile keeps semantic interpretation in the orchestration layer and accepts only a structured proposal at PAR. An AS MUST NOT replace structured-proposal validation with prompt-based semantic matching.

The purpose URI inside mission_intent plays the stable, lifecycle-managed role: it is registered with the client and tied to deployment policy. mission_expiry and context on the same envelope play the runtime, session-scoped role: they bound time and cross-cutting constraints for this run. The per-resource resource_access entries (or ecosystem-specific RAR types) narrow the stable purpose to one approved task. The envelope and the resource authorities live as sibling entries in the same authorization_details array; proposal_hash binds them together as one approved bundle.

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

Mission Lifecycle

The Mission lifecycle is independent of token expiry.

The wire protocol only needs one hard distinction: active permits derivation, and every non-active state refuses derivation. The named non-active states are for diagnostics, audit, policy, and user/admin experience.

The diagram shows the Minimum Profile’s current state machine. Supersession (Mission Expansion creating a successor) is not a distinct state in this diagram: the prior Mission transitions to completed, and the supersedence relationship is encoded through mission.supersedes and the SSF superseded event. Whether superseded should be promoted to a distinct terminal state is an open question; see Gaps.

Only active permits new derivation. Any other state causes token endpoints to fail with error="invalid_grant", error_uri="urn:ietf:params:oauth:mission-inactive", and a mission_state field. The mission_state value MUST be one of the named lifecycle states: pending_approval, suspended, revoked, expired, completed, or rejected. When the mission.id does not resolve at mission.origin, the AS MUST instead use mission_state="mission_not_found". Introspection returns active: false and MUST include mission.state carrying one of the same vocabulary values, plus mission_not_found for unresolvable IDs.

Attestation Layers

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

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

Detailed Solution

Mission Proposal

The agent submits the Mission Proposal as part of the OAuth authorization request, ideally through PAR so the proposal stays off the front channel.

A representative pushed request:

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

POST /par HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3

response_type=code
&client_id=agent.example.com
&redirect_uri=https://agent.example.com/cb
&scope=mission
&code_challenge=...
&code_challenge_method=S256
&authorization_details=<url-encoded mission_intent JSON>

Decoded:

 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

[
  {
    "type": "mission_intent",
    "purpose": "urn:example:mission:board-packet",
    "mission_expiry": "2026-06-05T12:00:00Z",
    "context": {
      "classification": "confidential"
    }
  },
  {
    "type": "resource_access",
    "resource": "https://docs.example.com",
    "actions": ["documents.read", "documents.write"],
    "constraints": {
      "folder": "board-materials"
    }
  },
  {
    "type": "resource_access",
    "resource": "https://calendar.example.com",
    "actions": ["calendar.events.read"],
    "constraints": {
      "time_window": "P30D"
    }
  }
]

The Minimum Profile defines two RAR types. mission_intent is the Mission envelope: purpose is a stable URI for the mission class, mission_expiry is a hard ceiling on the entire Mission, and context carries cross-cutting bounds that apply uniformly across every resource authority in the same array. resource_access is the generic per-resource authority: resource is the audience, actions is the allowed action set, and constraints carries resource-scoped bounds. Resource ecosystems MAY define richer RAR types (document_access, payment_initiation, and so on); the AS validates each entry against its registered type metadata and stores the entire approved array on the Mission record. The AS may store audit context such as the prompt, plan, or other evidence, but that evidence is not carried in access tokens.

The Minimum Profile does not standardize a global catalog of context keys. A deployment or ecosystem RAR type can define keys such as classification, assurance_level, risk_tier, max_budget, currency, max_calls, or geo_bound, but their syntax and narrowing semantics must be published in type metadata or deployment configuration before they can be enforced. If an AS enforces a context key, it treats the approved value as a hard bound for derivation. If it does not understand the key, it preserves it or refuses the derivation under the unknown-constraint rule below.

Clients discover the schemas for mission_intent, resource_access, and any ecosystem-specific RAR types through draft-zehavi-oauth-rar-metadata. The AS advertises authorization_details_types_metadata_endpoint; the endpoint publishes JSON Schema for each supported type. Mission-aware resource servers can advertise their required authorization detail types through RFC 9728 PRM. Orchestrators use both to pre-validate proposals before asking the user to consent.

Orchestrators MAY include an idempotency_key on PAR. If the same client and user submit the same key within a deployment-defined window, the AS returns the prior request_uri instead of creating a duplicate Mission.

Proposal Hash

The AS MUST compute proposal_hash as the base64url-encoded (no padding) SHA-256 digest of the canonical JSON serialization, per JCS (RFC 8785), of the entire approved authorization_details array (Mission envelope plus all per-resource entries). The hash MUST be taken at the moment the Mission transitions to active and MUST be computed over the post-narrowing array that the AS stores on the Mission record. The proposal_hash value MUST be stable for the lifetime of the Mission; an amendment that changes the approved array MUST create a successor Mission with its own proposal_hash.

When the AS narrows the proposal during validation (for example, trimming mission_expiry to a policy maximum or removing entries outside client registration), the narrowed array is what the user approves and is what proposal_hash covers. The token response MUST return the narrowed authorization_details per RFC 9396 §7. Clients MUST treat the returned authorization_details as the approved bounds; later derivation requests are evaluated against the narrowed array, not against what the client originally submitted at PAR.

The AS MUST also compute consent_rendering_hash as the base64url-encoded (no padding) SHA-256 digest of the exact human-readable rendering material shown to the user at approval time, including localization version, normalization rules defined by the AS, and any material UI text the user saw. The AS MUST document its rendering normalization rules so an auditor can reproduce the hash. proposal_hash proves which structured bounds were approved; consent_rendering_hash proves what the user saw. Both hashes are stored on the Mission record and surfaced in audit records. proposal_hash is also surfaced on introspection responses. This is the minimum portable evidence handle the profile commits to; richer Mission Receipt formats are out of scope for the Minimum Profile.

Lifetime and Audience

The proposal carries two scoping dimensions: time and audience.

mission_expiry is an RFC 3339 timestamp on the mission_intent envelope:

1
2
3
4
5
6
7
8

{
  "type": "mission_intent",
  "purpose": "urn:example:mission:board-packet",
  "mission_expiry": "2026-06-05T12:00:00Z",
  "context": {
    "classification": "confidential"
  }
}

The AS enforces a maximum Mission age by deployment policy. If the proposal omits mission_expiry, the AS applies a default. If the proposal exceeds policy, the AS narrows the value before consent. Expiry is a hard ceiling: continuing authority requires a new Mission.

Each resource_access.resource (or the audience field defined by an ecosystem-specific RAR type) contributes to the Mission’s audience whitelist for cross-audience derivation. Cross-audience ID-JAGs may only be minted for approved resources, and the projected actions and constraints are taken from the matching resource_access entry. Adding resources requires Mission expansion or a new Mission.

Token Claim and Introspection

Access tokens issued under a Mission carry the mission claim with id and origin. Refresh tokens are bound to the Mission server-side and may carry mission.id if they are structured. ID Tokens do not need the mission claim for the Minimum Profile; deployments that add it should treat that as an explicit privacy and correlation decision.

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

{
  "iss": "https://as.example.com",
  "sub": "alice@example.com",
  "aud": "https://docs.example.com",
  "client_id": "agent.example.com",
  "scope": "documents.read documents.write",
  "authorization_details": [
    {
      "type": "mission_intent",
      "purpose": "urn:example:mission:board-packet",
      "mission_expiry": "2026-06-05T12:00:00Z",
      "context": {
        "classification": "confidential"
      }
    },
    {
      "type": "resource_access",
      "resource": "https://docs.example.com",
      "actions": ["documents.read", "documents.write"],
      "constraints": {
        "folder": "board-materials"
      }
    }
  ],
  "mission": {
    "id": "msn_01HX4Y2P8BQ4Y3F0V0K9D6Z7M1",
    "origin": "https://as.example.com"
  },
  "cnf": { "jkt": "..." },
  "iat": 1716412800,
  "exp": 1716416400,
  "jti": "tok_..."
}

mission.id is opaque to the resource server. mission.origin identifies the AS where the Mission state lives, which matters after ID-JAG handoff. Mission-bound tokens MUST be sender-constrained with DPoP or mTLS confirmation (cnf).

Introspection returns normal RFC 7662 fields plus Mission state inside the same mission claim:

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

{
  "active": true,
  "scope": "documents.read documents.write",
  "exp": 1716416400,
  "sub": "alice@example.com",
  "aud": "https://docs.example.com",
  "client_id": "agent.example.com",
  "mission": {
    "id": "msn_01HX4Y2P8BQ4Y3F0V0K9D6Z7M1",
    "origin": "https://as.example.com",
    "state": "active",
    "expiry": "2026-06-05T12:00:00Z",
    "purpose": "urn:example:mission:board-packet",
    "proposal_hash": "fS8h4w7Z3Lq...base64url-sha256...",
    "consent_rendering_hash": "e9X2...base64url-sha256...",
    "supersedes": null
  }
}

If the Mission is not active, introspection returns active: false even if the token signature and expiry are otherwise valid. The response MUST include mission.state so the caller can distinguish a Mission-state denial from a token-validity denial. The authorization decision remains active: false.

The minimum Mission introspection response, for any Mission-bound token, MUST include the standard RFC 7662 fields plus a mission member containing at minimum:

• id: the opaque Mission identifier.
• origin: the originating AS.
• state: one of the named lifecycle states, or mission_not_found when the mission.id does not resolve.

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

• expiry: the Mission’s hard end-of-life timestamp.
• purpose: the approved mission_intent.purpose URI.
• proposal_hash: the canonical hash of the approved authorization_details array.

The response MAY include consent_rendering_hash, supersedes, and other Mission record fields. Cross-AS introspection responses, where a Resource AS calls back to mission.origin, SHOULD filter authorization_details to entries relevant to the requesting audience and SHOULD omit unrelated entries to minimize cross-audience disclosure.

Authority Model

The Authority Model answers: what is this Mission allowed to do?

The Minimum Profile does not standardize the internal representation. Deployments may store the approved authorization_details, compile to scopes, produce AuthZEN policy, create OpenFGA tuples, compile to Cedar, or use another local policy model. The protocol requirement is only that the AS can compare requested derivations against the approved bounds.

The minimum comparison rule is structural and applies per RAR entry, per type:

• Every derived authorization_details entry MUST be a subset of an approved entry of the same type. Subset semantics come from the type’s registered RAR metadata; the Minimum Profile defines them for mission_intent and resource_access below.
• mission_intent. purpose MUST match the approved value exactly. mission_expiry MUST NOT exceed the approved value. Every key in the derived context MUST be present in the approved context, and the derived value MUST imply the approved value under the constraint’s narrowing semantics. Narrowing semantics for context fields come from registered metadata or deployment configuration.
• resource_access. The derived resource MUST equal the approved resource exactly. The derived actions MUST be a subset (set inclusion) of the approved actions. Every key in the derived constraints MUST be present in the approved constraints, and the derived value MUST imply the approved value under the constraint’s narrowing semantics.
• Unknown constraints. A constraint is “unknown” to a participant when its narrowing semantics are not defined by registered RAR metadata or by deployment configuration. An AS or Resource AS that encounters an unknown constraint key MUST either preserve it verbatim in the derived entry (or the derived local token) or refuse the derivation with error="invalid_authorization_details". Silently dropping, ignoring, or modifying an unknown constraint is forbidden.
• Ecosystem-specific RAR types apply their own subset rules through their registered metadata. The Minimum Profile imposes the “unknown constraints” rule above on all types regardless of source.
• Omitted and unknown entries. Entries omitted from the derivation request are narrowed by removal. Entries with a type not present in the approved Mission MUST be rejected.

That is enough for interoperable derivation. Formal policy languages are composition points, not part of the minimum profile.

If a deployment uses Cedar or another formal policy language, the AS can compile the approved authorization_details array (envelope plus per-resource entries) after consent and project that policy to capable Resource Servers. Clients do not submit formal policy text at PAR in the Minimum Profile. The structured mission_intent envelope plus resource_access (or ecosystem-specific) entries form the consent surface.

Non-OAuth Actions

The structural comparison rule above governs derivation: it tells the AS whether to issue a new access token, ID-JAG, or exchanged token. It does not govern what happens inside an active Mission when an orchestrator performs a local action that is not an OAuth-protected API call: tool invocations, file writes, payment confirmations, or internal side effects.

Those actions are outside the Minimum Profile. A deployment can still use the Mission record as an input to local policy, but the wire-level MVP does not standardize PDP consultation, tool invocation checks, or per-action receipts. The IBAC Enforcement Profile below is the layer that turns Mission authority into a runtime policy gate for consequential non-OAuth actions.

Derivation

Mission-bound authority is derived along three paths.

Refresh, same audience. The client uses normal refresh. The AS resolves the Mission. If it is active, the AS issues a new access token with the same mission.id and bounded authority. If it is not active, the AS rejects the request with error="invalid_grant", error_uri="urn:ietf:params:oauth:mission-inactive", and a mission_state field carrying the current state (for example, revoked, suspended, expired, completed).

Token Exchange to ID-JAG, cross audience or cross AS. When the agent needs a different audience, possibly protected by a different Resource AS, the agent provider acts as the IdP Authorization Server in ID-JAG terms. The originating AS remains the Mission authority; each downstream Resource AS receives a narrowed assertion for its own audience.

1. The agent submits RFC 8693 Token Exchange with requested_token_type=urn:ietf:params:oauth:token-type:id-jag, the requested audience, and the current mission-bound token as subject_token.
2. The agent provider checks Mission state and the requested audience against the approved Mission.
3. The agent provider mints an ID-JAG carrying the mission claim (with id and origin), the user subject, audience, projected authority, and any actor chain.
4. The agent presents the ID-JAG to the Resource AS using the RFC 7523 JWT-bearer grant.
5. The Resource AS validates the ID-JAG, evaluates issuer trust, confirms Mission state through freshness, introspection at mission.origin, or events, applies local authorization policy, and issues a local access token bound to the same mission.id.

Sub-agent delegation. The parent agent submits Token Exchange with a sub-agent Client Instance Assertion as actor_token. The issued ID-JAG and any access token derived from it MUST include an act chain. The chain follows RFC 8693 conventions: the most recent actor is the outermost act, with the parent’s prior act (if any) carried as the nested act. The sub-agent receives only authority that is within the Mission and narrowed by the parent delegation. A Resource AS that enforces sub-agent-scoped policy MUST evaluate the full chain. Per-actor revocation keyed on the chain identity is companion work (see Gaps).

Five invariants apply to every path:

• mission.id is preserved under derivation.
• Mission state is checked before new authority is issued or accepted.
• Authority can narrow but cannot expand without a new approval.
• Any derived token’s exp MUST NOT exceed Mission expiry. This binds access tokens, refresh tokens, and ID-JAGs to the Mission’s hard end-of-life, independent of token-level TTL policy.
• Local Resource AS refresh, exchange, and introspection paths MUST preserve the Mission binding or refuse the operation.

Step-up authentication does not move the Mission state machine. If a derivation fails with RFC 9470 insufficient_user_authentication, the Mission remains active; only the attempted derivation fails.

Mission Expansion

A Mission’s authority cannot grow in place. Expansion creates a new Mission whose mission.supersedes points at the prior mission.id.

There are two paths:

• An out-of-bounds derivation returns a requestable denial through AuthZEN Access Request, and the approval flow creates the successor Mission.
• The agent submits a fresh mission_intent proposal with the expanded authority.

When expansion is approved, the prior Mission becomes non-active for new derivations and the successor Mission becomes authoritative. Existing tokens expire naturally; new derivations use the new mission.id. The supersedence chain through mission.supersedes preserves auditability across the transition. Whether the prior Mission should use completed, a distinct superseded terminal state, or another non-active state is an open question; see Gaps.

Termination and Events

Termination MUST happen at the Mission record, not only at the token layer.

Direct termination by the AS or its admin surface MUST transition the Mission to revoked, suspended, or completed. Future refresh and exchange MUST fail when the Mission is in any non-active state. Existing tokens MAY continue until token-level expiry unless the resource server introspects Mission state or consumes Mission state events.

Client-driven termination MAY use RFC 7009. Under the Minimum Profile, revoking a refresh token bound to a Mission MUST terminate the Mission by default. An AS MAY support per-token revocation that leaves the Mission active; in that case, the client SHOULD signal revoke_mission=true to terminate the Mission explicitly.

User and administrator termination MUST NOT depend on possession of a refresh token. Deployments MUST expose a Mission management surface, behind the user-visible inventory, that can revoke, suspend, resume, or complete a Mission by mission.id. The Minimum Profile does not standardize the wire shape of that management API (see Gaps); it requires only that the operation exist.

Client-driven completion is advisory. A client MAY request that a Mission transition to completed, but the AS MUST decide whether to accept the transition based on client authentication, Mission state, resource evidence, deployment policy, or user/admin action. This prevents a compromised client from using completion semantics to hide unfinished or unauthorized work.

Mission state can propagate through SSF/CAEP events:

The example URIs are placeholders. An event profile can register concrete event types later.

Operational Requirements

Compliance Tiers

The Minimum Profile composes with a deep OAuth and OIDC stack: PAR, RAR, JWT access tokens, Token Exchange, ID-JAG, introspection, revocation, SSF/CAEP, AuthZEN. Adopting all of them at once is a non-starter for most identity teams. Compliance Tiers let a deployment ship intent-binding immediately and add capability over time.

Compliance Tiers are about deployment dependencies (which specs you need to implement). They are orthogonal to Resource Server Tiers (per-RS capability) and to the choice of profile (Minimum vs IBAC). A deployment lives at a coordinate in three dimensions, not on a single ladder:

A “Tier-2 deployment with mixed RS-A and RS-D audiences under the Minimum Profile” means: the AS implements Tier-2 dependencies (PAR, RAR, Token Exchange, ID-JAG, JWT bearer); some RSes ignore the mission claim while others introspect Mission state per request; runtime enforcement stays at SHOULD level. A “Tier-3 IBAC deployment” implements every dependency in the stack and treats the policy layer as MUST.

A deployment can claim Tier-N compliance independently of which Resource Server Tiers it operates. A Tier-3 deployment with one RS-A audience still has Tier-3 properties for the rest of its surface; a Tier-2 deployment with several RS-D audiences gets stronger freshness at those audiences but does not claim Tier-3 because it lacks AuthZEN composition. The IBAC Enforcement Profile is an additional opt-in on top of Tier 3.

Resource Server Tiers

Resource servers can adopt Mission awareness incrementally:

• RS-A: OAuth-only. Validates scope, audience, expiry, and sender constraint. Ignores the mission claim. Revocation is bounded by token expiry.
• RS-B: Authorization-details aware. Also validates audience-relevant authorization_details, especially resource_access or ecosystem-specific RAR entries, against the request.
• RS-C: Policy-aware. Evaluates Cedar or another compiled Authority Model.
• RS-D: Mission-state aware. Introspects Mission state per request or subscribes to SSF/CAEP events.

The Mission gate at the AS works even with RS-A, provided the AS narrows issued tokens to Mission bounds. Stronger tiers reduce overuse and revocation staleness. Request-time intent enforcement starts at RS-B; RS-A gets only AS-side narrowing and expiry-bounded revocation.

RS-A is a migration tier, not the target security model. It prevents future over-issuance at the AS, but it does not stop a still-valid access token at request time.

RS-D deployments should keep Mission-state caches short-lived unless they hold a current SSF/CAEP subscription that delivers Mission state events; in that case, the cache can persist until invalidated by an event. When introspection at mission.origin is unreachable, RS-D should fail closed for derivation requests and high-risk state-changing API calls. RS-D can fall back to event-derived state if a current SSF/CAEP subscription is available.

Operand provenance is complementary to Mission-state enforcement: provenance signs values back to their upstream computation, while the Mission gate bounds which calls may be attempted. That belongs in a future enforcement profile, not the Minimum Profile.

Client and Token Constraints

The Minimum Profile is for confidential clients. Public clients should not act as Mission-bound clients. Confidential client authentication uses mechanisms such as private_key_jwt or mTLS at Mission-related endpoints.

Mission-bound access tokens, refresh tokens, and ID-JAGs MUST be sender-constrained. DPoP or mTLS confirmation (cnf) binds the token to a key. The sender-constraint key is stable within a Mission; key rotation requires a new Mission Proposal or successor Mission. For sub-agent delegation, the parent authenticates the Token Exchange, and the sub-agent instance key becomes the confirmation key on derived tokens.

Mission-bound access tokens should be short-lived by default. Stale-state risk at RS-A and RS-B audiences is bounded by token TTL because those tiers do not introspect or consume Mission state events. Deployments can use longer access-token lifetimes for RS-D audiences that introspect Mission state per request or maintain a current SSF/CAEP subscription, since those tiers have an independent invalidation path. Refresh tokens and ID-JAGs are bounded by Mission expiry per the Derivation invariants.

Governance Inventory

Deployments need a user-visible inventory of active Missions. It should show:

• Non-terminal Missions for the user.
• Purpose, requesting client, authority summary, expiry, and state.
• A per-Mission revoke action.

Without this, a user can approve a Mission but has no practical way to see or stop it later.

The inventory needs a backing lifecycle operation, even if the wire API is deployment-specific. Users and administrators must be able to revoke or suspend a Mission by mission.id without presenting a refresh token.

Tenant Binding

In multi-tenant deployments, tenant or organization context MUST be bound into every Mission-bound artifact so that authority approved under one tenant cannot be exercised against another.

• The approved Mission record MUST identify the tenant context in which it was approved, either as a Mission record field or inside mission_intent.context.
• Mission-bound access tokens, refresh tokens, and ID-JAGs MUST carry tenant context, either as an explicit claim (such as tenant or organization) or via a tenant-scoped issuer URI for iss and mission.origin.
• An AS MUST reject Mission Proposal or derivation requests whose presented tenant context differs from the approved Mission’s tenant.
• A Resource AS or RS MUST reject a Mission-bound token whose tenant context does not match the resource being accessed. A token approved under tenant A MUST NOT be accepted as evidence for tenant B’s resources, even if the resource URI is identical.
• Introspection responses MUST carry the tenant context in the same claim shape as the corresponding access tokens.
• Cross-tenant Mission Expansion (a successor Mission targeting resources in a different tenant) MUST require fresh approval under the new tenant. Tenant boundaries cannot be crossed by attenuation alone.

Audit and Receipts

Every Mission lifecycle and derivation event should produce an audit record:

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

{
  "mission": {
    "id": "msn_01HX4Y2P8BQ4Y3F0V0K9D6Z7M1",
    "origin": "https://as.example.com",
    "proposal_hash": "fS8h4w7Z3Lq...base64url-sha256...",
    "consent_rendering_hash": "e9X2...base64url-sha256...",
    "supersedes": null
  },
  "event_type": "mission.activated",
  "timestamp": "2026-05-22T16:21:08Z",
  "actor": {
    "client_id": "agent.example.com",
    "sub": "alice@example.com",
    "act": null
  },
  "prior_state": "pending_approval",
  "new_state": "active",
  "evidence_id": "ev_01HX4Y2P9KP5XQ..."
}

evidence_id is an opaque handle to confidential evidence such as the prompt or plan. The evidence itself MUST NOT be carried in tokens or transmitted audit records. The audit log should be append-only and integrity-protected.

Portable, third-party-verifiable provenance is companion work. A future Mission Receipt Profile could carry signed receipts per visible act hop and bind them to mission.id, mission.origin, proposal_hash, evidence_id, consent_rendering_hash, and auth_context. That is useful, but not required for the Minimum Profile.

Privacy and Security

Mission-Bound OAuth introduces persistent records with potentially sensitive content. Baseline expectations:

• Audit context is confidential storage and MUST NOT be placed in tokens.
• mission.id is opaque and high entropy.
• mission.id and mission.origin are the same across every hop in a single Mission, which permits Resource ASes and audit-log readers to correlate user activity across audiences. Deployments that need stronger cross-audience unlinkability SHOULD issue audience-pairwise identifiers: the originating AS maintains a single internal Mission identifier but projects an audience-specific opaque value into each derived ID-JAG and access token. The mapping from audience-pairwise value to internal identifier MUST remain server-side at the originating AS. Cross-AS introspection MAY require explicit identifier resolution. Deployments that do not project audience-pairwise identifiers MUST document that the universal mission.id permits cross-audience correlation.
• mission.origin is itself correlation-bearing because it identifies the originating AS. Deployments under privacy-strict regimes MAY use a per-tenant or per-audience opaque issuer URI for mission.origin, with the trusted-issuer mapping maintained server-side.
• purpose URIs are visible to every downstream Resource AS, RS, and audit record that processes a Mission-bound token. Deployments SHOULD NOT encode sensitive intent (project codenames, personnel actions, regulated-data identifiers) directly in purpose. When the human-readable purpose is sensitive, the AS should publish a stable but opaque URI and keep the sensitive label inside confidential audit context referenced by evidence_id.
• Cedar policies or other compiled policies should minimize embedded user identifiers.
• TLS is required for all Mission-related endpoints.
• SSF/CAEP events should carry Mission state changes, not prompt text or policy bodies.

Main threats and mitigations:

• Stale Mission state. Mitigate with short-lived tokens, introspection, and SSF/CAEP invalidation.
• Untrusted Mission origin. A malicious assertion issuer could point mission.origin at a trusted AS. Mitigation: Resource ASes accept Mission origins only when bound to the trusted issuer by local policy, ID-JAG metadata, or a configured trust framework.
• Mission identifier enumeration. Mitigate with high-entropy identifiers, authenticated introspection, and rate limiting.
• Policy injection from LLM output. The LLM emits structured proposals only; the AS validates the proposal and compiles any formal policy after consent. Pinning intent at consent time with proposal_hash avoids relying on post-hoc reconstruction of user intent from agent behavior.
• Silent constraint loss. A derivation path could drop constraints it does not understand while preserving broad scopes. Mitigation: unknown constraints on any authorization_details entry are preserved, narrowed, or cause refusal; they are not silently ignored.
• Downstream over-granting. A Resource AS could treat an ID-JAG as sufficient authorization and issue broader local tokens. Mitigation: Resource ASes apply local policy and bind local tokens to Mission bounds, expiry, and tenant context.
• Sender-constraint decoupling. Keep sender constraints stable inside a Mission; treat key rotation as a new approval boundary.
• Audience replay. ID-JAG audience validation prevents assertions for one Resource AS from being used at another.
• Confused deputy through sub-agents. The act chain names the executing actor, while the Mission bounds maximum authority.
• Audit tampering. Use append-only, integrity-protected audit storage.
• Long-lived Missions. Enforce maximum Mission lifetimes by purpose and expose user revocation.
• Cross-tenant leakage. Include tenant context in the Authority Model and introspection policy.

IBAC Enforcement Profile

The Minimum Profile delivers Mission-bound token issuance and lifecycle gating. Mission-Bound OAuth becomes Intent-Based Access Control (IBAC) when the Mission is not only a token-bounding object, but the authoritative input to runtime policy decisions for every consequential agent action.

This profile is OPTIONAL for v1 deployments and REQUIRED for any deployment that claims request-time intent enforcement. It strengthens several Minimum Profile SHOULD-level requirements to MUST-level for the policy layer, and adds requirements the Minimum Profile does not impose at all.

Several threats in the Privacy and Security section are mitigated more strongly under IBAC than under MVP alone. Silent constraint loss is reduced from “preserve verbatim or refuse” to “refuse on unknown constraint”: the PDP MUST understand every approved constraint or refuse the request. Downstream over-granting is constrained at request time, not only at token issuance, because RS-B or higher and the runtime policy gate evaluate every consequential request against the approved bundle. Confused deputy through sub-agents is bounded more tightly because the act chain is required on every Mission-bound token and the PDP evaluates the chain on every decision. Stale Mission state and audience replay are unchanged: IBAC strengthens the policy-state layer, not the token-state or Mission-state layer.

Intent-to-Policy Compilation

The IBAC AS MUST compile the approved authorization_details array into an evaluable policy artifact at the moment the Mission transitions to active. The compiled artifact MAY be Cedar, OpenFGA tuples, AuthZEN policy, or any internal representation; the compilation MUST be deterministic and reproducible from the same approved array. The compiled artifact is stored on the Mission record and consulted by every PDP evaluation. Clients do not submit compiled policy at PAR; the AS owns the compilation step.

Resource-Side Enforcement Contract

IBAC deployments require RS-B or higher. Every consequential request MUST be evaluated against the Mission’s approved bounds, covering: resource, action, constraints, actor (matches the approved act chain), tenant, time (within mission_expiry and any time-based constraints), risk signals (deployment-defined), and purpose (consistent with the Mission’s purpose URI). RS-A is insufficient for IBAC: a token check without authority evaluation does not enforce intent at request time.

Standard Subset Semantics per RAR Type

The Minimum Profile’s per-entry, per-type subset rule applies. IBAC tightens it:

• Action hierarchy. When actions form a containment hierarchy, the RAR type metadata MUST define the relation. Derived actions are evaluated under the hierarchy, not just under exact set inclusion.
• Resource containment. When resource URIs form a containment hierarchy (folders, projects, organizations), the RAR type metadata MUST define the relation. Derived resources MAY narrow to a contained resource if the type permits.
• Constraint preservation. Every approved constraint MUST be evaluated by the PDP. Constraints the PDP does not understand MUST cause refusal. This is stricter than the Minimum Profile baseline, which permits an AS to preserve an unknown constraint verbatim instead of refusing.
• Conflict handling. When two approved entries appear to grant overlapping authority with conflicting constraints, the PDP MUST take the more restrictive intersection.

Tool and Action Binding

IBAC binds approved authority to concrete tools, OpenAPI operations, MCP tool identifiers, or workflow steps. The AS MUST consult a tool manifest (RFC 9728 PRM extension, MCP server manifest, OpenAPI document, or equivalent) at approval time and bind each approved resource_access.actions value (or ecosystem-specific equivalent) to a stable tool identifier. Derived requests MUST present the tool identifier; the PDP MUST validate that the identifier is in the approved set. Tool-manifest drift after approval MUST cause refusal or trigger Mission Expansion; it MUST NOT silently broaden the agent’s authority.

Runtime Denial and Escalation

Every PDP denial that would fall within client registration and deployment policy if expanded MUST be returned as a requestable denial through AuthZEN Access Request (draft-mcguinness-authzen-access-request). The orchestrator MAY initiate a Mission Expansion from the denial response. Terminal denials (out of client registration, against deployment policy) MUST be returned without an escalation handle. This turns “agent exceeded the Mission” into a governed approval workflow rather than a silent failure. Under IBAC the escalation loop is MUST, not SHOULD.

Mission Introspection Profile

IBAC RS/PDPs need a richer introspection response than the Minimum Profile baseline. The IBAC Mission introspection response MUST include:

• All Minimum Profile minimum fields (id, origin, state, and when active: expiry, purpose, proposal_hash).
• The authorization_details entries relevant to the requesting audience.
• tenant and subject claims.
• The act chain when sub-agent delegation is in effect.
• The compiled policy artifact version or fingerprint, so the PDP can detect compilation drift between issuance and evaluation.

Actor and Provenance Chain

IBAC requires actor binding on every Mission-bound token and ID-JAG, not only on sub-agent paths. The act chain MUST identify the orchestrator client instance, each sub-agent in the delegation chain, the tool or workflow step invoking the action when applicable, and the human approver when the action was authorized through a human-in-the-loop step. Actor receipts (per draft-mcguinness-oauth-actor-receipts) are RECOMMENDED for high-risk Mission classes and MUST be supported by IBAC-compliant deployments even when not always emitted.

Audit Receipts

Every PDP decision on a consequential action MUST produce an audit receipt containing mission.id, mission.origin, proposal_hash, the action identifier, the action parameters or a hash of them when parameters contain sensitive data, the compiled policy version evaluated, the decision (permit or deny) and the constraint clauses that drove it, the actor chain at the time of the decision, and the resulting Mission Expansion request if any. Receipts MUST be append-only and integrity-protected. They are the evidence record that the agent stayed within the user’s approved intent. This strengthens the lifecycle audit-record shape described in Operational Requirements: MVP requires the record shape per Mission lifecycle event; IBAC additionally requires a per-decision receipt for every consequential action.

Governed Purpose Registry

IBAC requires a governed registry of mission_intent.purpose URIs. Each registered purpose MUST declare the allowed resource types and actions, the required and forbidden constraints, the risk class and escalation rules, the display language for consent rendering with localization, and the maximum Mission lifetime and reauthorization cadence. Free-form purpose URIs are insufficient for IBAC. The registry MAY be operated by the AS, by an organizational governance authority, or by an industry body.

Local-Action Boundary

The Minimum Profile explicitly leaves non-OAuth local actions outside the wire-level MVP. IBAC brings them into scope. Every consequential local action that is not an OAuth-protected API call (tool invocations, file writes, payment confirmations, internal side effects) MUST be governed by an AuthZEN Access Evaluation against the Mission before execution. The orchestrator MUST NOT execute consequential local actions inline; it MUST consult the PDP. The boundary between “consequential” and “not consequential” is deployment policy, but the default classification SHOULD treat any action with external side effects, irreversible state changes, or material consequence as consequential.

Standards Composition

Both profiles are mostly composition. The Minimum Profile names how existing OAuth surfaces participate in Mission state; the IBAC Enforcement Profile additionally names which surfaces become mandatory for runtime policy enforcement.

Minimum Profile composition

The Minimum Profile does not invent a new authorization protocol. It defines a small binding layer across RAR, PAR, Token Exchange, JWT access tokens, introspection, revocation, and ID-JAG.

IBAC Enforcement Profile composition

These rows describe what IBAC additionally requires or strengthens beyond the Minimum Profile.

The IBAC profile turns the Minimum Profile’s token-binding model into a runtime authority model: the Mission is not only a token-bounding object, it is the authoritative input to every PDP decision for every consequential agent action.

Gaps and Open Issues

The two layers have different open questions. The Minimum Profile questions are about the token/Mission binding layer. The IBAC questions are about runtime request-time enforcement.

Minimum Profile Open Issues

☐ Naming. Is mission the right claim name, or would authorization or mandate fit OAuth terminology better?

☐ resource_access standardization. The Minimum Profile defines resource_access as a generic per-resource RAR type with resource, actions, and constraints. Should resource_access be promoted to a standalone IETF RAR type usable outside Mission-Bound OAuth, or should it stay tied to this profile? If a richer generic type emerges elsewhere (for example, the eventual outcome of draft-chen-oauth-rar-agent-extensions), should the Minimum Profile defer to it?

☐ Termination default. Should refresh-token revocation terminate the whole Mission by default, or should it default to per-token revocation?

☐ Refresh-token coupling. Should Mission lifetime be independent of refresh-token lifetime, or should one bound the other?

☐ Event types. Should Mission state event URIs live under an IETF namespace, an OpenID Foundation namespace, or deployment-specific namespaces?

☐ Mission receipts. Portable consent/provenance evidence is companion work. What is the smallest receipt profile that composes with the proposal_hash and consent_rendering_hash already defined here?

☐ Mission Log retrieval. Audit records are produced per Mission lifecycle and derivation event, but the Minimum Profile does not define how a governance team or post-incident reviewer fetches them by mission.id at the originating AS. Should this be an extension to RFC 7662 introspection (for example, a mission_log=true parameter that returns an ordered array), a separate governance read API, or strictly deployment-specific?

☐ Mission management API. The profile requires user/admin lifecycle operations by mission.id, but does not define the API. Should that API be standardized in v1 or left to deployment/admin surfaces?

☐ Mid-approval clarification. Today the user either approves or rejects the submitted proposal. A later profile could standardize a back-and-forth clarification handshake using a concrete wire shape on top of PAR plus Deferred Code:

1. Pause. The agent posts a Mission Proposal through PAR. The AS holds the Mission in pending_approval and the user reviews the rendering.
2. Object. The user rejects part of the proposal (for example, “you can read calendar events but not write them”). Rather than terminating the authorization, the AS returns a 412 Precondition Failed (or an error="interaction_required" response with a clarification_handle field) carrying a machine-readable description of which entries or fields the user objected to.
3. Revise. The orchestrator submits a revised mission_intent array through PAR, referencing the clarification_handle. The new submission replaces the prior request_uri. The AS associates the revised proposal with the same pending Mission record.
4. Approve. The user sees the revised rendering. The AS computes consent_rendering_hash over the revised view and proposal_hash over the revised array, and releases the deferred code.

Deferred Code by itself is the “pause button” for OAuth: it lets the AS hold approval open while waiting for an out-of-band decision. It does not natively support “rewind and edit” of the proposal. A clarification-handshake profile would add that, and would let real human-in-the-loop negotiation happen on-the-wire instead of in deployment-specific UX glue.

☐ Mission amendment model. The Minimum Profile says expansion always creates a successor Mission. A later profile could allow a hybrid model: in-place version bumps for non-structural changes (extending mission_expiry by a small delta, tightening a constraint, narrowing an action) versus successor Missions for structural changes (adding a new resource_access entry, raising the budget cap, broadening tenant scope). The Mission record would carry a version field with an internal hash chain that the AS extends per in-place bump; successor Missions still get a new mission.id and a fresh proposal_hash. The open question is where the boundary lies and how the proposal_hash and consent-rendering semantics evolve under in-place bumps. Done right, this keeps the audit chain immutable while preventing database bloat from trivial extensions; done wrong, in-place mutation reopens the consent integrity question that proposal_hash was meant to close.

☐ Superseded terminal state. If expansion creates a successor Mission, should the prior Mission transition to completed, revoked, or a distinct superseded terminal state? A distinct state would let analytics and audit distinguish “Mission ended because the task was finished” from “Mission ended because authority was expanded.”

☐ Common context constraints. The Minimum Profile defines mission_intent.context as the place for cross-cutting Mission bounds, but it does not standardize a common catalog. Should a later profile standardize fields such as max_budget, currency, max_calls, max_duration, assurance_level, risk_tier, geo bounds, or data-classification bounds (as in draft-chen-oauth-rar-agent-extensions), or leave them to ecosystem RAR types and deployment-defined context fields?

☐ Per-sub-agent revocation inside an active Mission. Today the only standardized response to a compromised sub-agent is to revoke the whole Mission, which also terminates the parent and any sibling sub-agents. Mission-wide revocation is too destructive for long-running workflows where the parent has already completed most of a multi-step task using other healthy sub-agents. A later profile could define a revoke_actor mechanism keyed on the compromised actor’s identity at a specific act hop: the AS targets the cnf thumbprint at that hop and propagates an SSF/CAEP event (for example, https://schemas.example.com/mission/actor-revoked with mission.id, the targeted cnf.jkt, and the affected act position). Resource ASes that consume the event invalidate local tokens bound to that thumbprint; the parent orchestrator can then request a fresh sub-agent assertion under the same mission.id with a new cnf key and continue the task. The Mission state machine remains active throughout; only the compromised actor’s tokens are evicted.

☐ Key-compromise lifecycle event. The Mission state machine handles user-initiated revocation, AS-initiated suspension, and natural expiry, but not “this cnf key is compromised.” Today the response is Mission-wide revocation. A later profile could compose with CAEP session-revoked semantics scoped to the actor session, terminating only tokens bound to the compromised key while leaving the Mission active.

IBAC Enforcement Profile Open Issues

☐ Formal policy. Should a later profile define a recommended AS-compiled policy format, or leave formal policy entirely deployment-specific?

☐ Tool-manifest binding. Tool-bound narrowing is useful deployment practice but not part of the Minimum Profile. Should a later profile bind mission_intent to tool manifests using {uri, digest}, signatures, or some richer manifest format?

Standards Path

The natural shape is a single Internet-Draft, draft-mcguinness-oauth-mission-bound-minimum-profile, that profiles existing OAuth specs and defines the compact core surface:

• mission_intent RAR type (Mission envelope: purpose, mission_expiry, and deployment- or ecosystem-defined context).
• resource_access RAR type (generic per-resource authority: resource, actions, constraints).
• mission JWT claim (object with id and origin on tokens; AS extends with state, expiry, purpose, proposal_hash, consent_rendering_hash, supersedes on introspection responses).
• Mission-Bound OAuth grant-profile identifier, likely urn:ietf:params:oauth:grant-profile:mission-bound.
• Inactive-Mission signaling at the token endpoint (error_uri="urn:ietf:params:oauth:mission-inactive" plus mission_state) and at introspection (mission.state).
• proposal_hash as the canonical hash of the entire approved authorization_details array (envelope plus resource authorities), computed using JCS (RFC 8785) and surfaced on the Mission record, introspection responses, and audit records.
• consent_rendering_hash as the hash of what the user actually saw at approval time, surfaced in audit and receipt-oriented artifacts.
• Minimum cross-AS validation rules binding mission.origin to a trusted assertion issuer and preserving Mission bounds on downstream local tokens.

The companion drafts remain independent: ID-JAG, Actor Profile, Client Instance Assertion, Deferred Code, Insufficient Claims, Target Service Discovery, RAR Metadata, Trust Framework, Domain-Authorized Issuer Discovery, and Actor Receipts.

The IBAC Enforcement Profile would ship as a companion Internet-Draft, draft-mcguinness-oauth-mission-bound-ibac-profile, layered on top of the Minimum Profile. Its normative additions are:

• Intent-to-policy compilation requirement (AS-side, deterministic, reproducible).
• Tool-and-action binding to manifest-identified tools at approval time.
• Mandatory runtime escalation via AuthZEN Access Request (raised from SHOULD to MUST).
• Local-action policy gate via AuthZEN Access Evaluation for non-OAuth actions (raised from SHOULD to MUST).
• Extended Mission introspection response (compiled policy version, act chain, tenant, subject, audience-relevant authorization_details).
• Mandatory act chain on every Mission-bound token, not only sub-agent paths.
• Per-decision audit receipts bound to mission.id, mission.origin, proposal_hash, compiled policy version, decision, constraint clauses, and actor chain.
• Governed mission_intent.purpose registry with declared bounds, risk class, escalation rules, and reauthorization cadence.

Later profiles can add tool-manifest binding signatures, Mission receipts, formal policy projection, per-actor revocation, and key-compromise lifecycle events without changing the Minimum Profile’s core wire shape.

Mission-Bound OAuth as architecture is the destination. The Minimum Profile is the minimum useful step: capture intent, persist it, derive from it, and terminate it independently of token expiry.