Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Vittorio Bertocci <vittorio.bertocci@auth0.com> Tue, 12 May 2020 00:24 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 EA9653A0DDC for <oauth@ietfa.amsl.com>; Mon, 11 May 2020 17:24: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, 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=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 8nPmpiahvx78 for <oauth@ietfa.amsl.com>; Mon, 11 May 2020 17:24:44 -0700 (PDT)
Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 B8C3C3A0DD8 for <oauth@ietf.org>; Mon, 11 May 2020 17:24:44 -0700 (PDT)
Received: by mail-pg1-x52e.google.com with SMTP id f6so5332464pgm.1 for <oauth@ietf.org>; Mon, 11 May 2020 17:24:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=VdcSVqED1Y1vkuQlbbjRyMnaTNPMd8PxAfXX5bNjR0Y=; b=pYeKo2PyfNXNxerepcX+xywnsqrc5pHTs8gPWxV4w4C4o4UchvTn4gVenquedahNID bXCkpKDlpIFwpIiyWhLLDUlNF8rXnjbGHHGlJiMKUFEKHm7mnssVxRwx79cuSkspCZ15 Gjxr1brn9f6wK4Ro6PCwhw61psR4KeE12FwZAKiZg0/hmA7JjkTBOT2VLqVhGmbb/Yre TqCAUct4gYBjNVkxWTLLxrjNQMtFaQtwhGkoyZhQRUat4tmZZMBpuTCLZYtaSgeRV3aX eY2s8/OEfXV1EA07ePCXZKbYU0QiQYEICuLE+gsHKc+WnRI/3ZjpPgJ/x2Q0bW9pRZBo nxmQ==
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:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=VdcSVqED1Y1vkuQlbbjRyMnaTNPMd8PxAfXX5bNjR0Y=; b=Vzo1mw3u9mGNt4/MHyT2QCQZ7KdJHScr3X8pQGrcqxp8LFHspfG5x1IuAAvRf5qp8n vbMgzsG6lzx7pqJYGo+hQEYNOAQoJrh4RGsD+zdiotK7CPtErFzUCub88OhZYhXgB/DJ gavywh5kTFF61Qpf4RK+LLi6RxVipjGwrQIr5XX1M96UsMmDdyA8fyzqCPecNpbtFJDJ b+VjnBIfz6rrKI3ekejyUNbi543IVjwLLL8FbXUEEah8qymm32wN9I1TIhBI+E2NWnik 3tiKC1knh1GnOdoFTHG1UUvFQijBqkwiHNeLscRCdX83H8HAcGwving4ixlq9ZBMBWh9 KzEQ==
X-Gm-Message-State: AGi0PuYqs55f7irqd1Gf2hNb2ighMWMYSjhq5PygcYHdKnBleK/jRcwj 7ZzNElEyD9Xypo1vuDLO0nMqdA==
X-Google-Smtp-Source: APiQypICXqRrhpziDSEUgl4jCoHZwvcMVZfVkyWJrmaA0VbrABV1aDDih+h2W/k5jyeXkTdbcT3LIw==
X-Received: by 2002:a62:ee02:: with SMTP id e2mr17900570pfi.161.1589243083641; Mon, 11 May 2020 17:24:43 -0700 (PDT)
Received: from MWHPR19MB1501.namprd19.prod.outlook.com ([2603:1036:120:1d::5]) by smtp.gmail.com with ESMTPSA id g199sm490761pfb.95.2020.05.11.17.24.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 May 2020 17:24:42 -0700 (PDT)
From: Vittorio Bertocci <vittorio.bertocci@auth0.com>
To: Jared Jennings <jaredljennings@gmail.com>, Denis <denis.ietf@free.fr>
CC: Benjamin Kaduk <kaduk@mit.edu>, "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
Thread-Index: AWVjNzMz1Wh1JFmMLTwMf11UWdvKNjAxNzIx3/WxUgCABgjfgIAATU+AgAc5EACAA+g5AIAAD6KAgAC26Kk=
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Tue, 12 May 2020 00:24:40 +0000
Message-ID: <MWHPR19MB1501B1F305C170BCA0FD01F6AEBE0@MWHPR19MB1501.namprd19.prod.outlook.com>
References: <CAGL6epKuHTqLrZEjm0goKV+3jaPfTkN_JSLc0jfQyPqNzeP3aA@mail.gmail.com> <125f32d3-dd3b-3add-1172-391acd831cde@free.fr> <MWHPR19MB150159025ECBAD75B6DDE1DFAEAD0@MWHPR19MB1501.namprd19.prod.outlook.com> <79748d92-c084-c6f9-20b1-163cb5760d11@free.fr> <20200504055923.GH27494@kduck.mit.edu> <7ebcabb3-3160-37dd-2dac-407744084c33@free.fr> <20200509005408.GA27494@kduck.mit.edu> <22f844b4-966d-936d-df7c-ef7b8788b0aa@free.fr> <CAMVRk+Ln4xo_3pC6ALf0rp3+7gHyvO1zV=+NsA2pW4AZJ=1JAw@mail.gmail.com>
In-Reply-To: <CAMVRk+Ln4xo_3pC6ALf0rp3+7gHyvO1zV=+NsA2pW4AZJ=1JAw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_MWHPR19MB1501B1F305C170BCA0FD01F6AEBE0MWHPR19MB1501namp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/oXtWElVqiJYvfKSCRmvJqlYEzBE>
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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: Tue, 12 May 2020 00:24:47 -0000

