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

Dick Hardt <dick.hardt@gmail.com> Mon, 27 September 2010 14:02 UTC

Return-Path: <dick.hardt@gmail.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84D103A6B36 for <oauth@core3.amsl.com>; Mon, 27 Sep 2010 07:02:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.488
X-Spam-Level:
X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9bmWpbuFBdN for <oauth@core3.amsl.com>; Mon, 27 Sep 2010 07:02:56 -0700 (PDT)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 74A933A6953 for <oauth@ietf.org>; Mon, 27 Sep 2010 07:02:56 -0700 (PDT)
Received: by pzk6 with SMTP id 6so1619252pzk.31 for <oauth@ietf.org>; Mon, 27 Sep 2010 07:03:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=AhD9e0woP4eVcsreRTF3OnCdpm8PsHEnTtpE8lhYdHQ=; b=KdBzUcyg+NuzcTOsdwOrIgb9/rGqC3HrxEMkx562NHiu50FkQ2Oprv3+lmFN+xPhln IbEk8Wxev2+YVcFrLA0+Bj2xccDz3pApRNsqj7DVHpqreqruxjH+04TgEW/vaQrLnTmf zsEvQJkNKTV7Qn695GWToyYKzgx/aX7lmOHIw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=Od5YaSQoYDbaMsuiHi1YcgtPJhbVTjHbHeuPJZW6UEZZvf9DAvw735kfEXox2+LohJ igGxs2UbOa38T6Z9m3seDd7HB/RdmdELJytMYsQYvmZy2T3Dhc7g8VpQJD0nnJFEovmx dQVIbuNN2LqAQBVvTfOEEchDI24dEI0A7RK9M=
Received: by 10.142.242.9 with SMTP id p9mr6450933wfh.325.1285596215225; Mon, 27 Sep 2010 07:03:35 -0700 (PDT)
Received: from [192.168.1.5] (c-24-130-32-55.hsd1.ca.comcast.net [24.130.32.55]) by mx.google.com with ESMTPS id n20sm6230751ibe.11.2010.09.27.07.03.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 27 Sep 2010 07:03:33 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/alternative; boundary="Apple-Mail-11-198848753"
From: Dick Hardt <dick.hardt@gmail.com>
In-Reply-To: <AANLkTikQEHWPVXr=PqYkCa1ezRMPGWj+hZ2eT0b37VQN@mail.gmail.com>
Date: Mon, 27 Sep 2010 07:03:30 -0700
Message-Id: <698B4D4E-3CC4-4E9C-86C0-4E7DA812D80B@gmail.com>
References: <4E1F6AAD24975D4BA5B168042967394313F95E5F@TK5EX14MBXC202.redmond.corp.microsoft.com> <9B677A76-F163-4542-B898-EFAF612D936B@gmail.com> <4E1F6AAD24975D4BA5B168042967394313FBA71C@TK5EX14MBXC202.redmond.corp.microsoft.com> <4E0C8F8A-15CE-47DF-B58D-A53C5FFB14A4@gmail.com> <AANLkTikQEHWPVXr=PqYkCa1ezRMPGWj+hZ2eT0b37VQN@mail.gmail.com>
To: David Recordon <recordond@gmail.com>
X-Mailer: Apple Mail (2.1081)
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] JSON Web Token (JWT) Specification Draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Mon, 27 Sep 2010 14:02:59 -0000

If you don't have an envelope, you don't have a standard way of looking at what the contents might be. It is like HTTP headers vs the body of the message. Fairly standard architectural practice that makes extensions easy instead of a hack.

There are many use cases where encryption is needed. People that need it are not participating in the WG now -- but the requirement was stated by numerous people at IIW a year ago when we presented WRAP. It is needed if you want higher LOA.

A common envelope makes it much easier, and makes supporting alternative signing mechanisms easier to deploy without busting existing code. 

History has shown time and time again that near sighted architectural approaches lead to pain later when something needs to be changed or added. Of course, over architected approaches never get deployed. I see adding an envelope a nice balance where one does not need to have figured everything out, but there is an clear extension mechanism separated from the payload.

On 2010-09-27, at 6:55 AM, David Recordon wrote:

> I thought the discussion from June had most people not needing encryption and an extra envelope. Given how Mike wrote this spec is seems like supporting encryption with an extra envelope is possible, but shouldn't be required if all you're doing is signing.
> 
> On Sun, Sep 26, 2010 at 9:55 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
> Don't put the signature information in the token, put it in a separate component (an envelope) that describes how the token is either signed or encrypted. See discussion from June:
> 
> http://www.ietf.org/mail-archive/web/oauth/current/msg03211.html
> 
> 
> On 2010-09-26, at 9:20 PM, Mike Jones wrote:
> 
>> I’d be open to a proposal for also supporting encryption.  The draft was intended to be a starting point for productive discussion – not a finished product.
>>  
>> Your thoughts?
>>  
>>                                                             -- Mike
>>  
>> From: Dick Hardt [mailto:dick.hardt@gmail.com] 
>> Sent: Sunday, September 26, 2010 9:17 PM
>> To: Mike Jones
>> Cc: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] JSON Web Token (JWT) Specification Draft
>>  
>> Did you intentionally decide not to support encrypting the token?
>>  
>> On 2010-09-23, at 5:22 PM, Mike Jones wrote:
>> 
>> 
>> Recognizing that there is substantial interest in representing sets of claims in JSON tokens, Yaron Goland and I have put together a draft JSON Web Token (JWT) spec for that purpose.
>>  
>> To answer the obvious question, while this was produced independently of Dirk’s JSON token proposal, both of us agree that we should come up with a unified spec.  Consider this an additional point in the possible design space from which to start discussions and drive consensus.  (If you read the two proposals, I think you’ll find that there’s already a lot in common, which is great.)
>>  
>> Thanks to those of you who have already given us feedback to improve the draft prior to this point.
>>  
>>                                                             Cheers,
>>                                                             -- Mike
>>  
>> <jwt.html><jwt.xml>_______________________________________________
>> 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
> 
>