Re: [OAUTH-WG] JWT: add "iss" and "aud" to Reserved Header Parameter Names in JWE

Dick Hardt <dick.hardt@gmail.com> Wed, 29 May 2013 15:47 UTC

Return-Path: <dick.hardt@gmail.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 2F9F821F9590 for <oauth@ietfa.amsl.com>; Wed, 29 May 2013 08:47:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.855
X-Spam-Level:
X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 dEsGe8oe1yGy for <oauth@ietfa.amsl.com>; Wed, 29 May 2013 08:47:36 -0700 (PDT)
Received: from mail-bk0-x22d.google.com (mail-bk0-x22d.google.com [IPv6:2a00:1450:4008:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E907821F9509 for <oauth@ietf.org>; Wed, 29 May 2013 08:47:35 -0700 (PDT)
Received: by mail-bk0-f45.google.com with SMTP id je9so4395559bkc.18 for <oauth@ietf.org>; Wed, 29 May 2013 08:47:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OhM3v3GTvT+QRl77FvEFKCglVKc+Lpnw21FMxdCSEqE=; b=S4Z5JiVwvxkTWbrnPc2825iaY4r+nm+Bq4r4v5qDd1DeeGyVK/cJyzatcxrDh4u8DD zNK11bvO8QsZTBx4WeFBnisVv1ajgJSUcbDRyhcNaCKhwTI9MmZTdOCSzZIGY3TgEJpw u+Zp1q3XNqkFSPdhZZ/g2bBDnwNWsL6vVUpUaOgbYQxfJJm+mWSG4eqqD5YJpUYJ83HA e5dXiHGZdfWaa3gdOlMovVMLpqJ4LEFp/ehuwl8UBMppmKEMgDNHNTlJoo/cGn44WGGi /aEg4txeQ2NXc8xfawBIfuZY9hkx6bCyEcWf8OWLAtdbTx2WvADWMWBMGCTlyhw8V3MH RHNA==
MIME-Version: 1.0
X-Received: by 10.204.170.200 with SMTP id e8mr824504bkz.168.1369842454971; Wed, 29 May 2013 08:47:34 -0700 (PDT)
Received: by 10.204.228.8 with HTTP; Wed, 29 May 2013 08:47:34 -0700 (PDT)
In-Reply-To: <bdf66a4a6ade4c9f967b6ec2e5893f7d@BY2PR03MB189.namprd03.prod.outlook.com>
References: <4858A2E2-6F15-4D25-9909-E8F2AA15797E@gmail.com> <CAD9ie-sh-3jfL-aq7cmSp0hGaKust6-nM704CPz4Lh19G5w9KA@mail.gmail.com> <bdf66a4a6ade4c9f967b6ec2e5893f7d@BY2PR03MB189.namprd03.prod.outlook.com>
Date: Wed, 29 May 2013 08:47:34 -0700
Message-ID: <CAD9ie-u7H4N7C6QR5qs3MBwaYJRs9m2Ya4+DvO5kzEJzMACJhA@mail.gmail.com>
From: Dick Hardt <dick.hardt@gmail.com>
To: Anthony Nadalin <tonynad@microsoft.com>
Content-Type: multipart/alternative; boundary="bcaec52c6635ed895704dddd4c0b"
Cc: O Auth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] JWT: add "iss" and "aud" to Reserved Header Parameter Names in JWE
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: Wed, 29 May 2013 15:47:37 -0000

Yes, there could be privacy issues, and we can describe that as a
consideration in the specification. It is not an issue in my use case.


On Wed, May 29, 2013 at 8:23 AM, Anthony Nadalin <tonynad@microsoft.com>wrote:

>  So there could be privacy issues on why I would not want the ISS or AUD
> outside the encrypted payload****
>
> ** **
>
> *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf
> Of *Dick Hardt
> *Sent:* Tuesday, May 28, 2013 9:34 AM
> *To:* O Auth WG
> *Subject:* Re: [OAUTH-WG] JWT: add "iss" and "aud" to Reserved Header
> Parameter Names in JWE****
>
> ** **
>
> Following up on this topic ... ****
>
> ** **
>
> On Wed, May 1, 2013 at 2:12 PM, Dick Hardt <dick.hardt@gmail.com> wrote:**
> **
>
> "iss" and "aud" would be optional parameters in a JWE. These parameters
> are in the payload, but since it is encrypted, the payload must be
> decrypted before they can be read. Some times knowing these parameters is
> required to be able to decrypt the payload …
>
> These would be additions to 9.3.1 in the JWT specification.
>
> 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.****
>
>
>
> ****
>
> ** **
>
> --
> -- Dick ****
>



-- 
-- Dick