Skip to main content
Agent Identity

IETF · July 2015

OAuth 2.0 Dynamic Client Registration Protocol

RFC 7591

J. Richer, M. Jones, J. Bradley, M. Machulak, P. Hunt

RFCStableIdentityFoundationField guide

OAuth 2.0 Dynamic Client Registration Protocol (RFC 7591) is RFC, July 2015. An agent that discovers a new MCP server at runtime historically called DCR. That is why the ecosystem is moving to URL-as-client_id (CIMD) and why AAuth skips client registration entirely in favor of a published agent key.

ShareLinkedInX

At a glance

Problem
Clients that did not exist at AS-configuration time (mobile apps, and now agents and MCP clients) need a way to obtain a client_id without a human filling out a developer portal.
Identity / authn / authz
Client identity provisioning. It issues a client_id; it is not user identity.

Actors

  • Software client
  • Authorization server

01

The gap for agents

Clients that did not exist at AS-configuration time need a client_id without a human filling out a developer portal. RFC 7591 is how mobile apps and, later, MCP clients minted one at runtime. Open registration without software statements is an abuse magnet — spam clients, secret leakage, no lifecycle.

MCP 2026-07-28 deprecates DCR as the preferred mechanism in favor of CIMD, keeping DCR as a MAY for old servers. AAuth skips client registration entirely in favor of a published agent key.

02

Actors and trust boundaries

The registration endpoint is a provisioning plane. An open endpoint lets anyone become a client. Software statements (signed metadata) and initial access tokens are how you close it. client_secret in an agent host is a liability.

03

Mechanics

POST a metadata document to the registration endpoint. AS returns client_id, optional client_secret, and registered metadata. RFC 7592 (management) is optional. MCP requires that credentials obtained via DCR are bound to that AS issuer and not reused if PRM points at a new AS.

client_id / client_secretfrom spec
Quoted outputs. Secrets in agent hosts are a liability; CIMD or public-key methods are preferable.

04

Step-by-step flows

Flow 1

Register then authorize

  1. 1

    Client discovers registration_endpoint from RFC 8414 metadata.

  2. 2

    POSTs redirect_uris, client_name, token_endpoint_auth_method, jwks, …

  3. 3

    Stores client_id (and secret if any) keyed by AS issuer.

  4. 4

    Proceeds with authorization code + PKCE.

05

Identity vs authentication vs authorization

Client identity provisioning. Issues a client_id; not user identity. Not authorization of APIs.

06

How it composes

07

What bites agent implementers

  • Open registration abuse

    Botnets will register. Require software statements or CIMD instead.

  • Secret reuse across ASes

    MCP explicitly forbids reusing DCR credentials when the AS changes. Mix-up adjacent.

08

Stability — what you can ship

RFC 7591, July 2015. Stable RFC, politically deprecated for MCP-like open-world clients in favor of CIMD. https://www.rfc-editor.org/rfc/rfc7591.html

Catalog claims (short form)

client_id / client_secret
Newly issued credentials. Secrets in agent hosts are a liability; CIMD or public-key methods are preferable.

Implementer notes

MCP 2026-07-28 deprecates DCR as the preferred mechanism in favor of Client ID Metadata Documents, keeping DCR as a MAY for old servers. Open registration without software statements is an abuse magnet.

Related

Primary sources

  • RFC 7591https://www.rfc-editor.org/rfc/rfc7591.html