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

Neil Madden <neil.madden@forgerock.com> Wed, 08 July 2020 21:52 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 C3F6C3A07BD for <oauth@ietfa.amsl.com>; Wed, 8 Jul 2020 14:52:22 -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 Gli5n4bIMdx5 for <oauth@ietfa.amsl.com>; Wed, 8 Jul 2020 14:52:18 -0700 (PDT)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 761D43A0798 for <oauth@ietf.org>; Wed, 8 Jul 2020 14:52:17 -0700 (PDT)
Received: by mail-wr1-x431.google.com with SMTP id a6so214457wrm.4 for <oauth@ietf.org>; Wed, 08 Jul 2020 14:52:17 -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=e87pEQ2UEGzKAbLqoDw802VotJXTm3TyJu5Y2JEzxk0=; b=dsfqrxubdMvl9VKjfkHS9SAgdSgsod/wsQxoAlap2dowYJdASYAYoe/2gNZ4UH1Xgh SlIJsx9vpHiwOodqGE51Iv//PkXcX3ZhL0E6wG8oFDPRf4+pjN00UK/0l21QLEh9APSu +brmCQu3IjWULEI13v7wnUz0BTQeFTox+fkXU=
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=e87pEQ2UEGzKAbLqoDw802VotJXTm3TyJu5Y2JEzxk0=; b=k8WPp5l0UrOAIFnmVZZgmUDQXadsSr0LPdvlQ3zyT34K6u4zD8uIFq9vFHl3+GKcpQ DTwzsf7OvxAl1UxJ/m6trbtseV5ONcaaoO3qf5/7mv5UKyH/s6LDKN2FoZ6HWnvpXnPp 00ZNdajlKwUr67wgcCy5YSgZhmM5sK6yAWOlkWjPoIO5CW4XL0ZyhVmeokxFRhZuePOy /6p6RMCtaWTQU2lOXQ7tKFnh4nwC1DwseXnqsbwKjPSYN8YOo6LtVTgClXo9EkCJqZdj u9uQ3we0463tw+7oKWx5mpX96rWnfzA7+jWRdqJYtPuwvu+z61qCrKruMubIkh/+Yq5X tA+g==
X-Gm-Message-State: AOAM531wTdio+do9v4QknDS8765PMU35oVlZxll2Q+Da93mOdk02MrwU JC41F7Bd0Dx+m62G/ASrkPyaTvWxTS4Vng==
X-Google-Smtp-Source: ABdhPJzY63IxSZlEYh0ECDOzzeiRXjsbHvJ8U7gl3SpVq3lc9eAOpCoFlNQPO2zQJlFixARYmvvThA==
X-Received: by 2002:adf:fd8e:: with SMTP id d14mr60198100wrr.202.1594245135451; Wed, 08 Jul 2020 14:52:15 -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 d13sm2005139wrn.61.2020.07.08.14.52.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Jul 2020 14:52:14 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-38843936-B178-47A7-9EBA-B6EC64D6C019
Content-Transfer-Encoding: 7bit
From: Neil Madden <neil.madden@forgerock.com>
Mime-Version: 1.0 (1.0)
Date: Wed, 8 Jul 2020 22:52:12 +0100
Message-Id: <C65E3F43-B7C8-42AE-98AE-3C6409892F2D@forgerock.com>
References: <65F58D4B-4ECB-49CE-B681-169CBBFDCED9@lodderstedt.net>
Cc: Justin Richer <jricher@mit.edu>, oauth <oauth@ietf.org>
In-Reply-To: <65F58D4B-4ECB-49CE-B681-169CBBFDCED9@lodderstedt.net>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
X-Mailer: iPhone Mail (17F80)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/rlOOERNdPXGvS5Sm6T1yAR3_2WQ>
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: Wed, 08 Jul 2020 21:52:30 -0000

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

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

— Neil