Return-Path: 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 D752E3A0F55 for ; 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-Level: 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIDLDZSbkQSe for ; Wed, 27 May 2020 10:17:07 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr [80.12.242.126]) (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 ; Wed, 27 May 2020 10:17:06 -0700 (PDT) Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d59 with ME id jtH32200B4FMSmm03tH3is; Wed, 27 May 2020 19:17:04 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Wed, 27 May 2020 19:17:04 +0200 X-ME-IP: 86.238.65.197 To: oauth From: Denis 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 17:17:09 -0000 This is a multi-part message in MIME format. --------------E70E551A78284D113F8DBE93 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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. ADDITIONAL ARCHITECTURAL COMMENT 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 relationship. Denis --------------E70E551A78284D113F8DBE93 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

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 allowing to specify "fine-grained authorization requirements", that are more "privacy friendly"
should be considered to address the initial problem.


ADDITIONAL ARCHITECTURAL COMMENT

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 relationship.

Denis

--------------E70E551A78284D113F8DBE93--