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

[Mike Kuredjian <[e-mail]>]

Makes sense - I often forget about the management spec, to the point
that one of our internal developers messing around with Claw hit a
roadblock with their agentic code because our DCR implementation didn't
have the presumed management APIs, but it's good to keep it in mind as
something to formally support :D

On Mon, Aug 3, 2026 at 2:20 PM Dellaert, Philippe <[e-mail]>
wrote:

> 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]> 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]>
> *Sent:* Monday, July 20, 2026 12:40 AM
> *To:* [e-mail] <[e-mail]>
> *Cc:* [e-mail] <[e-mail]>;
> [e-mail] <[e-mail]>;
> [e-mail] <[e-mail]>; [e-mail] <
> [e-mail]>; [e-mail] <
> [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]
> To unsubscribe send an email to [e-mail]
>
>