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

Protected Resource Metadata (PRM), OAuth Client ID Metadata Document (CIMD), and related drafts are starting to close that gap. But the transition is incomplete.

This post focuses on that specific problem: what it takes for OAuth to work in an open-world deployment model.

Other agent authorization challenges, including agent identity, delegation governance, attestation, and attenuation, appear here only where they affect open-world trust bootstrapping rather than as the primary subject.

🧱 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 boundedness is a major reason the OAuth Security Best Current Practices could become so concrete over time: the assumptions were constrained enough to analyze rigorously and stable enough to harden through deployment.

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 Earlier Attempts Did Not Close the Gap

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.

OAuth 2.1 takes a different step. It 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 Model Context Protocol (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

One recently published RFC and a closely related active draft together address the core discovery problem.

Protected Resource Metadata 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.

OAuth Client ID Metadata Document addresses a narrower but important complementary problem: how an AS can evaluate client metadata for a client instance it has never seen before without relying only on self-asserted registration input.

Rather than accepting client metadata only in-band 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 only in-band; the AS can verify metadata 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.

Adjacent workload-identity work matters here too. The ongoing OAuth SPIFFE Client Authentication draft, alongside the AI Agent Authentication and Authorization draft that treats agents explicitly as workloads, profiles how SPIFFE identities and workload attestation can be used for OAuth client authentication.

That is not the same trust model as CIMD, and it does not by itself create a unified first-contact bootstrap story for open-world sub-agents. It is a complementary piece for deployments where the caller is better modeled as an attested workload inside a managed trust domain than as a traditional web-hosted software client. Work in this area also connects back to CIMD by defining metadata parameters such as spiffe_id and spiffe_bundle_endpoint, which help bridge origin-based client discovery and SPIFFE-backed client authentication without collapsing the two models into one.

A third layer sits between software-client identity and workload identity: agent-instance identity. CIMD anchors who the software client is; SPIFFE anchors what process is running. Neither addresses the identity of a specific agent invocation, which is an ephemeral, task-scoped principal that may call multiple resources within a single execution context or spawn sub-agents that need a verifiable identity derived from the parent authorization. There is no current standard for how an agent instance asserts a durable, scoped identity across the lifetime of a task, or for how a sub-agent’s identity is provably bound to its parent’s authorization context in a way that downstream resources can verify.

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.

It also leaves a deployment-shape question. CIMD is strongest for clients that can anchor themselves in DNS and HTTPS. Agents increasingly involve a mix of public clients, confidential clients, sub-agents, and short-lived workloads that may be better modeled as attested workloads than as traditional domain-hosted software. How those client classes authenticate, identify themselves, and compose in truly open-world deployments is still incomplete work rather than a settled standards path.

PRM answers most of: where should the client go, and what should it ask for?

CIMD answers part of: who is this client, and what metadata is it asserting from a stable origin?

Together, they move OAuth toward a 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. They still leave the policy question of whether a given AS should trust a newly encountered client for a given interaction.

🌐 OAuth Is Reaching For Web-Scale Trust Primitives

OAuth was always web-native. It runs on HTTP, uses browser redirects, and was built around URIs from the start. What is changing is that OAuth is now reaching for the layer of the web it never needed before: the trust model browsers developed for open-world, first-contact interactions with parties that have no prior relationship.

The web developed patterns for this problem, including anchoring identity in DNS origins backed by TLS, treating unknown cross-origin parties as untrusted by default, and verifying content integrity independently of the delivery channel. Those patterns exist because the web had to work at internet scale without assuming prior bilateral configuration. OAuth did not need them because its deployment model was closed-world.

PRM uses a related origin-anchoring pattern: resource identity is grounded in the same TLS origin as the resource itself. CIMD extends a similar idea to the client side, anchoring who a client is in DNS rather than in self-asserted registration input. Signed metadata would add independent content verification, validating a metadata document without relying only on the delivery channel that served it.

That analogy is illustrative rather than complete. It holds for the discovery and metadata layer: origin anchoring, independently verifiable artifacts, and runtime trust evaluation rather than pre-configured bilateral relationships. It stops being useful once the problem shifts to delegation semantics, workload identity, authorization-server trust evaluation, or Mission shaping. Those are the gaps that begin once discovery succeeds, and they require protocol primitives the web never needed to develop.

🧪 A Concrete Example of the Open-World Flow

Imagine an agent helping a salesperson prepare an account-renewal brief.

The agent discovers a CRM MCP tool at runtime. It calls a get-account operation and receives a 401 challenge. The WWW-Authenticate header in the response points to the resource’s metadata document. PRM returns the AS URL, the effective resource identifier, and the required authorization parameters. The agent uses that information to request a token. That is the discovery layer working as intended.

What the example also exposes is where the subsequent layers break. If the AS returns a token without echoing the effective resource binding, the agent cannot confirm whether the token is valid for the account API it just discovered. If the CRM AS is newly encountered, the client still has to decide whether it should trust that AS at all. If the workflow later points the agent toward a billing API in another trust domain, the delegation and issuer-acceptance problem repeats.

That full arc, from discovery through resource binding through first-contact trust, is the substrate open-world OAuth has to make reliable. The next section addresses two specific gaps that break that substrate in practice; the deeper semantic and governance questions begin where the substrate ends.

⚠️ Two Gaps That Break Discovery in Practice

PRM and CIMD point toward the right shape. But there are two specific gaps 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 PRM itself. The standard requires 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. The client knows what resource binding was honored before it sends the token anywhere.

Discovery finds the resource. The token request declares it. The token response confirms 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 gaps are targeted and fixable. The gaps described in the next section run deeper.

🕳️ What Is Still Not Solved

Solving the discovery layer is necessary but not sufficient. Even when PRM, CIMD, and the two gap-closing drafts are all in place, a generic agent still faces unsolved problems at the trust-framework and governance layers.

For open-world OAuth to be usable end-to-end, all three layers need to work. PRM and the two drafts above make real progress on the protocol layer. Adjacent agent and workload-identity work sharpens the identity side of the problem: open-world trust now has to compose not just with software clients in the abstract, but with attested workloads, ephemeral sub-agents, and multi-hop execution chains.

What remains in this post falls into three categories: a security-baseline adoption gap, metadata integrity, and first-contact trust. The semantic and governance gaps run deeper; they are the subject of Part 2.

🔐 Sender-Constrained Tokens Need to Be the Default Posture

The technical answer to sender-constrained tokens already exists. 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. PRM defines dpop_bound_access_tokens_required, which lets a resource server signal that it requires DPoP-bound tokens. The mechanism is specified and implementable today.

The gap is not the mechanism. It is adoption and mandate. In a closed world, bearer tokens are risky but manageable: the token audience is known, the RS validates against its configured AS, and the blast radius of a stolen token is bounded by pre-existing trust relationships. In an open world, tokens acquired from dynamically discovered authorization servers carry amplified replay risk. No baseline open-world OAuth mandate requires an AS to support DPoP, and nothing in the current standards makes sender-constrained tokens the expected posture for open-world deployments rather than an opt-in capability.

The closest existing baseline is FAPI 2.0 Security Profile, which mandates DPoP or mutual TLS for regulated financial API deployments and demonstrates that such a mandate is implementable at industry scale. FAPI applies to a specific regulated domain, not to open-world OAuth broadly. But it is the clearest existing evidence that a sender-constraint mandate can be specified, deployed, and hardened. What is missing is an equivalent baseline for open-world agentic contexts.

Pushed Authorization Requests (PAR) address a related concern for interactive, user-present 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. PKCE (RFC 7636) is the complementary baseline defense for authorization code interception in public-client flows. For agent-to-agent and machine-to-machine flows, which dominate agentic systems, DPoP is the more directly applicable sender-constraint mechanism; PAR and PKCE apply where a user-present redirect flow is involved.

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 can end up delivering an authorization code to the wrong security domain, 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 PRM, 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. Active deployment in eIDAS 2.0 gives it more than theoretical standing. 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.

This is distinct from the authorization server trust problem below. Here the question is whether the metadata document itself is authentic. The next question is whether the AS that document points to is one the client should trust at all.

🤝 First-Contact Trust Is Bilateral

The first-contact trust problem applies in both directions. A client that receives an AS URL from newly discovered resource metadata needs a way to evaluate whether that AS should be trusted at all. A resource server that receives a token from an unknown issuer faces the same problem in reverse. The current standards leave both sides underspecified.

On the client side, PRM 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, the AS URL comes from metadata discovered at runtime. 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. Authorization Server Issuer Identification (RFC 9207) helps bind an authorization response to the issuing AS, but it does not answer whether that AS should have been trusted in the first place.

On the resource server side, 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 can validate any token whose issuer publishes standard AS metadata, without needing to pre-register with that AS. But a valid JWT signature from an unknown issuer tells the RS only that it has a cryptographically well-formed token from some AS. It does not tell the RS whether that AS is one this resource should accept tokens from at all. Token introspection (RFC 7662) does not solve that first-contact problem: it requires the RS to already know where to send the token for validation, which presupposes the pre-existing AS relationship it does not have.

What is missing for both sides is a deeper trust channel independent of TLS delivery. Signing AS metadata with a JSON Web Signature (JWS) key whose binding can be verified out-of-band would give a client a way to evaluate a metadata document regardless of whether the delivery path was intact, and would give an RS a way to evaluate issuer trustworthiness beyond signature mechanics. What does not exist is a standard for how AS signing keys are published via JSON Web Key (JWK) Sets (RFC 7517), how either party discovers them on first contact, and what trust policy applies. 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?” That remains open work on both sides of the trust relationship.

The web’s experience with PKI and ACME is instructive. Web PKI solved open-world first-contact trust at internet scale by reducing identity to a verifiable property (domain control), delegating trust through a hierarchy of signed assertions, and making certificate issuance auditable through Certificate Transparency. ACME then demonstrated that automating trust bootstrapping, rather than requiring manual bilateral coordination for every new relationship, is what drove TLS adoption from a minority to a near-universal baseline.

OAuth already relies on Web PKI for transport security. The open gap is the application layer above TLS: a standard for verifiable AS identity, an automated bootstrapping mechanism for AS trust, and a transparency mechanism for issuer metadata. The problem is not unsolvable. The architecture exists. The OAuth-specific instantiation does not yet.

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

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

Agents expose 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 PRM, CIMD, 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 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.

That also means a large surface area has to evolve for OAuth to become truly capable in open-world agent ecosystems. There is real value in evolving the infrastructure we already have. OAuth, OpenID Connect, and the surrounding deployment base are too important to bypass. But this path will take time because it touches discovery, trust bootstrapping, sender constraints, and metadata integrity across several specifications rather than one.

The remaining gaps are easier to state than to solve. Some are protocol-standardization problems; others require coordination across trust frameworks and multiple specifications.

Adjacent work such as AAuth (editor’s copy, accessed April 7, 2026) takes a different angle by redesigning authorization choreography around open-world assumptions from the start. That deserves attention, but the narrower point for this post is the OAuth substrate: discovery, resource binding, sender constraints, metadata integrity, and first-contact trust all have to work before higher-level agent authorization can be reliable.

Two of those gaps are targeted and fixable now: the resource identifier matching fix and the resource binding confirmation draft described earlier in this post. The rest require deeper ecosystem work. Without a substrate that can handle runtime discovery, resource binding, and first-contact trust, the rest of the authorization stack is built on the wrong assumptions.

That is where Part 2 picks up: once discovery and first-contact trust exist, how does approved intent become bounded authority across delegation, tool semantics, consent continuity, and the full lifecycle of a task?