The Power of Attorney series argued that agent authority needs to be bounded by purpose, scope, conditions, and lifecycle, not inferred from credentials alone.

The Mission-Bound OAuth RFC made that concrete: the Mission is the durable authority object at the authorization server, tokens and assertions are derived artifacts, and mission_ref is the projected handle that ties them together.

This post is about a narrower question: what role does the authentication layer play?

The short answer is that authentication is the one moment in an agent workflow when the user is present: when intent can be confirmed, step-up can happen, and approval evidence can be captured. That makes it the natural bootstrap point for a Mission. OpenID Connect Client Context is the mechanism for doing that cleanly. When Mission approval cannot complete synchronously, the OpenID Connect Deferred Token Response Flow (DTR) handles the asynchronous path. When the Mission later needs to cross into another authorization domain inside the same enterprise, ID-JAG (Identity Assertion Authorization Grant) is how a reduced Mission projection can travel without dragging the full authority model with it.

None of these is an alternative to Mission-Bound OAuth. Together they form an authentication-layer companion profile for it.

The Audience Problem

Take a concrete scenario. An agent is asked to schedule a meeting with the engineering team, send the invitations, and record the follow-up in the CRM. Three services. Three authorization servers (ASes). OAuth access tokens are audience-bound by design: the token issued for the calendar API is not valid at the CRM. That is intentional, as audience restriction prevents token replay across services, but it creates a structural problem for governed agent execution.

RFC 8693 token exchange exists for this. Rich Authorization Requests (RAR, RFC 9396) can shape what each token contains. The OAuth Identity Chaining draft profiles how identity propagates across AS boundaries. None of these, by themselves, create what a governed agent mission actually needs: a single durable authority object that all three token issuances trace back to, with a unified lifecycle that can be suspended, revoked, or terminated as a unit.

An agent mission that spans three authorization domains needs more than three shaped tokens. It needs one governed authority object behind them.

The challenge is not that no cross-domain mechanism exists. The challenge is that each target AS needs bilateral trust with the source AS, must understand the specific semantics being propagated, and must apply them consistently. Inside a single organization’s infrastructure, this can work. Across the vendor and SaaS ecosystem an enterprise agent actually operates in, it does not scale reliably.

That is exactly the gap Mission-Bound OAuth fills. Once the Mission exists at the AS, token exchange and RAR become derivation mechanisms, ways to mint audience-specific tokens inside the governed envelope. The question this post addresses is earlier in the flow: how does the Mission get started when a user is in the loop?

The Gap Mission-Bound OAuth Leaves Open

Mission-Bound OAuth defines what governed authority looks like and how it behaves. What it did not yet define directly was the authentication-layer companion path: how an interactive OpenID Connect event binds a Mission to an actual human who explicitly delegated a specific authority to a specific agent for a specific purpose, with identity verified at a known assurance level.

Without an authentication layer, the Mission bootstrap problem has three unsolved parts.

The Mission knows what was approved, but not that the user actually confirmed it. Mission-Bound OAuth’s interactive approval path shows the user a consent display and captures their response. But without an OpenID Connect (OIDC) authentication event, there is no OpenID Provider (OP)-verified identity assertion binding that approval to a specific authenticated subject at a specific assurance level. The Mission records that someone approved it. It does not record who, with what authentication strength, or what was cryptographically confirmed at the moment of approval. For regulated or high-stakes delegation, that gap matters: the authority chain cannot be traced back to a verified human principal.

Open-world agents cannot have their authority envelope set correctly at Mission creation. The core thesis of the Power of Attorney series is that agents need bounded, governed authority, not just credentials. For open-world agents that discover resource requirements at runtime, this creates a hard problem without an authentication layer: the Mission envelope has to be set at creation time, before the agent knows what it will encounter. The only options without a user-confirmed bootstrap are to make the envelope as broad as the purpose class allows (defeating the governance goal), or to make it narrow and accept constant re-approval failures (defeating the usability goal). Neither is acceptable as a foundation for agents that are supposed to operate autonomously inside governed bounds.

The params object in the purpose context helps break this dilemma. The user authenticates at Mission initialization, confirms a purpose, and the agent supplies the specific parameters that bound the task. The AS can use these inputs to compile a Mission Authority Model that is tight enough to be meaningful governance and broad enough to cover the agent’s declared intent, without requiring the agent to enumerate every downstream audience in advance. That is the only path to a Mission that governs open-world execution rather than only closed-world workflows.

