Hi Frederik, Can you share more details on your use case? And I certainly welcome your contributions.
On the confusion: I'll address these in my next draft submission, thanks for pointing out the proper use. Max, you, and I are aligned on the use of CIMD being a better pattern if the client can host a CIMD URL. I also agree on the long polling, this draft targets short (minutes) to medium (hours) term approval, not days. On your questions: 1. The intention here is to allow the AS to associate the client with an approver, it is not mandatory if the AS doesn't see a use for it. My thought is that it is useful for security, audit and a trail to have an association. 2. I've modeled the verification URI and complete URI on RFC 8628 and used the same REQUIRED and OPTIONAL choices. While the use case you mention uses the complete URI to show a QR code to the user, the client could (and should) still display the verification URI itself to the user if they do not want to use the QR code. That verification URI could then redirect them to the native application where they can fill in the code manually. I can update the use case to mention this specifically. Let me know if you see either (or both) differently? Regards, Philippe From: Frederik Krogsdal Jacobsen <[email protected]> Date: Monday, July 20, 2026 at 6:51 AM To: Nick Watson <[email protected]> Cc: Philippe Dellaert <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: [EXTERNAL] [OAUTH-WG] Re: New Internet-Draft: Approval-Based Dynamic Client Registration CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. 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]<mailto:[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]<mailto:[email protected]>> wrote: On 20 Jul 2026, at 12:20, Max Gerber <[email protected]<mailto:[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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
