From nobody Thu Dec 3 00:57:04 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 C71753A0B87 for ; Thu, 3 Dec 2020 00:57:02 -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 oaGfZ15drXDx for ; Thu, 3 Dec 2020 00:57:01 -0800 (PST) Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (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 1B4E33A0B36 for ; Thu, 3 Dec 2020 00:57:01 -0800 (PST) Received: by mail-yb1-xb32.google.com with SMTP id r127so1319200yba.10 for ; Thu, 03 Dec 2020 00:57:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4F3KmQ31ZwXgQrca/Azgj8pe9qCHpFzDB6UYfRU+jMY=; b=iGnOG/PGdsgH60uIlTefMHd4F/L9Zws54jojc9EVBfEm3vFS8zOI0cm4HgWBrqcfrM TcSSo//4afJtCp3CljJ3/va5n4Au3EMlSN/ikCfHztJHn7nqrQOjmXgyPPJSAw/AriXX SEQnGqCByZsHQBR2xG7KuCZjk+1V0o9B2IWNg8AOv/ErTTrmTSTTvcZUqzDa15pH5kjx E3lvpfp2xA1vgUlqrNLVsq+RgN93L6BO69knRiKs3Mq3jwuw6mYr5hoyNq6Q6jbZrUzM 01fW5hz5g1FYI1EQQKCZ0r28o+FG9F9xP4WXUGk7fFcZV3c3FzUaC5IyruIFhopf1HW3 +QVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4F3KmQ31ZwXgQrca/Azgj8pe9qCHpFzDB6UYfRU+jMY=; b=YFjoHemQ3agWyuI6rmWBPHaOq07QxmZwjHSsnjatcn9VGfa8jMVl182pn/DLbJTi/2 itjFJvksZKIPIfNkMXBu99YgRgWgEbHnEPJu05koOCa1TWvIrOC5RP74gO1h4d7sAPh0 9H//PAcTFGZ5EmWD2OcucM6OVUmPpwnN/I5B8fBnLdJcEkA4MI7zgh9qa9FhHVZdc3cR x5+BuZbfnExmEcpsxa5QrDp6aH3MD2TQ/V4ywO4CcYlnmFLq3XbOJcQdyoHSciM5k6/M pD+JJBVtF9ls3c9xa8TVns3nxi1CS+mKGmp3LK9oGOU46KwRgWnND1U5LJ4ISTZ4kxQ6 enyA== X-Gm-Message-State: AOAM530OuBY7u/6Z+ntjwjKsvLbD9YoJKqo9N4x/L4VEYYnbkhOTh+di O5xfVeAoaUNmWD3bxrlVj2HcMaOvqXrkJ1Gd1qD0GjV7y/8h X-Google-Smtp-Source: ABdhPJxTEQjUIc4Rz36RBcmXRSVyU3dc4Q1BXazdvAtQ7XnecHfQoEAM1Q9y4izp/YIYW55lQyAKm7PWrxIOroXqT3g= X-Received: by 2002:a25:db53:: with SMTP id g80mr3275609ybf.85.1606985820252; Thu, 03 Dec 2020 00:57:00 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Filip Skokan Date: Thu, 3 Dec 2020 09:56:24 +0100 Message-ID: To: Brian Campbell Cc: oauth Content-Type: multipart/alternative; boundary="000000000000f9ac7705b58b8a2f" 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: Thu, 03 Dec 2020 08:57:03 -0000 --000000000000f9ac7705b58b8a2f Content-Type: text/plain; charset="UTF-8" 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. Best, *Filip* 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. > > 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 > --000000000000f9ac7705b58b8a2f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There are several documents already mentioning "= invalid_redirect_uri" as an error code, specifically RFC7519 and=C2=A0= OpenID Connect Dynamic Client Registration 1.0. But these don't registe= r it in the IANA OAuth Extensions Error Registry, presumably because they&#= 39;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.

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 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.i= etf.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 th= e error description). Some folks on that call thought it would be worthwhil= e to have a more specific error code for an invalid redirect_uri and I relu= ctantly took an action item to raise the issue here. At the time I'd fo= rgotten that PAR had already passed WGLC. But it's been sitting idle wh= ile awaiting the shepherd writeup since mid September so it's maybe rea= listic 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 b= e returned to the client via redirection. But the data flow in PAR would al= low 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 P= AR at this point. But I did say I'd bring the question up in the WG lis= t and I'm just trying to be true to my word. So here it is. Please weig= h in, if you have opinions on the matter.


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you.________________________= _______________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000f9ac7705b58b8a2f--