Cross-domain projection has no trust foundation without a shared identity anchor. Mission-Bound OAuth describes cross-domain Mission assertions for reaching authorization domains outside the home AS. But every bilateral trust relationship required to make those assertions work has to be established separately. In most enterprise deployments, the Identity Provider (IdP) is already the trust anchor: every Resource AS already trusts it. ID-JAG leverages that existing trust to project a minimal Mission view across same-IdP boundaries without requiring new AS-to-AS federation agreements. Without the authentication layer, you either accept the bilateral establishment cost for each new domain, or the agent’s authority simply cannot cross same-IdP boundaries in a governed way.

These are not gaps that tighter scope strings or stronger credentials can fill. They are gaps in the trust foundation of the Mission. A Mission created by a client asserting a purpose, without a user authentication event, without OP-confirmed identity, and without step-up enforcement, is not Power of Attorney. It is a client claiming authority on behalf of a user who was never in the room.

For Mission governance to be real rather than nominal, the delegation has to trace back to an authenticated human who actually confirmed it. Client Context and ID-JAG are how that traceability is established at the authentication layer.

Authentication Is the Right Bootstrap Moment

When a user kicks off an agent task through an interactive authentication event, something important is true that will not be true again until the user reappears: the user can read what they are approving, step-up can be triggered if the risk warrants it, and whatever they confirm becomes a tamper-evident approval record. That moment has always been where identity systems do their most important work.

For agent missions, it is also where the Mission can be created or approved, with the user’s explicit confirmation of purpose and scope, captured at the one point in the workflow where the human is genuinely present and attentive.

OpenID Connect Client Context is structured context attached to an OIDC authentication request. It is not a new credential type and it is not a replacement for OAuth tokens. It is the mechanism for making authentication intent machine-readable and policy-evaluable, so that the OP and its associated AS can act on it. Specifically, the OP can use the applied context to create or approve a Mission at the AS, establishing the governed authority object before any tokens are issued.

This matters only for user-delegated scenarios where a human is in the loop. Automated workloads with no human initiator, headless services, and pre-provisioned mission types use client credentials rather than interactive OIDC. Client Context is an extension of interactive OIDC, not a general-purpose bootstrap mechanism for every mission type.

That also means Client Context does not replace the broader control plane the older Power of Attorney framing called for. It bootstraps the Mission at the one moment a human is present. It does not answer the later question of whether runtime execution should continue after downstream facts, business events, or orchestration state change.

The Purpose Context

For agent missions, the context type that matters most is purpose. A purpose context for the scheduling scenario might look like this:

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

{
  "kind": "https://example.com/purposes/schedule-meeting",
  "display": {
    "title": "Schedule Meeting",
    "description": "Schedule a meeting with the engineering team and record the follow-up"
  },
  "params": {
    "calendar": "engineering@example.com",
    "date_range": "2026-04-01/2026-04-08"
  },
  "actor": {
    "type": "agent",
    "id": "assistant-agent-v2",
    "sub": "user-123"
  },
  "constraints": {
    "expires_at": "2026-04-01T17:00:00Z",
    "max_duration": 900
  }
}

Each field has a distinct job. kind is the stable purpose class the OP uses for policy lookup: it is the join key between the authentication layer and the Mission-creation rules at the AS, stable across deployments and reusable across requests of the same type. params are instance-level inputs: the specific calendar, the specific date range. They bound this particular run without carrying authority semantics themselves. display is a client-supplied UI hint the OP can present, supplement, or re-render so the user understands the task being approved. actor gives the OP advisory context about whether a human, agent, or service initiated the request; unless the client is separately authorized to assert it or the OP verifies it independently, it is not a verified fact. constraints bound the authentication event and its immediate outputs.

Together that is enough to bootstrap a Mission. It is not enough to replace one: the ID Token is not the authority artifact; it is evidence that authentication and approval happened. The Mission is the authority artifact, and it lives at the AS.

The kind field is architecturally the most important piece. A Mission profile can use it to map into purpose templates, approval workflows, or Mission-creation rules without forcing the base Client Context spec to define any of those things itself. It is the seam between the authentication layer and the authorization governance layer.

The Handoff

The handoff has five steps: the client sends client_context during interactive authentication; the OP evaluates it, applying authentication policy, presenting purpose information to the user, and handling step-up if needed; the OP returns the applied client_context in the ID Token and retains the approval evidence; the client verifies the returned client_context claim rather than trusting what it originally sent; the OP or its associated AS uses that applied context to create or approve a Mission; from that point, Mission-Bound OAuth takes over.

The easiest way to think about the data model is:

