Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
Anthony Nadalin <tonynad@microsoft.com> Sun, 30 December 2012 16:33 UTC
Return-Path: <tonynad@microsoft.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 0DB7421F87B4 for <oauth@ietfa.amsl.com>; Sun, 30 Dec 2012 08:33:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.951
X-Spam-Level:
X-Spam-Status: No, score=0.951 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbIyIJEIb-YD for <oauth@ietfa.amsl.com>; Sun, 30 Dec 2012 08:33:15 -0800 (PST)
Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.23]) by ietfa.amsl.com (Postfix) with ESMTP id B7F8921F8775 for <oauth@ietf.org>; Sun, 30 Dec 2012 08:33:15 -0800 (PST)
Received: from BY2FFO11FD013.protection.gbl (10.1.15.202) by BY2FFO11HUB021.protection.gbl (10.1.14.108) with Microsoft SMTP Server (TLS) id 15.0.586.12; Sun, 30 Dec 2012 16:33:12 +0000
Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD013.mail.protection.outlook.com (10.1.14.75) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Sun, 30 Dec 2012 16:33:12 +0000
Received: from va3outboundpool.messaging.microsoft.com (157.54.51.114) by mail.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.2.318.3; Sun, 30 Dec 2012 16:33:10 +0000
Received: from mail237-va3-R.bigfish.com (10.7.14.246) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.23; Sun, 30 Dec 2012 16:33:09 +0000
Received: from mail237-va3 (localhost [127.0.0.1]) by mail237-va3-R.bigfish.com (Postfix) with ESMTP id EAB20D002CF for <oauth@ietf.org.FOPE.CONNECTOR.OVERRIDE>; Sun, 30 Dec 2012 16:33:08 +0000 (UTC)
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT004.namprd03.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -21
X-BigFish: PS-21(zzbb2dI98dI9371Ic89bhd6eah542I1432Ic857h1447Izz1de0h1202h1e76h1d1ah1d2ah1082kzz8275bh8275dh8275ch1033IL177df4h18c673h17326ahz31h2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h9a9j1155h)
Received-SPF: softfail (mail237-va3: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT004.namprd03.prod.outlook.com ; .outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB042; LANG:en;
Received: from mail237-va3 (localhost.localdomain [127.0.0.1]) by mail237-va3 (MessageSwitch) id 1356885185753257_11605; Sun, 30 Dec 2012 16:33:05 +0000 (UTC)
Received: from VA3EHSMHS012.bigfish.com (unknown [10.7.14.247]) by mail237-va3.bigfish.com (Postfix) with ESMTP id B2B38180053; Sun, 30 Dec 2012 16:33:05 +0000 (UTC)
Received: from BL2PRD0310HT004.namprd03.prod.outlook.com (157.56.240.21) by VA3EHSMHS012.bigfish.com (10.7.99.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 30 Dec 2012 16:33:05 +0000
Received: from BY2PR03MB042.namprd03.prod.outlook.com (10.255.241.146) by BL2PRD0310HT004.namprd03.prod.outlook.com (10.255.97.39) with Microsoft SMTP Server (TLS) id 14.16.245.2; Sun, 30 Dec 2012 16:33:04 +0000
Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB042.namprd03.prod.outlook.com (10.255.241.146) with Microsoft SMTP Server (TLS) id 15.0.586.12; Sun, 30 Dec 2012 16:33:02 +0000
Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.7.160]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.7.160]) with mapi id 15.00.0586.000; Sun, 30 Dec 2012 16:32:50 +0000
From: Anthony Nadalin <tonynad@microsoft.com>
To: Mike Jones <Michael.Jones@microsoft.com>, Nat Sakimura <sakimura@gmail.com>
Thread-Topic: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
Thread-Index: Ac3lYXPokKfJ1TsWSvG7/OFVVl60vgAR1McAAB7o9hAAB4+qgAAIDBYAABIWM3A=
Date: Sun, 30 Dec 2012 16:32:47 +0000
Message-ID: <4326b9d5b13b407fb43fe08581c6477b@BY2PR03MB041.namprd03.prod.outlook.com>
References: <4E1F6AAD24975D4BA5B1680429673943669B0B1F@TK5EX14MBXC283.redmond.corp.microsoft.com> <50DEBAF4.6040700@kent.ac.uk> <517e9248dbf944d2a275b4850609f63c@BY2PR03MB041.namprd03.prod.outlook.com> <CABzCy2BHqeiQrkrsMSCDBqa4Nf7Nno1XbbnsKho_xSt6FTm78A@mail.gmail.com> <4E1F6AAD24975D4BA5B1680429673943669E05E8@TK5EX14MBXC283.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943669E05E8@TK5EX14MBXC283.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [50.46.126.7]
Content-Type: multipart/alternative; boundary="_000_4326b9d5b13b407fb43fe08581c6477bBY2PR03MB041namprd03pro_"
MIME-Version: 1.0
X-OrganizationHeadersPreserved: BL2PRD0310HT004.namprd03.prod.outlook.com
X-FOPE-CRA-Verdict: 157.56.240.21$kent.ac.uk%0%1%duplicatedomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com%False%False%0$
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%KENT.AC.UK$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-CrossPremisesHeadersPromoted: TK5EX14HUBC107.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14HUBC107.redmond.corp.microsoft.com
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(51704002)(51914002)(479174001)(24454001)(13464002)(5343635001)(56816002)(47976001)(5343655001)(44976002)(47736001)(50986001)(49866001)(76482001)(4396001)(6806001)(15202345001)(74502001)(56776001)(47446002)(51856001)(74662001)(33646001)(77982001)(46102001)(16676001)(59766001)(31966008)(53806001)(512874001)(54356001)(15395725002)(54316002)(5343645001)(550184003)(16236675001)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB021; LANG:en;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 071156160B
Cc: IETF oauth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
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: Sun, 30 Dec 2012 16:33:17 -0000
Mike, claims are in doubt thus they have to be verified thus they don’t carry the proof From: Mike Jones Sent: Saturday, December 29, 2012 11:54 PM To: Nat Sakimura; Anthony Nadalin Cc: David Chadwick; IETF oauth WG Subject: RE: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05 The problem with the X.1252 definition is it unnecessarily adds the “without being able to give proof” comment. That will distract the reader immediately. The current “a piece of information asserted about a subject” definition is just as accurate as the X.1252 and doesn’t send readers down a mental rathole. We can add an informative reference to X.1252 if you like, but I really think readability and simplicity are more important in this kind of a spec than reusing overly technical and off-putting ISO definitions. About the terminology ordering, the current order is intended to be what I think you would call a reverse dependency chain – what I would call a top-down ordering. It’s that way so that the JSON Web Token definition is first. Then, as that definition needs other definitions, they immediately follow. This is intended increase readability, by presenting concepts in a top-down manner. By comparison, bottom-up ordering makes readers wade through a sea of other terms before getting to the one they really cared about. If you want to reorder the terms to make sure they’re in the best top-down order possible, that would be useful. (If you decide to do that, I’d also look at the terminology ordering in JWS, JWE, and JWK, as we should be as consistent as possible across the specifications. -- Mike From: Nat Sakimura [mailto:sakimura@gmail.com] Sent: Saturday, December 29, 2012 8:04 PM To: Anthony Nadalin Cc: David Chadwick; Mike Jones; IETF oauth WG Subject: Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05 Tony, So do you agree with the following definition in -06? Or prefer X.1252 definition? Claim A piece of information asserted about a subject. Here, Claims are represented name/value pairs, consisting of a Claim Name and a Claim Value. Mike: Regarding the ordering of the terms in terminology, you should either use the dependency chain or alphabetic order. (Former is more desirable in my point of view.) However, as it stands, it is none of those. For example, the term "claim" appears in the definition of JWT, which is the first term in the terminology, without having been defined. If you do not mind, I will reorder them and send it to you. Nat On Sun, Dec 30, 2012 at 9:28 AM, Anthony Nadalin <tonynad@microsoft.com<mailto:tonynad@microsoft.com>> wrote: By definition a claim is always in doubt thus it would not call it a credential until it is verified -----Original Message----- From: oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org> [mailto:oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org>] On Behalf Of David Chadwick Sent: Saturday, December 29, 2012 1:42 AM To: Mike Jones Cc: IETF oauth WG Subject: Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05 If a claim provides proof then I would call it a credential not a claim David On 29/12/2012 01:11, Mike Jones wrote: > I found the X.1252 definition. It is: > > *6.18 claim *[b-OED]: To state as being the case, without being able > to give proof. > > That seems both a bit vague, and actually incorrect, as the JWT may > include proof of the veracity of the claim. Please see the updated > JWT draft for a hopefully more useful “Claim” definition. > > Best > wishes, > > -- Mike > > *From:*Mike Jones > *Sent:* Sunday, December 23, 2012 1:03 PM > *To:* Jeff Hodges; Nat Sakimura > *Cc:* IETF oauth WG > *Subject:* RE: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05 > > What is the X.1252 definition? > > -- Mike > > *From:* Nat Sakimura > *Sent:* December 23, 2012 10:09 AM > *To:* =JeffH > *CC:* Mike Jones, IETF oauth WG > *Subject:* Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05 > > Re definition of 'claim', as JWT is supposed to be generic, it may be > better to go with the definition of X.1252 rather than OIDC. > > =nat via iPhone > > Dec 24, 2012 2:42、=JeffH <Jeff.Hodges@kingsmountain.com<mailto:Jeff.Hodges@kingsmountain.com> > <mailto:Jeff.Hodges@kingsmountain.com<mailto:Jeff.Hodges@kingsmountain.com>>> のメッセージ: > >> >> > Thanks for the replies, Jeff. They make sense. Particularly, >> > thanks for the "JSON Text Object" suggestion. >> >> welcome, glad they made some sense. >> >> similarly, if one employs JSON arrays, I'd define a "JSON text array". >> >> >> > For the "claims" definition, I'm actually prone to go with >> >definitions based on those in >> >http://openid.net/specs/openid-connect-messages-1_0-13.html#terminol >> >ogy- >> > specifically: >> > >> > Claim >> > A piece of information about an Entity that a Claims Provider >> > asserts about that Entity. >> > Claims Provider >> > A system or service that can return Claims about an Entity. >> > End-User >> > A human user of a system or service. >> > Entity >> > Something that has a separate and distinct existence and that can >> > be identified in context. An End-User is one example of an Entity. >> >> well, it seems to me, given the manner in which the JWT spec is >> written, one can make the case that JWT claims in general aren't >> necessarily about an Entity (as the latter term is used in the >> context of the OpenID Connect specs), rather they're in general >> simply assertions about something(s). this is because all pre-defined > JWT claim types are optional and all JWT semantics are left up to > specs that profile (aka re-use) the JWT spec. >> >> HTH, >> >> =JeffH >> >> _______________________________________________ >> OAuth mailing list >>OAuth@ietf.org<mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org<mailto:OAuth@ietf.org>> >>https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org<mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
- Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-… =JeffH
- [OAUTH-WG] review: draft-ietf-oauth-json-web-toke… =JeffH
- Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-… John Bradley
- Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-… =JeffH
- Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-… Mike Jones
- Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-… Nat Sakimura
- Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-… Mike Jones
- Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-… Nat Sakimura
- Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-… Dick Hardt
- Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-… Mike Jones
- Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-… Mike Jones
- Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-… Mike Jones
- Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-… David Chadwick
- Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-… Antonio Sanso
- Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-… John Bradley
- Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-… Antonio Sanso
- Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-… Nat Sakimura
- Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-… Anthony Nadalin
- Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-… Nat Sakimura
- Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-… Anthony Nadalin
- Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-… Mike Jones
- Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-… Mike Jones
- Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-… David Chadwick
- Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-… Antonio Sanso
- Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-… Anthony Nadalin
- Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-… Anthony Nadalin
- Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-… David Chadwick
- Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-… John Bradley