Hi Brian, I'd like to propose the sentence in bold to be inserted into the current section 2.3 of PAR -04:
https://tools.ietf.org/html/draft-ietf-oauth-par-04#section-2.3 The authorization server returns an error response with the same format as is specified for error responses from the token endpoint in Section 5.2 of [RFC6749] using the appropriate error code from therein or from Section 4.1.2.1 of [RFC6749]. *In those cases where Section 4.1.2.1 of [RFC6749] prohibits automatic redirection with an error back to the requesting client and hence doesn’t define an error code, for example when the request fails due to a missing, invalid, or mismatching redirection URI, the “invalid_request” error code can be used as the default error code.* Hope with this we can close the case. Vladimir On 04/12/2020 18:08, Brian Campbell wrote: > > > On Fri, Dec 4, 2020 at 12:30 AM Vladimir Dzhuvinov > <vladi...@connect2id.com <mailto:vladi...@connect2id.com>> wrote: > > 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. > > > Following from the response I recently sent to Neil, I don't think a > legitimate need has been articulated. > https://mailarchive.ietf.org/arch/msg/oauth/gMiH1mTr0AKDvWpqO1zikcVUySY/ > > > 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. > > I don't know that that's needed either. But do have some text to > suggest that you think would be helpful? > > > > 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 >> 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 >> > _______________________________________________ >> > 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 >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > > > /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./ -- Vladimir Dzhuvinov
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
