{
 "url": "https://agenticweb.wiki/compare/oauth-vs-cimd/",
 "title": "OAuth 2.0 Consent & DCR vs CIMD & Agent OAuth…",
 "description": "OAuth 2.0 Consent & DCR vs CIMD & Agent OAuth Metadata: An autonomous agent connecting to an unfamiliar MCP server or API for the first time does not…",
 "markdown_url": "https://agenticweb.wiki/compare/oauth-vs-cimd/index.md",
 "markdown": "# OAuth 2.0 Consent & DCR vs CIMD & Agent OAuth Metadata\n\nClassic 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)).\n\nHow 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.\n\n[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/)\n\n| Dimension | Classic OAuth 2.0 manual client registration & browser consent Classic web | [OAuth Client ID Metadata Document](/protocols/oauth-cimd/) CIMD Agentic web |\n| --- | --- | --- |\n| Primary consumer | Human driving a web browser or pre-integrated developer code | Autonomous software agent, coding harness, or AI search/RAG crawler |\n| Lifecycle step | Classic web baseline for step 3 (Permit) | 3 Permit: What may the agent do here? |\n| 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? |\n| Wire format & entrypoint | /oauth/authorize interactive redirect + pre-registered client_id | document format at /.well-known/oauth-authorization-server |\n| 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. |\n| 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 |\n| Live adoption (/check/ census) | Universal across the classic web | multi-implementation — 26 of 572 probed origins (last checked 2026-10-23) |\n| 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/) |\n\n## Why OAuth 2.0 Consent & DCR breaks when the caller is an agent\n\nAn 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.\n\n## When to use which (and how they work together)\n\n- 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.\n\n- 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.\n\n## All agentic web standards replacing or extending OAuth 2.0 Consent & DCR\n\n- [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?\n\n- [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?\n\n- [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?\n\n- [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?\n\n- [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?\n\n- [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?\n\nCheck whether any domain publishes these standards live at [/check/](/check/) or over MCP with probe and validate_manifest. [Connect](/connect/).\n\n[JSON](/compare/oauth-vs-cimd/index.json) · [Markdown](/compare/oauth-vs-cimd/index.md) · [oauth-cimd.json](/data/protocols/oauth-cimd.json)\n"
}