OAuth was not designed for the world agents operate in.

That is not a criticism. It is why OAuth succeeded. OAuth became mature because its deployment model was constrained: clients, authorization servers, and resource servers were configured to know each other before runtime. That made the threat model legible and the security surface analyzable.

Agents break that assumption. They discover tools and protected resources at runtime, encountering authorization servers and resource servers they were never configured to know. That is a different deployment model, and it requires different protocol primitives.

The newer OAuth standards are starting to close that gap. But the work is not done.

🧱 The Closed-World Shape of OAuth

OAuth’s original deployment model (RFC 6749) was mostly closed-world. Clients had fixed relationships with Authorization Servers (ASes) and Resource Servers (RSes). Developers built the client, read the API docs, registered the software statically, and learned ahead of time which scopes were required for which endpoints. Registration happened before runtime. Trust was established at deploy time, not discovered dynamically during execution.

When the actor set is finite and known, the threat model is legible. The principals are enumerated. The trust relationships are explicit. The attack surface can be studied and hardened through deployment experience. That is what made the OAuth Security Best Current Practices (BCP) possible: the assumptions were constrained enough to analyze rigorously and stable enough to harden over time.

The attack surface of closed-world OAuth is still large. But it is bounded. An AS knows in advance which clients can approach it, which RSes it issues tokens for, and the expected shape of every authorization relationship. That makes it possible to constrain token audiences, detect anomalies, and eliminate whole categories of trust bootstrapping problems by construction.

Authorization server metadata (RFC 8414), first established in OpenID Connect Discovery and later generalized for OAuth, made clients more adaptive by letting them discover protocol endpoints and capabilities rather than hand-configuring every URL. Resource Indicators (RFC 8707) let a single AS issue tokens for multiple RSes with different audiences and scopes. These were real improvements to a model whose core assumptions stayed mostly intact: the AS still knew its RSes, the client still knew its AS, and the developer still configured the relationships before runtime.

🔓 Why Dynamic Client Registration Never Solved Open World

Dynamic Client Registration (RFC 7591) was the most direct attempt to open OAuth up.

In theory, DCR let a client discover an AS, register itself, and begin interacting without a prior bilateral setup process. In practice, it was never enough for genuinely open-world deployments.

The problem was trust bootstrapping. If a client can self-assert its identity and metadata to any AS it encounters, registration becomes easy to abuse. A malicious client presents itself as a well-known brand. There is nothing in the protocol preventing it. The AS has no reliable way to validate the client’s claimed identity against anything authoritative.

Software Statements were designed to fix this: a signed assertion from a trusted third party vouching for the client’s identity. But that required a trust-anchor ecosystem that never materialized at scale. Who issues them? Under what policies? Why should an arbitrary AS trust the issuer? Those questions were never answered end-to-end for open internet use.

DCR works well inside controlled ecosystems: enterprise deployments, managed federations, and developer platforms where a platform operator already has a bilateral relationship with the AS. But those are still bounded environments that happen to provision clients dynamically. The gap between that model and true first-contact trust was never closed.

🔄 Why OAuth 2.1 Doesn’t Close It Either

OAuth 2.1 consolidates security guidance accumulated over fifteen years of deployment, removes outdated patterns like implicit flow and password grant, and gives deployers a cleaner baseline.

But OAuth 2.1 is a modernization of the closed-world model. It makes the existing model more secure and more deployable. It does not redefine the model around runtime discovery and open-world trust.

OAuth 2.1 does not give a client a runtime path for discovering how a protected resource is protected. It does not provide a mechanism for an AS to evaluate a client’s identity in a web-native way before the client has ever been registered. It does not address how a client confirms which resource binding a token actually carries after issuance.

If your deployment is fundamentally closed-world (fixed clients, pre-configured ASes, known RSes), OAuth 2.1 is the modernization you need. If your deployment is fundamentally open-world, OAuth 2.1 is a better floor, not the model you need to reach.

🤖 Agents Invert the Deployment Assumption

Agents do not operate in closed worlds.

They discover tools, services, and protected resources at runtime. A simple example is a tool protocol like MCP: an agent loads a tool manifest from a URL it just discovered, calls an endpoint, receives a 401 Unauthorized, and has no prior knowledge of which AS protects that resource, which resource identifier to request, or which scopes are required. The agent was not configured at deploy time with a list of every RS it will need.

