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

Neil Madden <neil.madden@forgerock.com> Mon, 13 July 2020 14:16 UTC

Return-Path: <neil.madden@forgerock.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 AD3883A1204 for <oauth@ietfa.amsl.com>; Mon, 13 Jul 2020 07:16:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, MIME_QP_LONG_LINE=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 (1024-bit key) header.d=forgerock.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 taF9iBknKhuE for <oauth@ietfa.amsl.com>; Mon, 13 Jul 2020 07:16:35 -0700 (PDT)
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 67E1D3A08AA for <oauth@ietf.org>; Mon, 13 Jul 2020 07:16:35 -0700 (PDT)
Received: by mail-wr1-x42e.google.com with SMTP id r12so16706950wrj.13 for <oauth@ietf.org>; Mon, 13 Jul 2020 07:16:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=K5MKZfeIo2MBB0YkoAOoahoJyv6tAIkbstsNljCQ6EA=; b=f5gEJVmV8VezCrx3Df6Atlr8W9rjQ4eNuCK/xd/N+TJDwRJ9hBnTZ99Vgv4EJ6ePKo PYx8fe4mzHENOyWMUNyNCM/mQpdLD726e5HEpSnH1ioK/Id35zBykARU0dVtidpmTl+M 8ivIYb6E0lZyY01Y4Te+o+g7j9NXxp/ipFh0M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=K5MKZfeIo2MBB0YkoAOoahoJyv6tAIkbstsNljCQ6EA=; b=DvBir4uIOBZpoQbrjJlaGElOD6gfCum2+bSaMNLPnFFC3vgrpa/WrnBF6Zie/T8Boq zc1JMFUXf2DxT8pYKhE8hOOFVbiNByQTy3awCoGw0+Lk/nbF1vgpiCXM5iGUpkdHWF0p er0sbx8uvxYrJR81Jm18f31iNMItZTUynZAKKCNCxcDE6EVBuiE9pdklv5oqtrjJTNIJ JHeF9qkLaX+xjG8gcA8Sy68Q561tV1Co/5JaxV2NHiawaZfhYXEt0bfJfCWmJ62gFuJy 0c/q4Fg3rnHt/jPxFXwJfY6fTI6i1L29cchSiN25kdwmlWa8Nv84w8RZyPEXgo7FQT7G eOKA==
X-Gm-Message-State: AOAM532L7Wn6I8XhkYFaJCaS34RlgDWFGOr3kxJaXrb0BaU2jL81Hy3a eZDLJMtucDQM55eOfEJLxj6vKJfCvqGpsF+eNepWyOm9Qp9RWNQ/+oYcZSJeh1jG+86A8T5Ola+ NYzQgpecAAQsM6SCTdE3oQSKBBCPVzHdFATYUAdFmGRN8I+SwYXj9BCq4oStG4W8LeQ==
X-Google-Smtp-Source: ABdhPJwWmx77G3gn0vVVW1nt6FXo/wbInFzerzFZ0GcBMyefiq5Y8M+UZJxaUjASNfXdV0jc0ps19g==
X-Received: by 2002:adf:e7c2:: with SMTP id e2mr85518253wrn.179.1594649793327; Mon, 13 Jul 2020 07:16:33 -0700 (PDT)
Received: from [10.0.0.3] (128.211.93.209.dyn.plus.net. [209.93.211.128]) by smtp.gmail.com with ESMTPSA id z25sm20799191wmk.28.2020.07.13.07.16.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Jul 2020 07:16:32 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-85F4A80E-94AD-4116-A96C-C09F3740142B
Content-Transfer-Encoding: 7bit
From: Neil Madden <neil.madden@forgerock.com>
Mime-Version: 1.0 (1.0)
Date: Mon, 13 Jul 2020 15:16:31 +0100
Message-Id: <9B25F535-038C-4E24-9BF4-4BF954F33A02@forgerock.com>
References: <CAOW4vyNji0peKzH+gre3E6b778HfxWJ_18NP457LsPzg34m_xw@mail.gmail.com>
Cc: Torsten Lodderstedt <torsten@lodderstedt.net>, oauth <oauth@ietf.org>
In-Reply-To: <CAOW4vyNji0peKzH+gre3E6b778HfxWJ_18NP457LsPzg34m_xw@mail.gmail.com>
To: Francis Pouatcha <fpo@adorsys.de>
X-Mailer: iPhone Mail (17F80)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Y1SJV7CRo-ui3w8B5u2G8jAoi90>
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: Mon, 13 Jul 2020 14:16:38 -0000

> On 13 Jul 2020, at 01:52, Francis Pouatcha <fpo@adorsys.de> wrote:
> 
> 
> Hi Neil,
> 
> IMHO the purpose of RAR is to provide a rich substitute for oAuth2 scopes.
> 
> The point you are addressing in this thread is nevertheless very pertinent, even though not directly related to RAR. 

I think it is absolutely related. 

> 
> Proof of RO (PSU) authorized interaction between the RO and the Client (TPP) prior to starting an payment authorization request is essential.
> 
> The NextGenPSD2 specification addresses the problem with a so-called oAuth2 pre-step option. As this requires two authorization operations (SCA) for the release of a single payment, banks implementing oAuth2 pre-step fell under the scrutiny of the EBA (European Banking Association) last June. Now those banks have the burden of proving to their NCA's (national market/country authorities) that pre-step is necessary to mitigate the very problem you are raising in this thread.

I’m not sure this is the same issue I’m raising in this thread. In particular, what I’m suggesting would *not* need two authorization requests per payment. What I am suggesting is that there is one long-lived authorization between the RO and a client and then individual authorizations of each transaction: 1 + N not 2N. 

> 
> Let settle with:
> - RAR as a payload for carrying authorization details
> - The decision on whether to protect an authorization transaction with a preceding RO authorization to do so shall be left to the target oAuth2 profile.
> 
>> On Thu, Jul 9, 2020 at 1:58 PM Neil Madden <neil.madden@forgerock.com> wrote:
>> 
>> > On 9 Jul 2020, at 18:34, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>> > 
>> >> 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.
>> 
>> An identifier is not an access token or credential.
>> 
>> >> 
>> >> 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.
>> 
>> I don’t agree. It’s particularly acute with backchannel requests, but it still exists with front channel. If I can redirect your browser to a payment confirmation screen, what percentage of users will click ok? I would guess more than 0. It’s a problem precisely because a one-off interaction is enough to authorize a transaction.
>> 
>> It might be that in OB they accept this risk and mitigate it in other ways, e.g. making it easy to reverse transactions, or through sufficient vetting of clients and big legal consequences. As a UK banking user, that wouldn’t make me very happy but OK. The point is that RAR can’t make payment transactions the primary use-case, emphasised throughout the draft, and then fail to even discuss this issue or make any kind of suggestion as how to handle it. 
>> 
>> — Neil
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> -- 
> Francis Pouatcha
> Co-Founder and Technical Lead
> adorsys GmbH & Co. KG
> https://adorsys-platform.de/solutions/