Re: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names

Dick Hardt <dick.hardt@gmail.com> Thu, 04 April 2013 20:42 UTC

Return-Path: <dick.hardt@gmail.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8AC021F8CB5 for <jose@ietfa.amsl.com>; Thu, 4 Apr 2013 13:42:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.724
X-Spam-Level:
X-Spam-Status: No, score=-2.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdwo0f7nAexZ for <jose@ietfa.amsl.com>; Thu, 4 Apr 2013 13:42:31 -0700 (PDT)
Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) by ietfa.amsl.com (Postfix) with ESMTP id 53F6E21F8C14 for <jose@ietf.org>; Thu, 4 Apr 2013 13:42:31 -0700 (PDT)
Received: by mail-pd0-f175.google.com with SMTP id g10so1403203pdj.6 for <jose@ietf.org>; Thu, 04 Apr 2013 13:42:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=kv1m03fENvd15Ls14HSGYCcDL12m2DZWYyavrhje6D0=; b=ECIPdw12ADmHQpPbw0Jrpevg2ul3K9wu3kQSpSEATAiy/nbEc+bX4aQos/WE90tsuH cvz7YphSGZARHQn0kJL5j9x5lQdz0M6tLSBEBPC2Gta4a6rj4UuYtYG7H4Y1KqbrtHJB fmRf9MhigyIvrWqT2gA91RmxEen30WtGMG2ylCAoODzeXyV9LqydmddRnDzYwtxt85Nt w2XhPJEg7YeP6rz0I7xwZDdUiBtels9dy+weheAwnXKPMpPi32v/AQQX4nSDdHkss3BF 9gwhEsBS7wQpi00zm9kydVlfVv3Cu8z6mj125++YEUHPVHNR4xdrqldyHyvm04c8UFtp jwJw==
X-Received: by 10.67.1.39 with SMTP id bd7mr11223538pad.194.1365108151009; Thu, 04 Apr 2013 13:42:31 -0700 (PDT)
Received: from [10.0.0.80] (c-98-210-193-30.hsd1.ca.comcast.net. [98.210.193.30]) by mx.google.com with ESMTPS id kt5sm11403808pbc.30.2013.04.04.13.42.26 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Apr 2013 13:42:27 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Dick Hardt <dick.hardt@gmail.com>
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943675B4F79@TK5EX14MBXC283.redmond.corp.microsoft.com>
Date: Thu, 04 Apr 2013 13:42:25 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <5798695B-C14A-4603-BEB7-18A3354DFB77@gmail.com>
References: <059.28920e1fc6703f74a91ab3b3829a8a57@trac.tools.ietf.org> <074.45573b920fde1863b2b824557b6bbbe8@trac.tools.ietf.org> <70DD0047-E4B5-4A00-A74D-B4B3CC67D68E@gmail.com> <4E1F6AAD24975D4BA5B1680429673943675B4F79@TK5EX14MBXC283.redmond.corp.microsoft.com>
To: Mike Jones <Michael.Jones@microsoft.com>
X-Mailer: Apple Mail (2.1503)
Cc: rlb@ipv.sx, draft-ietf-jose-json-web-encryption@tools.ietf.org, jose@ietf.org
Subject: Re: [jose] #17: add 'aud' and 'iss' to 4.1 Reserved Header Parameter Names
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Apr 2013 20:42:32 -0000

On Apr 4, 2013, at 9:32 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

> Responding to your "unsettled" remark, I suspect most people are fine with having the "aud" and "iss" be claims in the JWT where they normally are.  Yes, you have to decrypt the token to get these claim values, but if you're going to use the token, you'll have to do that anyway.
> 
> I don't think it's clear to most people what problem is being solved by potentially these fields to be present in a different location.  Without a compelling use case, this just seems like more to implement without a clear benefit of doing so.


I will see if I can explain the use case better.

Why "iss" is needed:


Bob and Charlie each gave Alice a KID and a symmetric key to use to verify and decrypt tokens from them. 

The App and Alice share keys so Alice knows it is the App.

The User authorizes Bob to give the App a token (which authorizes the App to do something)

The App gives the token to Alice.

Since Alice indirectly received the token,  the only way for Alice to know who sent the token, is to look at the KID as the "iss" claim is encrypted. If the "kid" values are GUIDs, then Alice can just look up the "kid" and retrieve the associated symmetric key, and then decrypt and verify the token and THEN see who sent it. If there is a collision in KID values (Bon and Charlie gave the same KID for different keys), then Alice will not know which symmetric key to use.

Why "aud" is needed:

Dave gives a KID and symmetric key to Ellen, and Frank gives a KID and symmetric key to Gwen. 

Ellen and Gwen trust each other and know how to talk to each other. Gwen does not know Dave. Ellen does not know Frank

The App and Gwen share keys so Gwen knows it is the App.

The User authorizes Dave to give the App a token

Dave gives the token to Gwen (Dave does not have a relationship with Ellen)

Gwen now has a token that Ellen can decrypt and verify, but has no method for knowing that Ellen can do that. The "aud" property would allow Gwen to give the token to Ellen to decrypt and verify.

Feel free to ask for clarifications.

This is what is happening in A2P3 that enables a distributed system.

-- Dick