IETF Logo Mail Archive

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

Torsten Lodderstedt <torsten@lodderstedt.net> Wed, 08 July 2020 19:57 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 E28DF3A07B6 for <oauth@ietfa.amsl.com>; Wed, 8 Jul 2020 12:57:00 -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 (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 kzoPAlqmq1TE for <oauth@ietfa.amsl.com>; Wed, 8 Jul 2020 12:56:59 -0700 (PDT)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 97E063A0801 for <oauth@ietf.org>; Wed, 8 Jul 2020 12:56:58 -0700 (PDT)
Received: by mail-ed1-x52e.google.com with SMTP id h28so39116edz.0 for <oauth@ietf.org>; Wed, 08 Jul 2020 12:56:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lodderstedt.net; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=QA3fGGa+4+lb5OjDLeweaq+tgeRl4G+0+GnJBn5NtU0=; b=vTc3barbR7E5ZFedqs0aQIqLLlY6YYXeicJuRI7ATZL+0TyLgm7LP4QfEGzKpIXTNM mbelA9jzhfOl+yzOkp2g7cD8EaQL5hm63EDxmnNDhQudOqLNX+3xK8fmBicwPmKS5TQw htyqtvTT1/CwoaIRUWn/RxY8J18K2RGz6Rd5+wsqTWNyNlw8sKNuBn1UtZQNLKS7mnKk MX7CXP3RmCYCrxUi05kJ1FiZY+tqGnxb5fcW2ABBvjH+vHvAiFRmFPV8mt+Pj/gOu/h5 P4tkeWoaXcOwd2FhNzNa/lmyzlWOGnGAXIQYgK+UUYW1dXfP1gZa1orddLTlWZlxnOek TYMQ==
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=QA3fGGa+4+lb5OjDLeweaq+tgeRl4G+0+GnJBn5NtU0=; b=FUSgdoBte7iaD9n17LxQHYyoLG09QXLBnHHcovTXpwqj4KVGNE3tECQUz0GDV9r5ga 2SgtoFuO11Ox5QU+xzsDAFRedIo3IMfHg6lTiC/Hwn727MoIpZRhSKzf9Xwn2n85uy4M iyxqVuJlvzzr7RiXWshMdzZBxOr8zv/VYew6Rez3d4lMsanMB5v0g+8++Lf92EFO5O07 pmX+4EVPx53UuZpYumh1Pps8YiTiarCH9nBvUb8M05TIGG27OhYIqKwspXIVuKsRPMol q3zgLTwHExuSphgncUTKMJ5wsXmi9/ltwwjVohXODRz0qGYP2B9X9wU3OJdEascSFE/T JNQw==
X-Gm-Message-State: AOAM531Q0dlVrb/EcOcsydJwKoxyMFlJ+srFXqVAeVVFn0yNfGo6b6/o VFl4HSmzW7c/usF5Q+0PZoqvPw==
X-Google-Smtp-Source: ABdhPJwzRjL0+IBr+jjn3VKATH4MBzJnUOTZLuXB1hU4SWm6isVnxC4ScavWFyb5pF7TAiN8NHDsCA==
X-Received: by 2002:a05:6402:13d0:: with SMTP id a16mr68708849edx.269.1594238216864; Wed, 08 Jul 2020 12:56:56 -0700 (PDT)
Received: from [192.168.71.102] (p5b0d9bb4.dip0.t-ipconnect.de. [91.13.155.180]) by smtp.gmail.com with ESMTPSA id ks27sm329405ejb.7.2020.07.08.12.56.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Jul 2020 12:56:55 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail-85FB7887-16EF-4A1F-8DAA-C97B1336E30C"; protocol="application/pkcs7-signature"; micalg="sha-256"
Content-Transfer-Encoding: 7bit
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Mime-Version: 1.0 (1.0)
Date: Wed, 08 Jul 2020 21:56:54 +0200
Message-Id: <65F58D4B-4ECB-49CE-B681-169CBBFDCED9@lodderstedt.net>
References: <28DA6872-32D6-4FDA-850D-55B06A727694@forgerock.com>
Cc: Justin Richer <jricher@mit.edu>, oauth <oauth@ietf.org>
In-Reply-To: <28DA6872-32D6-4FDA-850D-55B06A727694@forgerock.com>
To: Neil Madden <neil.madden@forgerock.com>
X-Mailer: iPad Mail (17F80)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/PXPJWehBn3N8mwNnGPJaziKU2EA>
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 19:57:01 -0000


> Am 08.07.2020 um 20:46 schrieb Neil Madden <neil.madden@forgerock.com>:
> 
> 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?

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

> 
> — Neil

v2.23.0 | Report a Bug | By Email