One additional thought under the DynReg paragraph. (Sorry for the spam, just popped in my head)
Hi Justin, Thanks for getting back this quickly. Registration mode flag I proposed the flag on the client side to give a more deterministic approach for client and AS to know what each supports (AS in server metadata). If the client does not send the flag with “approval” as supported mode, in the current draft, the AS knows it can’t send back a 202 Accepted response and it can immediately return a 400 error with a reason (invalid_client_metadata, and a reason that approval is needed). It makes it safer for (older) clients not to receive a response code (202) they have no logic for. Using DynReg Management I didn’t think about using the Management spec for that. I might need to think a bit more about this before voicing a full opinion, so the next few sentences are an initial set of thoughts and will need refining. The original idea as proposed in my first rough sketches originated more from the inspiration of Device Authorization Grant and Deferred Token Response and was different from this first public draft. Through further reflection and feedback by Jeff for instance, the design has changed. DynReg might be an alternative indeed, it depends on the purpose of DynReg and whether polling (for registration) is considered a DCR Management activity or not. I can see it map into it. My one other thought to moving polling to DynReg: What’s different from adding the polling on the registration endpoint versus adding it to DynReg, would the protocol be simplified or easier to implement? One more thought: Another reason for using the registration endpoint for polling is that the (approved) outcome is a registration with the existing data format of a registration, just like the client expects to see in a 201 response from the registration endpoint today. It’s worth to discuss this further. Use cases I think this goes beyond enterprise. It is easier today to develop, distribute, and deploy applications, and these applications run in many environments with different capabilities and characteristics. When they need to register as a client to reach a resource server, an approval-based option lets the AS apply a policy for verification and attestation of its choice, at scale. One example: Many MCP services rely on OAuth for authorization. Anyone can develop an application that interacts with them, and these need to be registered as clients. DCR is called out as one of the options in the MCP specifications for that and with an approval-based protocol, the AS has a better path to control these client registrations. Regards, Philippe PS: removed Phil Hunt and Maciej Machulak's from the list as their addresses are bouncing. From: Justin Richer <[email protected]> Date: Sunday, July 19, 2026 at 11:36 PM To: Dellaert, Philippe <[email protected]>; [email protected] <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: RE: [EXTERNAL] 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. 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]
