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