If people have articulated a need to have an invalid_redirect_uri error for the PAR endpoint, then let's register it properly. Rifaat says there's still time to do this.
I'm also okay with using the general invalid_request code for this. In this case a sentence, next to the current example, spelling out what the PAR endpoint must do on a invalid redirect URI will help. Vladimir On 03/12/2020 13:49, Rifaat Shekh-Yusef wrote: > Torsten, Filip, > > You can absolutely make this change, as we are still very early in the > process. > So feel free to continue this effort and try to get WG agreement on > this, and update the document as needed. > > Regards, > Rifaat > > > On Thursday, December 3, 2020, Filip Skokan <panva...@gmail.com > <mailto:panva...@gmail.com>> wrote: > > To be clear, I'm not advocating to skip the registration, just > wanted to mention a potential concern. If the process allows it > and it will not introduce more delay to publication, I think we > should go ahead and register the error code. > > Best, > *Filip* > > > On Thu, 3 Dec 2020 at 11:06, Torsten Lodderstedt > <tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>> wrote: > > > > > Am 03.12.2020 um 09:56 schrieb Filip Skokan > <panva...@gmail.com <mailto:panva...@gmail.com>>: > > > > There are several documents already mentioning > "invalid_redirect_uri" as an error code, specifically RFC7519 > and OpenID Connect Dynamic Client Registration 1.0. But these > don't register it in the IANA OAuth Extensions Error Registry, > presumably because they're neither for the authorization or > token endpoints. > > > > While I think it'd be great if we had this error code > registered, I also worry that its registration could confuse > implementers to think it's okay to return it from the > authorization endpoint. > > I understand your concern. On the other hand, registering the > error code is in my opinion the proper way forward. The > registration is scoped to a usage location, should be pushed > authorization endpoint then, and RFC6749 gives clear guidance > on how to treat errors related to the redirect URI at the > authorization endpoint. > > "If the request fails due to a missing, invalid, or mismatching > redirection URI, … authorization server ... MUST NOT > automatically redirect the user-agent to the > invalid redirection URI." > > I think if an implementor ignores this, it will ignore any advise. > > best regards, > Torsten. > > > > > Best, > > Filip > > > > > > On Thu, 3 Dec 2020 at 00:29, Brian Campbell > <bcampbell=40pingidentity....@dmarc.ietf.org > <mailto:40pingidentity....@dmarc.ietf.org>> wrote: > > During the course of a recent OIDF FAPI WG discussion (the > FAPI profiles use PAR for authz requests) on this issue it was > noted that there's no specific error code for problems with > the redirect_uri (the example in > > https://www.ietf.org/archive/id/draft-ietf-oauth-par-04.html#section-2.3 > > <https://www.ietf.org/archive/id/draft-ietf-oauth-par-04.html#section-2.3> > even shows a general error code with mention of the > redirect_uri not being valid in the error description). Some > folks on that call thought it would be worthwhile to have a > more specific error code for an invalid redirect_uri and I > reluctantly took an action item to raise the issue here. At > the time I'd forgotten that PAR had already passed WGLC. But > it's been sitting idle while awaiting the shepherd writeup > since mid September so it's maybe realistic to think the > window for a small change is still open. > > > > Presumably nothing like an "invalid_redirect_uri" error code > was defined in RFC 6749 because that class of errors could not > be returned to the client via redirection. But the data flow > in PAR would allow for a "invalid_redirect_uri" so it's not an > unreasonable thing to do. > > > > As I write this message, however, I'm not personally > convinced that it's worth making a change to PAR at this > point. But I did say I'd bring the question up in the WG list > and I'm just trying to be true to my word. So here it is. > Please weigh in, if you have opinions on the matter. > > > > > > > > CONFIDENTIALITY NOTICE: This email may contain confidential > and privileged material for the sole use of the intended > recipient(s). Any review, use, distribution or disclosure by > others is strictly prohibited. If you have received this > communication in error, please notify the sender immediately > by e-mail and delete the message and any file attachments from > your computer. Thank > you._______________________________________________ > > OAuth mailing list > > OAuth@ietf.org <mailto:OAuth@ietf.org> > > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org <mailto:OAuth@ietf.org> > > > > https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth&source=gmail-imap&ust=1607590629000000&usg=AOvVaw3aW1gdv4EEiLmNYzlsJj-A > > <https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth&source=gmail-imap&ust=1607590629000000&usg=AOvVaw3aW1gdv4EEiLmNYzlsJj-A> > >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