To be precise: “open world” here does not mean “enterprise dynamic onboarding” or “managed federation with known trust anchors.” It means first-contact interaction with resources and authorization servers that were not pre-configured into the client at deployment time.

The closed-world question is: how does a known client get a token from a known AS for a known RS?

The open-world question is: how does a client safely discover a protected resource, learn how that resource is protected, determine which AS to use, determine the correct resource identifier and scopes, confirm that the discovered AS is actually the right one, and do all of this without prior configuration?

Different deployment model. Different protocol primitives. Different threat surface.

🧭 The New Standards That Start to Open OAuth Up

Two recent standards address the core discovery problem.

Protected Resource Metadata (RFC 9728) gives the client a runtime path from “I found a protected resource” to “I know how to get the right token for it.” The resource advertises the AS it uses, the resource identifier, and other authorization requirements. A client that encounters a 401 with a WWW-Authenticate challenge can use that challenge to locate the resource’s metadata document, learn which AS issues tokens for it, and proceed from there.

Client Instance Metadata Document (CIMD) addresses the complementary problem: how an AS decides whether to trust a client instance it has never seen before. Rather than accepting self-asserted client metadata in a registration request (where DCR’s trust problem originates), the client publishes a metadata document at a well-known URL under its own domain. The AS independently fetches and verifies it over TLS, anchoring client identity in DNS and HTTPS without importing the full browser security model. The client is no longer vouching for itself in-band; the AS performs out-of-band verification against a stable, independently fetchable identity anchor.

This model is parallel to authorization server metadata and OpenID Connect Discovery: a party publishes metadata at a well-known HTTPS URL, and relying parties trust it because TLS anchors it to a specific DNS origin. CIMD extends that pattern to the client side.

CIMD has a clear boundary. It prevents impersonation of established services: an attacker who does not control example.com cannot publish a fraudulent CIMD document for a client claiming to be hosted there. It does not prevent look-alike domains. That is the inherent limit of any DNS-anchored identity system.

That still leaves a policy question for the AS: proving control of a domain is not the same thing as deciding that a client hosted at that domain should be trusted for a particular kind of interaction. CIMD improves identity anchoring. It does not replace local trust policy.

Protected Resource Metadata answers: where should the client go, and what should it ask for?

Client Instance Metadata Document answers: who is this client, and should the AS trust it?

Together, they move OAuth toward a trust model built on runtime discovery, HTTPS-anchored identity, and DNS-based origin verification rather than on the assumption that every trust relationship was arranged manually in advance.

⚠️ Two Gaps That Break Discovery in Practice

RFC 9728 and CIMD establish the right architecture. But there are two specific defects that still prevent the discovery flow from working reliably in real deployments. Without addressing them, open-world OAuth will produce predictable failures for agents at runtime.

🔍 Resource Identifier Matching

The first gap is in RFC 9728 itself. The standard required the resource value returned through a WWW-Authenticate-driven metadata lookup to exactly match the URL the client requested. In practice, this breaks discovery for APIs that protect multiple paths under one authorization policy. A resource server protecting /api/v1/calendar, /api/v1/email, and /api/v1/contacts cannot serve a single metadata document with a single resource identifier; it would need one per path. Many real APIs are structured this way.

Update to OAuth 2.0 Protected Resource Metadata Resource Identifier Validation addresses this with a narrow, targeted change: the advertised resource identifier may be a path prefix of the requested URL rather than an exact match, while keeping the same TLS origin requirement that prevents cross-origin resource impersonation. The security boundary is preserved. The practical deployment constraint is removed.

🔗 Resource Binding Confirmation

The second gap is more serious. Even after a successful discovery flow, an agent that receives an access token has no standard way to confirm what that token is actually valid for. Resource Indicators (RFC 8707) let the client declare which resource it wants the token for, but there is no corresponding mechanism for the AS to confirm which resource binding it honored. An AS may silently ignore the requested resource, bind the token to a different identifier based on policy, or accept only a subset of what was requested. The client sends the token to the discovered resource and receives a 403. The client cannot tell why, cannot detect this before sending, and has no interoperable way to recover.

This is not an edge case. In any multi-resource or dynamically discovered environment, silent resource binding divergence is a realistic failure mode, not a theoretical one.

