Re: [OAUTH-WG] JSON Web Token Best Current Practices draft describing Explicit Typing

Justin Richer <> Tue, 18 July 2017 16:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0A9DD129B5E for <>; Tue, 18 Jul 2017 09:34:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id V-_tDfpVkQKj for <>; Tue, 18 Jul 2017 09:34:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BAC6712700F for <>; Tue, 18 Jul 2017 09:33:59 -0700 (PDT)
X-AuditID: 1209190c-967ff70000000780-ac-596e38754ac3
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id C9.64.01920.5783E695; Tue, 18 Jul 2017 12:33:57 -0400 (EDT)
Received: from (OUTGOING-AUTH-1.MIT.EDU []) by (8.13.8/8.9.2) with ESMTP id v6IGXuS1007161; Tue, 18 Jul 2017 12:33:56 -0400
Received: from artemisia.richer.local ( []) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id v6IGXsxW011330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 18 Jul 2017 12:33:55 -0400
From: Justin Richer <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9E90D9F9-4904-4536-B6EA-F4B0C6F303B4"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Tue, 18 Jul 2017 12:33:54 -0400
In-Reply-To: <>
Cc: "<>" <>
To: Mike Jones <>
References: <>
X-Mailer: Apple Mail (2.3273)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPKsWRmVeSWpSXmKPExsUixCmqrFtqkRdpMHGGtsXeaZ9YLE6+fcXm wOSxZMlPJo/WHX/ZA5iiuGxSUnMyy1KL9O0SuDL6F21gLuhPr7jwdQNbA+OLyC5GTg4JAROJ F19msHQxcnEICSxmkmiaN4cRwtnIKPF/wnJGkCohgYdMEq37ykFsNgFVielrWphAbF4BK4ml nZdZQWxmgSSJRU93A9kcQHF9id7nYK3CAgkSj691g5WwALXe/X+dBcTmFIiV2L4eZAwHUKu6 RPtJF5CwiICOxOOL39ggtsZIzDpwmx3iTlmJW7MvMU9g5J+FZNkshGUQYW2JZQtfM0PYmhL7 u5ezYIprSHR+m8i6gJFtFaNsSm6Vbm5iZk5xarJucXJiXl5qka6hXm5miV5qSukmRnBIS/Ls YDzzxusQowAHoxIP7wqOvEgh1sSy4srcQ4ySHExKorxblYFCfEn5KZUZicUZ8UWlOanFhxgl OJiVRHjztIByvCmJlVWpRfkwKWkOFiVxXgmNxgghgfTEktTs1NSC1CKYrAwHh5IEb5I5UKNg UWp6akVaZk4JQpqJgxNkOA/Q8AaQGt7igsTc4sx0iPwpRnuOTTN+fmPieDXhP5A89PvEdyaO YyBSiCUvPy9VSpy3wgyoTQCkLaM0D24yKF0lvD1s+opRHOhRYd4IkOE8wFQHN/sV0FomoLXC vjkga0sSEVJSDYz2a9xm3dm3/Xvx1o/zH3Kd+HPQ8Nf//z51yUqzVmjoe021mrSubIJOx1yp Ozs9ubrZuy58/Js3J/77EeP71TrfJs/ec6UnZs22Nek3frRN4Hl4RthP5O1+kWM7dv2QsQs6 XBG+pKlJLurOtot8z9JmGVtypTK+qWLMe3ZaRPduI5ezosaGdXFrlViKMxINtZiLihMB5VQe fjIDAAA=
Archived-At: <>
Subject: Re: [OAUTH-WG] JSON Web Token Best Current Practices draft describing Explicit Typing
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Jul 2017 16:34:02 -0000

Mike et al,

Overall, this document has some really great advice for people who have chosen to use JWT in various situations. It’s a needed draft and I’d like to see it go forward. I have some suggestions on how it can be improved.

In this draft, I’d like to see some more discussion about privacy and security issues around choosing JWTs to begin with. Namely, putting things like subject identifiers and scope/permission information into the JWT structure could potentially leak information about the end user to the client, if the JWT isn’t encrypted, and to multiple RS’s, if the JWT is encrypted with a shared key. It basically amounts to “anyone who can read the JWT can see what’s in it”, which on the one hand is obvious, but on the other hand it’s not always considered by implementers. Since the audience of an access token JWT is the RS and not the client, and the token is opaque to the client, it’s easy to assume that the client *won’t* read the token. However, that doesn’t mean that it *can’t* read the token. It’s a tradeoff in design space with other solutions.

I’d also like to see a discussion on expiration and revocation of self-contained JWT access tokens. Again, this is targeting the decision space of whether or not a self-contained token is an appropriate solution in the first place. If I’m issuing JWTs that are completely self-contained, I can’t revoke them once they’re on the wire. Yes, that’s an acceptable risk to many and that’s fine — but I would like this document to encourage that thought and discussion. 

 — Justin

> On Jul 4, 2017, at 3:43 PM, Mike Jones <> wrote:
> The JWT BCP draft has been updated to describe the use of explicit typing of JWTs as one of the ways to prevent confusion among different kinds of JWTs.  This is accomplished by including an explicit type for the JWT in the “typ” header parameter.  For instance, the Security Event Token (SET) specification <> now uses the “application/secevent+jwt” content type to explicitly type SETs.
> The specification is available at:
> <>
> An HTML-formatted version is also available at:
> <>
>                                                        -- Mike
> P.S.  This notice was also posted at <> and as @selfissued <>.
> _______________________________________________
> OAuth mailing list
> <>
> <>