In the current draft of Dyn-Reg-Management (https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-12 <https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-12>) there’s a clause that’s causing some consternation in the general review:
Since the client configuration endpoint is an OAuth 2.0 protected resource, it SHOULD have some rate limiting on failures to prevent the registration access token from being disclosed though repeated access attempts. A comment has been raised arguing that this text isn’t helpful to implementors as it doesn’t tell them what kind of rate limiting to do or how to accomplish it. It has also been pointed out that there’s not an obvious need for this recommendation if there’s enough entropy in the registration access token to begin with. The suggestion has been made to drop the above text, and potentially to add a reference to the sections on token complexity in 6750 §5.2 and 6819 §5.1.4.2.2. My suggested text in that regard is: Since possession of the registration access token authorizes the holder to potentially read, modify, or delete a client’s registration (including its credentials such as a client_secret), the registration access token MUST contain sufficient entropy such as described in [RFC6750] Section 5.2 and [RFC6819] Section 5.1.4.2.2. I would add this as the last sentence to the first paragraph in the security considerations section. What does the WG think of this suggested change? — Justin
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