What the AS receives from the applied Client Context: the purpose class as a stable policy key, the validated instance parameters, the authenticated subject, any actor information the OP has accepted as verified or retained as advisory context, and the retained display evidence for audit. What the AS creates in response: an Approved Mission with a Mission Authority Model, and a projected mission_ref that downstream token derivation can reference.

The deployment boundary can still vary. In the OAuth-centered model used in this series, the Mission lives at the AS. In a broader control-plane architecture, the same applied context could be handed to a separate authority service that becomes the Mission state owner and the AS becomes one consumer of that state. The authentication-layer handoff is the same either way.

The ID Token carries evidence that authentication and approval happened. The Mission carries the authority. Those are different jobs and they belong in different artifacts.

Once the Mission exists, the agent can get a calendar token, an email token, and when the time comes, a CRM token. All three trace back to the same Mission. All three are bounded by the same authority model. All three are under lifecycle that the AS can suspend, revoke, or terminate as a unit. The user approved the purpose once. The system enforces it everywhere.

That still leaves one more layer above this post’s scope: execution control. Authentication confirms who approved what purpose. It does not by itself ensure that the orchestrator pauses, unwinds, or escalates correctly when the Mission later changes state. That is why this profile is a bootstrap and projection companion, not the whole governance system.

When Handoff Cannot Complete Immediately

The handoff description above assumes synchronous OIDC: the user completes interaction, the OP issues an ID Token, Mission creation follows. That assumption holds for purpose types that auto-approve from a policy rule or that the user can confirm interactively in a single session. It breaks for purpose types that require more.

High-risk or high-assurance Mission bootstrap may need:

• identity verification beyond what can complete in a session, such as document scanning or biometric review that a human operator evaluates
• human approval of the Mission Proposal before authority is granted, where that approval follows an out-of-band review process
• step-up assurance that depends on an asynchronous channel

For these cases, the OpenID Connect Deferred Token Response Flow (DTR) provides the right shape. DTR is an emerging OpenID Connect specification that lets a user initiate an authentication flow, leave, and receive the result asynchronously. The user completes their interactive portion: providing identity information, expressing intent, stepping through any immediate prompts the OP requires. The OP responds not with a redirect containing an authorization code, but with a deferred_code. The RP exchanges that code for a deferred_auth_id, then polls the token endpoint or waits for a ping callback until the authentication decision is made.

The deferred_code code response type is the most useful form for Mission bootstrap. It lets the OP decide at runtime whether the Mission can be bootstrapped immediately (returning a code on the redirect) or requires deferred processing (returning a deferred_code). The RP handles both paths from the same initial request. Purpose types that auto-approve compile a Mission immediately; purpose types that require human review enter a pending state. The response type is the OP’s signal about which path applied.

The mapping between DTR states and Mission states is direct:

The ping callback, sent to the RP’s deferred_client_notification_endpoint when the authentication decision is made, is the authentication-layer equivalent of Mission lifecycle notification. For deployments that already use SSF/CAEP for Mission lifecycle events, the architectural role is the same: the OP signals completion asynchronously rather than making the RP poll indefinitely.

The interim_id_token that DTR can return during the Deferred Code Exchange Response is also worth noting for Mission deployments. When the OP can partially verify identity before the full authentication process completes, it can include an interim ID Token with partially-verified claims. For Mission bootstrap, this opens a preliminary pattern: a partially-verified identity could authorize a provisional Mission Proposal with restricted scope, upgraded to a full Mission once complete identity verification returns. That pattern is optional, but a deployment profile for high-assurance Mission types should address whether provisional Missions are permitted and what their authority bounds look like.

AAuth’s 202 Accepted pending state is the native equivalent of DTR’s deferred flow. In AAuth, deferred approval with a polling URL is a first-class part of the core protocol. In the OpenID Connect world, DTR is the spec that adds this capability. Part 3 of this series notes AAuth’s native deferred approval as an advantage over standard OAuth for agent Mission bootstrap. DTR is the OIDC ecosystem’s answer to that gap. It does not make the OIDC path as seamless as AAuth’s native flow, but it does mean the deferred-approval shape exists without requiring a protocol change, for deployments that need to stay in the OpenID Connect world.

The ID-JAG Payoff

So far the story covers the home domain. The interesting case is when the Mission needs to cross into another authorization domain inside the same enterprise, specifically one that trusts the same OP but issues its own tokens.

In the scheduling scenario, the calendar and email services might sit behind one Resource AS. The CRM sits behind another. Both trust the same enterprise IdP. Token exchange can bridge this gap, but there is a cleaner option when same-IdP trust already exists: the OP can issue an ID-JAG carrying a reduced Mission projection, and the downstream Resource AS can validate it directly.

