From nobody Wed Dec 2 15:28:39 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 8CAD33A15FC for ; Wed, 2 Dec 2020 15:28:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, 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=pingidentity.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 GsY0mFuOOEmv for ; Wed, 2 Dec 2020 15:28:36 -0800 (PST) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 607CE3A15FB for ; Wed, 2 Dec 2020 15:28:36 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id r18so423251ljc.2 for ; Wed, 02 Dec 2020 15:28:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=WpjwcpRhmhYKR9ivd6Zrd3S95cxXTcUA/qAK1rgdBGY=; b=RRDsPPDdmzI5YD1dIRxdMdFykmgy7LFIs0OI5wD23MRKoo1dMFzmrdkYkBER9531g/ dV9Sz9D2gOJP0niwBAEyr7AzozypSfgLv09nFLDa9h/uDsq3+seBq0M5zuPlmbE8t5j0 4Ljq/2MJYFYEzmgxlq53ro7UlB8bjevexARmYrSRVRvRE3HgVdt0I8Qs4YjTZvDWsUvm ovRtPoNjqRIw4V5hBpsJOEpMaRQl8QhqItJimt1BuAy/XV/4YxVBSOp92NYKTNj9JOVG RZokJq9RRMMtDF/2t81S0rQFn/tDTQDVP0F/iGvv2MpwVdSY4YJrVcgXjWGAp/94+l0F Wa9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=WpjwcpRhmhYKR9ivd6Zrd3S95cxXTcUA/qAK1rgdBGY=; b=kSh/ej6o3IS0LXD1EwTChGaRvfAsB5iC6uVxnXKifeBcgUdHPPsOje/ONYJx5qk2G7 AaT2Q9gaAHrqwU46mczIFrwLA80t2ExxYiI4AawX7a0bhYoax/9cprxRpu4yb8IYO+XR Vje3lMA2ktzUExADCi80hdHAB0RxLS+a7JBeE8BPYJTJDQymklRVJrzMHWBak2DycYKn ZFnJhBwu3jBo5Rs+H24dZDM/2x+FhIjxyKptyOHyI8UD5D3jCxLh70BHJwghUsV7YYeE ASerpZ+pRNO7gtGexPV0vvlpxHoDdU0Hl85MKL8TXiPjx1F7Y+Aw4hPfE2tCkHNQyccs 2NFQ== X-Gm-Message-State: AOAM530TgllDzZ6/JJDuW4txRjMzGyyllId1TRcPaECqHp8u1YO5R8fq NEupVW4LWQ/Ain4uWwmdOGahbwKVH25Fv3un9QZS0HWrNlb9L8c9hpTQQd9sHXzkbxVHl+84S+0 sKh5urnIVVhE9IkHH97I= X-Google-Smtp-Source: ABdhPJxzXLB4W1KCYg4J73jfEpVjvQUyU3Dqsrlj/KV9QI54AQETuW9HO1P8jy8Gspwyx9N+1ThglVvNqsgRW4jpj1Y= X-Received: by 2002:a05:651c:29c:: with SMTP id b28mr96407ljo.368.1606951714236; Wed, 02 Dec 2020 15:28:34 -0800 (PST) MIME-Version: 1.0 From: Brian Campbell Date: Wed, 2 Dec 2020 16:28:08 -0700 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="00000000000019446a05b5839ad7" 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: Wed, 02 Dec 2020 23:28:39 -0000 --00000000000019446a05b5839ad7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --00000000000019446a05b5839ad7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
During the course of a recent OIDF FAPI WG discussio= n (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.htm= l#section-2.3 even shows a general error code with mention of the redir= ect_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 in= valid 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 Se= ptember so it's maybe realistic to think the window for a small change = is still open.

Presumably nothing like an &quo= t;invalid_redirect_uri" error code was defined in RFC 6749 because tha= t 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 wor= d. So here it is. Please weigh 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. --00000000000019446a05b5839ad7--