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

Dick Hardt <> Wed, 19 July 2017 10:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D873C131CA3 for <>; Wed, 19 Jul 2017 03:53:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 0kT682owmv63 for <>; Wed, 19 Jul 2017 03:53:06 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7E8C3131A78 for <>; Wed, 19 Jul 2017 03:53:06 -0700 (PDT)
Received: by with SMTP id b40so38020476qtb.2 for <>; Wed, 19 Jul 2017 03:53:06 -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=yApXFyfb7+klhw+za2a2/f1W2aKxGL55OJxBYFYvxjo=; b=ntDOPQzD2Fn6vlsz2bqmwz+Hr3Ymk/g6ew36dxbPWbL+/ErWu+Z3Iii7sfQuQCRUyb sjEJsXMbrG3Izk3SZ58BdlVMMzovA9H/iW4KmYAfBo/zPgysbvmn1/7K7avYgkQGrAn3 92f6SAwyFvolzwFqdt9DvkLi1uFLLOYtmbc0/QMvJfNGAXvofOvfNGGSxtPHaS8ZymAy mJ71rvTCaUSUTd1XM/7BLkonOsYRQujpYYzTtH0ETfjLzT0h6yezRuVd1JB+6iUwhThj BaddUkvCPLdugsAxQ56yNUoDG5q0vAqX7mU5f9SL7Iz3LsnPxM+W8SOl//qgtKaxvUK+ Ch5g==
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=yApXFyfb7+klhw+za2a2/f1W2aKxGL55OJxBYFYvxjo=; b=UUcwH+3J57dskasvDbWFZUYsYgw4KHonyAw3MkvHuzkD3UwDg2Gf3wV9OcTnu6/Q8M X8i8aV5SeGpHZ4sHmzGcnTfL/Ophhw9kjIv6xVuYmbri/d6vDh/IGvuCbOW6ZtkKb1cZ Z5fFQ19DMsfZCVPB+55Sn48PUxLs7Q0URUoeNCMi2pDZHDrALVmI/vDFJYNdXMGE6GhL 6hs4LwbPVltm+fmKn8Cocgo0Yi59ztWjqf9K3MGEeFtSsMmS/uKC/gcICt47PmGzYlLg 24XWI0Zo0k6ygtFq5YQJkeLuB6h4oFw+zEsIgyTFof4cw5oVmHK9edlnGgDIRUS0tbwF mybA==
X-Gm-Message-State: AIVw111eUN6bzxNFVAtdXBFzXq+to8J63q5RPTFiGmAyz1O7EzAj/its TUJsHvMWMKRmpVnszXxl724ecuBUIA==
X-Received: by with SMTP id b1mr2272127qkd.76.1500461585646; Wed, 19 Jul 2017 03:53:05 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Dick Hardt <>
Date: Wed, 19 Jul 2017 10:52:55 +0000
Message-ID: <>
To: Justin Richer <>, Mike Jones <>
Cc: "<>" <>
Content-Type: multipart/alternative; boundary="94eb2c05ff5acfcfc70554a96f29"
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: Wed, 19 Jul 2017 10:53:09 -0000

Thanks for the feedback Justin. Do you have any specific wording?

On Tue, Jul 18, 2017 at 6:34 PM Justin Richer <> wrote:

> 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.
> Thanks,
>  — 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
> _______________________________________________
> OAuth mailing list
Subscribe to the HARDTWARE <> mail list to learn about
projects I am working on!