[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 [127.0.0.1]) 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-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 <oauth@ietfa.amsl.com>; 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 <oauth@ietf.org>; 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 <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.
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