+1 for following Vladimir’s proposal > Am 14.12.2020 um 14:54 schrieb Brian Campbell > <bcampbell=40pingidentity....@dmarc.ietf.org>: > > er, I mean an -05 > > On Mon, Dec 14, 2020 at 6:45 AM Brian Campbell <bcampb...@pingidentity.com> > wrote: > Thanks Vladimir, that seems quite reasonable. Barring any objections, I'll > add that to a -04. > > On Mon, Dec 14, 2020 at 1:33 AM Vladimir Dzhuvinov <vladi...@connect2id.com> > wrote: > 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> >> 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> 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> >>> 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 >> >> 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 > > > 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.google.com/url?q=https://www.ietf.org/mailman/listinfo/oauth&source=gmail-imap&ust=1608558896000000&usg=AOvVaw1OfSvPLJHvFwCsMayd7e4U
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
