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

Torsten Lodderstedt <torsten@lodderstedt.net> Thu, 09 July 2020 17:34 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 5F75C3A0D29 for <oauth@ietfa.amsl.com>; Thu, 9 Jul 2020 10:34:35 -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 32iJs18_lsOH for <oauth@ietfa.amsl.com>; Thu, 9 Jul 2020 10:34:33 -0700 (PDT)
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 E61E93A0D24 for <oauth@ietf.org>; Thu, 9 Jul 2020 10:34:32 -0700 (PDT)
Received: by mail-ed1-x52d.google.com with SMTP id b15so2460833edy.7 for <oauth@ietf.org>; Thu, 09 Jul 2020 10:34:32 -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=r4p9Y8I8gUS4KEQEDytRC8usr+bbBTNBay3Y+QIfd0M=; b=AfpPeKuLGZXLhjyWd54KBDh27wneIHyG2gKoNO4SmqHWBjKSxNQZl1K0yR81M2FXMm UdHCyfpM29J4I6bi7miPiQlDt4NpxZacuRFDKsLUPffL58Onm8YouNFFqWDa/TXGgMlK tFwoKFQRAhpWE74Gs6b02jJhWMOTm34KX2Z43EPO8i4noBDJ/5abg4mwMajYldkqDuXE LYd2R5ojBEvZmSCKrqTT7++5lbfRf7TCRZckCU/OvrmR0XaNLTOuTzxZ8cvES7q3hFIF iZjY1jc9iz/kHcJz5Gq83t7DohXNzLYeOg6qeGWe+XHDsjPsyWKMy3PM7ZbrUs/162/A 4iwA==
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=r4p9Y8I8gUS4KEQEDytRC8usr+bbBTNBay3Y+QIfd0M=; b=qSroh8T1JkOXkJXddeKxnJOVRpBVb/YN5n5j7s8Dc61MXWEK2w1T8Gde3aDvMy/A8R MBciB8jNWjo318GXkyth/QBEyo+yFpg43h1+qsn4sNv4K0s5b1ATJbj66GadbnMxpPUf 5LdYUpJBI9mCZPqJmRepdsu6V6Xa3zWqv8DO6iO/ocQjiDe/f7NBzb20nTv18Qk2cVxM QogVN+zS9y+jw15o0RU8GqxT7qTe3DFlHYoNI8yGnbMqGnTxT8TFjrSqIYyHKFqSKpBP Sin5/ov/iPDHNJQAzX6yDjm3EFPHlzHmYtI6xd+UBSRRy+k3+ntiYYQzQwjDds18RF+N 3oKw==
X-Gm-Message-State: AOAM533dSxMZcE7hdyMijtx4a/bQFuzzKjteoxdtIR32z48q0bRSnJzd VnqESFFhMjdmP2ffczUoMnXOYg==
X-Google-Smtp-Source: ABdhPJwjIdmZF4LezE7gFoLDZ5jG2a9G0yO9o9p35P8P0C5g7Yg98tovzK7akq3eN4iCnQvfKVzXbw==
X-Received: by 2002:aa7:c98d:: with SMTP id c13mr63863955edt.188.1594316071124; Thu, 09 Jul 2020 10:34:31 -0700 (PDT)
Received: from p200300eb8f0138ad00c78d47e32ff693.dip0.t-ipconnect.de (p200300eb8f0138ad00c78d47e32ff693.dip0.t-ipconnect.de. [2003:eb:8f01:38ad:c7:8d47:e32f:f693]) by smtp.gmail.com with ESMTPSA id e22sm2199319ejd.36.2020.07.09.10.34.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Jul 2020 10:34:30 -0700 (PDT)
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Message-Id: <4D681F6F-D67B-4BBD-99F9-08853F15AF73@lodderstedt.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_B98C3CD5-99EA-4FB1-B551-49BD29373D81"; 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 19:34:29 +0200
In-Reply-To: <43899574-72B3-488A-83A6-1CBCF41EEB30@forgerock.com>
Cc: Justin Richer <jricher@mit.edu>, oauth <oauth@ietf.org>
To: Neil Madden <neil.madden@forgerock.com>
References: <6F0ACCC8-98F7-46AE-BC45-7444F08C6C6E@lodderstedt.net> <E991259C-46FB-4B32-B87C-205B4507379F@forgerock.com> <888E8738-A5A6-4086-BAB0-418216342A7E@lodderstedt.net> <43899574-72B3-488A-83A6-1CBCF41EEB30@forgerock.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/IZi-bMMfVv4s8U3Mx88PhKdFBS8>
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 17:34:35 -0000


> On 9. Jul 2020, at 19:28, Neil Madden <neil.madden@forgerock.com> wrote:
> 
> On 9 Jul 2020, at 18:10, 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?
>>> 
>>> Because Open Banking allows any client at any time to send an asynchronous back channel request to my phone to approve a payment. This is pretty risky. 
>> 
>> Can you please explain how you came to that conclusion and how it relates to RAR?
> 
> https://openbankinguk.github.io/read-write-api-site3/v3.1.6/profiles/payment-initiation-api-profile.html
> 
> Client (PISP) initiates a payment-order consent using a client_credentials access token, then launches a CIBA backchannel authorization request. What prevents this?

The fact that the PISP cannot issue this request without a valid user identifier. The demos I’m remembering use a traditional first authorization flow to establish this identifier.

> 
> This relates to RAR, because RAR also has no protection against this. If you use RAR in combination with a backchannel authorization method then the same issue applies. This is a general issue with backchannel approaches,

Exactly! It's a problem with any kind of backchannel initiated _user interaction_. 


> but it is particularly a risk here because RAR is pitching itself as a way to do payment transactions.

The problem is the backchannel request, not RAR. RAR is just a more elaborated scope.

> 
>> 
>> In the simplest of all scenarios the client sends authorization details instead of scope values through the user browser and this way starts the authorization process with the AS.
>> 
>> When RAR is combined with PAR, the client first stores the authorization request including authorization details at the AS in exchange for a reference to this data. It then uses this reference to start the authorization process. This is more secure and robust than sending the data through the browser. 
>> 
>> So what is the risk here and why do you think unsolicited backchannel requests are sent to your device? 
>> 
>> 
>>> 
>>> I can’t think of another transactional auth system that allows this without some kind of initial indication of user consent. For example, in Apple Pay all payment requests must be initiated from an explicit user gesture, providing some indication that the user wants to use this. The Dropbox Chooser and Saver APIs also have to be triggered from a user gesture. Again, this provides some confirmation that the user actually initiated the interaction. 
>>> 
>>> In OAuth, the AS doesn’t have this level of integration into the client’s UI so it needs some other way to establish user consent. By the time the user has a payment confirmation request on their screen it’s too late. 
>>> 
>>> 
>>>>>>>> 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. 
>>>> 
>>> 
>>> Do you mean legal protection for the bank or their users? As a user, if an OB client acts in a way that I don’t like, but doesn’t break any actual laws or policies, what’s my recourse? In normal OAuth I can revoke the grant to that client. This is not possible in transactional uses of RAR, and that seems like a big difference that significantly changes the relationship between users and clients. 
>>> 
>>> — Neil
>