What about the whole issue of redirect_uri fragments? Are there any issues where a client for some reason can’t register a perm URI at registration time?
Phil @independentid www.independentid.com phil.h...@oracle.com On Jul 8, 2014, at 8:39 PM, Richer, Justin P. <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> 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 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
