Re: [OAUTH-WG] Comments on draft-ietf-oauth-jwsreq-22 (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request))

Benjamin Kaduk <kaduk@mit.edu> Sun, 31 May 2020 04:37 UTC

Return-Path: <kaduk@mit.edu>
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 61BAF3A11D9 for <oauth@ietfa.amsl.com>; Sat, 30 May 2020 21:37:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 P9BQ_DA_oc5m for <oauth@ietfa.amsl.com>; Sat, 30 May 2020 21:37:53 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 245B43A11D8 for <oauth@ietf.org>; Sat, 30 May 2020 21:37:52 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 04V4blXD029242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 31 May 2020 00:37:49 -0400
Date: Sat, 30 May 2020 21:37:47 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Denis <denis.ietf@free.fr>
Cc: oauth <oauth@ietf.org>
Message-ID: <20200531043747.GN58497@kduck.mit.edu>
References: <ead54f3c-48ac-d5c1-a903-38fcb3330740@free.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <ead54f3c-48ac-d5c1-a903-38fcb3330740@free.fr>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Xg0lnXm7jjiMRbM3CejmTLUp2ms>
Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-jwsreq-22 (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request))
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: Sun, 31 May 2020 04:37:54 -0000

On Wed, May 27, 2020 at 07:20:29PM +0200, Denis wrote:
> As indicated in the abstract:
> 
>     "This document introduces the ability to send request parameters in
>     a JSON Web Token (JWT) instead,
>        which allows the request to be signed with JSON Web Signature (JWS)".
> 
> This approach has a major consequence which is not indicated in the 
> "Privacy Considerations section:
> the AS will have the knowledge of these request parameters 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".
> 
> 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 a deep knowledge of every
> operation that can 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.
> 
> Other approaches that are more "privacy friendly" should be considered 
> to address the initial problem.

Do you have the start of a list of such other approaches to seed the
discussion?  There seemms to be some inherent tension between the
authorization server knowing what it is authorizing and the privacy
properties you are advocating...

Thanks,

Ben