---
title: "Mission-Bound OAuth Extensions"
date: "2026-06-06T12:30:00-07:00"
lastmod: "2026-06-06T12:30:00-07:00"
description: "Composition extensions to the Mission-Bound OAuth Profile Core. Delegated Authority Validation for open-world tool semantics, Concurrent Mission Expansion reconciliation, Token Size at Depth, the Common Constraints Catalog, Chain Continuation Assertions for same-IdP SaaS chains, Transaction Token Chaining composition, and the Stage 0-5 migration story."
summary: "The Core OAuth Profile defines the irreducible minimum: Mission Intent, Mission record, resource_access derivation, mission claim, and Mission-state gate. This companion post specifies the composition extensions a deployment adopts as it climbs the Conformance Ladder or addresses open-world tool semantics, deep delegation chains, concurrent expansion, governed budgets, and cross-trust-domain chaining."
slug: "mission-bound-oauth-extensions"
tags:
  - "OAuth"
  - "Authorization"
  - "Agentic Identity"
  - "Mission-Bound Authorization"
  - "Internet-Draft"
---


# Abstract

**Companion to [Part 3 Core](/notes/mission-bound-oauth-profile/).** Part 3 defines the irreducible Mission-Bound OAuth surface: `mission_intent` at PAR, the Mission record, `resource_access` derivation, the `mission` claim, and the Mission-state gate. This companion post specifies the composition extensions a deployment adopts as it climbs the Conformance Ladder or addresses surfaces Core deliberately leaves open: open-world tool semantics, deep delegation chains, concurrent expansion, governed budgets, same-IdP SaaS continuation, and cross-trust-domain chaining.

The extensions in this post compose with Core. None of them is required for a Conformance Level 1 deployment; each adds capability when a deployment reaches the relevant adoption stage.

# Common Constraints Catalog

Mission Intent's `constraints` field carries user-readable bounds. The `context` extension carries machine-actionable bounds. This section standardizes a base catalog of `context` keys with stable semantics so cross-vendor deployments can express common bounds without inventing parallel vocabularies. Profiles MAY register additional keys; the [unknown-constraint rule](/notes/mission-bound-oauth-profile/#authority-model) applies to every key not in this catalog or otherwise registered.

Each catalog key has a stable name in the `context` object, a Mission-level commitment semantics (how `authority_hash` covers it), and a runtime enforcement contract (how a PDP under [Part 6](/notes/mission-bound-runtime-enforcement-profile/) evaluates it).

| Key | Type | Mission-level semantics | Runtime enforcement (Part 6) |
| --- | --- | --- | --- |
| `max_budget` | object `{ amount, currency }` | Hard cap on cumulative monetary spend under this Mission. Cannot be exceeded by attenuation alone | PDP performs atomic reserve or charge per consequential action; refuses when remaining balance is insufficient |
| `max_calls` | object `{ scope, count }` | Hard cap on count of derivation or call events of the named scope | PDP increments an atomic counter and refuses past the cap |
| `max_duration` | RFC 3339 duration | Maximum wall-clock duration of consequential activity under this Mission (distinct from `mission_expiry`) | PDP tracks elapsed time since Mission activation and refuses past the cap |
| `assurance_level` | string from a deployment or profile-registered enum (e.g., `nist_aal2`) | Minimum authentication assurance required for the approving principal and any actor in the chain | PDP refuses when authenticated actor context does not meet the level |
| `risk_tier` | string from a deployment or profile-registered enum | Risk classification used to gate stricter freshness, action classification, and step-up requirements | PDP applies tier-specific staleness bounds and action-classification overrides |
| `geo_bounds` | object `{ allow: [], deny: [] }` of region identifiers | Geographic scoping of permitted resources or actions | PDP refuses when authenticated context (IP, attested location, tenant region) falls outside `allow` or matches `deny` |
| `data_classification` | object `{ allow: [], deny: [] }` of classification labels | Data-classification scoping (e.g., `public`, `internal`, `confidential`, `regulated`) | PDP refuses when accessed resource carries a classification not in `allow` or in `deny` |

Rules:

