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

Neil Madden <> Wed, 08 July 2020 07:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 498983A0BF3 for <>; Wed, 8 Jul 2020 00:14:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oxHRC3W6x-aB for <>; Wed, 8 Jul 2020 00:14:36 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 032F23A0A26 for <>; Wed, 8 Jul 2020 00:14:35 -0700 (PDT)
Received: by with SMTP id o11so47744041wrv.9 for <>; Wed, 08 Jul 2020 00:14:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 [] ( []) by with ESMTPSA id d18sm4599311wrj.8.2020. (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 <>
Mime-Version: 1.0 (1.0)
Date: Wed, 08 Jul 2020 08:14:32 +0100
Message-Id: <>
References: <>
In-Reply-To: <>
To: Vladimir Dzhuvinov <>
X-Mailer: iPhone Mail (17F80)
Archived-At: <>
Subject: Re: [OAUTH-WG] A few comments on draft-ietf-oauth-rar-01
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 08 Jul 2020 07:14:38 -0000

On 7 Jul 2020, at 21:09, Vladimir Dzhuvinov <> 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.