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

[Guilherme Oliveira Niero <[e-mail]>]

Hi Philippe,

I’d like to share a few thoughts from a perspective outside the agentic space, where many of our fellow WG members have already covered.

Your proposal seems to be a good fit for use cases where software is distributed to audiences with limited technical expertise, but where some OAuth setup is still required.

I can also imagine it being used in scenarios where it is not acceptable for an intermediary to handle any type of application credentials.

I have a use case that could probably use this approach to solve the setup of physical devices.

Regards,
Guilherme


Corporativo | Interno

From: Dellaert, Philippe <[e-mail]>
Date: Monday, 20 July 2026 at 01:42
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]>, [e-mail] <[e-mail]>, Guilherme Oliveira Niero <[e-mail]>, [e-mail] <[e-mail]>
Subject: 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

Esta mensagem é reservada e sua divulgação, distribuição, reprodução ou qualquer forma de uso é proibida e depende de prévia autorização desta instituição. O remetente utiliza o correio eletrônico no exercício do seu trabalho ou em razão dele, eximindo esta instituição de qualquer responsabilidade por utilização indevida. Se você recebeu esta mensagem por engano, favor eliminá-la imediatamente.

This message is reserved and its disclosure, distribution, reproduction or any other form of use is prohibited and shall depend upon previous proper authorization. The sender uses the electronic mail in the exercise of his/her work or by virtue thereof, and the institution takes no liability for its undue use. If you have received this e-mail by mistake, please delete it immediately.