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

Brian Campbell <bcampbell@pingidentity.com> Fri, 04 December 2020 15:52 UTC

Return-Path: <bcampbell@pingidentity.com>
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 D6A223A0DB2 for <oauth@ietfa.amsl.com>; Fri, 4 Dec 2020 07:52:54 -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 OeDkG5-CTofw for <oauth@ietfa.amsl.com>; Fri, 4 Dec 2020 07:52:52 -0800 (PST)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 1CD1A3A0DB4 for <oauth@ietf.org>; Fri, 4 Dec 2020 07:52:52 -0800 (PST)
Received: by mail-lf1-x129.google.com with SMTP id r24so8257171lfm.8 for <oauth@ietf.org>; Fri, 04 Dec 2020 07:52:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0X0Nvt3IxyCfU1pHfyiQ4nPTocIGWjQArj2Uq+6CRTw=; b=XVFK4a5DKNaBccYbjbEnuBVFTBxBoG6WTxW7v9EqXKP83gxjCE8NbfcMuxOb8WzTFX +GSxkXmLJcxZ12ky0gBycQTGiQ4J1aKg01GheVV3DE8pnRNycPKuw6EzCSLw01/sccKu SxON69TPs6wbClS3NBKTijI3E3qxaCLUZrDjKCePMISYm9zkLFQHqrjXzuewFpPx+Cd+ RZWEUOZdD4/xLloBYFU3DMCAmquCEAxn80HoElL7yq9HBptinXG/W8yu1y660EhqBLAB VxjrYE9f7pe9IcqnThLGqBjnsSB0etWxhU85h7i7aVCeiTWgiCnw3ZhPFEMvyDALlny6 Gdiw==
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=0X0Nvt3IxyCfU1pHfyiQ4nPTocIGWjQArj2Uq+6CRTw=; b=BfZJEtD7InQVHivIhhRvpN3cmEopqzLcTIpIsPL0ZNpBpX6zUyoG0JiahZCG7/3MZ2 jkHyT9gRGpZXQgRfVPUds5EULwBPHTRVNzYGnwZgsK5LpadDSVZYhvrqtnOtQN47UUUJ oCE4UVYXNCh1/gE9ZdsL5uPuhyqWfqAec1/X1pfvgeh/hzoj04hmEkTk9IrI4E+pku6Y 9oNOUFVp5GN0SwUk+CGtM5v5YNe4xGRmzzGhS2ckS3hI12FCM2+c8bG/Ss483ARSHJTi OPrMEzJeLzjxvIovWrsHPnyvFjLahEKUdRK03OfGqBtoj4iDTvt6uOYMBTmSPEuPL7Qn jM0A==
X-Gm-Message-State: AOAM531Hn+gPB2DF4XSPLPwVQ5lu3hAdgeuWpa/3EWmhiS4es5yeVyaJ KPElkm5wyMStGwZ3me60C8Ixuq1yMNxorW5zm4XhMXKTw88aPzjuYur5JIqestXxmI5rpnyHZ+Y PN9fOO3t0DPb4Jg==
X-Google-Smtp-Source: ABdhPJz9jBGYYHKVQQFWBVQ5QUDo/ZM7eQFLuzLINNzxRVdry5zTVkh1WyqMmmD/EwmRyeXoL0dJmFrZUoZA2NB2skI=
X-Received: by 2002:a19:5215:: with SMTP id m21mr3578192lfb.407.1607097170095; Fri, 04 Dec 2020 07:52:50 -0800 (PST)
MIME-Version: 1.0
References: <CA+k3eCQitAWnHaw2zz0jwyjHxWPYe0VPct1Op1T13BVhydkXDQ@mail.gmail.com> <23A0EC1E-B161-4CDC-B3F5-1EA670458785@forgerock.com>
In-Reply-To: <23A0EC1E-B161-4CDC-B3F5-1EA670458785@forgerock.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Fri, 04 Dec 2020 08:52:23 -0700
Message-ID: <CA+k3eCQ3oxT5q18CQ-JbTTJa4f6scCazTbYD-TbTxBfRGDbGgQ@mail.gmail.com>
To: Neil Madden <neil.madden@forgerock.com>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f18b7305b5a5775f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/gMiH1mTr0AKDvWpqO1zikcVUySY>
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: Fri, 04 Dec 2020 15:52:55 -0000

That's a good point. The context of the original discussion that led to
this thread wasn't about a client programmatically acting on the
information. Rather that banks (and similar entities) can be reluctant to
include additional info in descriptive error messages so having a specific
error code might help with the manual troubleshooting situation of problems
with the presented redirect URI. That rationale seems rather dubious.

On Fri, Dec 4, 2020 at 1:13 AM Neil Madden <neil.madden@forgerock.com>
wrote:

> Making it a specific error code rather than just an error message suggests
> that the client can do something with that information. That doesn’t seem
> likely to me. It’s most likely caused by a misconfiguration that somebody
> needs to manually sort out rather than something that can be automatically
> corrected, so I don’t see a reason for this to get its own error code.
>
> — Neil
>
> On 2 Dec 2020, at 23:28, 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
> <https://bitbucket.org/openid/fapi/issues/343/what-is-authenticity-and-integrity-of-the>
> 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
>
>
> ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>

-- 
_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._