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

Phil Hunt <phil.hunt@oracle.com> Tue, 11 March 2014 22:06 UTC

Return-Path: <phil.hunt@oracle.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 304B91A0811 for <oauth@ietfa.amsl.com>; Tue, 11 Mar 2014 15:06:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.293
X-Spam-Level:
X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
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 SfyJdQxXtALM for <oauth@ietfa.amsl.com>; Tue, 11 Mar 2014 15:06:06 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0428B1A0800 for <oauth@ietf.org>; Tue, 11 Mar 2014 15:06:05 -0700 (PDT)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s2BM4RkB025857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Mar 2014 22:04:27 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2BM4QSO012122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2014 22:04:26 GMT
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s2BM4Qu4024262; Tue, 11 Mar 2014 22:04:26 GMT
Received: from [192.168.1.186] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 Mar 2014 15:04:26 -0700
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Phil Hunt <phil.hunt@oracle.com>
In-Reply-To: <CC77962D-E341-4358-B320-E4C4D09FD17A@adobe.com>
Date: Tue, 11 Mar 2014 15:04:15 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <974419E4-29B9-4EC3-BCA3-91F577495EB8@oracle.com>
References: <3A1BC33F-1AE2-492F-BCE9-CCB9CF4C3C83@adobe.com> <531F1F72.8010805@gmx.net> <5275E1B4-64DD-48FF-A1A9-959C75EA5DE2@adobe.com> <531F234E.90609@gmx.net> <E8EF9394-73F1-413F-A064-C8543C52EAFD@adobe.com> <531F2632.2090204@gmx.net> <DF99C8A6-DD40-40DE-8F01-399C4CB6FFDC@ve7jtb.com> <F3EA5E97-BCC2-40E8-80FB-7170FD7D8BD4@adobe.com> <32BBE66D-883E-465C-91EB-CDB51333F08A@ve7jtb.com> <CC77962D-E341-4358-B320-E4C4D09FD17A@adobe.com>
To: Antonio Sanso <asanso@adobe.com>
X-Mailer: Apple Mail (2.1510)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/tOcSzOCho0bgK1e_nYcXV5eF3hc
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] JSON Web Token (JWT) Profile
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 11 Mar 2014 22:06:09 -0000

I think that's the wrong perspective. If you intend the issuer to be the subject, you need to declare it.

I wouldn't worry that it duplicates issuer. The fields have different meaning.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

On 2014-03-11, at 1:43 PM, Antonio Sanso <asanso@adobe.com> wrote:

