[OAUTH-WG] Comments on OAuth 2.0 Rich Authorization Requests (draft-ietf-oauth-rar-01)

Denis <denis.ietf@free.fr> Wed, 27 May 2020 17:17 UTC

Return-Path: <denis.ietf@free.fr>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D752E3A0F55 for <oauth@ietfa.amsl.com>; Wed, 27 May 2020 10:17:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.378
X-Spam-Status: No, score=0.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, SPOOFED_FREEMAIL=1.999] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id eIDLDZSbkQSe for <oauth@ietfa.amsl.com>; Wed, 27 May 2020 10:17:07 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73CE53A0F4F for <oauth@ietf.org>; Wed, 27 May 2020 10:17:06 -0700 (PDT)
Received: from [] ([]) by mwinf5d59 with ME id jtH32200B4FMSmm03tH3is; Wed, 27 May 2020 19:17:04 +0200
X-ME-Helo: []
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Wed, 27 May 2020 19:17:04 +0200
To: oauth <oauth@ietf.org>
From: Denis <denis.ietf@free.fr>
Message-ID: <57405c52-8356-62dd-e242-f075882eef57@free.fr>
Date: Wed, 27 May 2020 19:17:03 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------E70E551A78284D113F8DBE93"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/J3HM5UZLbr5u5NuOhf-JXWoX15k>
Subject: [OAUTH-WG] Comments on OAuth 2.0 Rich Authorization Requests (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, 27 May 2020 17:17:09 -0000

This document states that the "scope" parameter used to specify the 
requested scope of an access token
is only "sufficient to implement static scenarios and coarse-grained 
authorization requests".

The intent of this draft is to specify "fine-grained authorization 
requirements", such as "please let me make
a payment with the amount of 45 Euros" or "please give me read access to 
folder A and write access to file X".

The proposed draft presents some similarities with a capability model 
where the holder of an access token is given
the right by an AS to perform some operation(s) on an object through the 
content of the access token.

Such an approach has privacy issues which are currently not documented 
in the Privacy Considerations section.

The AS would be in a position to know, not only which resources servers 
are going to be accessed, but also
what kind of operations are going to be performed by its clients on the 
resource servers. With such an approach,
ASs will have the knowledge of every operation that is likely to be 
performed by a user on every RS.

As a consequence, the AS would also be in a position to trace the 
actions performed by its users on the resources servers
with which it has a relationship.

Other approaches allowingto specify "fine-grained authorization 
requirements", that are more "privacy friendly"
should be considered to address the initial problem.


OAuth initially assumed a static relationship between clients, 
authorization servers and resource servers.

The original model for OAuth was making the assumption that the AS and 
the RS had a strong bilateral relationship.

A key question is whether such strong relationship will be maintained 
for ever or whether it will be allowed to perform
some evolutions of this relationship.

In order to respect the privacy of the users, there is the need to 
encompass other scenarios. One of these scenarios is
that the AS and the RS do not need any longer to have such a strong 
relationship. In terms of trust relationships, a RS
simply needs to trust the access tokens issued by an AS. The AS does 
have any more a "need to know" of all the RSs
that are accepting its access tokens. This would be a major 
simplification of the current global architecture.

oauth-security-topics states:

       The privileges associated with an access token SHOULD be
    restricted to the minimum required for the particular
       application or use case.

This means that the client should be able to select by itself the claims 
it would like to be placed into an access token
with respect to the operations it is willing to perform on a RS.

As long as only the scope request parameter will be usable in an access 
token request to select the claims to be placed
into an access token, it will not be possible to remove this strong