Re: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT)

vittorio.bertocci@auth0.com Wed, 14 April 2021 15:23 UTC

Return-Path: <vittorio.bertocci@auth0.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 4FF863A12D1 for <oauth@ietfa.amsl.com>; Wed, 14 Apr 2021 08:23:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.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 yz8_4074adnE for <oauth@ietfa.amsl.com>; Wed, 14 Apr 2021 08:23:41 -0700 (PDT)
Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 C55403A12F0 for <oauth@ietf.org>; Wed, 14 Apr 2021 08:23:10 -0700 (PDT)
Received: by mail-pg1-x530.google.com with SMTP id k8so14644065pgf.4 for <oauth@ietf.org>; Wed, 14 Apr 2021 08:23:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=ZpOkS+aEx8HRIWpnFKhIWXrTwnAdvzzIL+tKFwuK6T0=; b=UW8+fXHMBE5zz5EUa01j543UL+ozyWMpQIGrO69JbpX9vK/MdvEhYS8u1nOdfMms9g jSFKUs92NfEzmXMfXYhDMPDDQccNed9ri2T1E0kQdYt6K88CmqMgEH1WJcSFIxkF8inG tg4gaqMe6s+kWyHdNFMMlFuoYhc0zunyUCQl7YP3r2MAy0AlUlgNI3MWDEq4lHb5p2sO UB3yQ+Cci9En/1JDlyzCHwd95h+PVMh0ANlRu9w+nWyWWiPoetjYu5hC4ZXN8QYsYLgB 967ZM1yvwaLloVpRT+gAJwZvEUpjV8g/+mCHtYPpBkQQaj3LC1P+pCnwE7JzKbZC7dQR 6H3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=ZpOkS+aEx8HRIWpnFKhIWXrTwnAdvzzIL+tKFwuK6T0=; b=n+ZGXWzwAXhIs/XEa/WYMeBPKtka6NrcNS2wRZU/IBKKO+mQT9bgEjQXhX0Dk1YXaS vOPvnRRaSuhXAAGgpyOmw6BZzgyC2YK+VeUq21BzLzRPxlyl5wFZm2pxKel35okEG3qH w0LpEyB6OMC2IH0jDOnZeaYhulCU2ww6RxZeAM3NBJihx9PvFiOybzeQzyrc3ycnFOWS 3Eb/9qKd2ZaLNrvjBloqOU8yY03/ypIHx1Qt+BFStC6qRwj6oFW/sIx10F84iRDSKtHd EBYBe2AVoC1ZNN2pwNxURCwY90UCDhwbt+Bow7oZF1KzZycSg6SFJben+rW5DGTKD82g sOPQ==
X-Gm-Message-State: AOAM530fllt0OKSh5m5Eq0ByTJUIIEobW8kuXt1HQy6a68/ZRjmw5jdF gRPwesfLbRQbWxplcV/tsLqxP7l6fb9D3vvA
X-Google-Smtp-Source: ABdhPJz6GhHA4qZc9T5xdJsOug29TKrUct2QwbaDCNPY9y+OJkA8AyXTHxqP48FK3q0L8w9hDoZESw==
X-Received: by 2002:a05:6a00:d4f:b029:251:75bc:85af with SMTP id n15-20020a056a000d4fb029025175bc85afmr7297314pfv.61.1618413789248; Wed, 14 Apr 2021 08:23:09 -0700 (PDT)
Received: from vibrosurface7 (c-67-171-8-60.hsd1.wa.comcast.net. [67.171.8.60]) by smtp.gmail.com with ESMTPSA id ch21sm4328598pjb.8.2021.04.14.08.23.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Apr 2021 08:23:08 -0700 (PDT)
From: <vittorio.bertocci@auth0.com>
To: "'Denis'" <denis.ietf@free.fr>, "'Vittorio Bertocci'" <vittorio.bertocci=40auth0.com@dmarc.ietf.org>, "'Murray Kucherawy'" <superuser@gmail.com>, "'The IESG'" <iesg@ietf.org>
Cc: <draft-ietf-oauth-access-token-jwt@ietf.org>, <oauth-chairs@ietf.org>, <oauth@ietf.org>
References: <161786294101.28888.16150454715315694485@ietfa.amsl.com> <CO6PR18MB4052516F8420BBF956A5992FAE4E9@CO6PR18MB4052.namprd18.prod.outlook.com> <b837264b-6fba-f77c-c288-5b3e3c1a2214@free.fr>
In-Reply-To: <b837264b-6fba-f77c-c288-5b3e3c1a2214@free.fr>
Date: Wed, 14 Apr 2021 08:23:07 -0700
Message-ID: <00b301d73142$128aae40$37a00ac0$@auth0.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B4_01D73107.662E2030"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQK6olU5aiFsYlY19s08mwnpZvepcAJUOXKHARXdSLKo0e1x4A==
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/HNcKFgQTlseqk1ZEf2g9Azkh6FY>
Subject: Re: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT)
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, 14 Apr 2021 15:23:46 -0000

