Re: [OAUTH-WG] Comments on draft-ietf-oauth-jwsreq-22 (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request))
Aaron Parecki <aaron@parecki.com> Sun, 31 May 2020 05:24 UTC
Return-Path: <aaron@parecki.com>
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 BB3B53A1228 for <oauth@ietfa.amsl.com>; Sat, 30 May 2020 22:24:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
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 RaJTCeQVICb0 for <oauth@ietfa.amsl.com>; Sat, 30 May 2020 22:24:49 -0700 (PDT)
Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91ADE3A1227 for <oauth@ietf.org>; Sat, 30 May 2020 22:24:49 -0700 (PDT)
Received: by mail-io1-xd2c.google.com with SMTP id q8so3599322iow.7 for <oauth@ietf.org>; Sat, 30 May 2020 22:24:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7gbIGsX9FZ5MXz3dclMg+8TNxi4G+7GIzPuna+o5u4Q=; b=iXURmm5/zQqa8o7Q/jtfYoY+/pP38HplUKzB5UC3Yxx4K1DD0BPnRh8uzkLmmhDdJU kO+Gwl4UQ6nlsdWUGDW3lqR4xLexaYtL2F61AgBKz3ChkjlE1L117GBOLbgIeCRa8BwN 0qNLCuI8P9eGpE2//Re8zE/9rm8BvxkifR6odXlinUyMrnDFKysXlP1GyQK0rOydZDKL Wo5qmncbpqeJSvz5LmXb7nFqaQLuKz8TgA8Ii4IEiypGvZrCatB5XFI/Sgm6ojuR2gF2 OtYiFsQPadoJFw28hF3mI+Kf0K8FbsgAOxehuLIizkM4Kz3T8NDfh6WNvb8UaHUlZge1 0kvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7gbIGsX9FZ5MXz3dclMg+8TNxi4G+7GIzPuna+o5u4Q=; b=DbaZtZBgCJ9ehI0wcEcTmv0Yv/V2JTGiM4SHUW9ZySReop/My5zu0Axe2XkQ4xA95l neewzR/WJgnIEXb5g8Sm7CG8f5yRZA+7tsmirxRp82s7pAxEscWJS3/chfG6CxzmT1Ir KrntqiwaJ0EQ9QHDmYlVKUr5XkuuIZHEGE7IJwhMaMXZcYYsrlAMRZDi3QwtG/Mh+8Io dMOSjUmgR3QMBiOQ1+Kqif5e7VGrzN/2yPLm2mssNBYyel/RWBGKz4T/9Bd+MfkqPTZ0 Sz8/i/VbnyaAriiRMBu0t7eUSIGnp7XWhgB+X39uIBD3OMALSgOW/DSQJmtR3aQ8CxB3 HmYA==
X-Gm-Message-State: AOAM531xgyp4MYJnOnsL1FMVO8dcR9HqiEvEn7oDh0bxQ68au0NEqJJj WClFhjJzL5nTj4o0nHmVoEj6vioVzAs=
X-Google-Smtp-Source: ABdhPJz0uPxQd7aHhpqy/tZAh6acD5Q7fQVvYTQ4ySrTTIm4+MM6mx2FT+9nWuADdA9wXbXYnuEWFA==
X-Received: by 2002:a6b:ea10:: with SMTP id m16mr13513674ioc.180.1590902687253; Sat, 30 May 2020 22:24:47 -0700 (PDT)
Received: from mail-io1-f53.google.com (mail-io1-f53.google.com. [209.85.166.53]) by smtp.gmail.com with ESMTPSA id f10sm7369965ilj.85.2020.05.30.22.24.46 for <oauth@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 30 May 2020 22:24:46 -0700 (PDT)
Received: by mail-io1-f53.google.com with SMTP id y18so3622597iow.3 for <oauth@ietf.org>; Sat, 30 May 2020 22:24:46 -0700 (PDT)
X-Received: by 2002:a02:998b:: with SMTP id a11mr14805591jal.117.1590902686012; Sat, 30 May 2020 22:24:46 -0700 (PDT)
MIME-Version: 1.0
References: <ead54f3c-48ac-d5c1-a903-38fcb3330740@free.fr>
In-Reply-To: <ead54f3c-48ac-d5c1-a903-38fcb3330740@free.fr>
From: Aaron Parecki <aaron@parecki.com>
Date: Sat, 30 May 2020 22:24:35 -0700
X-Gmail-Original-Message-ID: <CAGBSGjobTRhOwz9KKGq-knYTx=J6b-xmzRvSVdE0sy=wHFGykA@mail.gmail.com>
Message-ID: <CAGBSGjobTRhOwz9KKGq-knYTx=J6b-xmzRvSVdE0sy=wHFGykA@mail.gmail.com>
To: Denis <denis.ietf@free.fr>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000078dc4905a6eae564"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/yDO2J71YhvHcyD_QIcBlhHFyiZQ>
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 05:24:52 -0000
> 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" Typically in OAuth it's the authorization server's job to inform users and protect access to their resources. Obviously in order to do that the AS must know about the details of the request. Can you please clarify the scenario in which you would want the AS to have no information about the request that it's authorizing? Aaron Parecki On Wed, May 27, 2020 at 10:20 AM Denis <denis.ietf@free.fr> 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. > > Denis > > PS. This email closely relates to the previous email sent on the WG > mailing list with the following topic: > Comments on OAuth 2.0 Rich Authorization Requests > (draft-ietf-oauth-rar-01) > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- --- Aaron Parecki https://aaronparecki.com
- [OAUTH-WG] Comments on draft-ietf-oauth-jwsreq-22… Denis
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-jwsre… Benjamin Kaduk
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-jwsre… Aaron Parecki
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-jwsre… Denis
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-jwsre… Nat Sakimura