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

[Mike Kuredjian <[e-mail]>]

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]
>