- Catalog keys committed in `context` MUST be covered by `proposal_hash` over the post-validation Mission Intent.
- The AS MUST refuse derivation requests whose effective bounds violate any committed catalog key.
- Atomic counters and time-based bounds require an authoritative state holder. The natural home is the state authority identified by `mission.origin`; a deployment MAY designate a separate counter service that the state authority authenticates and trusts.
- Mission Expansion is the path for raising a committed catalog bound. In-place mutation is forbidden because the bound is part of `proposal_hash`.
- Profiles MAY extend the catalog through registered RAR-type metadata or a deployment-defined registry. The unknown-constraint rule applies to every unregistered key.

This catalog turns "gas controls" (budget, duration, call counts) and risk-tier governance from deployment-private extensions into a shared vocabulary that auditors and cross-vendor deployments can verify in common.

# Delegated Authority Validation

The AS owns final Authority Derivation, but in open-world deployments it may not know the resource's domain ontology. The Shaper supplied source-bound, non-authoritative derivation hints (`source_uri`, `operation_ref`, `source_digest`) from MCP `tools/list`, OpenAPI, or PRM-linked catalogs ([Part 2 Tool and Action Binding](/notes/mission-shaper-profile/#tool-and-action-binding)). Before the AS commits derived `authorization_details`, it MAY delegate domain-semantics validation to a Resource AS that owns the operation. This is the explicit composition point [Part 7](/notes/least-privilege-mcp-tool-calls/) calls "delegated evaluation" — the AS asks the Resource AS to validate proposed authority against current resource semantics.

The handshake is a server-to-server exchange between the AS and the Resource AS. It is not on the client-AS wire. A Resource AS that publishes this surface advertises it through PRM with an additional metadata member, `delegated_validation_endpoint`. The AS authenticates as a registered consumer.

A representative AS-to-Resource-AS request:

```http
POST /mission/validate-authority HTTP/1.1
Host: ras.example.com
Content-Type: application/json
Authorization: Bearer <as-client-credentials>

{
  "consumer_issuer": "https://as.example.com",
  "mission_intent": {
    "goal": "Prepare the Q3 board packet",
    "objects": ["Q3 financials"],
    "constraints": ["confidential classification"]
  },
  "candidate_authority": [
    {
      "type": "resource_access",
      "resource": "https://ras.example.com",
      "actions": ["query_financials"],
      "constraints": { "period": "Q3 2026" },
      "source_uri": "https://ras.example.com/mcp",
      "operation_ref": "mcp:tool/query_financials",
      "source_digest": "sha256:..."
    }
  ],
  "tenant": "example-corp",
  "purpose": "urn:example:mission:board-packet",
  "client_id": "agent.example.com"
}
```

The Resource AS response:

```json
{
  "validated_authority": [
    {
      "type": "resource_access",
      "resource": "https://ras.example.com",
      "actions": ["query_financials"],
      "constraints": {
        "period": "Q3 2026",
        "entity": "Example Corp"
      },
      "operation_ref": "mcp:tool/query_financials@v1.2",
      "source_digest": "sha256:..."
    }
  ],
  "refused": [],
  "expires_at": "2026-06-06T19:00:00Z",
  "validation_id": "val_01J9Z..."
}
```

The Resource AS:

- Validates each candidate entry against current operation semantics.
- MAY narrow `actions` or `constraints` to the operation's actual surface.
- MAY add resource-domain constraints the AS could not have known (e.g., a required `entity` field that `query_financials` enforces).
- MAY refuse entries that reference operations not present, deprecated, or not authorized for this client and tenant. Refused entries are returned in `refused` with a `reason` classifier.
- Returns a short-lived response bound to the candidate authority via `source_digest`.

The AS:

- MUST validate the Resource AS issuer against its trust framework before accepting the response.
- Treats the response as authoritative for resource-domain semantics within the response's freshness window (`expires_at`).
- Includes the narrowed entries in the AS-derived `authorization_details` consented to by the user.
- Commits `authority_hash` over the final form.
- Stores the Resource AS's `validation_id` on the Mission record as evidence so audit can reconstruct what the Resource AS approved at derivation time.

