Part 1 focused on OAuth’s substrate problem: agents discover protected resources at runtime, which inverts the closed-world assumption that clients, authorization servers, and resource servers were all pre-configured to know each other.

Protected Resource Metadata, OAuth Client ID Metadata Document, sender-constrained tokens, metadata integrity, and first-contact trust all matter because the protocol base has to work before anything higher-level can be trusted.

A working substrate is not the same thing as a complete authorization model for agents. Even after discovery, resource binding, and first-contact trust all work, a generic agent still faces a harder problem: how does it turn approved task intent into correctly bounded authorization requests across unfamiliar tools, resources, and domains?

That is where open-world OAuth runs into the Mission shaping problem.

In this model, a Mission is the durable authority object compiled from approved intent, bounded across delegation, and governed through the lifecycle of the task.

🤝 The Handoff From Protocol To Mission

Imagine the example from Part 1: an agent is helping a salesperson prepare an account-renewal brief.

The agent discovers a CRM Model Context Protocol (MCP) tool at runtime. Protected Resource Metadata tells it how the CRM API is protected. The Authorization Server (AS) returns a token whose effective resource binding is confirmed (OAuth 2.0 Resource Parameter in Access Token Response, as discussed in Part 1). The client has enough metadata to evaluate whether the CRM AS should be trusted. The CRM resource server has enough policy basis to accept the issuer.

That is a much better world than today’s open-world OAuth baseline.

But the agent then discovers that it needs billing history from another domain. The protocol questions return:

• can the agent discover the billing resource’s authorization requirements
• can it get a token with confirmed resource binding
• can each side evaluate first-contact trust
• can delegation cross the boundary safely

And even if every protocol step succeeds, the Mission question remains:

• is billing-history access still inside the user’s approved renewal-preparation task
• is the requested authority a narrow derivation or a material expansion
• should the user see a new approval prompt
• should the original Mission be expanded, forked, or rejected
• what happens to already-derived authority if the Mission is later narrowed or revoked

OAuth can expose better signals. It cannot, by itself, decide whether the agent is still operating inside the purpose the user approved.

⛓️ Delegation and Authorization Chains Across Trust Domains

Multi-hop delegation is still part of the open-world trust problem. Once discovery happens at runtime, delegation chains can reach AS boundaries that were not pre-configured either. The first-contact problem reappears, now applied to delegated authority rather than to client and resource discovery alone.

This is where Mission starts to matter. The question is not only whether one token can be exchanged for another. It is whether the delegated act still remains inside the purpose the user approved.

OAuth 2.0 Token Exchange (RFC 8693) provides a framework commonly used for delegation within a trust domain where the involved ASes have a pre-existing relationship. The act claim records who is acting on whose behalf, but even within a single domain the claim is not uniformly profiled: two standards-compliant implementations can disagree about delegation semantics when a token crosses a trust boundary (see Standardize act Across Assertion Grants and JWT Access Tokens). Multi-hop chains that cross AS boundaries with no prior relationship between them are not well specified.

The specific problems are operational, not abstract:

• how does a downstream AS validate that the delegation chain it is seeing is authentic
• how does it determine that the upstream AS that issued the parent token is trustworthy enough to vouch for delegation
• how does it enforce that each hop properly attenuated rather than expanded the delegated authority
• how does a generic client discover whether a target AS supports token exchange, chaining, or some narrower delegation profile at all

Three active drafts each address a different layer of this problem.

OAuth Identity and Authorization Chaining Across Domains addresses the cross-AS trust layer: how an AS establishes trust with another AS based on discovered metadata and how delegation claims propagate across AS boundaries.

Transaction Tokens address the intra-domain context layer: within a trust domain, how caller context propagates through chains of service or agent calls so that each downstream service sees who initiated the chain and under what authority.

Identity Assertion JWT Authorization Grant (ID-JAG) addresses a narrower downstream grant-friction problem: a user authenticates once with an Identity Provider (IdP), the IdP issues an identity assertion, and the client presents that assertion to a target AS as an RFC 7523 JWT Bearer authorization grant to obtain access without a full interactive authorization step in every coordinated downstream domain.

