[OAUTH-WG] Re: New Internet-Draft: Approval-Based Dynamic Client Registration

["Dellaert, Philippe" <[e-mail]>]

Hi Mike,

Thanks for your feedback. Your use case is aligned with what some others have pinged me on and what I’ve seen, glad there’s multiple of us facing these problems and there’s a use for this type of protocol.

I think it’s better not to put a requirement on the client_id format and let the AS decide. The draft does not put any requirements or restrictions on this.  If an AS wants to use the registration code as the client_id, it’s their choice.  If the AS wants to use a preferred format for their client_ids, or use a CIMD client_id (if the AS wants to host metadata for all registered clients), they should have that freedom.

On extending the management spec, I need to dig deeper what the most appropriate approach is. I think Justin feedback is good, so I’ll work on this idea more.

Regards,
Philippe

From: Mike Kuredjian <[e-mail]>
Date: Monday, August 3, 2026 at 1:07 PM
To: Justin Richer <[e-mail]>
Cc: Dellaert, Philippe <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: RE: [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.

Justin & Philipe,

Replying to echo that it's an interesting spec and I can think of one clear niche where it would apply: MCPs wherein the tools being offered are of a 2LO access nature and/or sensitive. In our particular case at Atlassian, we're looking to offer org administrators an MCP with tools geared around such use-cases (site admin, user admin, etc), and one could imagine wanting such a protection against fully dynamic client registration that we otherwise see with pure DCR agents. Of course CIMD + whitelist can be used to solve to this, but as we know, not all agents are able to host a TLS endpoint, so by providing an OOB approval option, you can offer DCR for these more sensitive use-cases, knowing activation will be gated.

Extending the management spec is also appealing... I wonder if there's a case to be made for the registration token to be a client_id itself (albeit in a disabled state)?

Best,

Michael


On Sun, Jul 19, 2026 at 11:36 PM Justin Richer <[e-mail]<mailto:[e-mail]>> wrote:
Phillipe, thanks for sending this out - this is an interesting idea. I had a couple questions upon first skimming that I was wondering if you'd already worked through or not, so I'd love to hear your thoughts. Most of them center around how this new functionality layers in with the existing DynReg spec, both for clients and servers.

You've got a registration mode flag here — but is it important in this model that the client opts in? Because I'm wondering if a client could just make a normal request and get back a "pending" response instead of the standard one. It seems like it'd be the AS's choice to support an immediate registration or not, based on some policy or something about the client's request, and not the client's stance on the matter. It's an error to the naive client if the AS doesn't do immediate mode anyway. Is there a difference here I might be missing?

Second, I'm wondering if the additional code and round-trip management protocol is necessary here. If the client gets back a "pending" response, instead of using a new protocol just to manage pending registrations, we could perhaps extend the DynReg Management spec (RFC7592) for this case. So the client gets its registration access token and to poll for updates does a GET on the management endpoint. If it's still pending, we can respond with the 202 pending request just like in the initial registration. To cancel it can do a DELETE on that endpoint, instead of having a special flag. I've not thought deeply about this, but am I missing something that a separate protocol and endpoint bring to the party here?

Overall, I think this semi-synchronous mode is an interesting one that could layer in with DynReg for (what seems to me) a niche set of use cases, but I can definitely see it in an enterprise type environment, for instance, where policy controls registration more strictly than on the open web.

 -- Justin
________________________________
From: Dellaert, Philippe <pdellaer=[e-mail]<mailto:[e-mail]>>
Sent: Monday, July 20, 2026 12:40 AM
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [OAUTH-WG] New Internet-Draft: Approval-Based Dynamic Client Registration

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 -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>