The ID-JAG is not the Mission traveling across the boundary. It is a signed assertion, issued by the OP the downstream AS already trusts, that carries a minimal projection: the mission_ref, the applied purpose.kind, the relevant expiry, and actor context only if that information is needed and trustworthy enough for the receiving policy. The downstream AS validates the assertion, maps the mission_ref to a locally-issued token reference, and issues an audience-specific access token scoped to its own resources.

What the projection carries, and what it deliberately omits, matters. It should include the mission_ref, the purpose.kind, audience-relevant params, expiry bounds, and actor context only when the receiving AS needs it for policy evaluation and can interpret its trust level correctly. It should not include the full applied client_context, UI-only display fields, parameters irrelevant to the receiving audience, or the internal Mission Authority Model. The downstream AS gets what it needs to issue a correctly bounded token. It does not get a copy of the governing Mission.

The right mental model is not “the mission lives in the ID-JAG.” It is “the ID-JAG carries a reduced Mission projection inside a trust domain that already trusts the OP as an assertion source.”

This is where the profile becomes compelling as a whole. The user authenticated once, the OP applied a purpose context, and that applied context bootstrapped a Mission. The same-IdP trust that already exists in the enterprise becomes the carrier for a minimal Mission projection. No new bilateral trust establishment. No new protocol. Just the enterprise’s existing federation infrastructure carrying a narrowly scoped assertion that lets downstream ASes issue correctly bounded tokens under the same Mission.

End-to-End Protocol Flow

The scheduling scenario, calendar, email, and CRM, has three authorization domains behind the same enterprise IdP. Here is how the protocol messages flow.

Phase 1: Authentication and Mission bootstrap

The agent initiates an OIDC authentication using Pushed Authorization Requests (PAR, RFC 9126) to keep the client_context payload out of the browser URL. The client_context parameter carries the structured purpose context as a JSON object:

 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

POST /par HTTP/1.1
Host: idp.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic <client_credentials>

response_type=code
&client_id=ai-assistant
&redirect_uri=https://assistant.example.com/callback
&scope=openid
&nonce=n-0S6_WzA2Mj
&client_context={
    "contexts": {
      "purpose": {
        "kind": "https://example.com/purposes/schedule-meeting",
        "display": {
          "title": "Schedule Meeting",
          "description": "Schedule a meeting with the engineering team and record the follow-up"
        },
        "params": {
          "calendar": "engineering@example.com",
          "date_range": "2026-04-01/2026-04-08"
        },
        "actor": { "type": "agent", "id": "assistant-agent-v2", "sub": "user-123" }
      }
    }
  }

The OP evaluates the purpose class against policy, presents purpose information to the user using the supplied display values or OP-generated text, applies step-up if required, and completes authentication. After the authorization code exchange, the ID Token confirms the applied context:

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

{
  "iss": "https://idp.example.com",
  "sub": "user-123",
  "aud": "ai-assistant",
  "nonce": "n-0S6_WzA2Mj",
  "client_context": {
    "contexts": {
      "purpose": {
        "kind": "https://example.com/purposes/schedule-meeting",
        "params": {
          "calendar": "engineering@example.com",
          "date_range": "2026-04-01/2026-04-08"
        },
        "actor": { "type": "agent", "id": "assistant-agent-v2" }
      }
    }
  },
  "exp": 1773072600
}

The OP or associated AS uses the applied client_context to create the Mission. Internally the AS records mission_id: m_Kq7r9X; the projected protocol-facing handle is mission_ref: mr_7M9Qx2.

That verification step matters. A client cannot safely treat the client_context it sent in the request as proof that the OP applied it. It has to verify the signed ID Token, check that the client_context claim is actually present, and reject the flow if required context is absent or inconsistent. Mission bootstrap only works if the applied context is carried in the signed ID Token and verified by the client.

Phase 1b (variant): Deferred Mission bootstrap

When the purpose type requires identity verification or human approval that cannot complete in a single session, the agent uses the deferred_code code response type instead. The PAR request is identical except for response_type:

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

POST /par HTTP/1.1
Host: idp.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic <client_credentials>

response_type=deferred_code+code
&client_id=ai-assistant
&redirect_uri=https://assistant.example.com/callback
&scope=openid
&nonce=n-0S6_WzA2Mj
&client_context={
    "contexts": {
      "purpose": {
        "kind": "https://example.com/purposes/schedule-meeting",
        "display": { ... },
        "params": { "calendar": "engineering@example.com", "date_range": "2026-04-01/2026-04-08" },
        "actor": { "type": "agent", "id": "assistant-agent-v2", "sub": "user-123" }
      }
    }
  }