Taken together, these drafts show that the delegation problem is visible and active. They do not yet provide a settled end-to-end answer for open-world, cross-AS delegation chains.

A settled answer would require at least:

• a standard way for ASes to publish support for specific token exchange and chaining profiles
• a trust framework that lets downstream ASes evaluate whether an upstream AS is authorized to vouch for delegation in a given context
• chain-level attenuation guarantees that are verifiable at each hop rather than enforceable only by convention within a single trust domain
• stronger subject and actor continuity so downstream parties can tell not just who is acting now, but how that actor relates to the original approved principal

For Mission-aware systems, actor continuity is not just provenance metadata. It is part of Mission state: the system needs to know whether the actor executing the next derived action is still the actor, or delegated actor, the Mission authorized.

And even if discovery, trust establishment, and delegation worked perfectly, a generic agent would still face a harder question: how does it know what authorization request it should form in the first place?

🧩 Task Intent and Tool Authorization Semantics Are Still Missing

A larger open gap runs across all of these layers: OAuth still does not give generic agent systems a reliable way to move from task intent to concrete authorization semantics.

That is the problem the Mission Shaping series is about. Enforcement systems do not authorize intent. They authorize operations on resources under specific conditions. A user intent such as “prepare the renewal notes for these accounts” is not an authorization request. Something has to translate the first into the second, and open-world OAuth exposes exactly where that translation is missing.

OAuth scopes are intentionally opaque strings. They carry no machine-readable semantics about what operations they represent, what resources they govern, or how they compose. That opacity worked in closed-world deployments where developers read the documentation and hard-coded scope values. It does not work for a generic agent encountering an unfamiliar domain at runtime. Three specific gaps make the problem concrete.

First, the client cannot understand the authorization semantics of an unfamiliar domain from scope strings alone. It sees opaque tokens, not a machine-readable mapping from tool intent to domain authority. This is where resource-declared semantics, richer authorization_details profiles (structured authorization objects defined by RFC 9396 for expressing richer authorization requests beyond flat scope strings), or equivalent machine-readable domain vocabularies become important.

Second, the consent path does not scale. Today’s consent path relies on WWW-Authenticate challenges and scope-based authorization requests. That allows incremental improvement, but it often puts a human back in the loop every time the agent encounters a new resource or tool surface. In the CRM-to-billing scenario, that can turn one coherent task into multiple consent interruptions or partial failures. This is partly a UX problem, but it is also a protocol-shaping problem because the ecosystem still lacks standard ways to bundle, reuse, or reason over related authorization requests as one task unfolds.

Third, delegation capabilities are not discoverable enough for generic clients. In principle, a parent agent should be able to request a narrowed token for a sub-agent. In practice, there is usually no standard way for the AS to publish that such an operation is supported, what token exchange profile it expects, whether chaining or attenuation constraints apply, or how a client should map its current intent into the scope values or authorization_details needed for the derived request. Even when token exchange exists, the agent often does not know what it should ask for.

📐 RAR, R3, and Where Semantics Should Live

Rich Authorization Requests (RAR, RFC 9396) and RAR metadata are relevant because they expose schemas for authorization_details types and give ASes a way to advertise some of the structured authorization language they understand.

That is useful progress. It turns at least part of the AS contract into discoverable metadata rather than documentation. But it still does not solve the full task-to-authorization problem for open-world agents. The client may know the shape of a valid authorization_details object and still have no reliable way to derive the right object from a newly discovered tool call or from a higher-level task description.

AAuth R3 (editor’s copy, accessed April 7, 2026) is interesting here because it pushes on the other side of the semantics problem. Instead of asking the client to invent the right authorization object, R3 lets resources publish structured, content-addressed authorization definitions in vocabularies agents already understand, including MCP, OpenAPI, and gRPC.

These two approaches reflect different assumptions about where authorization semantics should live.

RFC 9396 RAR is client-declared: the client constructs authorization_details and asserts them in the request.

R3 is resource-declared: the resource publishes structured authorization definitions in vocabularies agents already understand.

That distinction matters for generic agents. An agent encountering an unfamiliar resource has no reliable basis for constructing a correct RAR object from scratch. R3’s resource-declared model is a direct attempt to shift that burden. How RAR and resource-declared approaches compose will shape what the authorization semantics layer actually looks like for open-world agent systems.

