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

Vittorio Bertocci <> Tue, 12 May 2020 05:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E70793A0C3E for <>; Mon, 11 May 2020 22:40:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 37Z3_io_Ecwn for <>; Mon, 11 May 2020 22:40:34 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::102d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0C88F3A0C3C for <>; Mon, 11 May 2020 22:40:34 -0700 (PDT)
Received: by with SMTP id z15so229314pjb.0 for <>; Mon, 11 May 2020 22:40:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=VmYvgYJxliyxf1+Wm0HLacK+UvaH2uH+/nUWBGRCSZQ=; b=qLtXRz15xHvrBVC+ib2boCswVNRiSGC7PShLFIyomsn83513FIzZ8B7m77Ba0QjLAG NlgR3FJtjk6aFApzpbP0JRXK7gmQtSjZJ/u71Yht9Zd5832HNoM0WrA5rPQedop5Hhkc +izUdy3pPk1nAzBmRXvCo1Vr6+VTzf3Iz5NMA9j5+pYV4+K3LoekhKjAHVuK9WFVxVnj xhI6aJrzPRSbVDHOfoTXAXRfNUvTTVFGKG2xvlwGAyTaXkctkMxE458w5kxhrA3Z12DE NywckzLy8RToK2Zji2e/y5ef55UJWaLCiFrk+nyBzl02sIbP33joLDbfvPIDWhmIjbDa iYRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=VmYvgYJxliyxf1+Wm0HLacK+UvaH2uH+/nUWBGRCSZQ=; b=Gnm3Gib4Insm7iXygUXHPH5VftEwsSld6z41gCquix8DBOkXmYrxbdUe+TcwXGGMRx KTIjES+0+MnbH4uRUGDoGgv3GqZkvng2LpfdDnU+9HqjxHmpSqILr8KOCQVcmP5+Ze0m oLK5qm+4t3GSXVHEc6mL96gSadtsgf5SoeAjSmqrNp4uQsW61X/YZhnJxsmYvYSfmD6T lgfgzGKn0vEG/J8cf6aZw3YsmwiYtXQHy4RxttNdseKGQPvfRYj2fug8KAl8LvdX81o8 bvQrbCgFxUqYkCnMOPfMZTMBYWv7wEw+puYLU8inTZjiov1LxJfY+8gq5VkgXsB31pxC EJMg==
X-Gm-Message-State: AGi0PuYIBraryeWewzkVgw4cPgdQtBBYqz2Op8MK/dT1PKM2COZjFngT x9JecJqxMfzgXaqSyaAyCXfWZA==
X-Google-Smtp-Source: APiQypLfjCr8/b+ihmJ9M7cyaRFOenPLz95JcCtN1irOYe8fxedYbWTDnCJ3YqKnzZHVt4JsN1k5jA==
X-Received: by 2002:a17:902:8496:: with SMTP id c22mr18711180plo.182.1589262032989; Mon, 11 May 2020 22:40:32 -0700 (PDT)
Received: from ([2603:1036:120:1d::5]) by with ESMTPSA id q6sm10722515pfh.193.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 May 2020 22:40:32 -0700 (PDT)
From: Vittorio Bertocci <>
To: Jared Jennings <>
CC: Denis <>, Benjamin Kaduk <>, "" <>
Thread-Topic: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
Thread-Index: AXdwTzB4ofd1XzKTR3gsOll1nC4/fDAxQjMxu+3udACAACjKQw==
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Tue, 12 May 2020 05:40:30 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Exchange-Organization-SCL: -1
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_MWHPR19MB15018666981170A2DAA7B0D7AEBE0MWHPR19MB1501namp_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 May 2020 05:40:36 -0000

It’s not really an interop issue either, given that following or not following this requirement doesn’t alter the shape of messages or tokens. It’s more of an architectural requirement, which preserves the relationships between the OAuth2 roles involved and prevents the confusion that might arise by the availability of data that characterizes this particular scenario, but that doesn’t change the more general premises of the protocol. In terms of finding common ground, I am not sure if visions as diametrically opposed as pitting a MUST against a MUST NOT have much of an achievable common ground, especially given that the MUST NOT stance already passed consensus in the past year, and in more than one month of very public debate during last calls, the MUST side had mostly one backer and more than one opposed.

From: Jared Jennings <>
Date: Monday, May 11, 2020 at 20:14
To: Vittorio Bertocci <>
Cc: Denis <>fr>, Benjamin Kaduk <>du>, "" <>
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Hi Vittorio,

Yeah, this does make a bit of sense. So, the goal is to guide implementors from making bad choices, not from a security perspective. Meaning, it's not a security risk that a client does inspect or analyze the token. Instead, it's is an interop issue and thus we are guiding implementors to never assume or expect the token format to be consistent or of a expected format, for various reasons. I kinda know the answer to this question, but I am kinda asking this way to help restate the intent of the "topic" and maybe help guide to a wording that works for everyone.

For example, as a consultant, it can be very helpful to know how to decompile or inspect an "Object", but at the same time knowing that such a method or practice should never be used in production.


On May 11, 2020, at 19:24, Vittorio Bertocci <<>> wrote:

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 specin 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.