# OAuth 2.0 Consent & DCR vs CIMD & Agent OAuth Metadata

Classic OAuth 2.0 manual client registration & browser consent is the classic web primitive built for human browsers and pre-integrated services (Delegate scoped access to a pre-registered web or mobile application after a human clicks Allow in a browser), whereas OAuth Client ID Metadata Document (CIMD) and its step 3 (Permit) peers provide the machine-native agentic surface (/.well-known/oauth-authorization-server) so autonomous agents can answer: "How can an authorization server accept an OAuth client, such as an MCP client, that it has never seen before, without pre-registration or Dynamic Client Registration?" Across the agenticweb.wiki conformance panel, OAuth Client ID Metadata Document is multi-implementation (26 of 572 probed origins (last checked 2026-10-23)).

How OAuth 2.0 Consent & DCR compares to CIMD & Agent OAuth Metadata at step 3 (Permit): why the classic primitive breaks for software agents, and how sites deploy both together.

[3 Permit](/category/permit/) [OAuth Client ID Metadata Document](/protocols/oauth-cimd/) · [OAuth Protected Resource and Authorization Server Metadata (as used for agent authorization)](/protocols/oauth-metadata-for-agents/) · [auth.md](/protocols/auth-md/) · [Identity Assertion JWT Authorization Grant](/protocols/identity-assertion-authz-grant/) · [Agent Authorization Grant](/protocols/aauth/) · [OAuth Profile for Delegated AI Agent Authorization](/protocols/daap/)

| Dimension | Classic OAuth 2.0 manual client registration & browser consent Classic web | [OAuth Client ID Metadata Document](/protocols/oauth-cimd/) CIMD Agentic web |
| --- | --- | --- |
| Primary consumer | Human driving a web browser or pre-integrated developer code | Autonomous software agent, coding harness, or AI search/RAG crawler |
| Lifecycle step | Classic web baseline for step 3 (Permit) | 3 Permit: What may the agent do here? |
| Core question answered | Delegate scoped access to a pre-registered web or mobile application after a human clicks Allow in a browser. | How can an authorization server accept an OAuth client, such as an MCP client, that it has never seen before, without pre-registration or Dynamic Client Registration? |
| Wire format & entrypoint | /oauth/authorize interactive redirect + pre-registered client_id | document format at /.well-known/oauth-authorization-server |
| Failure mode for agents | An autonomous agent connecting to an unfamiliar MCP server or API for the first time does not have a pre-registered client_id with that origin, and headless agents cannot complete unannounced HTML login forms. | Solved natively: A Client ID Metadata Document lets an OAuth client use an HTTPS URL as its client_id and publish its metadata (name, redirect URIs, keys) at that URL. |
| Governance & status | Established IETF / W3C / industry baseline | IETF OAuth Working Group (WG Document) — Active Internet-Draft, WG Document of the IETF oauth WG; -02 dated 2026-07-06, expires 2027-01-07; the draft header says Standards Track |
| Live adoption (/check/ census) | Universal across the classic web | multi-implementation — 26 of 572 probed origins (last checked 2026-10-23) |
| Primary specification | https://www.rfc-editor.org/rfc/rfc6749 | [https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/](https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/) |

## Why OAuth 2.0 Consent & DCR breaks when the caller is an agent

An autonomous agent connecting to an unfamiliar MCP server or API for the first time does not have a pre-registered client_id with that origin, and headless agents cannot complete unannounced HTML login forms.

## When to use which (and how they work together)

- Keep Classic OAuth 2.0 manual client registration & browser consent: You are authenticating a known first-party or partner web app where a developer manually registered a client_id and redirect URI in your dashboard.

- Add OAuth Client ID Metadata Document (CIMD): You want any compliant MCP client or agent to self-identify via a URL-based Client ID Metadata Document (CIMD), discover auth endpoints via RFC 9728 /.well-known/oauth-protected-resource, or follow machine-readable /auth.md instructions.

## All agentic web standards replacing or extending OAuth 2.0 Consent & DCR

- [OAuth Client ID Metadata Document](/protocols/oauth-cimd/) (CIMD) — multi-implementation · 26/572 probed origins: How can an authorization server accept an OAuth client, such as an MCP client, that it has never seen before, without pre-registration or Dynamic Client Registration?

- [OAuth Protected Resource and Authorization Server Metadata (as used for agent authorization)](/protocols/oauth-metadata-for-agents/) — multi-implementation · 41/574 probed origins: How does an agent (or an MCP client acting for it) discover which authorization server protects a resource, and what that authorization server's endpoints and capabilities are, before requesting access?

- [auth.md](/protocols/auth-md/) — multi-implementation · 19/574 probed origins: How does an AI agent register a new account for its user on a service, without a human filling out a sign-up form or an OAuth redirect flow existing to authorize it?

- [Identity Assertion JWT Authorization Grant](/protocols/identity-assertion-authz-grant/) (ID-JAG) — multi-implementation · 5/574 probed origins: How can an app or AI agent, already SSO-federated to a user's enterprise identity provider, obtain scoped access to a third-party API or MCP server without a fresh consent screen at that third party?

- [Agent Authorization Grant](/protocols/aauth/) (AAuth) — none found: How can a conversational AI agent, reached over a channel without browser redirect (phone, SMS), obtain a properly scoped OAuth access token without impersonating the user?

- [OAuth Profile for Delegated AI Agent Authorization](/protocols/daap/) (DAAP) — prototype: How can a human user delegate constrained, attenuable, revocable authority to an AI agent using standard OAuth mechanisms, with no new endpoints or claims required?

Check whether any domain publishes these standards live at [/check/](/check/) or over MCP with probe and validate_manifest. [Connect](/connect/).

[JSON](/compare/oauth-vs-cimd/index.json) · [Markdown](/compare/oauth-vs-cimd/index.md) · [oauth-cimd.json](/data/protocols/oauth-cimd.json)