Resource semantics are still not Mission semantics.

Discovery tells the client where to go. Binding tells it what token it got. Trust helps it decide whom to trust. R3-style resource definitions help the agent understand what a resource exposes. None of those, by themselves, tell a generic agent whether the newly discovered action is inside the purpose the user approved.

🔄 Consent Continuity and Mission Lifecycle

The task-intent problem has a visibility problem layered on top of it.

Even if an agent could perfectly map intent to authorization requests, the user would still have no standard way to see what tokens were acquired during execution, what resources were accessed under their authorization, or whether the agent’s runtime behavior remained within the scope of what was originally approved.

The gap is not just semantic. It is auditability and control.

The gap spans both client and AS. The AS has no standard mechanism for evaluating whether a runtime token request for a newly discovered resource remains within the intent of the user’s original grant. The client has no standard mechanism for notifying the user when those acquisitions expand the effective authorization surface.

That leaves an unresolved model question: in an open world, what keeps user approval meaningful?

In the CRM-to-billing scenario, broad ex ante approval would let the agent keep expanding across systems without showing the user what changed. Step-up on every newly discovered resource would preserve visibility but destroy autonomy. Some form of policy-mediated expansion is the most plausible direction, but the protocol building blocks for it are still incomplete.

Revocation and termination sit inside the same gap. If a mission is narrowed, paused, revoked, or expires mid-execution, the ecosystem lacks a standard way to ensure that already-derived authority, cached tokens, and downstream delegated actions collapse with it coherently. Standard token revocation (RFC 7009) requires the client to know which AS to contact. When ASes were discovered dynamically and client state may be ephemeral, that assumption does not hold reliably.

In the renewal example, if the account owner cancels the renewal brief after the CRM token has been used to derive billing access, the system needs a way to terminate the billing-side authority as part of the same Mission lifecycle rather than waiting for an unrelated token expiry.

That is where protocol design ends and governance begins.

OAuth can expose better signals, boundaries, and artifacts. It cannot by itself answer whether an agent is still operating within the bounds of what was originally approved, nor can it decide where that policy should live operationally: at the AS, the RS, the orchestrator, or an external policy engine.

That is the question the Mission Shaping and Mission-Bound OAuth series address: not how a client discovers and acquires the right token, but how approved intent becomes a durable authority that stays in force across every derivation step.

🏗️ Open-World OAuth Needs a Mission Layer

Improving the open-world OAuth substrate is necessary and worth the investment. Part 1 identified targeted, fixable gaps (resource identifier matching, resource binding confirmation) and deeper trust-framework work around metadata integrity and first-contact trust. Those improvements matter.

But a better substrate does not eliminate the need for a Mission layer.

Mission shaping is not just better token exchange or richer request syntax. The unresolved problem is not only how authority is conveyed. It is how runtime action stays aligned with approved purpose as the agent discovers new tools, crosses domains, delegates work, asks for new authority, and eventually terminates the task.

AAuth (editor’s copy, accessed April 7, 2026) is one clear signal of this convergence. It redesigns authorization choreography around open-world assumptions and introduces explicit Mission concepts into the protocol conversation.

Other active drafts are pointing in the same direction. Policy and Lifecycle Extensions for OAuth Rich Authorization Requests explores policy context and task-bound authorization lifetime. OAuth 2.0 Scope Aggregation for Multi-Step AI Agent Workflows addresses repeated-consent pressure in multi-step workflows. The Agent Authorization Profile for OAuth 2.0 takes on task context, operational constraints, delegation chains, and human oversight as explicit protocol concerns.

That convergence is encouraging. The distinction that remains is between protocol concepts that make agent authorization more explicit and Mission shaping as durable bounded authority: compiled from approved intent, bounded across delegation, governed through the lifecycle of the task, and terminated coherently when the business reason ends. It sits above protocol artifacts and answers not just whether a token is valid, but whether the execution is still authorized.

Open-world OAuth is the substrate problem.

Mission shaping is the authority-governance problem above it.

Agent authorization needs both layers to hold.