Hi Denis, this aspect was debated at length (one example in https://mailarchive.ietf.org/arch/msg/oauth/OYgGsIa_4q8UYnl6SiGyvJ9Hnxw/, there are many others) and the consensus reflected in the current text was clear.

 

From: Denis <denis.ietf@free.fr> 
Sent: Wednesday, April 14, 2021 1:19 AM
To: Vittorio Bertocci <vittorio.bertocci=40auth0.com@dmarc.ietf.org>rg>; Murray Kucherawy <superuser@gmail.com>om>; The IESG <iesg@ietf.org>
Cc: draft-ietf-oauth-access-token-jwt@ietf.org; oauth-chairs@ietf.org; oauth@ietf.org
Subject: Re: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT)

 

Hi Murray,

 

Thank you for your comments. I come back on one of your comments (while other comments and Vittorio's responses are deleted):

   The first half of the second paragraph of Section 6 seems much more like an
   interoperability issue than a privacy issue to me.

I agree that, taken in isolation, the connection to privacy of that aspect is not immediately self-evident. 
I would argue it is not about interop either, given that noncompliance with the guidance given there doesn’t 
impact what's transmitted. Nonetheless, I believe the privacy section is the closest match we have for that 
guidance, given its many touch points to privacy matters (the ability of a client to inspect ATs is a privacy 
concern; the decision to use a JWT ATs, which ultimately makes spelling out the guidance necessary, is influenced 
by privacy considerations; and so on and so forth). In sum, although I agree it's not a perfect fit, I think 
that's the best fit we have; and given that consolidating consensus for that part has been particularly painful, 
I am inclined to leave that part as is.   

 

The second paragraph of Section 6 (Privacy Considerations) is as follows:

 

   The client MUST NOT inspect the content of the access token: the
   authorization server and the resource server might decide to change
   token format at any time (for example by switching from this profile
   to opaque tokens) hence any logic in the client relying on the
   ability to read the access token content would break without
   recourse.  The OAuth 2.0 framework assumes that access tokens are
   treated as opaque by clients.  Administrators of authorization
   servers should also take into account that the content of an access
   token is visible to the client.  Whenever client access to the access
   token content presents privacy issues for a given scenario, the
   authorization server should take explicit steps to prevent it.

As soon as there is a MUST NOT, this is not a guidance any more.

Some words of this paragraph, i.e. "any logic in the client relying on the ability to read the access token content" simply recognize that 
the client is able to inspect the content of the access token, but if it does it this is at its own risk since "the resource server might decide 
to change token format at any time (for example by switching from this profile to opaque tokens)".

The second paragraph may be rewritten by placing in front of it an important sentence that comes later on in this paragraph:

The OAuth 2.0 framework assumes that access tokens are treated as opaque by clients. 

Then after, the first sentence that includes the MUST NOT can be removed and the current text can be re-used after it, by shuffling the order
of the remaining sentences.

The end result would be the following:

  The OAuth 2.0 framework assumes that access tokens are treated as opaque by clients.   
  Administrators of authorization servers should take into account that the content 
  of an access token is visible to the client. The authorization server and the resource 
  server might decide to change token format at any time (for example by switching from 
  this profile to opaque tokens) hence any logic in the client relying on the ability to read 
  the access token content would break without recourse. Whenever client access to the access 
  token content presents privacy issues for a given scenario, the authorization server should 
  take explicit steps to prevent it.   

The key benefits are the following: the guidance is still there, but the sentence with the "MUST NOT" has been removed.

Denis