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 18:03 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 ACE9B3A059F for <oauth@ietfa.amsl.com>; Wed, 8 Jul 2020 11:03:08 -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 xN_dTlTZ4d3R for <oauth@ietfa.amsl.com>; Wed, 8 Jul 2020 11:03:07 -0700 (PDT)
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (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 20D933A0593 for <oauth@ietf.org>; Wed, 8 Jul 2020 11:03:07 -0700 (PDT)
Received: by mail-ej1-x635.google.com with SMTP id dr13so51513773ejc.3 for <oauth@ietf.org>; Wed, 08 Jul 2020 11:03:07 -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=fHNI/U2mCMtWabNG7pAufmkeIbWW2FaS8HdqHjscNxo=; b=W/8oWgeJDriUSNRvsNu6OQ0hEyC/dL7Ss0OLs18O4JObzTvhq2iPm5g7mxGWoIFMHL r3VbDH4s7dWxDeMUp8WRNFK/2rXaUFZYJ11xune4vzfgGBaks3DPavByo9rHM3SFM9pO qmzmvwVW2Cjszde8Flj3HUSUInM8AY/zJ5Ollq+SzeqO11Y/zhHPqleUqV8UnLfSkdNL yCmb8joinccXRA9NC937f3/nS+s+Wk1YBcOLXO31mYLymM1D8e40mvzSeeuc2fR8Gi3O ziX/mH0IC+5L39Cv9D5PHq0IarkIlPPeMzmH65QKnHwdR21T7xFPj1YvKXBOysSTP8p4 sasA==
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=fHNI/U2mCMtWabNG7pAufmkeIbWW2FaS8HdqHjscNxo=; b=MoHEB6Kpxpd88Vur3LO7WYtr/orG5zdb77mH4Zqc5jF9AbZBRZyGL0vmORHTZVQ/Jl g8yv0kJZjiJPFfOUlTUBOZKoEHyFh+Y0FV0f6yyVULR1hSXka6ISr3PBV3q0s5oCgo0j 5H7ePpfJHv6zecEBiAZsx+SYxJPUx9Pe0UtYfaWmcCEqlAzrm8ibYbE2U9dIr3Wz3BkK GNbbEDhULekzL/k4S+YGezmKZ+BVKpcoiJeblAydDxl1d5/yV4vmT+vxzs4rEheCHsdg MnAr08bJWVvBASzuYNNPnrg29x4sTEMIVp+x1oPw6XgRY1IPISeo+fmFfof++tDQTgWA puXw==
X-Gm-Message-State: AOAM531taTBKfvy6L4CAT0te8NG+oKuO2XHh0qX/ZwPw59srESfCpHg2 OKANyqjNm+bsYLbKz/4+dErqTA==
X-Google-Smtp-Source: ABdhPJxlBSEnGEsxFZT6GCo2Rues0FYBFBcWkAT8JmFYrJAzumrQwrjyENWzo9hnz7kwDQQxg7OQ7g==
X-Received: by 2002:a17:906:8417:: with SMTP id n23mr51921058ejx.192.1594231385490; Wed, 08 Jul 2020 11:03:05 -0700 (PDT)
Received: from p200300eb8f013880e46871ecac2fb6f0.dip0.t-ipconnect.de (p200300eb8f013880e46871ecac2fb6f0.dip0.t-ipconnect.de. [2003:eb:8f01:3880:e468:71ec:ac2f:b6f0]) by smtp.gmail.com with ESMTPSA id z8sm167120eju.106.2020.07.08.11.03.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Jul 2020 11:03:04 -0700 (PDT)
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Message-Id: <C2F16240-741F-423C-AC7B-17A5F74565A3@lodderstedt.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_F3A26ED9-8B1D-451C-A3FB-FD563A075152"; protocol="application/pkcs7-signature"; micalg="sha-256"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Wed, 08 Jul 2020 20:03:03 +0200
In-Reply-To: <27DB83CC-4A61-4CDB-BFCA-6727317120AE@forgerock.com>
Cc: Justin Richer <jricher@mit.edu>, oauth <oauth@ietf.org>
To: Neil Madden <neil.madden@forgerock.com>
References: <1DBD3620-18F8-47F1-B0C3-EDD08A64966C@lodderstedt.net> <27DB83CC-4A61-4CDB-BFCA-6727317120AE@forgerock.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/fs8rAFE9xOFh2Pyy9B9qwp_MQTc>
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 18:03:09 -0000


> On 8. Jul 2020, at 18:59, Neil Madden <neil.madden@forgerock.com> wrote:
> 
> 
> 
>> On 8 Jul 2020, at 17:21, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>> 
>> 
>> 
>>> On 8. Jul 2020, at 18:17, Neil Madden <neil.madden@forgerock.com> wrote:
>>> 
>>>> On 8 Jul 2020, at 15:40, Justin Richer <jricher@mit.edu> wrote:
>>>> 
>>>> The two-phase approach is exactly what OBUK does, where you get one access token using client credentials before getting a more specific one in context of the user’s consent. This ends up being awkward to implement at best, since OAuth involves the user too early in the process to allow for this kind of thing. PAR might help address this dichotomy, but RAR can provide places for this to fill in.
>>> 
>>> I’m not sure how client credentials would help here. The point I’m making is that the _user_ needs to consent to two separate things:
>>> 
>>> 1. An initial consent to allow this app/service to initiate payment requests on my behalf.
>> 
>> 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?

In case of open banking the user legally consents to this process at the client (TPP) even before the OAuth/Payment Initiation dance starts. 

> 
>> 
>>> 2. Consent to individual transactions.
>>> 
>>> RAR (and open banking?) completely omits step 1 at the moment, which seems crucial. Especially if you’re doing something like CIBA backchannel where step 1 is effectively consent for this app to spam my phone with payment approval requests.
>>> 
>>>> 
>>>> With XYZ, I tried to design for that kind of multi-stage transaction pattern more explicitly, with the idea that you could continue your request in context and vary it over time, or even start a new request in the context of an existing one. This is something that I intend to continue with the soon-to-be-formed GNAP working group, if you want to bring this use case there.
>>> 
>>> RAR is adopted by the OAuth WG so I think this needs to be discussed here.
>>> 
>>> — Neil
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>

v2.23.0 | Report a Bug | By Email