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

Vladimir Dzhuvinov <> Tue, 07 July 2020 20:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BB15F3A0A0D for <>; Tue, 7 Jul 2020 13:08:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id A1BMyYh-NPSG for <>; Tue, 7 Jul 2020 13:08:53 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 40B773A0A0C for <>; Tue, 7 Jul 2020 13:08:53 -0700 (PDT)
Received: from [] ([]) by :SMTPAUTH: with ESMTPSA id sttbjY1VAjqjisttcjeU0J; Tue, 07 Jul 2020 13:08:52 -0700
X-CMAE-Analysis: v=2.3 cv=U7zs8tju c=1 sm=1 tr=0 a=+I3yL00+yDwT8KNLgfs+4A==:117 a=+I3yL00+yDwT8KNLgfs+4A==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=VAMm1qzQAAAA:8 a=xbHvs1yBsIbqydze8tgA:9 a=_s9_IssjmW8t3rxW:21 a=iytcRMvxwO25_rXe:21 a=QEXdDO2ut3YA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10
References: <>
From: Vladimir Dzhuvinov <>
Autocrypt:; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd
Organization: Connect2id Ltd.
Message-ID: <>
Date: Tue, 07 Jul 2020 23:08:50 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms010300010300020303020101"
X-CMAE-Envelope: MS4wfKPaggICdUMj5eGQpWOgTsvGadMQlEFgxpe1ECW6iS4JCnNI2njeSCi8+9pXUjhgUQyg88Gz1xBvwYO/RRs8CfW8gQgv9jOD/wo+lRM45wpP5l4QmglL bGTtqf5N8AOrctBt+81wsegLGLBtOHH/8QVhEZTXjKc2LohcNxzODTqt
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: Tue, 07 Jul 2020 20:08:55 -0000

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.

> I have ideas for how this could be achieved, but I’d prefer to see
> what others think of this general idea rather than getting bogged down
> in specific details.
> [1]:
> [2]: 
> — Neil