From nobody Mon Dec 14 07:42:07 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 4E1043A0F13 for ; Mon, 14 Dec 2020 07:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=lodderstedt.net 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 osH_PnOSo0Jv for ; Mon, 14 Dec 2020 07:42:03 -0800 (PST) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 32BCD3A0EF5 for ; Mon, 14 Dec 2020 07:41:19 -0800 (PST) Received: by mail-wr1-x432.google.com with SMTP id w5so13147183wrm.11 for ; Mon, 14 Dec 2020 07:41:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oAdhlyay2ge7QYMLQGx+xAym6RRw5iy4B5S0dlRH5wI=; b=DoTfajz90MVVxjW0CKBK5UQSe1fCPkXca91xiCuVdTnlFW4EGorhRMKuvUOaODoH0a KR6Xh0NJdqYqU9N0tkAhuduTIkqk2DHtznGu85yzx2F8htpU7kMXy9tV/vMHzhP1CgGt OZPTQIIDqxjiPXcCEbUT8PZIhGLUBtqFZG2+7lZAmLI8flAUwjJ0P5ckfKTtzdKxSkPT a887Qm2XL2Ub2f+9belu0SR2YABBgzhpGMoPEqipAIEJrcb8xarb96DhOA9DgdmcNLAT DTUWcKqdmQg9L72mEgpGNnv9IIL4SnFIvBqX0Uvciz5FEIofUs6w8EvvTigmzURIis4H ZNeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oAdhlyay2ge7QYMLQGx+xAym6RRw5iy4B5S0dlRH5wI=; b=JO4wHYahtBzSCS5OZi4HpS7LFqZns5F+yUsRKuCZ5DL2yoir1p1UG+C9NALBCLLa18 yQCGqqV2a7Kkq9pD078ayXScKtPl0v7UhABMrHyrTn+GeDkMrpRNMq6q9E7E0XXkcDZL d6NcMFGQLCcTJc2rOJvuAFOP8RWZ/t5xlueA6WSIwDQANL11i20ci2vP4J7REk1O3dOL wbiG2cQBUBsc2uiQpLmFBWc5CWc+24K81ucRRWPIuab9G5zfjSJeDy/YkSX7/LG4aRdf twzGoxFCk4bj3PoZBFLnr+nVCkRQxQsmJEn2Mu2snI2dBzAWu+5vBHCkoGZ7Q5eLvC20 mBRA== X-Gm-Message-State: AOAM532xBCehNoVWqbMy0RLPC1TtT8A4Y95hFab6/uzdZA6ZJCYR3xb6 kYX2P+6QvcnSw0uWh5E8ig4p0A== X-Google-Smtp-Source: ABdhPJyUw45qqdwaZhcPvFVcwFzlhKspPg9pLZIWxk7ipEmJAdtF1SXLiO3Yi93MeaZ52WOiTui1Qw== X-Received: by 2002:adf:e547:: with SMTP id z7mr28811324wrm.283.1607960477368; Mon, 14 Dec 2020 07:41:17 -0800 (PST) Received: from p200300eb8f1bfa8c2d051919c65c81dd.dip0.t-ipconnect.de (p200300eb8f1bfa8c2d051919c65c81dd.dip0.t-ipconnect.de. [2003:eb:8f1b:fa8c:2d05:1919:c65c:81dd]) by smtp.gmail.com with ESMTPSA id a65sm30052825wmc.35.2020.12.14.07.41.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Dec 2020 07:41:16 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) From: Torsten Lodderstedt In-Reply-To: Date: Mon, 14 Dec 2020 16:41:15 +0100 Cc: Vladimir Dzhuvinov , oauth Content-Transfer-Encoding: quoted-printable Message-Id: References: <9a58bd66-e259-ebb9-1ed5-3f5075f44d97@connect2id.com> <8bf0dae0-54b8-3b33-87b2-634b40ac4a85@connect2id.com> To: Brian Campbell X-Mailer: Apple Mail (2.3654.20.0.2.21) Archived-At: Subject: Re: [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: Mon, 14 Dec 2020 15:42:05 -0000 +1 for following Vladimir=E2=80=99s proposal > Am 14.12.2020 um 14:54 schrieb Brian Campbell = : >=20 > er, I mean an -05=20 >=20 > On Mon, Dec 14, 2020 at 6:45 AM Brian Campbell = wrote: > Thanks Vladimir, that seems quite reasonable. Barring any objections, = I'll add that to a -04.=20 >=20 > On Mon, Dec 14, 2020 at 1:33 AM Vladimir Dzhuvinov = wrote: > Hi Brian, >=20 > I'd like to propose the sentence in bold to be inserted into the = current section 2.3 of PAR -04: >=20 > https://tools.ietf.org/html/draft-ietf-oauth-par-04#section-2.3 >=20 > 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=E2=80=99t define an error code, = for example when the request fails due to a missing, invalid, or = mismatching redirection URI, the =E2=80=9Cinvalid_request=E2=80=9D error = code can be used as the default error code. >=20 > Hope with this we can close the case. >=20 > Vladimir >=20 >=20 > On 04/12/2020 18:08, Brian Campbell wrote: >>=20 >>=20 >> On Fri, Dec 4, 2020 at 12:30 AM Vladimir Dzhuvinov = 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. >>=20 >>=20 >> 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/ >> =20 >> 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. >>=20 >> I don't know that that's needed either. But do have some text to = suggest that you think would be helpful?=20 >>=20 >> =20 >>=20 >> Vladimir >>=20 >> On 03/12/2020 13:49, Rifaat Shekh-Yusef wrote: >>> Torsten, Filip, >>>=20 >>> You can absolutely make this change, as we are still very early in = the process.=20 >>> So feel free to continue this effort and try to get WG agreement on = this, and update the document as needed.=20 >>>=20 >>> Regards, >>> Rifaat >>>=20 >>>=20 >>> 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. >>>=20 >>> Best, >>> Filip >>>=20 >>>=20 >>> On Thu, 3 Dec 2020 at 11:06, Torsten Lodderstedt = wrote: >>>=20 >>>=20 >>> > Am 03.12.2020 um 09:56 schrieb Filip Skokan : >>> >=20 >>> > 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. >>> >=20 >>> > 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. >>>=20 >>> 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.=20 >>>=20 >>> "If the request fails due to a missing, invalid, or mismatching >>> redirection URI, =E2=80=A6 authorization server ... MUST NOT = automatically redirect the user-agent to the >>> invalid redirection URI." >>>=20 >>> I think if an implementor ignores this, it will ignore any advise. >>>=20 >>> best regards, >>> Torsten.=20 >>>=20 >>> >=20 >>> > Best, >>> > Filip >>> >=20 >>> >=20 >>> > On Thu, 3 Dec 2020 at 00:29, Brian Campbell = 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. >>> >=20 >>> > 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.=20 >>> >=20 >>> > 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.=20 >>> >=20 >>> >=20 >>> >=20 >>> > 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=3Dhttps://www.ietf.org/mailman/listinfo/oauth= &source=3Dgmail-imap&ust=3D1607590629000000&usg=3DAOvVaw3aW1gdv4EEiLmNYzls= Jj-A >>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> 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. > --=20 > Vladimir Dzhuvinov >=20 >=20 > 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=3Dhttps://www.ietf.org/mailman/listinfo/oauth= &source=3Dgmail-imap&ust=3D1608558896000000&usg=3DAOvVaw1OfSvPLJHvFwCsMayd= 7e4U