Hi Max, The use cases are indeed for locally deployed applications that are unable to host a CIMD URL. CLI tools are one, agent frameworks are another, especially the latter can connect to different resource servers and there's no baked-in client identifier.
On the Authorization Grant: this was something that was initially in my rough notes for this draft, but after reviewing this, it was decided not to include it in AB-DCR because it would change the DCR client information response, or would require a different request and likely different endpoint. AB-DCR focusses on the registration and doesn't touch the established processes for grants. Happy to explore alternatives if there's good ideas on how to solve this user experience. Regards, Philippe From: Max Gerber <[email protected]> Date: Monday, July 20, 2026 at 4:20 AM To: Neil Madden <[email protected]> Cc: Philippe Dellaert <[email protected]>; [email protected] <[email protected]>; [email protected] <[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. 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. If the AS requires developers to be onboarded in some manner, those developers should be onboarded before making the client globally available. Additionally, several ASs currently have concepts of organization-bound or user-bound clients, which can only be used with a subset of users as determined by AS policy. On Mon, Jul 20, 2026 at 10:55 AM Neil Madden <[email protected]<mailto:[email protected]>> wrote: It would be good to understand exactly what approval you are expecting to happen during this flow? The draft says “an explicit approval step performed by an approving party, typically the user running the client”. But clients are not tied to one particular user, so this seems dangerous if any user can approve a client for everyone. Dynamic client registration always has the problem of what exactly the AS or an approver is supposed to base their decision on, when all they have is client-asserted values. Software statements improve this somewhat, where supported. The only approval steps I can think of that make sense are things like reviewing policy/privacy documents etc for compliance. But that’s not something that can be completed in a few minutes while the client sits around polling for a response. On 20 Jul 2026, at 05:41, Dellaert, Philippe <[email protected]<mailto:[email protected]>> wrote: Hi all, As you might have noticed, I’ve submitted a new Internet-Draft: Approval-Based Dynamic Client Registration: https://datatracker.ietf.org/doc/draft-dellaert-oauth-approval-based-dcr/ Dynamic Client Registration provides a way for new clients to register themselves using an open registration mechanism, or registering using an Initial Access Token for extra security. For certain clients like native applications, CLI tools, or applications at scale, providing an IAT is not always an option and open registration is something many operators prefer to avoid. I propose an approval-based registration using the existing DCR registration endpoint where the client opts-in for this new mode. If the authorization server’s policy supports and requires an approval before the client is registered, it returns a registration code, a verification code and a verification URI. The client polls the registration endpoint while an approver approves or denies the registration request out of band using the verification code and the verification URI. Once approved, on the next poll, the client receives a normal DCR response. A lot of this is inspired by the Device Authorization Grant (RFC 8628) and the Deferred Token Response draft. I do diverge from these proposals by using specific HTTP response codes instead of using error responses. Registration success remains 201, a pending registration waiting for approval returns 202, both for initial request and polling, and 429 with a Retry-After response header is used to indicate to the client to slow down the requests. 400 is still used for errors. I’d welcome feedback from the group, and especially from the authors of Dynamic Client Registration as this is an addition to DCR, and from the authors of Device Authorization Grant and Deferred Token Response as they are a source of inspiration. I have cc’d the DCR and DTR authors out of courtesy, not out of any expectation. Regards, Philippe _______________________________________________ OAuth mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> _______________________________________________ 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]
