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

"Manfred Steyer" <manfred.steyer@gmx.net> Tue, 11 March 2014 19:28 UTC

Return-Path: <manfred.steyer@gmx.net>
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 2C6391A052E for <oauth@ietfa.amsl.com>; Tue, 11 Mar 2014 12:28:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level:
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 6AVQEErfCtzs for <oauth@ietfa.amsl.com>; Tue, 11 Mar 2014 12:28:18 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 912E21A04AB for <oauth@ietf.org>; Tue, 11 Mar 2014 12:28:18 -0700 (PDT)
Received: from IWINB07 ([178.191.195.241]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MBVwM-1WUZcy43c6-00AYlF; Tue, 11 Mar 2014 20:28:11 +0100
From: "Manfred Steyer" <manfred.steyer@gmx.net>
To: "'Hannes Tschofenig'" <hannes.tschofenig@gmx.net>, "'Antonio Sanso'" <asanso@adobe.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>
In-Reply-To: <531F2632.2090204@gmx.net>
Date: Tue, 11 Mar 2014 20:28:03 +0100
Message-ID: <003201cf3d60$09a4be20$1cee3a60$@gmx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQMQvuGC6nCHESWBhgEiO0rGzvkC2gFy0GcIAOtUr0cCG1yEnQJJqlGNAoka7XaYDqTe4A==
Content-Language: de
X-Provags-ID: V03:K0:wypwKq2e1ns16o8aCEz2gQhdInxaOFJBAloU26YOlRHlR1dcpPk /hnnMpuUYnctnrYiHivTSwpnhDfSwJtgpQsgXD0dV8helHE/mMBAu6GxYbUETIl+BrF1TwZ 7KiE+1TDL7vndjdWoWiSlKBmiFnpZqdUTgj4hBMR5oOFSAv+RD2Ou/pcRrseQpSKHjqEU8M hQCYbbp8/1sAm5MHlHbfg==
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/M6cw4UKizHCVtla3JEAIz70vG-E
Cc: 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 19:28:21 -0000

Hi,

perhaps you can show that I'm wrong, but I still think, that there are
cases, where the subject is unknown cause it's not relevant. Let's consider
the following federation-scenario:

1. Bob has a Token T1 that says, that he works  for Company A on Project B.
The Subject of this token is "Bob".
2. Company X says, that everyone in Company A working for Project B gets
access to Accounting-Information.
3. Bob exchanges this Token T1 at Company X's AuthServer for another Token
T2. T2 contains a claim AccessLevel=Accouting. T2 could also get a copy of
the subj-claim, but Company X doesn't care about that, cause no one in
Company B knows Bob.

The only reason I can imagine, why the sub-claim should be copied into T2 is
because of tracing and finding out, that there is a correlation between T2
und T1. But this could be accomplished with other mechanisms too.

Did I oversee something? If there is another reason, why sub is mandatory, I
think, it would not hurt too much to copy the sub-claim from T1 to T2 (and
from T2 to T3 etc.)...

Wishes
Manfred



-----Ursprüngliche Nachricht-----
Von: OAuth [mailto:oauth-bounces@ietf.org] Im Auftrag von Hannes Tschofenig
Gesendet: Dienstag, 11. März 2014 16:05
An: Antonio Sanso
Cc: oauth@ietf.org
Betreff: Re: [OAUTH-WG] JSON Web Token (JWT) Profile

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
>>>>>
>>>>
>>>
>>
>