Re: [OAUTH-WG] WGLC Review of PAR

Torsten Lodderstedt <torsten@lodderstedt.net> Sat, 29 August 2020 11:52 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 1C2A73A1377 for <oauth@ietfa.amsl.com>; Sat, 29 Aug 2020 04:52:27 -0700 (PDT)
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=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 t7V6riXWtBaH for <oauth@ietfa.amsl.com>; Sat, 29 Aug 2020 04:52:25 -0700 (PDT)
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (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 2D3EE3A1373 for <oauth@ietf.org>; Sat, 29 Aug 2020 04:52:25 -0700 (PDT)
Received: by mail-ej1-x62f.google.com with SMTP id o18so2531029eje.7 for <oauth@ietf.org>; Sat, 29 Aug 2020 04:52:24 -0700 (PDT)
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=uC+MQ9n4rLuhSjuuGoG/J6Ul5iWExsVhuJJI2Z5qkOk=; b=HSVjs26TObO+ScEz05JUmvaGDZAUGhObsSW/ETiXyJUMJY4n/0mw3wYfgzxcS0/kR6 SUKAe7LI9femc1hI9qj/BUw+K/QoTyio8JUwFNbvq1QUW84wYzAYSkPIJz6Fh0wBnuFt ahzuzlcOLR1o2KNUgMGx+6KveLavvyTSVAQjU/zEz1k5CusJrEEwG4c0IdygHLigctRj FRil1hKwr9sL0cuT7ONBUJyodzQTgo4JqnL014TLZemjZgy98joPHoykNS+ZHwM8PZ9+ SJ6ceqG9GD4Pln6l6jixZAYSgReH24NvbPoHGVl+5N/8LOpDwqNPy6uxMMkrnhkjNVIe dScA==
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=uC+MQ9n4rLuhSjuuGoG/J6Ul5iWExsVhuJJI2Z5qkOk=; b=cwOIBOYbQWaAkrNwRdT3zV/Eb4mcJXNEhDMse8GdRaP1iNbbdMIksCkiHyMiWSKv7n etIhrhwIXN/36tX0FT7jy18+T5AOJ5GprDPN+j7sI6bSGQnxV/O/mrG3K03vy01jF0nv 9XebZY1RvW0yXTmUaxwBBkshrSjJyIP1+2IFlmOoTThGnXPhWnM78VYHfYmkcfiA63+8 TMYKfr/ovUhu2x76QfvXIN1O/zrTQ4Gmk53QHZq90sOxqbxrGAgAXP2QOgG4KK9jhcsU sclzMAUo74uxT9Q1hNJeDiNoFioRvDVeHySmiOvDx+Tf9v8N0VLn+ZCaWCEQXYysuVMQ 9Qww==
X-Gm-Message-State: AOAM531iZW7km3nfdG8/BOy3H8DXSQj05DB8+fRWBqbZOkACv3G60hhA hElLOUqajxCo06jV4TiqqYlvxA==
X-Google-Smtp-Source: ABdhPJy06rhpnshmjygZUgocPlrL7n3ov9Bv4SPkLisd0ealMS4epuweytiAtFdWLC/GiUICmqS1mw==
X-Received: by 2002:a17:906:8289:: with SMTP id h9mr1554617ejx.45.1598701943433; Sat, 29 Aug 2020 04:52:23 -0700 (PDT)
Received: from p200300eb8f1e2a0741fe1768a10f1ac2.dip0.t-ipconnect.de (p200300eb8f1e2a0741fe1768a10f1ac2.dip0.t-ipconnect.de. [2003:eb:8f1e:2a07:41fe:1768:a10f:1ac2]) by smtp.gmail.com with ESMTPSA id t22sm2045078ejf.24.2020.08.29.04.52.22 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Aug 2020 04:52:22 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Torsten Lodderstedt <torsten@lodderstedt.net>
In-Reply-To: <CA+k3eCRsBTvdhyzBOETxWLd6PJ61B2W4yY5QHv196amDFq7gnQ@mail.gmail.com>
Date: Sat, 29 Aug 2020 13:52:21 +0200
Cc: oauth <oauth@ietf.org>, Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B86967B1-3FA1-4ADA-BF9B-D34C693617C7@lodderstedt.net>
References: <7C0FD285-F677-4501-B2FB-9431A59855F6@mit.edu> <CA+k3eCRsBTvdhyzBOETxWLd6PJ61B2W4yY5QHv196amDFq7gnQ@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/fPPy5-xIImw5NO9iKKj7wlB77Mg>
Subject: Re: [OAUTH-WG] WGLC Review of PAR
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: Sat, 29 Aug 2020 11:52:27 -0000

> 
> 
>     ¶6: Does the AS really have "the ability to authenticate and authorize clients”? I think what we mean here is "the ability to authenticate clients and validate client requests”, but I’m not positive of the intent. 
> 
> I think the intent is that the AS can check whether a client is authorized to make a particular authorization request (specific scopes, response type, etc.). But checking authorization to request authorization is confusing wording. I think your working is less confusing and still allows for the intent. 
> 
> I'll let Torsten interject if he feels differently as I think he originally wrote the text in question. 

that was the original intent. I think “validate" is fine. 

> 
>  
> 
>     ¶7: I’m not sure I buy this example. Even if the clientID is managed externally, the association with a set or pattern of allowed redirect URIs is still important, and the AS will need to know what that is. I think this example could lead an AS developer to (erroneously and dangerously) conclude that they don’t have to check any other values in a request, including scope and redirect URI. It’s important that DynReg doesn’t alleviate that issue, but removal of DynReg doesn’t really change things in that regard. Suggest removing example or reworking paragraph.
> 
> I'm going to have to defer to Torsten on this because, to be honest, I'm not too sure about it myself. I tend to lean towards thinking the draft would be better off without it. 
> 

In the traditional authorization flow, the redirect_uri serves as way to make sure the AS is really talking to the legit client and the allowed redirect_uri values are determined by the legit client at registration time (might be manually).

With PAR, we have a much stronger means to ensure the AS is talking to the legit client. That’s why I don’t see an issue with letting the client set a per transaction redirect_uri. This will give the client more flexibility (mint AS-specific redirect URIs on the fly) and makes client management much easier since redirect URIs are the most volatile part of a client policy. 

It also makes use of OAuth much easier in deployments where client identities are managed by external entities (even without any idea of OAuth). A prominent example is open banking in the EU (aka PSD2). The (technical) identity of any PSD2-licensed client is asserted by an eIDAS compliant CA in a special X.509 certificate. Those certificates contain the permissions (access to account information and/or payment initiation allowed) and the identity (member state specific). But they don’t contain OAuth policy values. Nevertheless, the regulation requires any financial institution in the EU to at runtime, without any registration, to accept and process calls from any licensed PSD2 clients.

There are two ways to cope with it in OAuth context:
a) use dynamic client registration with the X.509 cert as credential. Unfortunately, RFC 7591 does not support other client authentication means then an initial access token. Beside that, it would violate the text of the regulation. 
b) establish a redirect URL with every transaction. This is the recommended approach in at least one of the PSD2 specs.

PAR is a clean way to solve that problem. 

I don’t want this text to cause confusing. On the other hand this potential of PAR is way too important to not mention it at all. What about moving it into a special section "redirect_uri management”?

>