The OP determines this purpose class requires human approval before Mission authority can be granted. It redirects back with a deferred_code instead of a code:

HTTP/1.1 302 Found
Location: https://assistant.example.com/callback?
  deferred_code=SplxlOBeZQQYbYS6WxSbIA
  &state=af0ifjsldkj

The agent exchanges the deferred_code for a deferred_auth_id:

1
2
3
4
5
6
7
8
9

POST /token HTTP/1.1
Host: idp.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic <client_credentials>
DPoP: <dpop_proof>

grant_type=urn:openid:params:grant-type:deferred
&deferred_code=SplxlOBeZQQYbYS6WxSbIA
&deferred_notification_token=8d67dc78-7faa-4d41-aabd-67707b374255

1
2
3
4
5

{
  "deferred_auth_id": "f4oirNBUlM",
  "expires_in": 10800,
  "interval": 60
}

The agent polls at the configured interval. Until the approval decision is made, the OP returns authorization_pending. When the human reviewer approves the Mission Proposal, the next poll returns a successful Token Response:

1
2
3
4
5
6

{
  "access_token": "...",
  "token_type": "DPoP",
  "id_token": "<jwt containing applied client_context claim>",
  "expires_in": 3600
}

If the RP registered a deferred_client_notification_endpoint, the OP sends a ping callback when the decision is made rather than requiring indefinite polling:

1
2
3
4
5
6

POST /callback HTTP/1.1
Host: assistant.example.com
Authorization: Bearer 8d67dc78-7faa-4d41-aabd-67707b374255
Content-Type: application/json

{ "deferred_auth_id": "f4oirNBUlM" }

The agent then makes one final token request to retrieve the ID Token. Both paths, synchronous and deferred, converge here: the returned ID Token contains the applied client_context claim in the same structure as Phase 1. The OP or associated AS uses it to create an Approved Mission, issues a mission_ref, and Phase 2 proceeds identically.

Phase 2: Mission-governed token derivation

With a mission_ref in hand from either bootstrap path, the agent requests a calendar token referencing the Mission via authorization_details. DPoP (Demonstrating Proof of Possession, RFC 9449) sender-constraining is assumed throughout.

1
2
3
4
5
6
7
8
9

POST /token HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
DPoP: <dpop_proof>

grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https://assistant.example.com/callback
&authorization_details=[{"type":"mission","mission_ref":"mr_7M9Qx2"}]

The AS validates Mission state and issues an audience-bound access token:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

{
  "iss": "https://as.example.com",
  "sub": "user-123",
  "sub_profile": "user",
  "aud": "https://calendar-api.example.com",
  "act": { "sub": "assistant-agent-v2", "sub_profile": "ai_agent" },
  "mission_ref": "mr_7M9Qx2",
  "scope": "calendar.schedule",
  "cnf": { "jkt": "<dpop_key_thumbprint>" },
  "exp": 1773069300
}

The email token follows the same pattern via RFC 8693 token exchange, with resource=https://email-api.example.com and the calendar access token as the subject token. The AS checks Mission state at each exchange before issuing.

Phase 3: ID-JAG projection for the CRM (same-IdP)

The CRM sits behind crm-as.example.com, a separate Resource AS that issues its own tokens but trusts the same enterprise IdP. The agent requests a Mission-projection assertion from the OP using token exchange, identifying the target audience:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

POST /token HTTP/1.1
Host: idp.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic <client_credentials>

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token=<id_token>
&subject_token_type=urn:ietf:params:oauth:token-type:id_token
&requested_token_type=urn:openid:params:token-type:id-jag
&audience=https://crm-as.example.com
&authorization_details=[{"type":"mission","mission_ref":"mr_7M9Qx2"}]

The OP confirms the Mission is still active and the CRM audience is within the Mission’s bounds, then issues the ID-JAG. This is a signed JWT carrying only what the CRM AS needs: no display fields, no full authority model, no parameters irrelevant to CRM enforcement:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

{
  "iss": "https://idp.example.com",
  "sub": "user-123",
  "sub_profile": "user",
  "aud": "https://crm-as.example.com",
  "act": { "sub": "assistant-agent-v2", "sub_profile": "ai_agent" },
  "mission_ref": "mr_7M9Qx2",
  "purpose": "https://example.com/purposes/schedule-meeting",
  "jti": "id-jag-8f3a2b",
  "exp": 1773069600
}

The agent presents this ID-JAG at the CRM Resource AS as a JWT bearer grant:

1
2
3
4
5
6
7
8

