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

Brian Campbell <bcampbell@pingidentity.com> Thu, 27 July 2017 18:50 UTC

Return-Path: <bcampbell@pingidentity.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 418CF1320CD for <oauth@ietfa.amsl.com>; Thu, 27 Jul 2017 11:50:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id cNwgq_PlZSqg for <oauth@ietfa.amsl.com>; Thu, 27 Jul 2017 11:50:29 -0700 (PDT)
Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 519AB1320D3 for <oauth@ietf.org>; Thu, 27 Jul 2017 11:50:28 -0700 (PDT)
Received: by mail-pf0-x236.google.com with SMTP id e75so8571003pfj.2 for <oauth@ietf.org>; Thu, 27 Jul 2017 11:50:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to; bh=AGV8lNuZMlSJvBhNn1opB4HDTBLBuGCi0M1VXnxMv48=; b=Pizl4/Q8s57Q0QQSjWypPCivU2zAoYXlyCeSDJuNOa6iJOptGBJIzQLo5n0FS/uJBR BxRZ7eRU3xmZa92W4Kc1OceD48h/Ugg7f2pWrazrj+y6F6VFku5o/yt2VIaXuCN+ZF0C cRcu4xZbwMTyjbSTbzR42OE6hlpgHF9F2tGmY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=AGV8lNuZMlSJvBhNn1opB4HDTBLBuGCi0M1VXnxMv48=; b=i+cOuJjLCU67Z5hpNwiFBwMtlpL2QUXme+xCX4kg/mg+WhXlYNrHUJ4tKIrdlQhPvt HVubtoQMmQ8zImkSjnpoxsbGiRiv4VOmlDTqxBf0aAtNYfWYuPTjiyCAr5bf1XXDXs2U cz/jXjIQzJpcyIGHai0K0aGCr5YMr3tgUDO7SGRnk5LI88Gl30eHX7JeGqUf0L9ROZG6 F9UODA9e3sbVhK+ZTqSunmcLOqZq0ucwyavwpPnN6Budz4mzvCXqUc/tSRFwHPmLcIIr yzz8R4qhgs8KtFL13x1ADf70oSKovKV7IvdzfEMXWVreq3YpghsM/os0FWb2ZL7pSEkV yAPA==
X-Gm-Message-State: AIVw113mmxGUyFXBWkW+Okk2KTbprFdfNJ30vn+R4uSmzvpyW9kOhj5l rqFKokVx4PtESyzSve653AiFtpu4HkqDmr0jPaf1qh0MXv7wVhxXhL2OZC1V6LDV6jnCaadGhg4 4SVT5S1c=
X-Received: by with SMTP id i15mr5409741plk.248.1501181427707; Thu, 27 Jul 2017 11:50:27 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 27 Jul 2017 11:49:57 -0700 (PDT)
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Thu, 27 Jul 2017 12:49:57 -0600
Message-ID: <CA+k3eCRT_iuLHYrLxz+tf1MT9L9XG2jV0D0anC0h5w7A_ujEdQ@mail.gmail.com>
To: oauth <oauth@ietf.org>, "jose@ietf.org" <jose@ietf.org>
Content-Type: multipart/alternative; boundary="f40304361ef4be0b9d05555109bf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/LdomtTkRKeTeBVf95-Q446RSToQ>
Subject: [OAUTH-WG] preventing confusion of one kind of JWT for another in JWT BCP
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jul 2017 18:50:31 -0000

During the first WG meeting last week
<https://datatracker.ietf.org/doc/minutes-99-oauth/> 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
<https://tools.ietf.org/html/draft-sheffer-oauth-jwt-bcp-01#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 <https://tools.ietf.org/html/rfc7519#section-5.1> strongly suggest
that it's not currently being used for any validation.

Alternatively using the JWS/JWE "crit" (Critical) Header Parameter
<https://tools.ietf.org/html/rfc7515#section-4.1.11> 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.


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