Re: [OAUTH-WG] PAR error for redirect URI?

Torsten Lodderstedt <torsten@lodderstedt.net> Mon, 14 December 2020 17:04 UTC

Return-Path: <torsten@lodderstedt.net>
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 B01793A0B32 for <oauth@ietfa.amsl.com>; Mon, 14 Dec 2020 09:04:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.097
X-Spam-Level:
X-Spam-Status: No, score=-0.097 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 D4hnpQl0KCVv for <oauth@ietfa.amsl.com>; Mon, 14 Dec 2020 09:03:58 -0800 (PST)
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 013813A0B2D for <oauth@ietf.org>; Mon, 14 Dec 2020 09:03:57 -0800 (PST)
Received: by mail-ed1-x530.google.com with SMTP id h16so17891131edt.7 for <oauth@ietf.org>; Mon, 14 Dec 2020 09:03:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=FZ4izZcb0NQUlrWNcYJAeaNFdngjtRsIPBZqUdEB48Y=; b=CpiKkgrxk3fjZmZforsaxvQn2fQ3AmwAeDX8Id01WcGmEgFOZSvXpiDJvak7BqIkfT bl7+aBLl/9pXC/VVBM/juE54LBo1uwmcMRbt5pP+OzdiNu+JuFy3o+USpDI1jYRKh9hY j+SAEO07M+fozhqF7WlkkCfxoaPRP6bOmVRoR2MTn4KcbbADUGiS0lKz3l61a+6MB+c9 1uLnUbB/g+veRupxQZwzgYmWPX7mbt5b6aUHZ+67Q4zUVB3nzuex0gNmiEogCaaympjY 87hkEOpRO+Pc7Xov0vlovBTED/SoIWOITV8Xr2gNlecQDVa24427KrcZLkPtB/WGpq4x 0jtA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=FZ4izZcb0NQUlrWNcYJAeaNFdngjtRsIPBZqUdEB48Y=; b=mPyQeUheTC15mCmkao/owoRjeOBqK2rCaggGCWxePyMF0UNJJfYknclxN2cX6W/jgP 6EFi8A4KzeZ/AcC1zGD4Ly+k0mVb95elJIn7sbTK82KSWl8Y3Vusjn4QLhucklCEf851 pjZr700fynQnRHAQ6dmcq7SpC/wImOPkQ5lW/dt6JjneEoCMgHK1lqnc0oYhtPayP+fT QYKDQxd3jG/cwFk8Is5bjCFTAu3DRYa8gdo9oG8owKWO4jWDLb+d/MT0Kq3bTeQFb8d0 yKaMoowKHEfg96f5WdilqnlCa7uak3Ex3RdQ/viPhQHTLgkvarN5Hr8EutVayjIfXAv9 AZsg==
X-Gm-Message-State: AOAM532GAZmuzM+8GsVgk05gbL5uN8DqobdAD2b2EtCyM1NIOn82cwZt Xpkck6huDfaM07xgy1QIw3YReQ==
X-Google-Smtp-Source: ABdhPJwMv2sS8VCVI6gsabMEap5Q9TeUSE5TkEAcD1cYtIQIFqx/FSnAzzpo92l2ILK4yhOBRKK/pA==
X-Received: by 2002:aa7:d9c1:: with SMTP id v1mr25861830eds.115.1607965436211; Mon, 14 Dec 2020 09:03:56 -0800 (PST)
Received: from ?IPv6:2a01:598:90a1:2ea1:30a5:61cb:ed66:8814? ([2a01:598:90a1:2ea1:30a5:61cb:ed66:8814]) by smtp.gmail.com with ESMTPSA id p24sm13182755edr.65.2020.12.14.09.03.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Dec 2020 09:03:55 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail-C1507697-DC35-4720-9869-D6AE7621D6A6"; protocol="application/pkcs7-signature"; micalg="sha-256"
Content-Transfer-Encoding: 7bit
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Mime-Version: 1.0 (1.0)
Date: Mon, 14 Dec 2020 18:03:53 +0100
Message-Id: <9225F7E5-F603-4185-AE85-AD8561EBDC76@lodderstedt.net>
References: <CA+k3eCSrCvGrNJK3_F0mUFoirAQJJtttukvK3Gzx0j=Jhf+sPw@mail.gmail.com>
Cc: Vladimir Dzhuvinov <vladimir@connect2id.com>, oauth <oauth@ietf.org>
In-Reply-To: <CA+k3eCSrCvGrNJK3_F0mUFoirAQJJtttukvK3Gzx0j=Jhf+sPw@mail.gmail.com>
To: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
X-Mailer: iPhone Mail (18B92)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Gsy-wjptdyrINSdfBFeEyZBhOpE>
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 <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Dec 2020 17:04:02 -0000

đź‘Ť

> Am 14.12.2020 um 17:39 schrieb Brian Campbell <bcampbell=40pingidentity.com@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.net@dmarc.ietf.org> wrote:
>> +1 for following Vladimir’s proposal
>> 
>> > Am 14.12.2020 um 14:54 schrieb Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>:
>> > 
>> > er, I mean an -05 
>> > 
>> > On Mon, Dec 14, 2020 at 6:45 AM Brian Campbell <bcampbell@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 <vladimir@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 <vladimir@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.ip@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 <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'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.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 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.