POST /token HTTP/1.1
Host: crm-as.example.com
Content-Type: application/x-www-form-urlencoded
DPoP: <dpop_proof>

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&assertion=<id_jag_jwt>
&scope=crm.notes.write

The CRM AS validates the signature, confirms the same enterprise IdP as issuer, and issues a CRM-scoped token:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

{
  "iss": "https://crm-as.example.com",
  "sub": "user-123",
  "sub_profile": "user",
  "aud": "https://crm.example.com/api",
  "act": { "sub": "assistant-agent-v2", "sub_profile": "ai_agent" },
  "mission_ref": "mr_7M9Qx2",
  "scope": "crm.notes.write",
  "cnf": { "jkt": "<dpop_key_thumbprint>" },
  "exp": 1773069900
}

The critical point is not the exact wire format. It is that the Mission remains at the AS, the OP projects only the minimum information the same-IdP domain needs, and every issued token still traces back to the same governed Mission.

Consent Fatigue Is the Failure Mode

This architecture only helps if it reduces repeated user prompts rather than multiplying them.

That is the real danger with any authentication-layer Mission bootstrap model. If every newly discovered tool, every downstream token exchange, or every sub-step in a long-running Mission forces the user back through another interactive approval screen, the result is not stronger governance. It is just consent fatigue.

Consent fatigue breaks the model in predictable ways:

• users stop reading prompts
• agents get broad standing approval just to avoid interruption
• teams weaken the prompts because the workflow becomes unusable
• genuinely high-risk transitions become harder to distinguish from routine noise

That is why this profile only makes sense on top of Mission-Bound OAuth rather than in place of it.

The point of the authentication step is not to ask the user about every downstream token. The point is to create or approve a Mission once, at a moment when the user is present, and then let the authorization layer govern bounded derivations inside that approved Mission.

The practical rule is simple:

• use Client Context when a fresh human authentication or approval event is genuinely needed
• use the Mission to carry that approval forward across bounded downstream actions
• require a new user interaction only when the agent needs to go outside the approved Mission envelope

If the profile cannot do that, it has failed.

RAR, Token Exchange, Client Context, and DTR

These mechanisms are complementary, not competing.

Client Context explains why the user is authenticating and what they are approving. Mission-Bound OAuth defines the durable authority object and lifecycle. RAR shapes resource-specific authorization requests. Token exchange derives audience-specific tokens. ID-JAG projects reduced Mission context across same-IdP trust domains. DTR makes Mission bootstrap asynchronous when the purpose type requires it.

That is the layered model that makes sense for enterprise agent deployments.

RAR is still the better fit when there is one authorization server, the resource domain is already tightly governed, and the main problem is the shape of the access token.

Client Context plus ID-JAG adds the most value when:

• a user is present
• the OP is the enterprise trust anchor
• the Mission spans multiple authorization domains
• same-IdP trust makes assertion projection practical
• authentication-time step-up and approval evidence matter

DTR adds value on top of that when:

• Mission bootstrap for the given purpose type cannot complete synchronously
• human review of the Mission Proposal is part of the approval flow
• identity verification requirements exceed what a single interactive session can confirm
• the RP needs a notification model rather than a blocking wait

GNAP (RFC 9635) is worth acknowledging here too. It addresses multi-resource delegation with a different architectural model and does not depend on the same shared-IdP assumption. For greenfield systems, that may be the cleaner direction. This post is about how to improve the world enterprises actually have today.

What This Companion Profile Needs To Define

Client Context plus ID-JAG is enough to improve Mission bootstrap, but it only becomes a real companion profile when the handoff and projection rules are explicit.

So rather than leave those pieces as open questions, here is the profile definition that seems to fit this architecture.

1. Client Context To Mission Handoff Profile

The base Client Context draft intentionally stops at the authentication layer. It defines requested context, applied context, and client verification, but it does not define the server-side object that applied context might instantiate. This profile closes that seam by treating the Mission as the target object.

Handoff Preconditions

Before any Mission is created, approved, or resumed from an interactive authentication event, all of the following have to be true:

• The client has validated the ID Token normally, including signature, issuer, audience, expiration, and nonce. This prevents Mission bootstrap from hanging off an untrusted authentication result.
• The ID Token contains a client_context claim. This ensures the OP actually returned applied context.
• The client has verified that the returned client_context contains the required applied context for the operation it is about to enable. This prevents the client from treating requested context as if it were applied context.
• The OP or associated Mission service treats only the applied client_context from the ID Token as Mission input, never the raw request value. This ensures Mission creation is rooted in confirmed, signed context rather than client-supplied request data.

