Re: [OAUTH-WG] A few comments on draft-ietf-oauth-rar-01

Torsten Lodderstedt <torsten@lodderstedt.net> Thu, 09 July 2020 06:33 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 ABE703A0F7B for <oauth@ietfa.amsl.com>; Wed, 8 Jul 2020 23:33:40 -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=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 MQ8Gtzl6cMeF for <oauth@ietfa.amsl.com>; Wed, 8 Jul 2020 23:33:39 -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 D05F53A0970 for <oauth@ietf.org>; Wed, 8 Jul 2020 23:33:38 -0700 (PDT)
Received: by mail-ej1-x62f.google.com with SMTP id a1so1038537ejg.12 for <oauth@ietf.org>; Wed, 08 Jul 2020 23:33:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=3gsgy/mb8zEV4vaJqxtAwmFeovdmZIz46sGTyazX+MQ=; b=zSTMA5ppCGNUzYth3xwNmpsKgahMagTVKSWsjQW77MI2+jEIcX9B6erEGuOb7SUx58 kYROKP1bCUBcl9srRdypczzqOWFeHZXXIIaNuxHiII9+teOb3uBT8iO6njEjzQJlOZY1 38BkJpbGfN7z63sC3Y5CDQKLf6mjpWw8i/0o25GyuIahquxbHm/NFR6atuZG0oyzPvjo X4apeyxpFSmIiUoh8dkUlbClxW7wvj60Pl+yWAn499lxgRx769opiAcqD/D6q7VfeML4 OQbD7uTnJtSECL45YsdLHo1FOqOdn5HQnEIttk8y1T3w4VTyWMZpur/Dv7qfQgPZq8Lt ZTlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=3gsgy/mb8zEV4vaJqxtAwmFeovdmZIz46sGTyazX+MQ=; b=umigq2khbkYWcrvGvsYzXItYpr1zKXXo05QYU4GDRDyJ5Z5YBhmkkVDdjxxQUed9U7 3FrfozmxHrUD8DHYWkhEsKx2ltetkRkEFjSRgPRcZ4RH4C3lq1hUtsGvPktdnvkG1ZG9 DfOmjJeIWWSuZjn+zuEULZPaSpuWqhfUHY9bdbDZ/9J5qiyujQMhbSBfy5EGrp74WHJP 6/6bYlK+het06wiRahbnmvAg7A+0EbY+qN31NXZzKqTpd4BlZv/UidXl9w0EuTOpAiHB 3sLAEkWooCpTkeIIToiQlqJc9aJnxPG209hXQ2FMKRv1avH+JcZWNy8Wz79HVUJy5z8u +1Rw==
X-Gm-Message-State: AOAM530FIWijg8WeSTzbWhJAao236NYsk5E/ZNiYyIPl8RzPC3HQsM54 I6SosQTF8W5t46ffLr2zDRxIOw==
X-Google-Smtp-Source: ABdhPJzVNnpmzxYi/iwVYcBICeBB4cZgM5F6YesZstB0ycfjmODPoZiT1dfGrJVnllWW0uFPcepXOg==
X-Received: by 2002:a17:906:940f:: with SMTP id q15mr56396867ejx.470.1594276417077; Wed, 08 Jul 2020 23:33:37 -0700 (PDT)
Received: from p200300eb8f0138adc89b3a305e9c3444.dip0.t-ipconnect.de (p200300eb8f0138adc89b3a305e9c3444.dip0.t-ipconnect.de. [2003:eb:8f01:38ad:c89b:3a30:5e9c:3444]) by smtp.gmail.com with ESMTPSA id e4sm1173761ejx.76.2020.07.08.23.33.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jul 2020 23:33:36 -0700 (PDT)
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Message-Id: <6F0ACCC8-98F7-46AE-BC45-7444F08C6C6E@lodderstedt.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_0E2275AA-4CE9-4522-839F-536CF3795383"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Thu, 9 Jul 2020 08:33:34 +0200
In-Reply-To: <C65E3F43-B7C8-42AE-98AE-3C6409892F2D@forgerock.com>
Cc: Justin Richer <jricher@mit.edu>, oauth <oauth@ietf.org>
To: Neil Madden <neil.madden@forgerock.com>
References: <65F58D4B-4ECB-49CE-B681-169CBBFDCED9@lodderstedt.net> <C65E3F43-B7C8-42AE-98AE-3C6409892F2D@forgerock.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/bAYBHS1hguYppc9n1EQr_WZwnAw>
Subject: Re: [OAUTH-WG] A few comments on draft-ietf-oauth-rar-01
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, 09 Jul 2020 06:33:41 -0000


> On 8. Jul 2020, at 23:52, Neil Madden <neil.madden@forgerock.com> wrote:
> 
>> 
>> On 8 Jul 2020, at 20:56, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>> 
>>> Am 08.07.2020 um 20:46 schrieb Neil Madden <neil.madden@forgerock.com>om>:
>>> 
>>> On 8 Jul 2020, at 19:03, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>>>>>> 
>>>>>> What in particular should the use consent with in this step?
>>>>> 
>>>>> “FooPay would like to:
>>>>> - initiate payments from your account (you will be asked to approve each one)”
>>>>> 
>>>>> The point is that a client that I don’t have any kind of relationship with can’t just send me a request to transfer $500 to some account. 
>>>> 
>>>> Are we talking about legal consent or a security measures here?
>>> 
>>> Normal OAuth consent. My phone is my resource, and I am its resource owner. If a client wants to send payment requests to my phone (e.g. via CIBA backchannel) then it should have to get my permission first. Even without backchannel requests, I’d much rather that only the three clients I’ve explicitly consented to can ask me to initiate payments rather than the hundreds/thousands clients my bank happens to have a relationship with.
>> 
>> To me it sounds like you would like to require a client to get user authorization to send an authorization request. Would you require the same if I would use scope values to encode a payment initiation request?
> 
> Yes. If something is sufficiently high value to require per-transaction authorization then initiating transactions itself becomes a privileged operation. 

The per transaction authorization alone is a significant increase in security. What is the added value of requiring an authorization to send a per-transaction authorisation request in an additional step?

> 
>>>> 
>>>> In case of open banking the user legally consents to this process at the client (TPP) even before the OAuth/Payment Initiation dance starts. 
>>> 
>>> How does the bank (ASPSP) confirm that this actually happened?
>> 
>> It does not because it is not the responsibility of the ASPSP. The TPP is obliged by law to obtain consent.
> 
> If the TPP can be trusted to obey the law about this, why not also trust them to be honest about transactions? Why enforce one thing with access tokens but take the other on trust? Especially as the actual transactions are more likely to have a rigorous audit trail. 
> 
> If we could trust clients to obtain consent we wouldn’t need OAuth at all. 

I thought the same initially, but we must distinguish between legal consent and strong authentication/transaction authorization in such a case. Legal consent can be obtained in various ways including the traditional OAuth user consent but also in other places. Authenticating the user (probably with 2FA) and getting authorization for a certain transaction (the meaning of PSD2 SCA) must be conducted by the AS. 

> 
> — Neil