OAuth 2.0 Resource Parameter in Access Token Response closes the loop by having the AS echo back the effective resource in the token response. Paired with the JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens (RFC 9068), which provides a standardized aud claim, the client can validate the resource binding before it sends the token anywhere.

Discovery finds the resource. The token request declares it. The token response confirms it. The token carries it.

If you are implementing or deploying OAuth for agentic systems, these two drafts are where review and implementation feedback will have the most direct impact on whether the discovery model actually works. Those defects are targeted and fixable. The gaps described in the next section run deeper.

🕳️ What Is Still Not Solved

For open-world OAuth to be usable end-to-end, four things need to hold at once:

• Discovery: the client can learn how a newly encountered resource is protected
• Binding: the client gets issuance-time confirmation of which resource a token is actually valid for
• Trust: both client and resource can evaluate newly encountered authorization servers without prior configuration
• Consent: the user’s approval stays meaningful even when downstream resources are discovered at execution time

Protected Resource Metadata, the two drafts above, and CIMD make real progress on discovery and binding. What remains falls into three areas: a security baseline that open-world clients need but current standards do not mandate; a trust chain running from metadata integrity through authorization server trust to delegation chains; and a consent model that stays meaningful when resources are discovered at execution time rather than known in advance. The subsections below follow that order.

🔐 Sender-Constrained Tokens Need to Be the Default Posture

In a closed world, bearer tokens are risky but manageable. The token’s audience is known, the RS validates it against its configured AS, and the blast radius of a stolen token is bounded by the trust relationships already in place.

In an open world, bearer tokens acquired from dynamically discovered authorization servers carry amplified risk. A token stolen in transit can be replayed against the resource it was issued for. DPoP (Demonstrating Proof-of-Possession at the Application Layer) sender-constrains access tokens to a specific key pair: a stolen token is useless without the corresponding private key.

But DPoP remains optional and negotiated informally. Protected Resource Metadata has no standard field for a resource server to require DPoP, and there is no standard mechanism for a client to negotiate DPoP use before beginning the token acquisition flow. In open-world deployments, sender-constrained tokens should be the expected posture, not an optional hardening step.

Pushed Authorization Requests (PAR) raise a parallel concern for interactive authorization flows. In open-world deployments where clients are not pre-registered and redirect URIs cannot be tightly validated in advance, authorization request injection becomes more realistic. PAR mitigates this by having the client push the full authorization request to the AS before the browser redirect. Neither DPoP nor PAR should require explicit per-deployment negotiation in open-world contexts; they should be discoverable defaults.

Mutual TLS sender-constrained tokens (RFC 8705) are another established option. But for open-world and web-native clients, DPoP is the more natural fit because it does not assume pre-existing certificate provisioning.

🎯 Metadata Integrity Under Adversarial Conditions

The open-world discovery model depends on resource servers serving accurate metadata. A malicious resource server can serve metadata pointing to an attacker-controlled AS. A client that completes an authorization flow against that AS delivers a valid-looking authorization code to an attacker, potentially for an account at a legitimate service. This is structurally analogous to open redirect vulnerabilities: the discovery mechanism becomes a vector for directing clients toward attacker-controlled infrastructure.

The current protections, HTTPS delivery and the same-origin requirement for resource values in RFC 9728, assume the resource server is honest. Signing metadata documents with JWS, using a key whose binding is verifiable independently of the TLS delivery channel, would let a client verify that a metadata document was signed by a key it has reason to trust. The cryptographic primitives already exist in JSON Object Signing and Encryption (JOSE). What does not exist is a standard for how resource servers publish signing keys, how clients discover and evaluate them, and what trust policy applies on first encounter.

OpenID Federation 1.0 is the closest existing answer: its entity statements are JWS-signed metadata documents, and its trust chains let parties establish trust without prior bilateral configuration by tracing signed assertions to a common trust anchor. The constraint is that both parties must be enrolled in a shared federation, which moves the closed-world assumption up one level rather than eliminating it. For first contact between parties with no common trust anchor, the metadata integrity problem remains open.

🤝 Authorization Server Trust on First Contact

Protected Resource Metadata tells a client which AS to use. It does not tell the client whether to trust that AS.

In a closed world this question does not arise: the AS was configured at deploy time. In an open world, a client receives an AS URL from resource metadata it just discovered. If that metadata was served by a compromised or malicious resource server, the AS URL could point anywhere.