Thank you Jared for your comment!
I have to admit I have been very tempted to go that route, mostly for moving things forward, but I still think we’d do the reader a disservice by relaxing the language there.
Real world scenarios are full of situations where additional assumptions can lower dangers that must be taken in consideration in the general case, which might make less of a risk going against the spec in those particular circumstances, but their existence doesn’t warrant relaxing guidance for the general case. A concrete example: I worked on scenarios where resource servers wanted to guarantee some degree of business continuity in case of AS outage, which boiled down to RS’ willingness to accept ATs past their declared expiration time, on the condition that the AS outage condition was detectable and the staleness of the AT didn’t cross a tolerance threshold. The business scenario made sense, and the implementer was within their right in deciding that disregarding exp in those circumstances was acceptable. Nonetheless, I would not argue that given the existence of that scenario, rfc7519 should turn its MUST NOT into a SHOULD NOT.
There might be circumstances in which the stars align and it is safe for a client to inspect the AT, but in the general case that’s not true (this has been covered in details in the various threads on the topic). Also note, the fact that the client (as the application code) is banned from doing that inspection doesn’t mean that the solution as a whole cannot do it. Developers can examine network traces, or use any other mechanism available in their particular circumstances to inspect traffic that are out of scope for this specification, and that would give them in practice the oversight discussed here where possible. The specification doesn’t aim at preventing that inspection in general, but it does aim at ensuring that the ability to do perform that is excluded from the contract between the roles described in OAuth2, so that any violation is either understood to be high bar, or the logic meant to perform those checks is implemented outside of the client code itself, preserving the protocol invariants and protecting developers from one of the most painful production issues I have observed in many years of real life use of JWT ATs.
Ultimately, the latter part is one of the reasons for which I have a hard time relaxing this part, whereas pretty easily relaxed constraints on other areas where my initial position was more strict (multiple resources in audience, etc). I know this to be very painful if not addressed correctly, and the only arguments against it appear to be more about principle than about concrete scenarios, expressive power or security.

From: Jared Jennings <jaredljennings@gmail.com>
Date: Monday, May 11, 2020 at 06:30
To: Denis <denis.ietf@free.fr>
Cc: Benjamin Kaduk <kaduk@mit.edu>du>, Vittorio Bertocci <vittorio.bertocci@auth0.com>om>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

If I may, step in and offer a suggestion.

What if instead of "MUST NOT" replace with "SHOULD NOT"?

To me, (and this might be me), but MUST NOT describes a violation. As in I broke the law. Conversely, I interpret, "SHOULD NOT" as a recommendation, a guideline, best practice, etc.

If then the sentence went on to explain why you should not inspect the token, the risk is therefore known and on the "implementer" of the inspection.

Jared


On Mon, May 11, 2020 at 7:34 AM Denis <denis.ietf@free.fr<mailto:denis.ietf@free.fr>> wrote:
Hi Benjamin,

We are making progress since we now understand better each other. You wrote several sentences on which I agree:
"I do in fact agree that token inspection by a client can be useful in at least some situations".

"I fully support having privacy considerations sections that discuss the privacy properties of the protocol in question,
  even including aspects that are currently lacking.

"I do not believe that a JWT profile for OAuth use is the place to make changes to the core OAuth protocol that improve its privacy properties".
I also accept your apologies.

RFC 6749 is quite clear in section 1.4 that "The string [access token] is usually opaque to the client".
However, it does not mean that : "The client MUST NOT inspect the content of the access token".
I believe the wording I proposed corresponds to the reality:
There is no guarantee that token inspection can always be performed.