AI has blurred the line between developer and user. If my dad asks Claude to make him a custom news aggregator, he is the user in one sense and the developer in another.
If the use case at hand is "user authorizes creation of a personal client on their behalf", could that be addressed by protecting the DCR endpoint with a regular OAuth scope? Authorization is granted using one of the existing OAuth flows, and then the DCR endpoint is called with the user's dcr-scoped access token. It puts the responsibility for getting a human in the loop in the client's hands, as opposed to making it the DCR endpoint's problem. However, in the case of client registration, *hopefully* most of this could be frontloaded by the client while the user is still present. On the other hand, if the approval needed is from something (or someone) on the authorization server side (e.g. verifying privacy policy / ToS URLs), then I don't think polling is a good fit there as it could take days/weeks for that process to finish. Nick On Mon, Jul 20, 2026 at 5:04 AM Neil Madden <[email protected]> wrote: > > > On 20 Jul 2026, at 12:20, Max Gerber <[email protected]> wrote: > > > A few scattered thoughts: > - The latest spec > <https://modelcontextprotocol.io/specification/draft/basic/authorization/client-registration#dynamic-client-registration> > of > MCP has deprecated DCR in favor of CIMD. It is only included for backward > compatibility now. > - I would appreciate concrete examples of how AB-DCR compares to CIMD, and > where AB-DCR might be more appropriate to use. Off the top of my head - > this would be primarily for clients unable to host a CIMD URL? So primarily > native applications or CLI tools that are not associated with a website or > domain? > - I would be interested in exploring mechanisms that combine the approval > of the client with an authorization grant, so that the user doesn't need to > click through multiple flows back-to-back. > > Niel wrote: > > > clients are not tied to one particular user, so this seems dangerous if > any user can approve a client for everyone > > I think this is an issue the AS is already equipped to solve. The AS must > already have a policy defining which user or developer can register a > client manually, and that same policy should extend to which user can > approve a client registration. If the AS allows any developer to self-serve > sign up and create a client, then that same policy should govern client > approval. > > > Developer != User. Registration != Approval. Let’s not start conflating > these things! > > — Neil > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
