Re: [OAUTH-WG] WGLC on JSON Web Token (JWT)

Prateek Mishra <prateek.mishra@oracle.com> Wed, 21 August 2013 23:51 UTC

Return-Path: <prateek.mishra@oracle.com>
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 4147311E8129 for <oauth@ietfa.amsl.com>; Wed, 21 Aug 2013 16:51:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLIzX1BnBUNY for <oauth@ietfa.amsl.com>; Wed, 21 Aug 2013 16:51:13 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9F39311E8143 for <oauth@ietf.org>; Wed, 21 Aug 2013 16:51:13 -0700 (PDT)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7LNp7M2025977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Aug 2013 23:51:08 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7LNp6Gj028982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Aug 2013 23:51:07 GMT
Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7LNp65n015597; Wed, 21 Aug 2013 23:51:06 GMT
Received: from [10.152.55.230] (/10.152.55.230) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 21 Aug 2013 16:51:06 -0700
Message-ID: <52155269.7040302@oracle.com>
Date: Wed, 21 Aug 2013 19:51:05 -0400
From: Prateek Mishra <prateek.mishra@oracle.com>
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
References: <5202113B.1020505@gmx.net>
In-Reply-To: <5202113B.1020505@gmx.net>
Content-Type: multipart/alternative; boundary="------------070803070105030009000709"
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] WGLC on JSON Web Token (JWT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Aug 2013 23:51:19 -0000

1) As a JWT is always an instance of JWE or JWS, I am not sure why there 
is a need for the the materials found in Section 5, para 1 (these are 
also found in the JWE and JWS draft specifications). It could simply be 
removed from the draft.

2) Why do we need both a "typ" claim and a "typ" header name? Need they 
have some relationship to each other?
Isn't this also covered by Section 5.3?

3)  The materials in Section 5.3 could be simplified further.

Why should the use of claims as header parameters be restricted to the 
case where the JWT=JWE; what about the encrypt then sign (symmetric) 
use-case? I see no issue in allowing this feature with a JWT of any type.

The last paragraph of Section 5.3 ("This specification reserves the iss 
(issuer), sub (subject),....") seems to be an instance of the
previous paragraph. If claims are allowed in the header, then iss 
(issuer), sub (subject) are trivially allowed, right? I couldn't find 
any additional information in this last paragraph.

Finally, do we need "SHOULD verify that their values are identical" - 
given that this matter is left upto applications, couldnt they choose to 
verify only a certain relationship between the corresponding values 
(e.g., header carries hash of value, JWT carries the (large) complete 
value)?  Can this be weakened to "SHOULD verify that their values have 
an appropriate (application-defined) relationship. In many instances, 
applications may want to ensure that they are identical".

4) Section 8 -

am I correct in reading this as: all conforming JWT implementations MUST 
implement JWS and MAY implement JWE?
At least thats what I understood from the last paragraph ("/if/ an 
implementation provides encryption capabilities...").



- prateek
> Hi all,
>
> this is a working group last call for the JSON Web Token (JWT).
>
> Here is the document:
> http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-11
>
> Please send you comments to the OAuth mailing list by August 21, 2013.
>
> Ciao
> Hannes & Derek
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth