Skip to 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

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.

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.

Relationship to others

Primary sources

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