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

Takahiko Kawasaki <> Tue, 24 March 2020 06:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 39E643A1026 for <>; Mon, 23 Mar 2020 23:47:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 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_NONE=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 vSoPS_6ywkYn for <>; Mon, 23 Mar 2020 23:47:31 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A5FDA3A07E0 for <>; Mon, 23 Mar 2020 23:46:57 -0700 (PDT)
Received: by with SMTP id m3so2201532wmi.0 for <>; Mon, 23 Mar 2020 23:46:57 -0700 (PDT)
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=Jvch+pjMBvxHfBJ3sNC5DiuBHg+QsXqA8ZSxv/ukLJs=; b=klwPJSCcngFDgtOdXHbdukzIRN489y47YlNErrLb1cKgQ/24anHGVc5pw6wGLfUQU6 s11mVhZJ4smyIMPUB+oi5wbxiY1theqRaIQFMWUROR76UmIjc8n7vV/hWlFH6VioOIOY WCwh8mFqhFQuJ6J2Q4hZpTJGrSgOf2BNOZ0eq9PeMoEozxmUafBnYPXbhMsfnUkV1VaM JJI8YyIs3voepw0GswrbKaRdh+0yy7eAq7iGZoSGsRPQcir7ZR3T9TPkzWu2flBV57Ta c38dx6JNDhYh0Ofemi6zU82dR+t6pP5Z/s/w6FzokK9FlIgoNDvRoUovslC8JrfE5gLi aViQ==
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=Jvch+pjMBvxHfBJ3sNC5DiuBHg+QsXqA8ZSxv/ukLJs=; b=T92t/gqNUBTu32To4k7lJ1dtAVfP6eVteQYCptY/i1AJ9RAAHvyPdq6LkoF57YdHrO R+HInOKtQe5d/a7IHwk6DVkM1L1dQfv9gvnDAP2HAdcq8RcBynijjB3ev9SaclgrvtOE GehHdKKsOojsV1f9xAyYWcWvXSP1pdOk9FwCRsY34CGAjreUmXgYjmhQJtnISPytpi1Q SpxbDQCDwV7xYIR4yFUsFujNOVSf7rTZLXpMS4lKY4mOEyE6u3jWF3WrIfUcywtAFimc yvwV7KAYmBy30th5VkdOgqPEzzs1IvyW80HEIcH0+Vkcd1n1ptr9yVdgpS8gC0T6OCdH Deww==
X-Gm-Message-State: ANhLgQ3flqAb1+m2+/wwHPxBSkPsuKLpE7jJrgFD/1vfIo8mgEGF577+ 6Sqf7ByRBlHN6SjiHus9olDMSgXlSmZ0meqj0S2fnlnyxCHZ8w==
X-Google-Smtp-Source: ADFU+vvMMBjDZihF2y/CjCHno9alJuEw3bJlTvhO917SDaTE0woUCSrqZSz/lfBzLclaC3maXVaB8QOgDwKhU16WC44=
X-Received: by 2002:a1c:2056:: with SMTP id g83mr3639365wmg.179.1585032415824; Mon, 23 Mar 2020 23:46:55 -0700 (PDT)
MIME-Version: 1.0
References: <> <01ec01d6017c$162eb2e0$428c18a0$>
In-Reply-To: <01ec01d6017c$162eb2e0$428c18a0$>
From: Takahiko Kawasaki <>
Date: Tue, 24 Mar 2020 15:46:44 +0900
Message-ID: <>
To: Nikos Fotiou <>
Cc: Hannes Tschofenig <>, oauth <>
Content-Type: multipart/alternative; boundary="0000000000001a630a05a1941eb7"
Archived-At: <>
Subject: Re: [OAUTH-WG] 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: Tue, 24 Mar 2020 06:47:35 -0000

The requirement in the paragraph below excerpted from "3. Requesting a JWT
Access Token":

*If it receives a request for an access token containing more than one
resource parameter, an authorization server issuing JWT access tokens MUST
reject the request and fail with "invalid_request" as described in section of [RFC6749] or with "invalid_target" as defined in section 2 of
[RFC8707].  See Section 2.2 and Section 5 for more details on how this
measure ensures there's no confusion on to what resource the access token
granted scopes apply.*

apparently conflicts with RFC 8707. I'm afraid vendors that support RFC
8707 won't support this draft unless the requirement is loosened, for
example from MUST to SHOULD.

Regarding another paragraph shown below from the same section.

*If the request does not include a resource parameter, the authorization
server MUST use in the aud claim a default resource indicator.  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.  The mechanism through which scopes are associated to default
resource indicator values is outside the scope of this specification.  If
the values in the scope parameter refer to different default resource
indicator values, the authorization server SHOULD reject the request with
invalid_scope as described in section of [RFC6749].*

The rule described here whereby to determine the default value of the "aud"
claim is unintelligible. In addition, I don't think the rule referring to
the "scope" parameter is worth being defined. That "aud" is missing but
"scope" is available is enough for resource servers. In other words, if
"aud" is determined based on the "scope", why do we have to set "aud"

Requiring the "aud" as a MUST claim is the reason that this draft has to
introduce philosophy about "aud" that may conflict with other
specifications and may not be supported by all implementers. I would
suggest changing "REQUIRED" to "OPTIONAL".

Best Regards,
Takahiko Kawasaki
Authlete, Inc.

On Tue, Mar 24, 2020 at 10:32 AM Nikos Fotiou <> wrote:

> Hi all,
> Allow me some comments and forgive me if some of them are naïve.
> - In Section 2.2 why nbf claim (
> <> is not considered? I
> can imagine some interesting applications of this claim.
> - In the same section, it is not clear why some claims are required,
> especially exp, sub, and client_id. The last two claims are not even used
> during token validation.
> - RFC7519 specifies that, in the general case, the aud claim is an array
> of StringOrURI values. In this draft it is not clear if this still the
> case, or here aud is a simple string (e.g., in page 5 it is stated: the
> resource indicated in the aud claim, rather than the resource*s*).
> - In the token validation procedure, i.e., Section 4, is there any reason
> why the resource server first checks the aud claim, then the signature, and
> finally the exp claim? Given the fact that Error responses are not
> specified, returning something like “invalid aud claim” even for tokens
> with invalid signature may result in privacy/security attacks.
> - IMHO The token validation procedure it too bound to the particular
> discovery mechanisms mentioned at the beginning of this section. E.g., Step
> 2 mentions a “registration” process, and Step 3 mentions and an “Issuer
> Identifier” which must much the iss claim. Moreover, I think it should be
> explicitly mentioned that the resource server “must validate that the JWT
> access token has been singed with a signing key that corresponds to the
> authorization server included in the iss claim”
> Best,
> Nikos
> *From:* OAuth <> *On Behalf Of *Hannes Tschofenig
> *Sent:* Monday, March 23, 2020 11:18 PM
> *To:* oauth <>
> *Subject:* [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0
> Access Tokens"
> Hi all,
> this is a working group last call for "JSON Web Token (JWT) Profile for
> OAuth 2.0 Access Tokens".
> Here is the document:
> Please send you comments to the OAuth mailing list by April 6, 2020.
> Ciao
> Hannes & Rifaat
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> _______________________________________________
> OAuth mailing list