How an MCP client should tell your OAuth server who it is

Authorization systems serving autonomous agents increasingly distinguish between identifying client software and establishing the user authority under which it acts. MCP’s July 2026 specification deprecated Dynamic Client Registration (DCR) in favor of Client ID Metadata Documents (CIMD), though DCR remains necessary during a transition period for clients such as IDE plugins and CLIs; DCR creates server-side client records but can cause client sprawl, abuse risks, and credential-lifecycle burdens. CIMD instead uses an HTTPS URL as a portable client ID whose hosted JSON metadata is fetched and validated by authorization servers, reducing registration writes but requiring strong SSRF protections, caching, and policies for unknown domains because domain control does not establish reputation or user authorization. The auth.md protocol is presented as a complementary layer for delegation, using OAuth metadata, identity assertions, and service-owned claim flows to connect an agent to a user, apply staged scopes, enforce step-up authentication for account linking, and support both anonymous and provider-verified registration paths. It also separates revocation of individual credentials from provider-initiated revocation of an entire agent-user relationship, while emphasizing audit logging, rate limits, secret handling, trusted provider lists, and short-lived tokens. The recommended approach is to adopt CIMD for open MCP client identity, retain DCR for legacy compatibility, and use auth.md when services need to determine whose authority an agent holds, what it can access, and how that access can be withdrawn.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.