Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens

Vittorio Bertocci <> Thu, 14 May 2020 14:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6D4B53A0AA2 for <>; Thu, 14 May 2020 07:55:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 UfiCDLYVbEBW for <>; Thu, 14 May 2020 07:55:11 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 63E6C3A0A96 for <>; Thu, 14 May 2020 07:55:11 -0700 (PDT)
Received: by with SMTP id g4so3871557ljl.2 for <>; Thu, 14 May 2020 07:55:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=mHetsZlfGgGKtPt3BFw40YsaeTpRs5PNzeKKNZ+QtJw=; b=lFRUYlkWDOxJ7GnllroG5aRiGdDqCEdclW6XvvGubsW3eEjJ/u+33DN4oLm/kWpihl UOtS+mw8cTa9yg9UcZMMAOdepeFj/9+uQ5/VufIO/4Yj71+qVPmtVEf7BvFpndMKnizC LxDIJXohKSKT7xGvqOlJaNmCfK+FE6D+r+GIfdkxa7R4BT45CU/xhET0gb0PX0iyC6Kg YNJbRefXajKFixxl/CONr5/LkeuADl7fw5fR5nGen8ca9unm7nHPvpiNmjMF6XcDpQAx FKWKD+UxGg4JyJBIIUKgeXTgvB5eCxxDgQA4Tv/gXN6eySiPxUIZ6eqPKyGNuR3YJiEY p2kA==
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:reply-to :from:date:message-id:subject:to:cc; bh=mHetsZlfGgGKtPt3BFw40YsaeTpRs5PNzeKKNZ+QtJw=; b=lYvwXaEYf/HXnmhZnPaTOvwfsMIgCVMlXvrtYM07eMIQWc7/lUN102NnRdPFZ62RfG Po7jIuFJq0wMb4+m0JyRu608kc73BFBwjyWgjn4zlDTGwrklGhwtkmxNusXNmmc+JWsm izTPJV+X9JnAHCIo6To4fUMVZprvSBia4mApslrE2x8BMcXk8HY56enVLy6ISBW3mKoI 1SBNVkWmkDuryx8qmiRlJpfUITGwOA0MOI7z5cWqJFXvrFox/kBItgIhdHgR1jyYxEJS 22XeKWxTw5LgJxMyM+soXOVXxbr25SEwvzImOsYyMU2OTCNc34MKhTqxVwtQPrOO7gOQ ntng==
X-Gm-Message-State: AOAM532ugMw/2gbVZXXKqeweanDqR4CEVSO95qQuJXqGgJn92Xd6pH8K T8bmhGvOVs0wxwRRaefFFMcAAMM3wf83+vWi1odQ9Q==
X-Google-Smtp-Source: ABdhPJwUetiLANRnsGSitwccnIFtH3DdUYMOtybcgaMgSDaJrAGR/7KODhey9/TkpOmHsYL/kJ+oqhXJ8+jF/h/S0l4=
X-Received: by 2002:a05:651c:112c:: with SMTP id e12mr3074583ljo.127.1589468109115; Thu, 14 May 2020 07:55:09 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Vittorio Bertocci <>
Date: Thu, 14 May 2020 07:54:57 -0700
Message-ID: <>
To: Denis <>
Content-Type: multipart/alternative; boundary="00000000000006acc105a59ce2c4"
Archived-At: <>
Subject: Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
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, 14 May 2020 14:55:15 -0000

Denis, the change you mentioned is basically a typo, which I did fix but
did not publish a new draft for- that doesn’t change the substance of the
consensus (and is something that will be fixed in the subsequent phases of
the process).
Whether the sub should be mandatory has been discussed for two reasons:

- as a way of distinguishing whether the token was obtained on behalf of a
user or an application identity, by omitting it in the latter case. We had
extensive discussions following IETF105 and concluded that not enough
people were interested in that scenario. I kept that discussion open for a
long time.
- for privacy concerns. Those has been debated and your position failed to
gather momentum.

Some of the recent discussions on sub didn’t pick up on the discussions
above and didn’t bring new arguments that weren’t already debated.
Nonetheless I did my best to provide context and pointer to the past
discussions when answering the concerns. In other words, those discussions
didn’t appear to change the consensus achieved on the matter. We have 3
last calls, I don’t think the chairs changed the status of the document

On Thu, May 14, 2020 at 07:29 Denis <> wrote:

> The current version of this draft is
> "draft-ietf-oauth-access-token-jwt-07" issued on April the 27 th.
> This means that comments sent later on on the list have not been
> incorporated in this draft.
> In particular, this one sent on April the 28 th:
> *1) *The title of this spec. is:
> JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
> So, this spec. is supposed to be targeted to OAuth *2.0. *
> However, the header at the top of the page omits to mention it.
> Currently, it is :
> Internet-Draft       OAuth Access Token JWT Profile           April 2020
> It should rather be:
> Internet-Draft       OAuth *2.0* Access Token JWT Profile           April
> 2020
> It has been acknowledged by Vittorio on April, the 29 th:
> *> The title of this spec.*
> Fixed, thanks!
> This means that the draft document currently available on the IETF server
> is not reflecting the agreed comments.
> Since then, I questioned myself how a client would be able to request an
> access token that would be
> *strictly compliant with this Profile*.
> For doing this exercise, I took a look at section 3 on pages 6 to 8. To
> summarize my findings:
>    - the request MAY include a "resource" parameter. If the request does
>    not include a "resource" parameter,
>    the authorization server MUST use in the "aud" claim a default
>    resource indicator.
>    - the request MAY include "scope" parameter. If a "scope" parameter is
>    present in the request,
>    the authorization server SHOULD use it to infer the value of the
>    default resource indicator to be used in the "aud" claim.
> It seems to mean that if the request includes no "resource" parameter and
> no "scope" parameter, the access token will necessarily
> include the "sub" claim.
> If in the request, there would be present a parameter meaning "I want a
> token compliant with *this OAuth 2.0 profile*",
> then there would be no problem, but this is not the case.
> In the future, if additional parameters are included in the request, will
> the "sub" claim necessarily be present in the access token ?
> If yes, this may be a privacy concern.
> On the list there have been requirements for not making the "sub"
> parameter mandatory.
> This point needs to be addressed and solved one way or another.
> Denis
> All,
> Based on the 3rd WGLC, we believe that we have consensus to move this
> document forward.
> We will be working on the shepherd write-up and then submit the document
> to the IESG soon.
> Regards,
>  Rifaat & Hannes
> _______________________________________________
> OAuth mailing listOAuth@ietf.org