The current protections rely on HTTPS and the Web Public Key Infrastructure (WebPKI): the AS must use valid TLS, and the resource metadata must be served from the same TLS origin as the resource. This does not address a resource server that is malicious rather than compromised, or one whose metadata can be influenced without full TLS compromise.

Even once a client has reached the AS, there is a related mix-up question: how does the client know which AS it is actually talking to at the point the authorization response comes back? Authorization Server Issuer Identification (RFC 9207) helps bind the response to the issuing AS, but it does not answer the earlier first-contact trust question of whether that AS should have been trusted in the first place.

A more complete trust model would give clients a way to evaluate AS identity beyond bare certificate validity. Signing AS metadata with a JSON Web Signature (JWS) key whose binding can be verified independently of the TLS channel that delivered the document would provide a foundation. A client that has reason to trust a particular signing key can verify a signed metadata document regardless of whether the delivery channel was intact. What is missing is standardization of that pattern: how signing keys are published using JSON Web Key (JWK) Sets (RFC 7517), how clients discover them, and what trust policy applies on first contact.

🪞 Resource Servers Need a First-Contact Trust Model Too

A dynamically discovered RS faces the symmetrical problem on the validation side: how does it validate a token the client presents when it has no pre-configured relationship with the AS that issued it?

JWT-structured access tokens (RFC 9068) provide a partial answer. The token is self-contained, carries standard claims including iss and aud, and can be validated by fetching the issuer’s JWK Set via authorization server metadata discovery (RFC 8414). A dynamically discovered RS that implements RFC 9068 validation can validate any token whose issuer publishes standard AS metadata, without needing to pre-register with that AS.

This resolves the mechanics, not the trust question. A valid JWT signature from an unknown issuer tells the RS it has a cryptographically well-formed token from some AS. It does not tell the RS whether that AS is an issuer this resource ought to trust in the context of this deployment. This is the RS-side version of the same first-contact trust problem: both client and RS need ways to evaluate newly encountered authorization servers that go beyond validating a certificate against the WebPKI.

At minimum, an RS needs some policy basis for acceptance: issuer allowlists, federation membership, signed metadata anchored in a trust framework, or some equivalent rule that answers not just “is this token valid?” but “is this issuer one I should accept tokens from at all?”

Token introspection (RFC 7662) does not help here. It requires the RS to already know where to send the token for validation, which presupposes a pre-existing AS relationship. It solves the validation mechanics for closed-world deployments; it cannot establish first-contact trust.

🔗 Client and Delegation Trust Across Authorization Servers

Agents frequently operate in chains. An orchestrating agent, acting on a user’s behalf, delegates to a sub-agent, which calls a resource it discovered at runtime, potentially protected by an AS that neither the user nor the orchestrator has ever interacted with.

This is still part of the open-world trust problem, not a separate agenda item. Once discovery happens at runtime, delegation chains can cross trust boundaries that were not pre-configured either. The same first-contact problem reappears, now applied to delegated authority rather than only to client and resource discovery.

OAuth 2.0 Token Exchange (RFC 8693) handles single-hop delegation within a trust domain where the involved ASes have a pre-existing relationship. The act claim records who is acting on whose behalf. Multi-hop chains that cross AS boundaries with no prior relationship between them are not well specified.

The specific problems: 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?

OAuth Identity and Authorization Chaining Across Domains addresses the cross-AS case directly, exploring how an AS can establish trust with another AS based on discovered metadata and how delegation claims can propagate across AS boundaries. Transaction Tokens addresses the complementary intra-domain problem: 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 what authority it was acting under. Identity Assertion JWT Authorization Grant (ID-JAG) covers a third pattern: a user’s identity assertion from one IdP is exchanged via RFC 8693 token exchange for a JWT grant that a target AS in a different domain can accept, allowing delegation to cross AS boundaries without an interactive authorization step at the target.

Together these drafts address the delegation problem at three layers (cross-AS trust establishment, intra-domain call context propagation, and IdP-mediated cross-domain identity assertion), but none is finalized and their interactions remain underspecified.

👀 Consent Transparency in Dynamic Discovery Flows

When a user authorizes an agent at setup time, they approve a stated purpose. During execution, the agent discovers resources dynamically and acquires tokens, each an implicit extension of the user’s original approval.

