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

Neil Madden <neil.madden@forgerock.com> Thu, 09 July 2020 08:08 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 D8A543A08AF for <oauth@ietfa.amsl.com>; Thu, 9 Jul 2020 01:08:01 -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 G3y0asvKz2Gy for <oauth@ietfa.amsl.com>; Thu, 9 Jul 2020 01:07:59 -0700 (PDT)
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 005063A08AB for <oauth@ietf.org>; Thu, 9 Jul 2020 01:07:58 -0700 (PDT)
Received: by mail-wm1-x333.google.com with SMTP id w3so861488wmi.4 for <oauth@ietf.org>; Thu, 09 Jul 2020 01:07:58 -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=NZA4xsNn3BVZUl5zg+v3lQa+7ypXkuu7Ri+BVyxEafk=; b=N0zKVO9vlDlNPOTEat98qMjMdA4MU2AjEL7Fc4AayQ32pDFloU7DLLo+nntt66HNul GU3bhm4K/+pijaK1yR9LC2CtM8Uy8adUg5kB3PvhoK8PBu3NSI8NqsDksAoplgNQM4dV NwXnZIm92AxKXbbpYtKu5+hygjLt0td0fj7rY=
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=NZA4xsNn3BVZUl5zg+v3lQa+7ypXkuu7Ri+BVyxEafk=; b=mJJdKhzntgWeDAvSzJIlpVIuHj3bkkVgWCkFrZjpO5a2/NZ2+qU+DiiUhUkQeYiBgJ EOYd1OOQ0NG7XtPydta0J4AHqxDnp/haui1mhMnFuF+myxz3RLyjE+xVCg1oGadyxs1H jIPMRpoGGS7hCsATDuPeTKpyCcSkbqXLee7mTfQlgEVMmzdE6mT6E8vzEFoURURO5nzU +A+/f6YBk5Vv8M9gEbJCj5+/5F5XjM55TQCb9iZpqK5OltYhNixvuIRC9sgZY6vGngyF YUU5hfWD9uE+ZHtbIxx9sfLIGCW2RMpU28NhmRNQ85ysLl05kF9xrrsuW0VOMPox4CKN 7OgQ==
X-Gm-Message-State: AOAM532qzo2El+P4QNcTTnm0q4bYUovST1tnQZDTQOmzqB6e9dGFvaOX /5Cyf3eQYnRvgjl6VIW7WHH7UdvewpPb3g==
X-Google-Smtp-Source: ABdhPJwXxTLn908kTmmqvZ6ZQRKQAJe2e+8V6/rFpKlo2OlfVt/ITVrZ5IbC/NcPJrwKVB91Lxznig==
X-Received: by 2002:a1c:4c16:: with SMTP id z22mr12743345wmf.103.1594282077084; Thu, 09 Jul 2020 01:07:57 -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 q1sm4271891wro.82.2020.07.09.01.07.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Jul 2020 01:07:56 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-5C995DB6-3880-4B7B-953D-C6CC252CB145
Content-Transfer-Encoding: 7bit
From: Neil Madden <neil.madden@forgerock.com>
Mime-Version: 1.0 (1.0)
Date: Thu, 9 Jul 2020 09:07:55 +0100
Message-Id: <3AB19607-2D27-416B-BB6A-F9A5C566B9A7@forgerock.com>
References: <CAP-T6TSBiOnSAMHLPtGpNyFz2h2XRRyT8zL-EnNNSrvuhCGXxA@mail.gmail.com>
Cc: oauth <oauth@ietf.org>, Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>
In-Reply-To: <CAP-T6TSBiOnSAMHLPtGpNyFz2h2XRRyT8zL-EnNNSrvuhCGXxA@mail.gmail.com>
To: Dave Tonge <dave.tonge@momentumft.co.uk>
X-Mailer: iPhone Mail (17F80)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/nOjqDH075jKYJGH8PFSeiJ6fN6w>
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 08:08:02 -0000


> On 9 Jul 2020, at 08:28, Dave Tonge <dave.tonge@momentumft.co.uk> wrote:
> 
> 
> Hi Neil
> 
> From a conceptual point of view I'm not really sure what RAR changes from vanilla OAuth?
> For example what is the difference between a client redirecting a user to an AS in order to:
>  - grant access to sensitive health data
>  - initiate a specific payment
>  - grant full read/write access to file storage containing sensitive commercial data

The difference is that one of these is transactional and the others aren’t. Normal OAuth relationships are durative and give the user some measure of control to manage that relationship over time. The transactional uses of RAR preclude this because every transaction is a completely isolated interaction. 

Unless you are suggesting dropping the transactional use-cases from RAR then this should be considered and addressed. 

> 
> All of the above could happen with RAR or vanilla OAuth.
> 
> Ironically in most jurisdictions, there is more protection for a user if they are tricked into initiating a payment vs whether they are tricked into granting access to data. Payments can be refunded, data cannot.

> From my perspective if an AS is granting access to sensitive data, payments, etc. then it has an obligation to protect its users by not allowing any random client to to start an authorization flow.

I’m glad we agree. 

> In the case of Open Banking, this obligation is taken care of by national regulators, but other commercial OAuth deployments often employ some form of vetting of clients before allowing them to request sensitive data. In addition certain sensitive actions can always require step-up authentication - this is also the case in OpenBanking, a payment to a new payee or over a certain amount will always require multi-factor authentication even if the user has a valid logged in session.

Putting aside the question of whether regulation is an adequate substitute for user consent, RAR is being proposed as a general specification, not within the context of any specific regulatory framework. It’s not ok to just assume this will all be handled by deployments. 

> 
> An AS is always free to implement the 2 step solution that you proposed and indeed it could be easier to implement with RAR in the manner you described, but I don't think it should be the prescribed approach.

How can an AS implement this with RAR? This is my point - there is no mechanism at all in RAR to link a transaction to any kind of prior consent. It’s not about mandating such an approach, it’s about *supporting* it at all. Every transaction in RAR is a blank slate at the moment. 

— Neil