đź‘Ť
> Am 14.12.2020 um 17:39 schrieb Brian Campbell > <bcampbell=40pingidentity....@dmarc.ietf.org>: > >  > And that's done: > https://mailarchive.ietf.org/arch/msg/oauth/W0eq4HUiiLVS5F5qyXXY6Gdw7vs/ > >> On Mon, Dec 14, 2020 at 8:42 AM Torsten Lodderstedt >> <torsten=40lodderstedt....@dmarc.ietf.org> wrote: >> +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 >> > > 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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