A discrepancy between the Shaper-supplied `source_digest` and the Resource AS's current view of the source is a drift signal under the [Runtime Enforcement Profile Tool Binding Module](/notes/mission-bound-runtime-enforcement-profile/); the Resource AS MAY refuse, or it MAY require Mission Expansion per its declared policy.

This handshake closes the open-world ontology gap in Path A (token-side FGA) without requiring the AS to learn every Resource AS's domain model. Path B deployments do not need it because resource-side FGA evaluates at the Resource Server's PDP at request time. A deployment MAY use both: delegated validation at derivation, and PDP evaluation at request time.

# Concurrent Mission Expansion

A long-running multi-actor Mission may have multiple sub-agents hit out-of-bounds denials simultaneously, each triggering a [Mission Expansion](/notes/mission-bound-oauth-profile/#mission-expansion) request. The state authority MUST reconcile concurrent proposals deterministically to prevent diverging successor Missions or lost approvals.

Reconciliation rules:

- **Idempotent collapse on identical proposals.** Two proposals over the same approving principal, the same prior `mission.id`, and the same JCS-canonical proposed Authority Set MUST collapse to one approval workflow. The state authority returns the same `expansion_request_id` to each proposer; on approval, one successor Mission is created and every proposer learns of it through the AuthZEN Access Request callback or polling response.
- **Sequential serialization for non-overlapping proposals.** When proposal A and proposal B request additive but distinct authority (different resources, different action sets, different constraint keys), the default reconciliation is sequential: proposal A is approved first, the successor Mission `msn_A` is activated, and proposal B is rebased onto `msn_A` before its own approval workflow begins. A deployment MAY declare a merge policy that produces one combined successor instead; the policy MUST be documented and the merge MUST present the combined disclosure for consent.
- **Rejection on conflict.** When proposals A and B request mutually exclusive bounds — for example, A asks for `geo_bounds.allow: ["US"]` and B asks for `geo_bounds.allow: ["EU"]` over the same resource — the state authority MUST reject the second proposal with a structured response carrying `error="expansion_conflict"` and `conflicting_expansion_id` identifying the first. The rejected proposer MAY resubmit a revised proposal that is consistent with the in-flight one or wait for the first to resolve.
- **In-flight expansion lock.** While any expansion proposal is pending approval, the state authority MUST hold a per-Mission expansion lock. Subsequent proposals are queued or rejected per the rules above. The lock prevents the state authority from accidentally creating two divergent successor Missions in flight. Sub-agents MAY continue executing under the prior Mission's existing authority while the lock is held; only the expansion request itself is reconciled.

These rules make concurrent expansion deterministic without serializing all sub-agent activity. The pipelining halt on a Mission Expansion request is a feature of the design, not a flaw: expanding user-approved authority necessarily requires a decision from the approver (user, administrator, risk engine, or policy). What concurrent reconciliation adds is that simultaneous expansion requests resolve to one approval outcome rather than racing to create conflicting successor Missions.

# Token Size at Depth

Nested `act` chains grow with delegation depth. A JWT carrying a five-hop chain plus `mission`, `authorization_details`, and `cnf` claims can exceed the 8–16 KB HTTP header buffer limits common at ingress proxies (Envoy, Nginx defaults). Three patterns mitigate this:

- **Bounded delegation depth.** A deployment SHOULD declare a maximum JWT delegation depth (typically 3–4 hops). Past that depth, derivation switches to opaque reference tokens. The Mission record at `mission.origin` retains the full chain server-side; the opaque token references it through introspection.
- **Chain-digest summarization.** A credential MAY carry `act_chain_digest` (base64url SHA-256 over the JCS-canonical nested `act` chain) plus only the immediate actor in `act`. The full chain is retained at the issuer and resolved through introspection or [Mission Status](/notes/mission-bound-runtime-enforcement-profile/) when the PDP evaluates. The PDP MUST verify the digest before treating the resolved chain as authentic. This preserves audit reconstruction without inflating credentials past ingress limits.
- **Flat-array projection at the PDP.** The credential carries the nested `act` per RFC 8693 conventions; the PEP translates to a flat-ordered array for the AuthZEN evaluation context per [Part 6](/notes/mission-bound-runtime-enforcement-profile/). The flat array is a serialization convenience for evaluation, not a separate authority claim — actors in the chain are not independently signed merely because they appear in the flat form.

Sender-constraint mechanism choice interacts with chain depth: DPoP carries one JWK thumbprint plus a per-request proof header; mTLS carries a certificate thumbprint in `cnf` and no per-request proof. At depth, DPoP keeps the credential smaller; mTLS shifts the size cost to the transport layer.

Whichever pattern a deployment chooses, the Mission record at `mission.origin` is the canonical source of the full delegation chain, and per-decision evidence under [Part 6](/notes/mission-bound-runtime-enforcement-profile/) records the authenticated chain regardless of credential format.

# Migration Story: Stages 0–5

This series-stage sequence is one practical operational path to incremental adoption on top of an existing OAuth deployment. Each stage delivers value on its own. The numerical stage labels do not correspond to Conformance Ladder levels; the mapping is called out per stage.

## Stage 0: Where you are today

| Surface | Typical state |
| --- | --- |
| Authorization Server | Issues JWT access tokens via `authorization_code` + PKCE; some clients use PAR; few use RAR. |
| Resource Server | Validates JWT signature, `aud`, `exp`, and a flat `scope` claim. May introspect (RFC 7662). |
| Refresh tokens | Multi-hour TTL. Refresh is mostly unconstrained until natural expiry. |
| Cross-AS | Token Exchange (RFC 8693) where present; no shared task identifier across hops. |
| Approval object | None. The user's task lives in the application; only authority lives in the protocol. |

Nothing in Stage 0 needs to change for Stage 1 to begin. The first stage is purely additive at the AS.

## Stage 1: Shadow Mission

The AS accepts `mission_intent` at PAR, validates against the published JSON Schema (`mission_intent_schema_uri`), renders for user approval alongside the existing consent screen, and creates an `active` Mission record on approval. The AS emits the `mission` claim on tokens. Tokens still carry the pre-existing flat `scope`; authority narrowing arrives in Stage 3.

- **AS changes:** Accept `mission_intent` at PAR. Persist a Mission record. Compute `proposal_hash`. Emit `mission` claim. Expose a user-visible inventory.
- **Client changes:** Add a Mission Shaper. Submit `mission_intent` at PAR alongside existing `scope` and `authorization_details`.
- **RS changes:** None. The `mission` claim is an unknown JWT claim that RSes ignore per RFC 7519.
- **Delivers:** Per-Mission audit join, user-visible inventory, integrity anchor on the user's approved intent.

Shippable behind a feature flag without breaking existing clients.

## Stage 2: Gate refresh and exchange on Mission state

The AS enforces Mission state at derivation boundaries. Refresh and same-AS Token Exchange succeed only while the underlying Mission is `active`. Revocation, suspension, completion, or expiry stops future derivation even though previously issued access tokens remain valid until their natural `exp`.

- **AS changes:** Gate refresh and exchange on Mission state. Implement the seven-state lifecycle. Return `error="invalid_grant"` with the `mission_state` extension on inactive-Mission rejections.
- **Client changes:** Handle inactive-Mission rejections gracefully.
- **RS changes:** None.
- **Delivers:** Long-running task revocation independent of token expiry. The user-visible inventory becomes the place where in-flight agent work can actually be stopped.

Stage 2 is the first stage where the Mission becomes load-bearing for security.

## Stage 3: Narrow authority from the Approved Mission

The AS begins deriving `authorization_details` from the Approved Mission and computes `authority_hash`. Tokens carry the narrowed RAR; the flat `scope` claim remains as the union of approved Mission scopes.

- **AS changes:** Implement Authority Derivation against client registration, resource metadata, and deployment policy. Render the derived authority. Compute `consent_rendering_hash`. Reject in-place authority changes (Mission Expansion is the supported path).
- **Client changes:** None mandatory.
- **RS changes:** None mandatory. RS-A continues on `scope` and audience.
- **Delivers:** User approval and issued authority structurally separated and cryptographically anchored.

After Stage 3 the deployment is at Conformance Ladder **Level 1** with Compliance Tier 1.

## Stage 4: Resource Server uptake

Per-RS, not coordinated. Each Resource Server moves up the [RS Tier ladder](/notes/mission-bound-authorization-conformance/#resource-server-tiers) on its own schedule.

- **RS-A to RS-B:** RS resolves Mission state through issuer introspection or Mission Status. Rejects inactive Missions.
- **RS-B to RS-C:** RS reads `authorization_details` and enforces against audience-relevant `resource_access` entries.
- **RS-C to RS-D:** RS adopts per-action enforcement against the [Runtime Enforcement Profile](/notes/mission-bound-runtime-enforcement-profile/).

When every consequential RS reaches RS-C and the issuer reaches Compliance Tier 3, the deployment is at Ladder **Level 3**.

## Stage 5: Cross-AS continuity

The originating AS adds Mission-aware ID-JAG issuance for downstream Resource ASes.

- **Originating AS:** Bind ID-JAG issuance to the active Mission, validate `subject_token`, cap `exp` at the deployment-profile maximum (recommended: 300 seconds).
- **Resource AS:** Accept the ID-JAG, validate `mission.origin` against local trust policy, apply local authorization, preserve `mission.id` and `mission.origin` on the locally issued token.
- **Delivers:** Cross-hop audit joins use the canonical Mission identifier or pairwise resolution at `mission.origin`. Revocation at the state authority terminates future derivation across audiences.

With Stage 5, the deployment reaches Ladder **Level 2** for the multi-AS surface and combines with Stage 4 for Level 3.

## Common back-compat hazards

- **Refresh tokens issued before Stage 1.** Honor them through their natural lifetime without Mission gating; require Mission Intent on the next interactive grant.
- **Long-lived service-to-service tokens (`client_credentials`).** Outside the Mission story.
- **Pre-existing RAR ecosystems (FAPI, OpenID4VCI, others).** Their RAR types remain valid. The AS treats them as derivation hints when a `mission_intent` is present and as authoritative when no `mission_intent` is present.
- **Clients without a Mission Shaper.** A deployment can require `mission_intent` per client-class registration.
- **Consent UX template versions.** `consent_rendering_hash` covers the canonical disclosure object including `template_version`. Updating the template is a routine operation.
- **JWT access token size.** Adding `mission` plus derived `authorization_details` enlarges access tokens. Deployments close to header-size limits should measure before Stage 3 rollout. See [Token Size at Depth](#token-size-at-depth) for mitigations at depth.

# Same-IdP Chain Continuation

In the most important enterprise chaining case, all Resource Authorization Servers trust the same IdP for SSO and subject resolution, but each API is protected by its own Resource AS. The chain may look like `ClientA -> SaaS1/RAS1 -> SaaS2/RAS2 -> SaaS3/RAS3`. The user authenticated once at the IdP, and the IdP may use different subject identifiers at each SaaS audience. Downstream SaaS services do not know the global subject mapping; only the IdP does.

For this case, the token request shape stays the same as the direct ID-JAG request. The client swaps only the `subject_token`:

```http
grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&requested_token_type=urn:ietf:params:oauth:token-type:id-jag
&audience=https://ras3.example/
&resource=https://api3.example/
&scope=orders.read
&subject_token=<chain_continuation_assertion>
&subject_token_type=urn:ietf:params:oauth:token-type:chain-continuation+jwt
```

The Chain Continuation Assertion is not an ID-JAG and does not grant access to the API. It is the proof artifact presented to the IdP so the IdP can decide whether to issue an onward ID-JAG for the requested `audience` and `resource`. Its minimum JWT claims are `iss`, `aud` identifying the IdP, `iat`, short `exp`, unique `jti`, `mission` (`id` or its IdP-resolvable projection plus `origin`), `authority_hash`, authentication context (`auth_time`, `acr`, and `amr` when present on the root authentication), the RFC 8693 `act` delegation chain, bounds covering the requested `resource` and `scope`, and `cnf` binding it to the current sender. A deployment MAY carry an IdP-issued opaque delegation correlation value when the Mission identifier is audience-pairwise; that value is correlation input, not authorization proof.

The IdP validates the assertion signature, `aud`, trusted `iss`, lifetime, replay status, sender constraint, Mission state and hashes, authentication-context non-escalation, actor authority, and that the requested `audience`, `resource`, and `scope` are within the committed Mission authority. It then resolves the target-audience subject and issues the onward ID-JAG. Only the IdP performs subject translation; no SaaS hop needs to know another audience's subject identifier.

# Transaction Token Chaining

When the agent is mid-task inside Trust Domain A and Txn-Tokens are already mediating intra-domain calls, the trust-domain crossing can use [Fletcher's chaining profile](https://datatracker.ietf.org/doc/draft-fletcher-transaction-token-chaining-profile/) instead of ID-JAG. The Txn-Token never leaves Trust Domain A.

1. Under the proposed MBO composition, the agent (or a workload acting on its behalf) holds a Txn-Token whose `tctx` carries `mission.id`, `mission.origin`, and optionally `proposal_hash` and audience-relevant authority.
2. The agent submits RFC 8693 Token Exchange to AS-A with `subject_token_type=urn:ietf:params:oauth:token-type:txn_token`, `subject_token=<Txn-Token>`, `audience=<AS-B issuer URL>`, and `requested_token_type=urn:ietf:params:oauth:token-type:jwt`.
3. AS-A mints a JWT Authorization Grant with `typ: txn-chain+jwt`, transcribing the originating `txn` claim. A future MBO composition defines which Mission fields are transcribed and how internal workload identifiers are filtered.
4. The agent presents the JWT Grant to AS-B using the RFC 7523 JWT-bearer grant.
5. AS-B validates the grant against trusted issuer policy, verifies Mission state through assertion freshness, authenticated status, or events, applies local authorization policy, and issues a local access token preserving the grant's Mission binding.

```mermaid
sequenceDiagram
    participant A as Agent / Workload
    participant AA as AS-A (Trust Domain A)
    participant AB as AS-B (Trust Domain B)

    Note over A: Holds Txn-Token<br/>tctx: mission.id, mission.origin
    A->>AA: Token Exchange<br/>subject_token_type = txn_token<br/>subject_token = Txn-Token<br/>audience = AS-B issuer
    Note over AA: Check Mission active<br/>Check audience within bounds
    AA-->>A: JWT Grant (typ: txn-chain+jwt)<br/>txn transcribed<br/>mission claims in txn_claims
    A->>AB: JWT-bearer grant<br/>assertion = JWT Grant
    Note over AB: Validate trusted issuer<br/>Check Mission state at mission.origin
    AB-->>A: Local access token<br/>bound to mission.id
```

The choice between paths is driven by the originating credential and trust model. Use direct ID-JAG when the caller can present a user-authenticated identity assertion. Use Chain Continuation Assertion when a same-IdP SaaS chain needs an onward ID-JAG and the IdP must remain the subject-resolution authority. Use the Txn-Token chaining profile when the Mission has been instantiated and intra-domain Txn-Tokens are the call-chain substrate.

# References

- [Part 3: Mission-Bound OAuth Profile (Core)](/notes/mission-bound-oauth-profile/)
- [Part 2: Mission Shaper Profile](/notes/mission-shaper-profile/)
- [Part 6: Mission-Bound Runtime Enforcement Profile](/notes/mission-bound-runtime-enforcement-profile/)
- [Part 8: Mission-Bound Authorization Conformance](/notes/mission-bound-authorization-conformance/)
- [Transaction Token Chaining Profile](https://datatracker.ietf.org/doc/draft-fletcher-transaction-token-chaining-profile/)
- [ID-JAG](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/)
- [RFC 8693](https://datatracker.ietf.org/doc/html/rfc8693): OAuth 2.0 Token Exchange
- [RFC 9126](https://datatracker.ietf.org/doc/html/rfc9126): OAuth 2.0 Pushed Authorization Requests
- [RFC 9396](https://datatracker.ietf.org/doc/html/rfc9396): OAuth 2.0 Rich Authorization Requests