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

Jared Jennings <> Mon, 11 May 2020 13:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6CDF23A0ACD for <>; Mon, 11 May 2020 06:30:16 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ruMn32yCQoEt for <>; Mon, 11 May 2020 06:30:14 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::62c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5CD9E3A0AC8 for <>; Mon, 11 May 2020 06:30:14 -0700 (PDT)
Received: by with SMTP id z5so7103015ejb.3 for <>; Mon, 11 May 2020 06:30:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Kx0DFgBRR7YZp58mIOoMP06TGTWUw1A7YdDOq6SjBH4=; b=svZmaP8LNSw08S1LN8G52xWJ9DfL7Jgun2wjHtlWo9O6rR9/NF23Tv8bHkzTiDAt6y nKFWDhbO8d2g8C7Jd98tdg4gp01AqU/2CTo/+hHFoTmDTkmgQtDGfY6skWtjEU0llxv9 +qwij7kS1dlmpaNyvIdMOcZCc0uzTCneIcRp0qCZZNIRe+MrJRkNmoR9U0P/6ngnju7P pm1Kdj7Ne+STmFoTi0cp09af/UCwQoOJchGrI4D20ZshCXqQ0cCJv2R8Ccma/jvc5ktL cQsS/pCGsYQRCPfdCCMX7Actp7ic9cGNz/+8/X8yDwFT2EsIcU2OdGA1kW2baF01+bC3 4Siw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Kx0DFgBRR7YZp58mIOoMP06TGTWUw1A7YdDOq6SjBH4=; b=Bal1JlIouCZMDjNNaiWTFM8zYMWFyQ0P3DwN/QRAgut7uAcR+sbKMSQA+SN/nldbmq 7R+syOMRneY57UusSXArMwAZ/Q/84rrwpY31YdOXab8tfiH5Xcr3R6+C+m/B4X+WDap9 Q2eoVonpUeQKZAqBLj1zRAriq8MGdjSpiYINwC4zJhLcQFKLJwneK05RSTBHuFCJyDJQ +HtG5/ZPxWHRPaUgXXBffyA+9/aXviTwj4hDAoHsnLon4rVjogE7/0xy5JgdA9GQPS/7 UEwwK9xvfH/j/qn50oddQw0Gno69kq4Yg28UfBRDIef/PUHh64sTClUArzS39xOswjj9 GHYw==
X-Gm-Message-State: AGi0Pua8Zx3hd85OnONPRKlI9PNgFgY+E4GuLh8rzuXIXNk6WLFfTjtS DK+cHuqxywNCIIZ4HiI5DcYkmZYlwQz2DvHiSz4=
X-Google-Smtp-Source: APiQypJYPtZ70D/DWEPVpOCnVZqGwocI7pIOrbaMxunE60cWZS1iizxIt7EkOKjVuezj2AyIQr/9rYtm3Pm7iT+044g=
X-Received: by 2002:a17:907:4272:: with SMTP id nq2mr13624642ejb.205.1589203812461; Mon, 11 May 2020 06:30:12 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Jared Jennings <>
Date: Mon, 11 May 2020 08:30:01 -0500
Message-ID: <>
To: Denis <>
Cc: Benjamin Kaduk <>, Vittorio Bertocci <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000b7b20c05a55f58f7"
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: Mon, 11 May 2020 13:30:17 -0000

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


On Mon, May 11, 2020 at 7:34 AM Denis <> 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,
>   *e**ven 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 opaqu**e* 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.