Overview

The OAuth Profile Core defines the irreducible Mission-Bound OAuth surface: mission_intent at PAR, the Mission record, mission_resource_access derivation, the mission claim, and the Mission-state gate. This companion specifies the composition extensions a deployment adopts as it climbs the Capability 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. None is required for a Capability 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 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 the Runtime Enforcement Profile evaluates it).

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 (the Shaper Profile’s 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 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:

 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

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": "mission_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:

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

{
  "validated_authority": [
    {
      "type": "mission_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; 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.

Adoption note. This handshake requires Resource ASes to publish delegated_validation_endpoint and accept validation requests from authorized consumer ASes. It is a proposed surface and cannot be assumed available. The proposal is most useful where the same organization operates both ends (and can deploy them in coordination), or where an ecosystem agrees on the contract as part of a broader open-world MCP profile. Deployments that cannot rely on Resource AS cooperation should use Path B (resource-side FGA) instead. PDP evaluation at request time avoids the need for an AS-to-Resource-AS handshake entirely. The Delegated Authority Validation profile is a coordination pattern, not something a single deployment can adopt unilaterally.

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 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 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 the 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 the 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 Capability Ladder levels; the mapping is called out per stage.

Stage 0: Where you are today

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 Capability Ladder Level 1 with AD-1.

Stage 4: Resource Server uptake

Per-RS, not coordinated. Each Resource Server moves up the RS Tier ladder 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 mission_resource_access entries.
• RS-C to RS-D: RS adopts per-action enforcement against the Runtime Enforcement Profile.

When every consequential RS reaches RS-C and the issuer reaches AD-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 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 and must not invent one; only the IdP performs subject translation.

This extension defines a new Chain Continuation Assertion token type:

1

urn:ietf:params:oauth:token-type:chain-continuation+jwt

Its JOSE typ value is:

1

oauth-chain-continuation+jwt

The assertion is not an ID-JAG, access token, or transaction token. It is short-lived evidence from an IdP-trusted Chain Authority that an authenticated actor is continuing a delegation rooted in an earlier IdP authentication. It is accepted only by the IdP as a Token Exchange subject_token for onward ID-JAG issuance.

Stable Client Request, New IdP Processing

The chained request preserves the direct ID-JAG request’s outer Token Exchange parameters. The client changes the subject_token value and subject_token_type; audience, resource, scope, and requested_token_type retain their direct-call meanings:

1
2
3
4
5
6
7
8
9

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
&actor_token=<service-b-credential>
&actor_token_type=<actor-token-type>

This is a client ergonomics property, not protocol reuse by the IdP. ID-JAG -04 defines identity assertions and, optionally, IdP refresh tokens as subject tokens; it does not define this continuation-token type. The continuation case is needed when the downstream SaaS actor has valid chain context but does not possess the user’s root identity assertion or IdP refresh token. An implementation must add Chain Continuation Assertion validation, Chain Authority trust policy, delegation-context lookup, replay handling, and onward-ID-JAG issuance rules.

Root Delegation Context

When the IdP issues an initial ID-JAG that may be continued, it creates an opaque dlg_id containing at least 128 bits of entropy. The IdP binds that value server-side to:

• the root authentication event and IdP-internal subject;
• the initial client and authenticated actor context;
• auth_time, acr, and amr;
• the Mission reference and authority_hash, when Mission-Bound Authorization is in use;
• maximum resource, audience, scope, tenant, and lifetime bounds; and
• an active, suspended, revoked, expired, or completed lifecycle state.

The initial ID-JAG carries dlg_id through a registered extension claim. Every continuation assertion and onward ID-JAG carries the same value unchanged. Resource ASes and SaaS services treat it as opaque. It contains no user-identifying information and is not authorization proof by itself.

The IdP is the only party that resolves dlg_id to its internal subject and then derives the audience-appropriate subject claims for the onward ID-JAG. A Chain Authority need not know, and should not receive, another SaaS audience’s subject identifier.

Chain Authority Trust

A Chain Authority may be a TTS or another service that receives authenticated inbound chain context and is authorized by the IdP to attest continuation. The IdP registers or otherwise establishes:

• the Chain Authority issuer identifier and verification keys;
• allowed signing algorithms;
• clients, tenants, and actor classes for which it may attest;
• permitted target audiences and resources, or a policy reference that computes them;
• maximum delegation depth and assertion lifetime; and
• required sender-constraint and actor-authentication methods.

Trust in the issuer is necessary but not sufficient. The current actor is independently authenticated through actor_token or another IdP-accepted client authentication mechanism and must match the assertion’s terminal actor and sender constraint.

Assertion Claims

An assertion has this minimum shape:

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

{
  "iss": "https://tts.saas2.example/",
  "sub": "pairwise-or-chain-local-subject",
  "aud": "https://idp.example/",
  "iat": 1710000500,
  "exp": 1710000800,
  "jti": "continuation-assertion-1",
  "dlg_id": "01JZ8F4J9J8Y3NDK5WQ4P9K7Q2",
  "mission": {
    "id": "msn_01J9Z2P8BQ4Y3F0V0K9D6Z7M1",
    "origin": "https://missions.example/"
  },
  "authority_hash": "base64url-sha256",
  "auth_time": 1710000000,
  "acr": "urn:example:loa:2",
  "amr": ["pwd", "mfa"],
  "act": {
    "iss": "https://saas2.example/",
    "sub": "service-b",
    "act": {
      "iss": "https://saas1.example/",
      "sub": "client-a"
    }
  },
  "resource": ["https://api3.example/"],
  "scope": "orders.read",
  "cnf": {
    "jkt": "base64url-jwk-thumbprint"
  }
}

The sub value is meaningful in the Chain Authority’s assertion context; it is not required to equal the subject identifier the IdP will issue for RAS3. This profiles RFC 8693’s usual expectation that the subject token’s subject becomes the issued token’s subject: the IdP instead resolves the root subject through dlg_id and emits its target-audience identifier. Requested target authorization remains in the Token Exchange request’s audience, resource, and scope parameters. The assertion carries upper bounds for those values rather than a second permitted_audiences vocabulary.

IdP Validation and Issuance

The IdP issues an onward ID-JAG only after it:

• validates the assertion signature, typ, trusted iss, IdP aud, lifetime, and unique jti;
• rejects replay, normally by retaining (iss, jti) through exp; higher-risk profiles may require one-time use;
• validates dlg_id as known, active, and eligible for continuation;
• binds the assertion to the root subject, authentication context, Mission, tenant, and maximum authority stored for dlg_id;
• verifies that asserted auth_time, acr, and amr do not strengthen or contradict the root context;
• authenticates the current actor and validates the terminal act entry, maximum depth, and actor authority;
• validates the cnf sender constraint against the current request;
• verifies that requested audience, resource, and scope are within the root delegation, Mission authority, Chain Authority policy, and assertion bounds; and
• applies normal ID-JAG policy before deriving the target-audience subject and claims.

The onward ID-JAG is issued by the IdP, has the requested Resource AS as audience, carries the unchanged dlg_id, preserves or updates the actor chain according to the ID-JAG profile, and contains subject-resolution claims appropriate to that Resource AS. The Chain Authority never mints the ID-JAG.

Discovery and Errors

Because this is an ID-JAG extension, an IdP that supports it needs metadata advertising the continuation subject-token type and supported assertion signing algorithms. Candidate metadata members are:

• id_jag_subject_token_types_supported: an array that includes urn:ietf:params:oauth:token-type:chain-continuation+jwt; and
• chain_continuation_assertion_signing_alg_values_supported: the accepted JWS alg values.

A concrete specification must register the final metadata names. Chain Authority authorization policy and the issuer allowlist may remain private; metadata advertises protocol capability, not trust in arbitrary issuers.

The token endpoint uses existing OAuth and Token Exchange errors where possible:

• malformed requests or unsupported token types: invalid_request;
• invalid, expired, replayed, untrusted, or unbound continuation assertions: invalid_grant;
• disallowed audience or resource: invalid_target;
• scope outside the permitted bounds: invalid_scope; and
• inactive Mission or delegation context: invalid_grant, with profile-defined mission_state or delegation-state detail when disclosure policy permits.

Error descriptions must not reveal whether an otherwise unknown dlg_id belongs to a user, tenant, or Mission. Implementations should return the same external error for unknown, revoked, and unauthorized delegation contexts unless the caller is entitled to more detail.

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

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

• Mission-Bound OAuth Profile (Core)
• Mission Shaper Profile
• Mission-Bound Runtime Enforcement Profile
• Mission-Bound Authorization Capability Model
• Transaction Token Chaining Profile
• ID-JAG
• RFC 8693: OAuth 2.0 Token Exchange
• RFC 9126: OAuth 2.0 Pushed Authorization Requests
• RFC 9396: OAuth 2.0 Rich Authorization Requests