Re: [OAUTH-WG] [jose] preventing confusion of one kind of JWT for another in JWT BCP

Nathaniel McCallum <> Thu, 27 July 2017 19:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 019D0131CD7 for <>; Thu, 27 Jul 2017 12:31:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.419
X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hWfSc397JR95 for <>; Thu, 27 Jul 2017 12:30:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E1A29131C31 for <>; Thu, 27 Jul 2017 12:30:57 -0700 (PDT)
Received: by with SMTP id v205so71038282itf.1 for <>; Thu, 27 Jul 2017 12:30:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cxqnsmY86lDsmVHlQ4LcmGoFHKwPin2R2bfMlQxKjVE=; b=tG+R/AHasJf1rfCv4xoLk57KLtas2djKmubE9QBulimpnyvIxBlUHsg4lM2YehxgQp 4phD5pGfGoYuNYGW7yngVAmtAMbNnOzQevQOepC1gpuMslVRgjEjH5er1uIJPkBDMuIq rENCTpMdFMvm+eMwEEt1MrZBa5hZtj7iINwLahpPHy/rj7233UzVqdadsulG9X9wxXqW i0/hC2XrHkGb8vrhfLXRZ4EHaZA9TVruX+AN6NgGbJlyfGR01e2B0RnjFzFDlHl/Eg2I /vohoHnEicE9fFZFr1ucJqMYKHcabAiTP9+cPt4/jNBF+FIDxdVig81SOcE1lwEGMxkf 3SYg==
X-Gm-Message-State: AIVw112MVpN62FeGmZerPezuT6kLR1cqbwuw9oRNj+1VtXn7E/M3hqYk zsjGU5+tXANBKUOgNK6luLhI9q5ug/T93us=
X-Received: by with SMTP id w14mr6557593ite.76.1501183857107; Thu, 27 Jul 2017 12:30:57 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 27 Jul 2017 12:30:56 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Nathaniel McCallum <>
Date: Thu, 27 Jul 2017 15:30:56 -0400
Message-ID: <>
To: Brian Campbell <>
Cc: oauth <>, "" <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [OAUTH-WG] [jose] preventing confusion of one kind of JWT for another in JWT BCP
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: Thu, 27 Jul 2017 19:31:00 -0000

What class of attacks is this trying to prevent? I frankly don't see a
problem with confusing different types of JWT. But I may just be

On Thu, Jul 27, 2017 at 2:49 PM, Brian Campbell
<> wrote:
> During the first WG meeting last week I asked if use of the JOSE "crit"
> (Critical) Header Parameter had been considered as a recommendation for
> preventing confusion of one kind of JWT for another. Time was running short
> in the meeting so there wasn't much discussion and it was requested that I
> take the question to the list. And so here on the list is that.
> Section 3.9 of the JWT BCP draft now recommends explicit typing using the
> "typ" JWS/JWE header parameter but does concede that 'the use of explicit
> typing may not achieve disambiguation from existing kinds of JWTs, as the
> validation rules for existing kinds JWTs often do not use the "typ" header
> parameter value.'  And the recommendations for how to use the Type Header
> Parameter in JWT strongly suggest that it's not currently being used for any
> validation.
> Alternatively using the JWS/JWE "crit" (Critical) Header Parameter to signal
> the type/intent/profile/application of a JWT could achieve disambiguation
> even in validation of existing kinds of JWTs. The critical header lists
> other headers which must be understood and processed by the receiver and
> that the JWS/JWE is invalid if those listed aren't understood. So a new
> type/profile of JWT that uses the "crit" header would produce JWTs that
> would be rejected even by existing applications of JWT validation (that
> actually implement "crit" properly anyway).
> The JWT BCP could suggest the use of "crit" in conjunction with a
> profile/application/type specific header. Or it could provide a bit more of
> a framework like defining a registering a new JOSE header "p" (strawman of p
> as a very short name for profile) and create a registry for its values. A
> JWT header using that approach might look like the following where the value
> 1 is registered as some cool new JWT profile/application. The consumer of
> such a JWT would have to understand and process the "p" header, which would
> mean checking that it had the value expected.
>      {
>       "alg":"ES256",
>       "crit":["p"],
>       "p":1
>      }
> A JOSE compliant JWT validator would reject such a JWT even for an OAuth
> access token or OIDC id_token because the "p" header isn't known or
> understood but is marked as critical.
> To me, that seems like an approach to preventing confusion that has more
> teeth than the "typ" header. Which is why I asked about it last week and am
> now bringing it to the list.
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
> material for the sole use of the intended recipient(s). Any review, use,
> distribution or disclosure by others is strictly prohibited.  If you have
> received this communication in error, please notify the sender immediately
> by e-mail and delete the message and any file attachments from your
> computer. Thank you.
> _______________________________________________
> jose mailing list