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

Dominick Baier <> Thu, 16 April 2020 07:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 536893A1015 for <>; Thu, 16 Apr 2020 00:10:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 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, UNPARSEABLE_RELAY=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 22T2gWmdQd6q for <>; Thu, 16 Apr 2020 00:10:08 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BE4E03A0F74 for <>; Thu, 16 Apr 2020 00:10:07 -0700 (PDT)
Received: by with SMTP id s63so16109372qke.4 for <>; Thu, 16 Apr 2020 00:10:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=IULBDrfj46/g8qt1WsvquebT0ycN7SA829C0NkBcUi8=; b=u/LnQI9Ox9hGuEkOnSehNu4Ws5vU7F3XzBMgA91UYthAEVFN1Z6HP8JrJuiHvMa9TS TzjQO9gXuEDvYf9maDboZ8oOHrYFEHUOrBdEI8kfXp05rB0DmfeNGYJNz8YTp0kf2I/n kIgIpWdBXENrjT4olvODaFEp6cQD9NTfkUZ9arwOIw/gMrcdBHP4GVncGOzTSIdcanGi CtpZtepzuYYDqe/qHcxMt/rJwnmyWuQNy+9BCVHUKZoIHYxFRo7pLAqYfLTH/aqrJA8f aHMe0QBYE0BvwT17xAqYf4YTDOYDVA0EeBCSqos/wVTrujvBHNPGJQWxHj4AuZyHNaRl XMdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=IULBDrfj46/g8qt1WsvquebT0ycN7SA829C0NkBcUi8=; b=NOjw9GlK4tDDsmrpyJyjL1Nbf2ZxcZSDkVqI86MxLft1xGEpD4/O2+w1pBFOTGBTyB ze7d+QxWpktH4iywZnwTj64DkoppcxkkUNTVwrvdUf66dYgDQUVkJ7QliH7c9VvcRih7 W4bYsTGdbvDTirtgB+EYNTNBQX65/nGhVwCZGcieB2GWhTQrEnwYIykDuePkygFaoJc2 +liXiK4arVbNqXiElyHJltxDl6QzoZohc3J8++wmsGPTlKxKyPF5JhwjTYfqcyi6j53e FQDA3bPCBl5LDCcCOSCvWIT2dLx4d4PaN9r3s3E1WodGU3N2r+lAHLwMhMHc1UU6/qAR 4tfA==
X-Gm-Message-State: AGi0PuZvhZ8XWMoZn9RGPyVc0iNLXZzhDEb/iaCJoRjRWXHG3zSNQIkY UZMfrOt1Sn2tGxkBMLOJUlCZfRgmxswvDaDcM4lw
X-Google-Smtp-Source: APiQypJTpmoSOucV6ATKq6ftmnuBwxVyq1dfT3EP2aTIeUB8SF9H+M+gy2tCc8eoPbSUYNNZHy+e89VeDKAPiKmFlcY=
X-Received: by 2002:a05:620a:2054:: with SMTP id d20mr16892050qka.496.1587021006246; Thu, 16 Apr 2020 00:10:06 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Thu, 16 Apr 2020 00:10:05 -0700
From: Dominick Baier <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Date: Thu, 16 Apr 2020 00:10:05 -0700
Message-ID: <>
To: Rifaat Shekh-Yusef <>, oauth <>
Content-Type: multipart/alternative; boundary="000000000000542c3e05a3631f1b"
Archived-At: <>
Subject: Re: [OAUTH-WG] Second WGLC on "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, 16 Apr 2020 07:10:12 -0000

Since this is the last call, I thought I bring up some of thoughts /
concerns. Some of them have been discussed before.

*client_id vs sub*
I am still not entirely happy with the “re-purposing” of the claim types
based on flow.
If the intention is, that sub expresses the entity against which the
resource will do authorisation (and that might be a client or a user) - I
get it (and maybe it should be stated like that) - but
this thinking reminds me of the old AD days where there was no distinction
between user and service accounts (something that has been fixed IIRC in
Windows Server 2012 R2).

All other OAuth specs make a very clear distinction between users and

Furthermore it says

"Authorization servers should prevent scenarios where clients can
   affect the value of the sub claim in ways that could confuse resource

If we keep that dual semantics of the sub claim - it must be clearly
stated, that subject ID and client ID are now in the same collision domain.
So when an AS / OP creates them, they need to be unique across user ids and
client ids.

Maybe it should be also explicitly mentioned that sub has a different
semantic here as in OIDC - even though a majority of the software built
today will use them together.

*audience claim*
I am not fully clear why aud is required. OAuth itself does not have a
notion of an audience (in the JWT sense) - they have scopes (which is very
similar). But in simple scenarios where resources don’t exist, you'd need
to make up an audience just to fulfil this requirement. And in many case
this will be either static or just repeat the scope values. What’s the
value of that?

If the concept of resources are used, I absolutely agree that aud should be
used too. But I wouldn’t make it required.

*iat vs nbf*
What’s the rationale for using iat instead of nbf. Aren’t most JWT
libraries (including e.g. the .NET one) looking for nbf by default?

This spec feels somehow in between a profile and a BCP. On one hand you
define some claims and their semantics (good) - on the other hand there is
some prescriptive guidance and maybe over-specification. My concern is,
that in the end no-one will fully comply with it, because it doesn’t work
one way or the other for them.

I know we just went though the discussion to make certain claims required
as opposed to optional - but maybe less is more.

Tbh - the most valuable part of the doc to me is the definition of the
“at+jwt” typ. For the rest I’d rather like to see just some standard claims
and IF they are used, which semantics they have.

Dominick Baier

On 15. April 2020 at 20:59:31, Rifaat Shekh-Yusef (

Hi all,

This is a second working group last call for "JSON Web Token (JWT) Profile
for OAuth 2.0 Access Tokens".

Here is the document:

Please send your comments to the OAuth mailing list by April 29, 2020.


 Rifaat & Hannes

OAuth mailing list