> agree, but in some cases the subject is not only same as the issuer but simply it doesn’t matter.
> 
> In my example below all it matters is that the assertion signed by app1 is valid…. 
> 
> Continue in my probably not relevant “Google example” if I set the prn same as the issuer it would not work (keeping only the issuer without any subject gives me back a correct access token instead).
> 
> Again this is not relevant spec wise. AFIU there is consensus in the working group to keep the subject mandatory. Would it make sense at least to add a little not that in some situations the issuer and the subject are the same?
> This might clarify at least something to people that do wonder...
> 
> regards
> 
> antonio
> 
> On Mar 11, 2014, at 8:12 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
> 
>> The specification is intended to allow the interoperation of standard libraries.  
>> 
>> In some cases the subject and the iss may be the same, however the underlying OAuth library may be a general one and always require a subject for security processing.
>> 
>> It is possible that all libraries could have a special rule for when sub is not present and use the value of iss as sub.  This will save some bytes in the JWT but it is probably not worth creating an extra code path in libraries for the size optimization. 
>> 
>> I don't think your saying there is no subject just that it is redundant with iss in some cases.
>> 
>> John B.
>> 
>> On Mar 11, 2014, at 2:11 PM, Antonio Sanso <asanso@adobe.com> wrote:
>> 
>>> Ok this is my use case:
>>> 
>>> - I  am John Doe and going to AS to register my app named app1
>>> - I then either upload my public key or download a private key
>>> - at this point I am ready to build my assertion, the issuer claim is going to be app1 and should suffice.
>>> 
>>> is the subject really needed in this use case? 
>>> 
>>> regards
>>> 
>>> antonio
>>> 
>>> 
>>> On Mar 11, 2014, at 4:25 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>>> 
>>>> The missing scheme especially on JWT issued by google is something I understand they are working on but need to be careful about breaking existing code, so will possibly need new endpoints that are spec compliant. 
>>>> 
>>>> While in this google case the subject and the issuer happen to be the same they may well not be even in the self signed case.   In WG discussions being consistent in providing the subject was considered to be better for interoperability than optimizing for the case where sub or issuer could be dropped.  
>>>> 
>>>> John B.
>>>> 
>>>> On Mar 11, 2014, at 12:05 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>>>> 
>>>>> Maintaining both information in the JWT is IMHO valuable since it gives
>>>>> you some information about the security properties. Needless to say that
>>>>> there is a substantial difference between a self-created JWT and a JWT
>>>>> from a third party the relying party has some confidence in.
>>>>> 
>>>>> Why Google has an old implementation and whether they are planning to
>>>>> update their code remains to be seen.
>>>>> 
>>>>> More importantly, however, is why you argue that the subject claim has
>>>>> to be optional.
>>>>> 
>>>>> Ciao
>>>>> Hannes
>>>>> 
>>>>> Ps: I also noticed in the examples that all URIs have their URI scheme
>>>>> missing. While that might be OK I am not entirely sure...
>>>>> 
>>>>> On 03/11/2014 04:08 PM, Antonio Sanso wrote:
>>>>>> 
>>>>>> On Mar 11, 2014, at 3:53 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>>>>>> 
>>>>>>> Thanks for clarifying.
>>>>>>> 
>>>>>>> I took a quick look at the Google API and it seems that in their use
>>>>>>> case the client creates the JWT and consequently the subject and the
>>>>>>> issue would actually be the same. I suspect that this is the reason why
>>>>>>> they omitted the subject.
>>>>>> 
>>>>>> agreed that is why in my mail I said the subject might overlap with the issuer.
>>>>>> The subject in the google case is still called with its obsolete name (prn) and it is actually listed as ‘additional claims’ hence not mandatory.
>>>>>> 
>>>>>> regards
>>>>>> 
>>>>>> antonio
>>>>>> 
>>>>>>> 
>>>>>>> Could you explain why you would like to omit the subject claim in the JWT?
>>>>>>> 
>>>>>>> Ciao
>>>>>>> Hannes
>>>>>>> 
>>>>>>> PS: Your feedback on the  draft-ietf-oauth-jwt-bearer-07 spec is timely
>>>>>>> since we are about to finish all three assertion specs.
>>>>>>> 
>>>>>>> 
>>>>>>> On 03/11/2014 03:56 PM, Antonio Sanso wrote:
>>>>>>>> hi Hannes,
>>>>>>>> 
>>>>>>>> I am aware of the 2 documents,
>>>>>>>> 
>>>>>>>> I might be wrong but http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07 is also about Authorization Grant Processing (this is the part I do use in my implementation ) and not only Client Authentication Processing.
>>>>>>>> 
>>>>>>>> Just my 0.02 $ but this seems to be a place where different implementer have the same issue :)
>>>>>>>> 
>>>>>>>> regards
>>>>>>>> 
>>>>>>>> antonio
>>>>>>>> 
>>>>>>>> On Mar 11, 2014, at 3:36 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>>>>>>>> 
>>>>>>>>> Hi Manfred, Hi Antonio,
>>>>>>>>> 
>>>>>>>>> Note that there are two documents that talk about the JWT and you guys
>>>>>>>>> might be looking at the wrong document.
>>>>>>>>> 
>>>>>>>>> The main JWT document (see
>>>>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-18) defines
>>>>>>>>> the subject claim as optional (see Section 4.1.2).
>>>>>>>>> 
>>>>>>>>> The JWT bearer assertion document (see
>>>>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07) does indeed
>>>>>>>>> define it as mandatory but that's intentional since the purpose of the
>>>>>>>>> spec is to authenticate the client (or the resource owner for an
>>>>>>>>> authorization grant).
>>>>>>>>> 
>>>>>>>>> The assertion documents are used for interworking with "legacy" identity
>>>>>>>>> infrastructure (such as SAML federations).
>>>>>>>>> 
>>>>>>>>> So, are you sure you are indeed looking at the right document?
>>>>>>>>> 
>>>>>>>>> Ciao
>>>>>>>>> Hannes
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 03/11/2014 03:13 PM, Antonio Sanso wrote:
>>>>>>>>>> hi *,
>>>>>>>>>> 
>>>>>>>>>> JSON Web Token (JWT) Profile section 3 [0] explicitely says 
>>>>>>>>>> 
>>>>>>>>>> The JWT MUST contain a "sub" (subject) claim 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Now IMHO there are cases where having the sub is either not needed or
>>>>>>>>>> redundant (since it might overlap with the issuer).\
>>>>>>>>>> 
>>>>>>>>>> As far as I can see “even Google” currently violates this spec [1] ( I
>>>>>>>>>> know that this doesn’t matter, just wanted to bring a real use case
>>>>>>>>>> scenario).
>>>>>>>>>> 
>>>>>>>>>> WDYT might the “sub” be optional in some situation?
>>>>>>>>>> 
>>>>>>>>>> regards
>>>>>>>>>> 
>>>>>>>>>> antonio 
>>>>>>>>>> 
>>>>>>>>>> [0] http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-07#section-3
>>>>>>>>>> [1] https://developers.google.com/accounts/docs/OAuth2ServiceAccount
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> _______________________________________________
>>>>>>>>>> OAuth mailing list
>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> 
>>> 
>> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth