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

Neil Madden <neil.madden@forgerock.com> Mon, 13 July 2020 14:33 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 CCFC43A12E5 for <oauth@ietfa.amsl.com>; Mon, 13 Jul 2020 07:33:07 -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 (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 132FkAZoYwJE for <oauth@ietfa.amsl.com>; Mon, 13 Jul 2020 07:33:06 -0700 (PDT)
Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) (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 1B46E3A12CB for <oauth@ietf.org>; Mon, 13 Jul 2020 07:33:05 -0700 (PDT)
Received: by mail-wm1-x342.google.com with SMTP id l2so13391403wmf.0 for <oauth@ietf.org>; Mon, 13 Jul 2020 07:33:05 -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=wceTCreC9LL9/JLokkuPko5EqvqTh4R3KkIVYjDs08U=; b=hMZmigQ2QDEx6WIc9bs36bVe6oQfDrDFRg1CCgtb/IN2dtiKBAYCzet0FWIfCn5ciq w8uVQgt5WJz5LY+6Z/yWsF5MN9eonus0PUHNZQsUgrjXv6oYlN+8h3r3iO7k5236vM0l IAoVy2YorR2xE02O7gs6r5aKcEFvvih3lDvdg=
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=wceTCreC9LL9/JLokkuPko5EqvqTh4R3KkIVYjDs08U=; b=O8cMyUaj2i3FwwN76U9wcG7vyugzFs5qb5IzctmR2ye2ZLtR5U2DSaWWkmEfDwX1y7 iXw4JdRxaBHquJy9jlLrhrPT2cI0GfMowUlaXRm7qXtQ7WJmAd8nd2XF9w/wuQKwUeo/ wh95wbAyRRb87ozKtFuPuQlrxSGR2noFQo5KMMG1AUPVstBOl8vRyD1rAqKF6f77G0Ba kFUJpIltGSfV97nN7qec50aCc0yAi4LW52KNbm5VsEPOFT4d0axIq2zmcWpxx/b+VfnO AN8/J6ffkbGKxUHwxmqA74F7LD9CM/gkuSBfNk0elhhut5fbuCDZx9WfSycrq5w6vsZc dsSA==
X-Gm-Message-State: AOAM533tQcxrEhPMPC08USTMLnHV5RMnuI8EON8ah/9crgP80YU0pxwA 0D4Cw4KSm/sk6NG7MSY9a//y/Q==
X-Google-Smtp-Source: ABdhPJxru+nLd1CEXXxQxSdG7hFHkXbgB8zKSMFWgbSenq4uR16Fbo5SwoBgDiQ0Lnau1Dl8B2uUqQ==
X-Received: by 2002:a1c:5453:: with SMTP id p19mr223255wmi.41.1594650784333; Mon, 13 Jul 2020 07:33:04 -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 b10sm21345238wmj.30.2020.07.13.07.33.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Jul 2020 07:33:03 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Neil Madden <neil.madden@forgerock.com>
Mime-Version: 1.0 (1.0)
Date: Mon, 13 Jul 2020 15:33:02 +0100
Message-Id: <DA1B644C-404B-4A35-AC7E-DBAF8319C7AF@forgerock.com>
References: <56A079DA-7237-496F-A9D7-6A7E9F994551@lodderstedt.net>
Cc: Justin Richer <jricher@mit.edu>, oauth <oauth@ietf.org>
In-Reply-To: <56A079DA-7237-496F-A9D7-6A7E9F994551@lodderstedt.net>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
X-Mailer: iPhone Mail (17F80)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/KWYkS2A9i7RZG6wRFkf8LTkMiJU>
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:33:08 -0000


> On 13 Jul 2020, at 09:29, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
> 
> 
> 
>> On 9. Jul 2020, at 19:58, Neil Madden <neil.madden@forgerock.com> wrote:
>> 
>> 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. 
> 
> I’m still trying to understand the issue and your proposed solution. What you are suggesting is an OAuth authorization to subsequently send another more detailed or transactional OAuth authorization. 
> 
> If your basic assumption is that users just accept a payment conformation screen, why do you think the additional pre-authorization won’t be accepted straight away?

It’s not about having two authorization screens. It’s about allowing users to manage their relationship with a client just as they can for any other OAuth client. If a normal OAuth client behaves badly I can go and revoke my grant of access to that client. I can’t do that with the transactional uses of RAR because each one is a blank slate. 

Having individual transactions tied to an overall grant of authority lets the user control which clients they interact with and which they trust. 

To me, this (user consent and control) is a fundamental strength of OAuth and any approach to transactional authorization using OAuth should preserve this. 

The other point I was making is that when the transactional authorization occurs over a backchannel then it is much better if the user has previously explicitly authorized that client over a front channel - eg when they first installed an app. I’m not suggesting that the AS would send two backchannel authorization requests instead of one. 

> 
> The way PSD2 uses to secure such transactions is transaction authorization using a dynamic second factor (called strong customer authentication). I assume the rational is SCA will make users think before they confirm. 

I hope so. But given that authN usually occurs before the consent stage, the user may not know what it is they are consenting to before they complete 2FA. 

— Neil