Re: [OAUTH-WG] Secdir last call review of draft-ietf-oauth-access-token-jwt-11

Joseph Salowey <> Thu, 25 February 2021 02:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5E7683A0C7D for <>; Wed, 24 Feb 2021 18:10:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0tWQzLCFjdpn for <>; Wed, 24 Feb 2021 18:10:52 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3F7B53A0C6D for <>; Wed, 24 Feb 2021 18:10:52 -0800 (PST)
Received: by with SMTP id w36so6197059lfu.4 for <>; Wed, 24 Feb 2021 18:10:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=48YcDm9c/I0Gs87VMmNMcSN0unJHvvNeyXB+nXJk8TY=; b=buEq94Kp/+1bWD5QZGMN0HfoyKu2Dhtug4cR1p0F8ZeXWAfvPefj/9PjjzJqC1hz/C ULprzXUCEOjrBf9hzcARoZ4roUC9c5cyXju0VDmXCQOxtMVGNN3hcQpyYalaUoyx6px7 s83AZNSiAVKtIbxuZxoXsFdqCPHZLJBN+vQ6fKEANVbZtISN209GLylEEuT4c+mJXFpy JB6gQasK9fvS7cA7MD+IoQBQonkkx2d2H/WznAhCTfSzrGTjq9WW8haRdzqNjK6rflhQ GZji4m0ePgw5DfVj+Rsc+VR0w4+s9nsJ7gXVnlkXe+ijbwvBKeFJp9p/HlXjqjgiJp6u FjIA==
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=48YcDm9c/I0Gs87VMmNMcSN0unJHvvNeyXB+nXJk8TY=; b=QdPWErGGVe/QnGNOJKzXC1Ns2J2MUSrLmmlAOOIP3uLFNf2hPBYEm4sC2m1013W6GT kUSH54DpQkICbwkl3IjGfvE7gV7D7jOJX3Hv6sC3L57/7Maj5rxfcit130Z7KnHxDVTq fOFlY2euUvwzd0pne6KzOpFVJQru02Q2ij+3nfmd0MOiX44qcC5ep5ynN+5CZXhEi9Rk fNo7Q6Un2ZMtjESGQ2ouwf5OCqstsyR55XQ9Q2ZpxlOPb22ZZdXNwDtyL8anpzEg0Q+d L53snCim9e3xhbchCuBZlnpcz+hLgB0S8vqlsP0ZhzFC4ZCDfsDzmdgee0ov+RuKRNdu vt8A==
X-Gm-Message-State: AOAM530INcFaR0Eh7nRLBispC9C1UbFiZc9Mm3ZiQpqlL7HmFrcHPuWZ f0rMFXWX15M5mlnapUOPFhZikHlCpAp3t+p6bmlLUA==
X-Google-Smtp-Source: ABdhPJz5kgxz0lVvkNg/TN+lKBGTnghmLz0AgCUVWLqBqV3vWnnMM028RvxI7Vivr9/uLz7wl38thPnFLPh2H/rykl4=
X-Received: by 2002:a05:6512:38ce:: with SMTP id p14mr533458lft.428.1614219050457; Wed, 24 Feb 2021 18:10:50 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Joseph Salowey <>
Date: Wed, 24 Feb 2021 18:10:39 -0800
Message-ID: <>
To: Vittorio Bertocci <>
Cc: "" <>, "" <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="00000000000017aaba05bc1fa905"
Archived-At: <>
Subject: Re: [OAUTH-WG] Secdir last call review of draft-ietf-oauth-access-token-jwt-11
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: Thu, 25 Feb 2021 02:10:54 -0000

On Sat, Feb 20, 2021 at 12:42 AM Vittorio Bertocci <> wrote:

> Thank you Joseph for your comments!
[Joe] Thanks for your response, comments inline below:

> > 1.  (Editorial) What is the relationship between this document and RFC
> 7523.
> >   They are using JWT for different purposes, but I think it would be
> useful to
> >    clarify this in the introduction.
> Good point, I agree it would be good to preempt doubts on this. I am
> suggesting to append the following language to the current introduction
> (pardon the XML).
> Please note: although both this document and <xref target="RFC7523"/> both
> use JSON Web Tokens in the context of the OAuth2 framework, the two
> specifications differ in both intent and mechanics. Whereas <xref target="
> RFC7523"/> defines how a JWT Bearer Token can be used to request an access
> token, this documents describes how to encode access tokens in JWT format.
[Joe] Yes, that looks good to me.

> >    2.  (Issue) The specification does not specify any mandatory to
> implement for
> >    the recommended asymmetric algorithms.  This will not help interop.
> Perhaps
> >    specify one or both of  "RS256" and "ES256".
> The current text doesn’t mandate a format for two main reasons:
> - thanks to the AS metadata the negotiation between a RS and an AS is very
> easy to perform, hence the likelihood of interop issues at runtime is very
> low
> - worries that as crypto advances, what we mandate at this point might no
> longer be suitable.
> That said, if you feel strongly about this please do let me know, and I
> will be OK with adding RS256 as a mandatory supported alg for both AS and
> RS.
> From a cursory check, ES256 doesn’t seem to enjoy as widespread support at
> the moment (see libraries list) hence I would be hesitant
> to make it mandatory.
[Joe] I think you should add RS256 as mandatory to implement.  Since RFC
7518 does not mandate an asymmetric algorithm it's possible that two
implementations make different choices on which one to support.

> >    3. (Question) Is it currently possible to use the JWT access token in
> a mode
> >    other than a bearer token?  For example is there a way to bind the
> JWT to a
> >    verifiable key or identifier.  If there is, there should be some
> discussion of
> >    this in the security considerations.  If not, do the authors know if
> there is
> >    any work planned in this area?
> At this time, the main mechanisms that can work with non-bearer ATs are
> dPOP and MTLS. In both cases, the binding mechanism relies on a cnf claim
> (or reference to it) - which can be added to a JWT access token without
> changing any of the guidance in this specification. There's a quick primer
> for both approaches in
> Given that
> there are no changes in the AT format and verification, and MTLS/DPOP would
> be purely additive, any language here would likely be functionally
> equivalent to "You should be aware that MTLS exists, and the tokens defined
> here do not break it" (DPOP isn’t mentioned because it's still in progress)
> but my intuition is that the compatibility should be assumed, with a note
> being required when it's not the case and the reader should be aware of
> potential problems. What do you think?
[Joe] Thanks for the explanation. I don't think there needs to be anything
added to the document for this.