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

Torsten Lodderstedt <torsten@lodderstedt.net> Thu, 03 December 2020 10:06 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 DE1443A0E13 for <oauth@ietfa.amsl.com>; Thu, 3 Dec 2020 02:06:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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 VFcm5KvjE5gl for <oauth@ietfa.amsl.com>; Thu, 3 Dec 2020 02:06:41 -0800 (PST)
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) (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 D158B3A011B for <oauth@ietf.org>; Thu, 3 Dec 2020 02:06:40 -0800 (PST)
Received: by mail-ej1-x631.google.com with SMTP id n26so2582648eju.6 for <oauth@ietf.org>; Thu, 03 Dec 2020 02:06:40 -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=kLO8+46tAWVR5pH910Eaoso8EHxFm6uYSSorb57ZBdc=; b=vMCsrWOgeSsXwV3/akljUVvrMdOgOcqboy+4CXkwCRuABA8G7j5PgtmPRsM324D155 ZL2CROChrZwDxQJyvyDLF5cxtr7mpo2xhs70b9J2nw3yU47h5eK80V68P32DdCnV4LYB jH3TnhT4FZ4wjKf1Y5jZnmEUPDmTlqy6Lwtqumsnzu9eITLo7SQaN17KTkespDAuvYkH Zvo0y9r8XE2QNkLOq5lPuiV/P59noIRaWouJq6/nJGto7srf3C5J9yYgbAE9vsr+A9H/ EaA3MBMOMPiXMD/7PomXepjYrtXKGVUh1Pbd+I0FNwJymFzHvgW+Jz0ZM0A/u2dByXBQ Bp+w==
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=kLO8+46tAWVR5pH910Eaoso8EHxFm6uYSSorb57ZBdc=; b=Nat0ckglyJzGFVX+Udsc68Fptyz3zfZwTsb53ddqSwNQI63zfl1XLln29kbC9ImbMA tE8WwDSaNeLrhE0pbwIOTbT4e3nJcNJvVB3tbLiLs601dWPhya0cU03fWr5XltbRbaLa 3E5FBu+A6hzgdIy3y0sS5Viw9qmSf/zxfgky036nXXdhUVlA3ztrrFPuto8vdepzOD27 BMhqB6VjuRaoZ0nEo2hLtuUPIRjNZZKIeueb/96LNzTK9el1foO0llLbeXawuCe91pud AVuRrfZxHAghJ7cjC0Iwc3hB/ysFeWcnBKCwOsddAMs0oLX0j4Ayegr9kq1upybv+H15 Ufag==
X-Gm-Message-State: AOAM531VGtgAOn3cmyizFzVLh5E9dGxSKi38nvyb5gG7Fzzj/deefLi0 RCedshG6Leq1eyeqrS2BQTVZk2WuiMrdYQ==
X-Google-Smtp-Source: ABdhPJzM/Cz7+9PH25Y5xsofECHoRSFocpir6l5XeEXZn1AIJq5yzycPQZwvlN2RBR3dtRSiHgBPcw==
X-Received: by 2002:a17:906:16da:: with SMTP id t26mr1767634ejd.478.1606989999027; Thu, 03 Dec 2020 02:06:39 -0800 (PST)
Received: from [192.168.71.123] (p4fc08d1c.dip0.t-ipconnect.de. [79.192.141.28]) by smtp.gmail.com with ESMTPSA id u3sm471358eje.33.2020.12.03.02.06.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Dec 2020 02:06:38 -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 <torsten@lodderstedt.net>
In-Reply-To: <CALAqi__ncGQgbunhunmaCrtUsAe-v+HnLWZM2Ca5VWarUr2Y=w@mail.gmail.com>
Date: Thu, 03 Dec 2020 11:06:36 +0100
Cc: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>, oauth <oauth@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <CDA006E7-8D4F-49AF-9C68-3BCEEFCFA687@lodderstedt.net>
References: <CA+k3eCQitAWnHaw2zz0jwyjHxWPYe0VPct1Op1T13BVhydkXDQ@mail.gmail.com> <CALAqi__ncGQgbunhunmaCrtUsAe-v+HnLWZM2Ca5VWarUr2Y=w@mail.gmail.com>
To: Filip Skokan <panva.ip@gmail.com>
X-Mailer: Apple Mail (2.3654.20.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/2b8dUHINJUyacFsPl2rdTaWRwcs>
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: Thu, 03 Dec 2020 10:06:43 -0000


> 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