If those conditions are not met, no Mission bootstrap occurs.

Handoff Modes

This profile defines three handoff modes:

The profile should fail closed here: if the Mission service cannot determine whether the event is a create, approve, or resume operation, it rejects the handoff.

In shorthand, the decision flow looks like this:

1
2
3
4

No mission_ref?                 -> Create
Pending or pre-created Mission? -> Approve
Existing active mission_ref?    -> Resume
Anything ambiguous?             -> Reject

Mapping Applied Context Into Mission Inputs

The handoff takes the applied context and maps it into Mission inputs with a strict split between governance inputs and audit-only inputs.

That split matters. purpose.kind and validated params can shape the Mission Authority Model; the display text can help explain what happened, but it must not define what the system is authorized to do.

Purpose Catalog Requirement

This profile depends on a purpose catalog keyed by purpose.kind.

For each supported purpose.kind, the catalog needs to define:

• The schema for params. This defines what instance inputs are valid.
• Which params members are Mission-governing versus audit-only. This separates authority-shaping data from evidence-only data.
• Allowed tenants, applications, or resource classes, where relevant. This constrains where the Mission may apply.
• Required authentication strength or step-up rules. This tells the OP what assurance level is needed.
• Maximum lifetime and propagation rules. This limits duration and downstream spread.
• Conditions for resume versus recreate. This determines when a Mission can be re-attested rather than re-issued.

This is what allows applied context to compile into a bounded Mission instead of becoming just another bag of metadata.

Failure Semantics

If authentication succeeds but Mission compilation or policy evaluation fails, the profile should treat that as a Mission bootstrap failure, not as a soft success.

1
2
3
4
5

Authentication succeeds
Mission compilation fails
-> No Mission created / approved / resumed
-> Client does not enable the Mission-bound operation
-> Failure is surfaced distinctly from ordinary authentication failure

That is the only safe behavior. “The user authenticated successfully” is not equivalent to “Mission bootstrap succeeded.”

2. Mission Projection Profile For ID-JAG

Once a Mission exists, same-IdP propagation needs a stable projection model. This profile defines ID-JAG as a reduced, audience-bound Mission projection, not as a portable copy of the Mission itself.

Projection Model

Minimum Projection Claims

At minimum, the projected assertion should carry:

• iss: identifies the OP issuing the assertion.
• aud: binds the projection to exactly one downstream AS audience.
• sub: carries the authenticated user subject.
• mission_ref: carries the stable protocol-facing Mission handle.
• purpose or purpose_kind: carries the applied purpose.kind.
• iat and exp: bound issuance time and lifetime.
• jti: supports replay detection.

The assertion MAY also carry:

• Minimized audience-relevant params. Include these only when they are needed for downstream issuance policy.
• Actor information. Include it only when the issuer can state whether it is verified or advisory and the receiver has policy for that distinction.
• Sender-constraining information such as cnf. Include it when the deployment binds assertions or derived tokens to a proof-of-possession key.

Projection Minimization Rules

The profile should define strict minimization rules:

The projection should answer one narrow question for the downstream AS: what Mission-scoped facts does this AS need to issue a correctly bounded local token?

In practice, the boundary looks like this:

Downstream AS Processing

The downstream AS validates the assertion and then makes a fresh local issuance decision. At minimum it should:

1
2
3
4

Validate signature, issuer, audience, time validity, and replay protections
Confirm the issuer is trusted for Mission projection into this audience
Apply local policy to mission_ref, purpose.kind, minimized params, and actor information
Reject if projected values exceed local policy, even if the assertion is otherwise valid

The downstream AS does not inherit the Mission wholesale. It receives enough projection to mint its own audience-bound token under local policy.

Projection Failure Semantics

If the projection is invalid, expired, replayed, insufficiently trusted, or outside local policy, the downstream AS rejects it and issues no token.

That rejection should not be treated as proof that the home Mission is invalid. It only means that this downstream domain will not honor this projection under its own policy.

What Mission-Bound OAuth Now Defines

The remaining piece, actor verification and execution continuity, now sits where it belongs: in Mission-Bound OAuth.

The latest Client Context draft is right to treat actor as advisory by default. That protects the authentication-layer protocol from over-claiming trust it has not earned. But Mission-Bound OAuth needs more than advisory actor context. It has to answer the separate question of whether the actor executing derived actions is the same actor the Mission approved at bootstrap.

The Mission-Bound OAuth draft now defines that as verified agent binding. In that model:

