AgentGrade

RFC 7591 — Dynamic Client Registration

Identity & trust · IETF OAuth Working Group · Updated 2026-07-31

Status: Proposed Standard (IETF), published July 2015; deprecated by MCP in favor of Client ID Metadata Documents · Authoritative source

The 2015 RFC that lets a client register itself with an authorization server by POSTing JSON — no human, no form. It made the first wave of agent auth possible, and the agentic web is already replacing it.

RFC 7591 defines a registration endpoint: a client POSTs its metadata (name, redirect URIs, grant types) as JSON and receives a client_id — and optionally a secret — in return. Registration can be open (“the client registration endpoint SHOULD allow registration requests with no authorization”) or gated by an initial access token; signed software statements let a trusted party vouch for client metadata. Its companion, RFC 7592 (managing registrations after the fact), never advanced past Experimental.

For agents, DCR answered the cold-start question: an agent encountering a brand-new MCP server can’t have pre-registered, so the 2025-06-18 MCP spec recommended DCR to let clients “obtain OAuth client IDs without user interaction.” The cost surfaced quickly — an open registration endpoint means anyone in the world can mint clients, so operators bolted on rate limits and verification. And every server issues its own client_id, so a popular agent accumulates thousands of identities, one per server it has ever met.

That churn is why the recommendation flipped. Since the 2025-11-25 revision — unchanged in the current 2026-07-28 spec — MCP recommends OAuth Client ID Metadata Documents (CIMD; an active OAuth WG draft by Aaron Parecki and Emelia Smith): the client’s client_id is an HTTPS URL, and the authorization server fetches the client’s metadata from it. Same self-service property, no registration endpoint to abuse, one stable identity everywhere — and it reuses RFC 7591’s metadata vocabulary, so the RFC’s field names outlive its endpoint. The spec keeps DCR as a MAY, explicitly “deprecated and retained for backwards compatibility.”

DCR request → the CIMD replacement

POST /register                       ← RFC 7591 (deprecated in MCP)
{ "client_name": "Example Agent",
  "redirect_uris": ["https://agent.example/cb"],
  "grant_types": ["authorization_code"] }
→ 201 { "client_id": "s6BhdRkqt3", ... }

client_id = "https://agent.example/oauth-client.json"
                                     ← CIMD, current MCP guidance: the AS
                                       GETs that URL and uses the JSON as
                                       the registration — no /register needed

How AgentGrade checks it

Not scored directly: registration is a property of the client-and-authorization-server pair, not of the scanned site. What the scanner does verify is the discovery chain that leads here — the MCP handshake and, on the roadmap, the RFC 8414 metadata that advertises whether a registration endpoint exists at all. Scan your site to see where you stand.

Related

All standards

RFC 9421 · Web Bot Auth · RFC 8615 · MCP · A2A · x402 · WebMCP · llms.txt · RFC 9309 · RFC 9110 · RFC 9116 · OAuth Discovery · RFC 7591 · RFC 9727 · ACP / UCP / AP2 · Index