spec(auth, draft): clarify pre-provisioned registration fallback#1506
spec(auth, draft): clarify pre-provisioned registration fallback#1506monmohan wants to merge 2 commits intomodelcontextprotocol:mainfrom
Conversation
…ove credential mentions
monmohan
changed the title
|
@D-McAdams Thanks for the Discord feedback. I’ve updated this PR to address it:
This should clarify the fallback path without overlapping with the client-credentials work. PTAL when you have a moment. |
| ### Pre-provisioned registration fallback | ||
|
|
||
| MCP **clients MUST** support a pre-provisioned registration path in addition to Dynamic Client Registration (DCR). Clients **MUST** provide either: | ||
|
|
||
| 1. A user-facing input mechanism for a pre-provisioned `client_id`; or | ||
| 2. A managed configuration mechanism (e.g., a configuration file). | ||
|
|
||
| When a corresponding authorization server does not support DCR—or when enterprise policy requires pre-registration, clients **MUST** allow users or administrators to supply these values. | ||
|
|
||
| **Authorization servers** that do not support DCR **MUST** provide a non-DCR mechanism to register a client and obtain the resulting `client_id` (e.g., an administrative portal), allowing **users or administrators** to supply any required **client metadata** (such as redirect URIs) during registration. |
There was a problem hiding this comment.
This has changed the requirement on clients. Before, clients could only support DCR. Now, you are saying clients MUST support pre-provisioned registration even if they do support DCR.
I think at the very least, this should be changed to a SHOULD. This flow is riddled with problems because it requires users/admins to correctly configure said client metadata...something that users can and will get wrong. This will cause toil both for the users and for the client implementors who will get plenty of issues opened on them that "my client isn't connecting to my MCP server" when really it was the user who misconfigured it.
I understand that this is a stopgap for Auth Servers that don't support DCR, but the UX burden is a lot, and I think this should be heavily considered before we go forcing every client to support this flow.
There was a problem hiding this comment.
Hi Tyler,
This is mainly a clarification of the existing verbiage in the spec, which already required pre-provisioned registration as a fallback. It appears that VS Code has already implemented this functionality based on the original wording of the spec. microsoft/vscode#252892
Given the nature of this change as clarifying the existing text rather than adding new requirements, and that VS Code has already implemented it, do you still have concerns with it?
There was a problem hiding this comment.
I think I got mixed up by the original text, good we're clarifying it 😄 seems like it was always expected that there is some mechanism for handling AS that don't support DCR.
Yes, VS Code already supports this flow as a fallback to DCR.
|
Wanted to reiterate something I wrote over in the Discord thread in support of this:
|
|
After reviewing the updated docs/specification/draft/basic/authorization.mdx, I can see that preregistration fallback and prereg support are now covered there (Preregistration section# 5.2). That effectively captures what I was aiming for with this PR, so I’m going to close this as superseded by SEP-991 / PR #1296 Thanks to everyone who weighed in on the earlier discussion—glad to see preregistration clarified in the spec. |
4 participants
Summary
Minor clarifications to the Draft Authorization spec to make pre-registration a first-class fallback when DCR is unavailable or enterprise policy requires it.
Changes
client_id(e.g., administrative portal), allowing users/administrators to supply required client metadata (e.g., redirect URIs).docs/clients.mdxto satisfy Prettier CI (No content changes).Motivation and Context
Many enterprises require pre-registered/static clients for change control, scoped blast radius, and incident isolation. This gives a spec-blessed fallback to DCR, that popular clients can implement with minimal work.
How Has This Been Tested?
Doc-only change. No code changes.
Breaking Changes
None. Backward compatible; no protocol flow changes.
Types of changes
Checklist
Additional context
This change reflects discussion in the MCP WG Discord (Aug 23–26, 2025) on pre-registration, with input from Paul Carleton (Anthropic) and others. It captures:
Discord link: https://discord.com/channels/1358869848138059966/1408762963807961138