Abstract

Companion to Part 3 Core. 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 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 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 (Part 2 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 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": "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": "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.

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

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

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

1
2
3
4
5
6
7

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

• Part 3: Mission-Bound OAuth Profile (Core)
• Part 2: Mission Shaper Profile
• Part 6: Mission-Bound Runtime Enforcement Profile
• Part 8: Mission-Bound Authorization Conformance
• 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