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> wrote: > > > > Am 03.12.2020 um 09:56 schrieb Filip Skokan <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> 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 > 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 > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > > https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth&source=gmail-imap&ust=1607590629000000&usg=AOvVaw3aW1gdv4EEiLmNYzlsJj-A > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