• the Mission record at the AS is the binding anchor
• sender constraining provides key continuity across derivation steps
• the AS performs actor verification at token exchange time
• derived actor claims are AS-authoritative rather than client-self-asserted
• cross-domain projection carries actor context, but live actor continuity across trust domains still depends on introspection or equivalent state sharing

That is the right split. Client Context and ID-JAG handle authentication-time bootstrap and reduced projection. Mission-Bound OAuth handles authority continuity across the Mission lifecycle.

How This Closes The Security Gaps

Those profile pieces are not just interoperability work. They are how the architecture closes its remaining security gaps.

The main security gaps still open are these:

• Bootstrap/request confusion. The client must verify applied context in the ID Token before treating a Mission as user-rooted. The profile now says that explicitly, but the handoff profile must make it impossible for Mission creation to rely on unverified request data.
• Actor substitution. Advisory actor data is not enough for high-stakes delegation. The Mission-Bound OAuth draft now addresses this with verified agent binding, so the remaining gap here is making sure this companion profile depends on that model rather than trying to redefine it.
• Projection over-sharing. ID-JAG needs minimization rules so deployments do not dump the full applied context, UI text, or broad params objects into downstream assertions.
• Replay and confused deputy risk. Projection claims have to be audience-bound, time-bounded, replay-resistant, and tied to local policy evaluation at the downstream AS. Otherwise one resource domain can be tricked into honoring context intended for another.
• Lifecycle drift. If a Mission is suspended, revoked, or terminated, projections and derived tokens need coherent invalidation behavior. Otherwise Mission lifecycle becomes an aspiration rather than an enforcement property. That is fundamentally a Mission-Bound OAuth responsibility, even if this profile depends on it.

These are exactly the kinds of gaps that appear when governance lives in one object, authentication evidence in another, and downstream assertions in a third. They are solvable, but only if the profile makes the joins explicit.

What Open-World Agents Still Require

The hardest requirement is still the original one: making open-world agents possible without turning the Mission into a standing blanket approval.

That requires more than authentication-time bootstrap. It requires a bounded discovery model.

At Mission creation time, the system has to be able to say something stronger than “this one exact API and scope are allowed” and something narrower than “the agent may do whatever seems related.” In practice, that means the profile needs a purpose catalog that defines, for each purpose.kind:

• the schema of allowed params
• the classes of downstream resources the agent may discover at runtime
• the operations that are in-family for that purpose
• the maximum privilege, lifetime, and propagation rules for those operations
• the boundary where newly discovered work is no longer considered part of the approved Mission

That lets the Mission service compile a Mission Authority Model that is tight enough to govern real execution while still giving the agent room to discover concrete resources at runtime.

The missing rule is the re-approval boundary.

An open-world agent should be able to keep working when it discovers a new calendar folder, a new mailbox, or a new CRM record that is still inside the approved purpose class and parameter bounds. It should not be able to silently expand into a different subject, a different tenant, a stronger operation, a different resource class, or a longer-lived execution than the compiled Mission allows.

At a high level, the boundary should work like this:

So the complete model needs a deterministic answer to one question:

Is this newly discovered action still inside the Mission envelope, or does it require a fresh human interaction?

If the system cannot answer that question mechanically, then open-world execution collapses back into either over-broad standing authority or repeated consent prompts.

That is why the real end state is not “put more data in Client Context.” It is a cleaner division of labor:

• Client Context bootstraps purpose at authentication time
• the handoff profile compiles applied context into a bounded Mission
• Mission-Bound OAuth governs that Mission across downstream derivations
• ID-JAG projects only the minimum necessary Mission view across same-IdP trust domains
• Mission-Bound OAuth ensures the executing actor is the actor the system approved
• re-approval triggers fire automatically when discovery crosses the compiled Mission boundary

That is the architecture that closes the remaining security gaps and makes open-world agents plausible without giving them permanent ambient authority.

The Practical Claim

The claim here is not that Client Context solves agent security.

The claim is narrower:

Client Context is a strong way to capture and confirm interactive Mission bootstrap input at authentication time, and ID-JAG is a strong way to project reduced Mission context across same-IdP trust domains, while leaving the durable Mission and its lifecycle where they belong: at the authorization server.

That is a smaller claim than “mission in the ID Token.” It is also a much better architecture.

If you work in identity, security architecture, or agent systems and are thinking about how to carry mission context through the authentication layer, the questions I care most about are:

• what should a Client Context to Mission handoff look like in a real profile
• what minimum Mission projection belongs in an ID-JAG
• where same-IdP projection stops being enough and a broader Mission assertion profile is needed

The Client Context draft is at github.com/mcguinness/connect-client-context.