From nobody Thu Dec 3 03:49:31 2020 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0573A07B3 for ; Thu, 3 Dec 2020 03:49:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4HiOBFCU6Zj for ; Thu, 3 Dec 2020 03:49:27 -0800 (PST) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C2873A0769 for ; Thu, 3 Dec 2020 03:49:27 -0800 (PST) Received: by mail-lf1-x135.google.com with SMTP id u18so2260469lfd.9 for ; Thu, 03 Dec 2020 03:49:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aEmswWxW8lZW9BgkupyraOZtjFRYupq1YMH/JQgEghQ=; b=aHzmP47CJpCbRHfXrqZpwP2TL/Tss3yBVliV9zV0bgggGp2GIXdeQDQyMn8ds/lf30 lhIAlJdWfH+YoOQxGuMxHoy47lJ0HITQp0gdcWhZiZyG5pPPamKpMhhRKJ2NnnStbjSL WZkwKu51Lg+HJSkwKnRpopUfRQXWCLiwg7DmzAja0m3N2tSqmeMtCrmWzMbAMB4hg/Rb UPHrxp2C3gwO5Kbu+O1/qT8FZBq2zX5/NJNODHruc36KzVXPI8hdZ0bmLNM+6ptdfBrx NCS7awGP/XqCa/B/N/rmUnpqkgDnXFrAoEPe4AIl0dVIqiYdNXh2PCbSBty45AQxPvIb aD7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aEmswWxW8lZW9BgkupyraOZtjFRYupq1YMH/JQgEghQ=; b=WAhtccv4cpHSrYQxvtW1QDoOvdGNQ353K6YS76tpD/oCm+1i/lscoIa7N9GvnvufKM 63W8MkCFVH7QOODAPPcJTkjqPY8pAPHA/Cq9Nux9UyD4+7KJsXQbZ5b7OTc3mOF5LIx6 HsW6l8Rc7jxyF47D2Ek3znHZbiMsk3bcmB850IJErITBUE+xSBbM9ypBv3BObfaxziGZ qdeIQTmNcZttFFzYTMTR0YMWJrMkFXv8quxby2Fa2b8Cy0EfcUxYM6yjNxm1Y8PRgoBW Oy4PprYszQr7kCZfx5OBFFvvB8vwYwVyHuiFlfNhjQ0ELRHWZCy2vphqIanjJNSuvJB0 CZLQ== X-Gm-Message-State: AOAM531yvcEHK2Q2hF8WeRdOs1hNKouLoJkdG4O8bBBNaHtZa7EoXs6h s38hikC9r6gce8IVKOQVUGwHLBsYZUnTf4cdL7M= X-Google-Smtp-Source: ABdhPJy0nxgNEMA3qX8g18kEXTW+lHwoTmkDX4pdCwsitNXJF6YIG6/zdpky/6ASCgphJIZ6X9HkkZq90U0fuf0ObYI= X-Received: by 2002:a19:8405:: with SMTP id g5mr1193434lfd.360.1606996165193; Thu, 03 Dec 2020 03:49:25 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a19:4c5:0:0:0:0:0 with HTTP; Thu, 3 Dec 2020 03:49:24 -0800 (PST) In-Reply-To: References: From: Rifaat Shekh-Yusef Date: Thu, 3 Dec 2020 06:49:24 -0500 Message-ID: To: Filip Skokan Cc: Torsten Lodderstedt , Brian Campbell , oauth Content-Type: multipart/alternative; boundary="00000000000094f3d105b58df3b7" Archived-At: Subject: [OAUTH-WG] PAR error for redirect URI? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 11:49:30 -0000 --00000000000094f3d105b58df3b7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 > wrote: > >> >> >> > Am 03.12.2020 um 09:56 schrieb Filip Skokan : >> > >> > 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 Extensio= ns >> 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 RFC674= 9 >> 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, =E2=80=A6 authorization server ... MUST NOT automati= cally >> 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 > 40pingidentity.com@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 th= at >> call thought it would be worthwhile to have a more specific error code f= or >> an invalid redirect_uri and I reluctantly took an action item to raise t= he >> 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 t= o >> 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 send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> 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=3Dhttps://www.ietf.org/mailman/li >> stinfo/oauth&source=3Dgmail-imap&ust=3D1607590629000000&usg=3DAOvV >> aw3aW1gdv4EEiLmNYzlsJj-A >> >> --00000000000094f3d105b58df3b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Torsten, Filip,

You can absolutely make this change, as = we are still very early in the process.=C2=A0
So feel free to con= tinue this effort and try to get WG agreement on this, and update the docum= ent as needed.=C2=A0

Regards,
=C2=A0Rifa= at


On Thursday, December 3, 2020, Filip Skokan= <panva.ip@gmail= .com> wrote:
To b= e clear, I'm not advocating to skip the registration, just wanted to me= ntion a potential concern. If the process allows it and it will not introdu= ce more delay to publication, I think we should go ahead and register the e= rror code.

Best,
Filip


On Thu, 3 Dec 202= 0 at 11:06, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:


> Am 03.12.2020 um 09:56 schrieb Filip Skokan <panva.ip@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&#= 39;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 usag= e location, should be pushed authorization endpoint then, and RFC6749 gives= clear guidance on how to treat errors related to the redirect URI at the a= uthorization endpoint.

"If the request fails due to a missing, invalid, or mismatching
=C2=A0 =C2=A0redirection URI, =E2=80=A6 authorization server ... MUST NOT a= utomatically redirect the user-agent to the
=C2=A0 =C2=A0invalid 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=3D40pingidentity= .com@dmarc.ietf.org> wrote:
> During the course of a recent OIDF FAPI WG discussion (the FAPI profil= es 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 <= a href=3D"https://www.ietf.org/archive/id/draft-ietf-oauth-par-04.html#sect= ion-2.3" rel=3D"noreferrer" target=3D"_blank">https://www.ietf.org/archive/= id/draft-ietf-oauth-par-04.html#section-2.3 even shows a gene= ral error code with mention of the redirect_uri not being valid in the erro= r description). Some folks on that call thought it would be worthwhile to h= ave a more specific error code for an invalid redirect_uri and I reluctantl= y took an action item to raise the issue here. At the time I'd forgotte= n that PAR had already passed WGLC. But it's been sitting idle while aw= aiting 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 d= o.
>
> As I write this message, however, I'm not personally convinced tha= t 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 t= o my word. So here it is. Please weigh in, if you have opinions on the matt= er.
>
>
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged material for the sole use of the intended recipient(s). Any review, us= e, distribution or disclosure by others is strictly prohibited.=C2=A0 If yo= u have received this communication in error, please notify the sender immed= iately 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=3Dhttps://www.ietf.org/mailman/listinfo/o= auth&source=3Dgmail-imap&ust=3D1607590629000000&usg=3DAOvV= aw3aW1gdv4EEiLmNYzlsJj-A

--00000000000094f3d105b58df3b7--