[Decision] Registry will not implement RFC 7591 DCR server-side

[aarora79]

Sub-issue G: Decision doc — "Registry will not implement RFC 7591 DCR server-side"

Parent: #988
Labels: documentation, architecture, oauth, mcp-spec, subtask
Phase: n/a (decision)
Depends on: none
Blocks: none

---

Summary

Record the explicit decision that the Registry Gateway will not implement RFC 7591 Dynamic Client Registration as a server-side feature. Point future contributors to the CIMD path (sub-issues B and C) as the supported alternative. Prevent re-attempts like the old Feat/DCR PR (#511) from reopening the discussion.

Background

DCR is currently a SHOULD in the MCP 2025-06-18 authorization spec, with an explicit fallback clause. The November 2025 spec direction (Aaron Parecki) retires DCR in favor of CIMD + ID-JAG. Reasons documented in the spec update:

• Unbounded database growth on every authorization server — every client registration is a new row, forever.
• Rate-limiting complexity — ASes have to guard against registration-based abuse.
• No revocation mechanism — once registered, a client can't be un-registered in any standard way.
• Enterprise IT loses control — employees can register arbitrary clients without admin approval.

Implementing DCR server-side in the Registry would expose us to all four, for a feature that the spec is actively moving off of. We control the upstream IdP config (Entra / Keycloak / Okta / Cognito / Auth0) and can register clients there when genuinely needed. CIMD covers the "self-describing client" use case without DCR's drawbacks.

A prior PR (#511 Feat/DCR, ryohang) attempted this and was closed. We want to make the decision explicit so future contributors don't re-attempt.

Scope

In scope

• Decision document in docs/ or docs/adr/ titled "No DCR in the Registry" (or ADR-NNN format, whichever matches existing repo conventions). Content:
  • Decision statement.
  • Context (spec references, current state).
  • Alternatives considered: DCR server-side; DCR client-side only; CIMD; pre-registered clients only.
  • Consequences: what operators do instead (configure clients in upstream IdP; use CIMD); how this affects contributors (reject DCR PRs pointing here).
  • Revisit trigger: the MCP spec reinstates DCR as MUST or a major client regresses to DCR-only.
• README.md pointer to the ADR in a "Design decisions" section.
• CONTRIBUTING.md pointer (if it exists) in a "Before opening a PR" checklist.
• Close-the-loop on Feat/DCR #511 with a comment linking to this ADR so the history is traceable.

Out of scope

• Actually implementing CIMD (that's B and C).
• Changing any current code behavior. This is a docs-only issue.

Design notes

• Use whichever decision-record format the repo already uses. If there's no existing ADR directory, this is the first one; establish docs/adr/NNNN-no-dcr.md as the convention going forward.
• Keep it short. One page. The point is to be findable and authoritative, not exhaustive.
• Link to the recommendation doc (.scratchpad/coding-assistant-oauth/recommendation-2026-05-04.md) only if we decide to promote parts of it into /docs. Scratchpad paths should not be long-term references.

Acceptance criteria

• Decision doc exists in docs/ (or docs/adr/ if establishing ADR convention).
• README has a "Design decisions" section (or equivalent) linking to the ADR.
• Feat/DCR #511 has a comment linking to the ADR.
• Merged; discoverable via repo search for "DCR" and "Dynamic Client Registration".

Risks and open questions

• Spec direction could reverse. Unlikely in the short term, but if DCR comes back as MUST in a future MCP spec revision, the ADR needs a "revisit date" and a process for amending decisions. Establish that pattern here since we don't have it yet.
• Enterprise customer ask. If a customer specifically asks for DCR, the ADR gives us a clean, documented response rather than an ad-hoc refusal.

References

• RFC 7591 Dynamic Client Registration
• Aaron Parecki, MCP Authorization Spec Update (2025-11-25) — rationale for removing DCR
• PR Feat/DCR #511 Feat/DCR (CLOSED) — prior attempt
• Umbrella issue Support New MCP Authorization Spec (November 2025) #256
• Recommendation doc §4 TL;DR point 4, §5 #NEW-G: .scratchpad/coding-assistant-oauth/recommendation-2026-05-04.md