There is currently no standard for making that token acquisition visible to the user as it happens, for providing an auditable record of what resources the agent accessed under their authorization, or for flagging when the agent’s runtime token acquisitions exceed the reasonable scope of the user’s original intent.

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? Broad ex ante approval is easy to implement but weak. Step-up on every newly discovered resource destroys autonomy. Some form of policy-mediated expansion is the most plausible direction, but the protocol building blocks for it are still incomplete.

That is also the point where protocol design ends and trust framework design begins. OAuth can expose better signals, boundaries, and artifacts. It cannot by itself decide what a deployment considers meaningfully within intent.

⚖️ Authority Governance Above the Token Layer

The consent transparency gap points at a deeper problem. OAuth tokens answer one question: is this request permitted right now? They do not answer a different question that matters for open-world agents: should this agent still be operating at all?

In a closed world those two questions are close enough to treat as equivalent. In an open world they diverge. An agent that discovers tools and resources at runtime, adapts its plan mid-execution, and keeps running long after the user has left the room is not well-governed by credential validity alone. What it needs is a Mission: a durable authority record that was approved before execution began, stays in force across every derivation step, and can be terminated when the business reason ends regardless of how many tokens are technically still valid.

OAuth has no native concept of bounded lifecycle authority above the token layer. Tokens expire and rotate. The Mission behind them has no standard representation.

Two series I have written explore what this looks like in practice. Mission-Bound OAuth defines the Mission as a lifecycle-governed authority object at the AS: bounded by purpose, revocable by business event, and enforced across every downstream token and delegation. Mission Shaping addresses the prior question: how approved human intent becomes something a control plane can govern, and why the open-world runtime creates a second failure point even after shaping is done. Neither is an IETF draft. Both are WIP architecture that takes the consent transparency problem seriously enough to ask what the protocol layer above it needs to look like.

🌐 OAuth Is Moving Closer to the Web

The underlying pattern in the newer OAuth work is that the protocol is being pulled toward the same architectural constraints the web had to solve: runtime discovery, origin-bound trust, and defenses against redirection and replay in a world of first contact.

That analogy should not be pushed too far. Browsers have user-facing trust signals, origin isolation, and a much broader security model than OAuth clients do. But the family resemblance is real. Protected Resource Metadata makes authorization discoverable at runtime. CIMD anchors client identity in DNS and HTTPS. DPoP moves OAuth away from pure bearer semantics. The remaining gaps, signed metadata, stronger issuer trust policy, and better first-contact validation, look a lot like the hardening layer the web accumulated only after the basic model was deployed.

🚪 Closed World Was a Feature. Open World Is the Next Step.

OAuth became robust because it was designed around constrained assumptions and hardened over years of deployment and analysis.

Agents force a different assumption set. They operate in open worlds, encounter resources dynamically, and need a trust model that works without prior bilateral registration for every relationship they may encounter.

The newer OAuth work, including Protected Resource Metadata, Client Instance Metadata Document, and the gap-closing drafts, represents the first serious structural movement toward native open-world OAuth. These are not incremental additions to the old model. They are changes to its foundational deployment assumptions.

The remaining gaps are easier to state than to solve. Open-world OAuth still needs stronger first-contact trust for authorization servers and metadata, clearer rules for when a resource server should accept tokens from newly encountered issuers, and a better way to keep user approval meaningful when resources are discovered during execution. Some of those are protocol-standardization problems. Others are ecosystem trust-framework problems. Both matter.

The closed-world model gave OAuth the stability to become mature. The open-world extensions now in progress are the work required to make that maturity applicable to the next generation of clients operating in environments OAuth was never designed for.

Two of those gaps are targeted and fixable now. Update to OAuth 2.0 Protected Resource Metadata Resource Identifier Validation and OAuth 2.0 Resource Parameter in Access Token Response are active proposals in the IETF OAuth working group. If you are building or deploying OAuth for agentic systems, review them, implement against them, and bring feedback to the working group. These are the drafts where implementation experience will matter most before they can advance.

The harder problem is the one above the token layer. The Mission-Bound OAuth and Mission Shaping series lay out the architecture, but the right answers here depend on what people building real agent systems are actually running into. If you are working on agent authorization governance, lifecycle management, or the gap between approved intent and what the agent actually does at runtime, I want to hear from you.