Re: [OAUTH-WG] [COSE] A draft on CBOR Web Tokens (CWT)

Hannes Tschofenig <Hannes.Tschofenig@arm.com> Tue, 17 November 2015 07:22 UTC

Return-Path: <hannes.tschofenig@arm.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 B9B481B2BCC for <oauth@ietfa.amsl.com>; Mon, 16 Nov 2015 23:22:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 cG2o5NgrAYyp for <oauth@ietfa.amsl.com>; Mon, 16 Nov 2015 23:22:47 -0800 (PST)
Received: from eu-smtp-delivery-143.mimecast.com (eu-smtp-delivery-143.mimecast.com [146.101.78.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41B591B2BCB for <oauth@ietf.org>; Mon, 16 Nov 2015 23:22:46 -0800 (PST)
Received: from emea-cam-gw1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-31-QIHZRZLbTpSltOBEVznyuw-1; Tue, 17 Nov 2015 07:22:43 +0000
Received: from GB-CAM-EXCAS2.Emea.Arm.com (10.1.106.66) by emea-cam-gw1.Emea.Arm.com (10.1.248.203) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 17 Nov 2015 07:22:42 +0000
Received: from emea01-db3-obe.outbound.protection.outlook.com (10.1.2.79) by nebula.arm.com (10.1.106.66) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 17 Nov 2015 07:22:41 +0000
Received: from HE1PR08MB0732.eurprd08.prod.outlook.com (10.163.179.30) by HE1PR08MB0729.eurprd08.prod.outlook.com (10.163.179.27) with Microsoft SMTP Server (TLS) id 15.1.325.17; Tue, 17 Nov 2015 07:22:40 +0000
Received: from HE1PR08MB0732.eurprd08.prod.outlook.com ([10.163.179.30]) by HE1PR08MB0732.eurprd08.prod.outlook.com ([10.163.179.30]) with mapi id 15.01.0325.003; Tue, 17 Nov 2015 07:22:40 +0000
From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
To: William Denniss <wdenniss@google.com>
Thread-Topic: [COSE] A draft on CBOR Web Tokens (CWT)
Thread-Index: AQHRHX3DyXQEi0Hb60mPSXqbnVxSe56YykQAgAAEkACAAHpjAIAFe1lwgABs4oCAAKM5oA==
Date: Tue, 17 Nov 2015 07:22:39 +0000
Message-ID: <HE1PR08MB0732DEC772A47528634F1F5CFA1D0@HE1PR08MB0732.eurprd08.prod.outlook.com>
References: <53BB1987-979C-4945-9C7D-CDB6619AEFFC@nexusgroup.com> <5644EC40.4010002@tzi.org> <73929C18-A3E7-4ACA-A6DC-5A7AD7576C9B@nexusgroup.com> <CAAP42hAWfBRKw-3OM1dPkgK40Af4KVBaVdhzdAGhon=VFV6LSA@mail.gmail.com> <HE1PR08MB07324FD345F82CF6EC3AEAE3FA1E0@HE1PR08MB0732.eurprd08.prod.outlook.com> <CAAP42hD2xsOGT5_iFQ2QZD5Om8Xkj0Z3vAFTk5ZhimM+Nf9X0Q@mail.gmail.com>
In-Reply-To: <CAAP42hD2xsOGT5_iFQ2QZD5Om8Xkj0Z3vAFTk5ZhimM+Nf9X0Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [80.92.121.34]
x-microsoft-exchange-diagnostics: 1; HE1PR08MB0729; 5:+CZctf+5eO8FrnAdHw87oYCPjCuZIdmOo3wgtGWVqeh4/G29yn1UUAw03jLNVqDGGYgj9z0YpD+j3u20J74BAYTu0DPtFgI1JkXs+Cn9KLNHeYPlfRdbawZJjcyeHlHnyym8pygbArFbRWF9MYFdpw==; 24:8G3KPSAwZqgriAHaUhX6HQvRgH6AG49Zh6OENUlTxwCD7IUSFscquuQP6vCGEz4tBhMB0i4UDGttnwRxnDSYS44XvwC+/nZPd/37T2zhbYw=; 20:Jt+0yU8pFr+GUSnS+HN/g1iaJ/Qw7bvSQSQn0G7/17O44/2hHLpQiutTHenLzt3FB8aI6Gxwi17N/0Gn3x/jdN/yZz2Rhn31wxEzGGtszmFSE7UAn1Hcq7UzkMjxIRxCI9nkNAgLlyeo/hc94eVooR0xgXPdxg+IKJeT/IzuWh0=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR08MB0729;
x-microsoft-antispam-prvs: <HE1PR08MB072947D36701B859D5E5EDA5FA1D0@HE1PR08MB0729.eurprd08.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(211936372134217)(108003899814671);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(10201501046)(3002001); SRVR:HE1PR08MB0729; BCL:0; PCL:0; RULEID:; SRVR:HE1PR08MB0729;
x-forefront-prvs: 07630F72AD
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(164054003)(40434004)(189002)(377454003)(199003)(76576001)(97736004)(33656002)(19580395003)(5001960100002)(92566002)(2950100001)(74316001)(102836002)(105586002)(81156007)(189998001)(5004730100002)(110136002)(5007970100001)(15975445007)(106116001)(5003600100002)(10400500002)(5890100001)(11100500001)(40100003)(586003)(106356001)(19580405001)(77096005)(101416001)(19300405004)(2900100001)(16236675004)(5008740100001)(50986999)(66066001)(93886004)(19625215002)(561944003)(5002640100001)(86362001)(54356999)(87936001)(76176999)(122556002)(19617315012); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR08MB0729; H:HE1PR08MB0732.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2015 07:22:40.0462 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR08MB0729
X-OriginatorOrg: arm.com
X-MC-Unique: QIHZRZLbTpSltOBEVznyuw-1
Content-Type: multipart/alternative; boundary="_000_HE1PR08MB0732DEC772A47528634F1F5CFA1D0HE1PR08MB0732eurp_"
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/ztePvrbky_93pIKwcTJ4DMdJHrI>
X-Mailman-Approved-At: Mon, 16 Nov 2015 23:25:58 -0800
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] [COSE] A draft on CBOR Web Tokens (CWT)
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: <https://mailarchive.ietf.org/arch/browse/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, 17 Nov 2015 07:22:51 -0000

Hi William,

You are indeed correct that the current document contains a list of one-by-one copies of claims from the JWT. The only difference is the data type. Probably it would have been better to just reference the semantic from the JWT spec and then state the new data type.

I fully understand the concern of defining CWT claims that have the same name as JWT claims but then different semantic. This would be terribly confusing.

Ciao
Hannes

From: William Denniss [mailto:wdenniss@google.com]
Sent: 16 November 2015 22:32
To: Hannes Tschofenig
Cc: Erik Wahlström neXus; Carsten Bormann; Mike Jones; <oauth@ietf.org>
Subject: Re: [COSE] A draft on CBOR Web Tokens (CWT)

You raise some good points, and perhaps that is relevant to future claims. The spec as drafted, is a one-for-one copy of the standard JWT claims, which is why I raised this point.

Is the goal a CBOR representation of a JWT? If so, can it be defined in terms of a JWT?  Would the CNF claim then inherit that representation (treating the JWE and JWK as their CBOR equivalents)?

Perhaps if you go the separate registry route, those claims that *are* defined the same should at least normatively reference JWT?  I want to avoid the whole "on behalf of" / "act as" fiasco where things can get re-defined, and muddled.

On Mon, Nov 16, 2015 at 7:09 AM, Hannes Tschofenig <Hannes.Tschofenig@arm.com<mailto:Hannes.Tschofenig@arm.com>> wrote:
Hi William,

I have been trying to do a document update to see how well a combined registry works and I have been wondering whether it is really worth the effort.
To make a good judgment I looked at the CNF claim defined in draft-ietf-oauth-proof-of-possession. The CNF claim may contain sub-elements, such as a JWE or a JWK.

If we translate the same mechanisms to the CWT (which makes sense) then we need to point to the respective COSE structures instead. Those do not only use a different encoding but also the functionality does not match the JOSE structures 100%. So, there are potentially differences. I am also not sure whether we really want to translate the full functionality of all the claims from JWT over to the CWT equivalent. It basically puts the burden on someone defining new claims (either in JWT or in CWT) to create the corresponding structures in a format they may not necessarily be familiar with or even care about. I have seen that happening in the RADIUS world protocol designers had to also define the equivalent structures for use with Diameter and, guess what, most of the definitions were wrong (since the authors did not care about Diameter when working on RADIUS).

Ciao
Hannes


From: William Denniss [mailto:wdenniss@google.com<mailto:wdenniss@google.com>]
Sent: 12 November 2015 19:19
To: Erik Wahlström neXus
Cc: Carsten Bormann; Hannes Tschofenig; Mike Jones; cose@ietf.org<mailto:cose@ietf.org>; <oauth@ietf.org<mailto:oauth@ietf.org>>; ace@ietf.org<mailto:ace@ietf.org>
Subject: Re: [COSE] A draft on CBOR Web Tokens (CWT)

Regarding the draft itself, a few comments:

1.
Can we unify the claim registry with JWT? I'm worried about having the same claims defined twice in CWT and JWT with possibly conflicting meanings (and needless confusion even when they do match).

Comparing https://tools.ietf.org/html/draft-wahlstroem-oauth-cbor-web-token-00#section-3.1.2 and https://tools.ietf.org/html/rfc7519#section-4.1.2 which are nearly identical, I just don't see the value in re-defining it.

We may add new standard claims to JWT in the future (I proposed one<https://mailarchive.ietf.org/arch/search/?email_list=id-event&gbt=1&index=7qNUnaE9lt2LyayMnmNyWpZSIEM> in Yokohama on the id-event list<https://www.ietf.org/mailman/listinfo/id-event>)t>), it would be good if this didn't need a separate entry in CWT too, but could just apply directly (separately, I think you should consider this claim, as it helps prevent tokens from being re-used in the wrong context).

2.
Is Section 4 "Summary of CBOR major types used by defined claims" normative (https://tools.ietf.org/html/draft-wahlstroem-oauth-cbor-web-token-00#section-4)? What is the intention of this section? I feel like it could probably be fleshed out a bit.

3.
Add a xref to draft COSE spec in section 6<https://tools.ietf.org/html/draft-wahlstroem-oauth-cbor-web-token-00#section-6>
Add xref to RFC7519

On Thu, Nov 12, 2015 at 12:01 PM, Erik Wahlström neXus <erik.wahlstrom@nexusgroup.com<mailto:erik.wahlstrom@nexusgroup.com>> wrote:
Hi Carsten,

Thanks, and I agree. I’ve heard arguments for all three work groups.

Borrowed some of your words to define the content of the draft :)
It’s it essentially a JWT, phrased in and profiled for CBOR to address ACE needs, where OAuth needs COSE functionality, for object security.

I’m open for letting the AD’s move it around, but having it right next to JWT seems right to me. Also open for the ACE WG. Feel it has less place in COSE for the same reasons JWT is not in the JOSE WG.

/ Erik


> On 12 Nov 2015, at 20:45, Carsten Bormann <cabo@tzi.org<mailto:cabo@tzi.org>> wrote:
>
> Hi Erik,
>
> having this draft is a good thing.
>
> One thing I'm still wondering is what WG is the best place to progress
> this.  We probably don't need to spend too much time on this because,
> regardless of the WG chosen, the people in another WG can look at it.
> Still, getting this right might provide some efficiencies.
>
> What is the technical content of this draft?  Is it a new token that
> OAuth needs specifically for the new COSE-based applications of OAuth?
> Is it a new token that is specifically there for addressing ACE needs?
> Or is it essentially the same substance as JWT, but phrased in and
> profiled for CBOR?
>
> Depending on the answer, CWT should be done in OAuth, ACE, or COSE.
> (I'd rather hear the answer from the authors than venture a guess myself.)
>
> Grüße, Carsten
>
>
>
> Erik Wahlström neXus wrote:
>> Hi,
>>
>> In the ACE WG a straw man proposal of a CBOR Web Token (CWT) was defined
>> in the draft "Authorization for the Internet of Things using OAuth 2.0”
>> [1]. We just broke out the CBOR Web Token into a separate draft and the
>> new draft is submitted to the OAUTH WG. It can be found here:
>>
>> https://datatracker.ietf.org/doc/draft-wahlstroem-oauth-cbor-web-token/
>>
>> Abstract:
>> "CBOR Web Token (CWT) is a compact means of representing claims to be
>> transferred between two parties.  CWT is a profile of the JSON Web Token
>> (JWT) that is optimized for constrained devices. The claims in a CWT are
>> encoded in the Concise Binary Object Representation (CBOR) and CBOR
>> Object Signing and Encryption (COSE) is used for added application layer
>> security protection.  A claim is a piece of information asserted about a
>> subject and is represented as a name/value pair consisting of a claim
>> name and a claim value."
>>
>> / Erik
>>
>>
>> [1] https://tools.ietf.org/html/draft-seitz-ace-oauth-authz-00
>>
>>
>> _______________________________________________
>> COSE mailing list
>> COSE@ietf.org<mailto:COSE@ietf.org>
>> https://www.ietf.org/mailman/listinfo/cose

_______________________________________________
COSE mailing list
COSE@ietf.org<mailto:COSE@ietf.org>
https://www.ietf.org/mailman/listinfo/cose


________________________________

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


________________________________

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.