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

Neil Madden <neil.madden@forgerock.com> Wed, 08 July 2020 07:14 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 498983A0BF3 for <oauth@ietfa.amsl.com>; Wed, 8 Jul 2020 00:14:38 -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 oxHRC3W6x-aB for <oauth@ietfa.amsl.com>; Wed, 8 Jul 2020 00:14:36 -0700 (PDT)
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 032F23A0A26 for <oauth@ietf.org>; Wed, 8 Jul 2020 00:14:35 -0700 (PDT)
Received: by mail-wr1-x42b.google.com with SMTP id o11so47744041wrv.9 for <oauth@ietf.org>; Wed, 08 Jul 2020 00:14:35 -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=4FjfIUxPaGiLjDfCVlehIZbsbq6Y41On7ixfDBp7N3s=; b=SRmWeENfaS4jYXKtRAcapj6zX5OQFu/tvq0J20FmqGpxl9Y/RGNHLoqpVZc9N5H0GF rfACcOvEMeuD2mymKq2lQDS/QoQshFlbqBC1EzShQrAYy4Y7mezcI/mFknmLd3FxRX7G SE5NF4y6WNgYiuJQTTm5lIT0sTjoNPynF9CHU=
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=4FjfIUxPaGiLjDfCVlehIZbsbq6Y41On7ixfDBp7N3s=; b=p8RTEsn9TI/c/jo59jS4x/MV3QcqDZJSE+YcjguqLWxkevFmtccyIXlllBjmXTkrxQ SOZ5QGnMDPoHZZM+1TWwRVTQBWHC6xcsdaBc9XysYlu2HfNrFgo8qcnop+P3qU4Y2ER3 6mNyICplt1OjfmA4GDUvTjzqPAHVHkjCcAVe1BxRDqqLJCE8ztejr5BWcWPYkimh45hG kHtpU89mJc7F0NK8iwOZcDLLObyYHJbxfuok1W2w82eNegn7buyiNgtnb9Efo6Ed2qvE yLy6ihUMCOAgfwh8LJLwrQ+jHO4KilJbBg6hCUXIGaXIfVeOJmgULMg8ICksD+HFzUp7 /CoA==
X-Gm-Message-State: AOAM533bLLtoqiEPcXZkuxzcUQCgFutP+NyoZk5VsqXNXvoc8thjWflm IAdlgDthI+Hmktmv5iwqm7aKhQfp98b/Pw==
X-Google-Smtp-Source: ABdhPJxXMkcCj3XW0PQQF1Ep8mJ/P7hvr2O1h3/UYJiHZs8kbjZpnRa9fH4aO6BXOwoyQxeMJ9Erng==
X-Received: by 2002:a5d:6749:: with SMTP id l9mr56158037wrw.63.1594192473817; Wed, 08 Jul 2020 00:14:33 -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 d18sm4599311wrj.8.2020.07.08.00.14.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Jul 2020 00:14:33 -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: Wed, 8 Jul 2020 08:14:32 +0100
Message-Id: <BF273D10-D5A0-4B16-8F13-E03E60256091@forgerock.com>
References: <c1dc7ae2-e64c-8440-3e7d-7c956145e1e6@connect2id.com>
Cc: oauth@ietf.org
In-Reply-To: <c1dc7ae2-e64c-8440-3e7d-7c956145e1e6@connect2id.com>
To: Vladimir Dzhuvinov <vladimir@connect2id.com>
X-Mailer: iPhone Mail (17F80)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/KgdM8PJy7O3ZkvsD4EZ29As4-lY>
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 07:14:38 -0000

On 7 Jul 2020, at 21:09, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
> 
> 
>> On 06/07/2020 19:32, Neil Madden wrote:
>> I’m reading draft-ietf-oauth-rar-01 in a bit more detail now I have
>> some time, and I have a few comments.
>> 
>> An assumption in the draft appears to be that the client knows ahead
>> of time what it wants to gain access to and can describe it in detail.
>> For example, the last example in section 2.1 is a client requesting
>> access to particular files, which assumes that the client already
>> knows the paths of the files it wants to access. This in turn seems to
>> imply that the client already has some level of access to be able to
>> determine this, e.g. to list directories, which may not be desirable.
>> In many cases like this I think it’s more natural for the client to
>> not know exactly what it is asking for but instead to want access to
>> *some* file, chosen by the user. An example of this is the Dropbox
>> Chooser [1] and Saver [2] APIs, which notably are not built on top of
>> OAuth. In these cases it would be more natural for the client to send
>> a more generic request and for the details to be filled in by the user
>> as part of the consent process.
>> 
>> Another issue is that as far as I can see in the current draft, any
>> client can initiate a rich authorization request at any time without
>> any kind of prior approval. This seems problematic for the main
>> example in the draft, i.e. payment initiation. As an attacker, if I
>> can get a consent screen up on a user’s device requesting to move
>> money around then it seems like half my job is already done - some
>> fraction of users will probably approve such a transaction without
>> properly checking it. It feels like the ability to ask for transaction
>> approval should already be a privileged operation that should require
>> consent and approval.
>> 
>> A related issue is that each approval is in effect a completely
>> isolated incident. In a normal OAuth2 interaction I would grant an app
>> some longish-term access to data and it would get an access token and
>> optionally a refresh token. At some later point I can go to the AS and
>> see that I have granted this access and revoke it if I choose. With
>> RAR there is no representation of a long-term relationship between the
>> RO and the client and each transaction starts from fresh. Again, this
>> seems potentially problematic and not quite in keeping with how OAuth
>> currently operates. Each grant of access is ephemeral. (Do refresh
>> tokens make sense in the context of RAR?)
> 
> The original motivation for RAR was indeed transactions, which require
> parameters, and this class of use cases do typically imply "ephemeral"
> access (single-use token).
> 
> But nothing precludes RAR from being used for long term access (with a
> refresh token) and there are one or two simple examples in the spec
> which can be interpreted as such.
> 
>> 
>> I think a better approach would be a two-phase authorization process:
>> 
>> 1. In step 1 an app gets a normal long-lived access and/or refresh
>> token that grants it permissions to ask to initial transactions (RARs)
>> - e.g. with scope initiate_payments
>> 2. In step 2 the app requests authorization for individual
>> RARs/transactions using some proof of its grant from step 1
> 
> Such a two-phase authorisation can make good sense in cases when user
> trust needs to be built up.
> 
> Mentioning this and / or some other pattern can be useful, but I don't
> think we should make this normative for RAR, because there can well be
> use cases which won't need this.
> 

Do you have any examples? 

I think this is something the draft needs to address. 

Neil