Re: [OAUTH-WG] JSON Web Token (JWT) Profile
Antonio Sanso <asanso@adobe.com> Wed, 12 March 2014 09:44 UTC
Return-Path: <asanso@adobe.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 7029E1A0932 for <oauth@ietfa.amsl.com>; Wed, 12 Mar 2014 02:44:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 4PjonGClBSH5 for <oauth@ietfa.amsl.com>; Wed, 12 Mar 2014 02:44:39 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) by ietfa.amsl.com (Postfix) with ESMTP id 729AA1A0930 for <oauth@ietf.org>; Wed, 12 Mar 2014 02:44:39 -0700 (PDT)
Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by BL2PR02MB306.namprd02.prod.outlook.com (10.141.91.19) with Microsoft SMTP Server (TLS) id 15.0.893.10; Wed, 12 Mar 2014 09:44:31 +0000
Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.29]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.185]) with mapi id 15.00.0893.001; Wed, 12 Mar 2014 09:44:30 +0000
From: Antonio Sanso <asanso@adobe.com>
To: Manfred Steyer <manfred.steyer@gmx.net>
Thread-Topic: [OAUTH-WG] JSON Web Token (JWT) Profile
Thread-Index: AQHPPTQaKxckAjMng0+5U95NRYKjsJrb9DEAgAAFrgD///7sAIAABF2A////FQCAAEllgIAABfqAgAC93ICAACt1gA==
Date: Wed, 12 Mar 2014 09:44:29 +0000
Message-ID: <C7EE63D7-16D6-4607-AE7E-640D6E82B179@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> <003201cf3d60$09a4be20$1cee3a60$@gmx.net> <8523B6DF-C085-42F0-A02A-51F2A9AF0FFB@ve7jtb.com> <006a01cf3dc1$f1333080$d3999180$@gmx.net>
In-Reply-To: <006a01cf3dc1$f1333080$d3999180$@gmx.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [193.104.215.11]
x-forefront-prvs: 01480965DA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(428001)(377454003)(479174003)(24454002)(51704005)(199002)(189002)(77982001)(80022001)(92726001)(15202345003)(59766001)(69226001)(51856001)(76482001)(86362001)(83322001)(53806001)(54356001)(81686001)(74706001)(74366001)(47736001)(85852003)(65816001)(93136001)(93516002)(83072002)(66066001)(46102001)(76796001)(76786001)(50986001)(19580405001)(80976001)(56776001)(49866001)(19580395003)(33656001)(4396001)(77096001)(81342001)(15975445006)(81816001)(81542001)(47446002)(2656002)(92566001)(95666003)(74662001)(31966008)(94316002)(83716003)(97186001)(97336001)(79102001)(87266001)(94946001)(36756003)(95416001)(90146001)(54316002)(82746002)(56816005)(47976001)(74876001)(74502001)(63696002)(85306002)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR02MB306; H:CO1PR02MB206.namprd02.prod.outlook.com; CLIP:193.104.215.11; FPR:EFBFF175.AFF25119.F8EB112B.8428C552.20619; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (: adobe.com does not designate permitted sender hosts)
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <32DB87F74D9D724597C1E8CA372FC91C@namprd02.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/H2IwBOFrXu0YuOtmViav446zetY
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: Wed, 12 Mar 2014 09:44:44 -0000
+1 thanks antonio On Mar 12, 2014, at 8:08 AM, Manfred Steyer <manfred.steyer@gmx.net> wrote: > Hi John, > > thx for this explanation. It helps me to see, why this decision has been > made. > > Wishes, > Manfred > > > -----Ursprüngliche Nachricht----- > Von: John Bradley [mailto:ve7jtb@ve7jtb.com] > Gesendet: Dienstag, 11. März 2014 20:49 > An: Manfred Steyer > Cc: Hannes Tschofenig; Antonio Sanso; oauth@ietf.org > Betreff: Re: [OAUTH-WG] JSON Web Token (JWT) Profile > > Company X will likely care about the subject being asserted by company A for > auditing and possible revocation. > > It may be that the extension claim accessLevel=Accounting is sufficient to > grant the access token. > > By Policy A could make sub itself, or an identifier for the user of the > client in it's namespace. > > Yes there are some cases where it may be redundant or not disclosed for a > privacy reason, but the current decision is to keep the library consistent > and push that decision to the application logic. > > You can make the case the decision was wrong. > > The other reason for it is that the JWT and SAML assertions are parallel and > in SAML subject is required. That was the other consistency reason for > making it mandatory. > > John B. > > > On Mar 11, 2014, at 4:28 PM, Manfred Steyer <manfred.steyer@gmx.net> wrote: > >> 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 >>>>>>> >>>>>> >>>>> >>>> >>> >> >> >> _______________________________________________ >> 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-WG] JSON Web Token (JWT) Profile Antonio Sanso
- Re: [OAUTH-WG] JSON Web Token (JWT) Profile Manfred Steyer
- Re: [OAUTH-WG] JSON Web Token (JWT) Profile Hannes Tschofenig
- Re: [OAUTH-WG] JSON Web Token (JWT) Profile Antonio Sanso
- Re: [OAUTH-WG] JSON Web Token (JWT) Profile Hannes Tschofenig
- Re: [OAUTH-WG] JSON Web Token (JWT) Profile Antonio Sanso
- Re: [OAUTH-WG] JSON Web Token (JWT) Profile Hannes Tschofenig
- Re: [OAUTH-WG] JSON Web Token (JWT) Profile John Bradley
- Re: [OAUTH-WG] JSON Web Token (JWT) Profile Antonio Sanso
- Re: [OAUTH-WG] JSON Web Token (JWT) Profile John Bradley
- Re: [OAUTH-WG] JSON Web Token (JWT) Profile Manfred Steyer
- Re: [OAUTH-WG] JSON Web Token (JWT) Profile John Bradley
- Re: [OAUTH-WG] JSON Web Token (JWT) Profile Antonio Sanso
- Re: [OAUTH-WG] JSON Web Token (JWT) Profile Phil Hunt
- Re: [OAUTH-WG] JSON Web Token (JWT) Profile Nat Sakimura
- Re: [OAUTH-WG] JSON Web Token (JWT) Profile Manfred Steyer
- Re: [OAUTH-WG] JSON Web Token (JWT) Profile Antonio Sanso