Also, I just noticed that paragraph has a typo: "redirect_uri" should be "redirect_uris".
-- Justin On Jul 8, 2014, at 11:39 PM, Justin Richer <jric...@mitre.org<mailto:jric...@mitre.org>> wrote: I can see where you're going with it. Requiring clients to use it implies that servers need to enforce it. In the security considerations we currently have: For clients that use redirect-based grant types such as "authorization_code" and "implicit", authorization servers MUST require clients to register their "redirect_uri" values. This can help mitigate attacks where rogue actors inject and impersonate a validly registered client and intercept its authorization code or tokens through an invalid redirection URI or open redirector. However, in previous versions up to -17, this was a SHOULD, not a MUST. This is a normative requirement change for server implementors and I want to make sure everyone realizes was made. As of a handful of versions ago, our server started to enforce this anyway. What have other developers done with this, and would it be difficult to comply with the new requirement? -- Justin On Jul 8, 2014, at 10:22 PM, Mike Jones <michael.jo...@microsoft.com<mailto:michael.jo...@microsoft.com>> wrote: That’s close but not quite right, since use is required by clients when using redirect-based grant types. We could however, use this language: The implementation and use of all client metadata fields is OPTIONAL, other than "redirect_uris" which is REQUIRED for authorization servers that support and clients that use redirect-based grant types. redirect_uris (...) Authorization servers that support dynamic registration of clients using redirect-based grant types MUST implement support for this metadata value and clients that use redirect-based grant types MUST use this parameter. -- Mike From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Richer, Justin P. Sent: Tuesday, July 08, 2014 6:44 PM To: oauth@ietf.org<mailto:oauth@ietf.org> list Subject: [OAUTH-WG] Dynamic Client Registration: comment on metadata requirements In draft -18, we clarified the optionality of the client metadata parameters in § 2 with new text, including the sentences: The implementation and use of all client metadata fields is OPTIONAL, other than "redirect_uris". redirect_uris (...) Authorization servers MUST implement support for this metadata value. However, since OAuth core defines two non-redirect flows (client credentials and password) and we're about to publish another one (assertions), I suggest that we adopt the following clarification: The implementation and use of all client metadata fields is OPTIONAL, other than "redirect_uris" which is REQUIRED for authorization servers that support redirect-based grant types. Authorization servers that support dynamic registration of clients using redirect-based grant types MUST implement support for this metadata value. I think this language brings the requirement more in line with the intent and would like comment from the WG. -- Justin
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
