Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1E23A0AB4 for ; Thu, 14 May 2020 07:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.4, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zh0ZghnuK2WM for ; Thu, 14 May 2020 07:29:47 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp02.smtpout.orange.fr [80.12.242.124]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 335B13A0AB0 for ; Thu, 14 May 2020 07:29:46 -0700 (PDT) Received: from [192.168.1.11] ([86.238.65.197]) by mwinf5d55 with ME id eeVj220094FMSmm03eVjM3; Thu, 14 May 2020 16:29:44 +0200 X-ME-Helo: [192.168.1.11] X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg== X-ME-Date: Thu, 14 May 2020 16:29:44 +0200 X-ME-IP: 86.238.65.197 To: oauth@ietf.org, Vittorio Bertocci References: From: Denis Message-ID: <7cf781ef-67c9-eddd-3076-403e59e371bc@free.fr> Date: Thu, 14 May 2020 16:29:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9DE4E1B69B1BDCC34C1FCC14" Content-Language: en-GB Archived-At: Subject: Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens X-BeenThere: oauth@ietf.org 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:29:49 -0000 This is a multi-part message in MIME format. --------------9DE4E1B69B1BDCC34C1FCC14 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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. > https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/ > > We will be working on the shepherd write-up and then submit the > document to the IESG soon. > > Regards, >  Rifaat & Hannes > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------9DE4E1B69B1BDCC34C1FCC14 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
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 list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--------------9DE4E1B69B1BDCC34C1FCC14--