Thanks for sharing this draft Philippe. I have a use case for this as an AS and have been wanting to implement this kind of pattern for a while. I think doing the work to standardize this is valuable and would like to contribute to any work on this.
I think some of the confusion in the replies so far is because the draft seems to use the word "client" in a non-standard way (e.g. in the sentence "typically the user running the client"). The word "user" also seems to be used to mean both "end user" and "operator/developer of a client" (here I am using the standard meaning of client). The introduction could make more consistent use of the term "approving party" and might need some more terminology. With that being said, I think I understand the intended use cases. I agree with Max that CIMD is probably a better pattern unless you can't use it (because clients can't host a URL). Regarding Nick's point about really long polling, that is the pattern we are trying to enable with deferred token responses. I'm not sure it's necessary here though. A few comments on the draft itself: 1. It's not clear to me how this happens or that it is always necessary: "A registration produced by this flow is associated with the specific authenticated approver who approved it." (from section 4.1) 2. I'm not sure that the verification_uri should be REQUIRED. For instance, your use case "High-Assurance Approval via a Native Application" does not use it. Cheers, Frederik On Mon, 20 Jul 2026 at 15:29, Nick Watson <[email protected]> wrote: > 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]
