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

Dick Hardt <> Thu, 02 May 2013 02:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9D4C721F9A56 for <>; Wed, 1 May 2013 19:00:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W6g1OVyaExrB for <>; Wed, 1 May 2013 19:00:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D915B21F9A54 for <>; Wed, 1 May 2013 19:00:00 -0700 (PDT)
Received: by with SMTP id bg2so71251pad.11 for <>; Wed, 01 May 2013 19:00:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=9a6aq48ZAjqDXYh+Jl2AMEP6w0h2lWC9rwxDdXybUJ8=; b=FyA3RvYa8h5zUyhrtFYuhvK4ohfcEoftSDXVyoW43j4vMK+lVlWr1wVRd/Q9tCorvC tubfkLniFXLqVlApn0h9DXFsmK1z/qowMpnkaf00kA0ksMk8MzpZRrFXuCbHDIo05azz ujOk6YFXRXq53kArrppVoFm5lmdn9WmNbNKkkIRqtmdm23Zw/7XT0BEvL11ghUypN6qy CMdZDNHmVArCO2gTrB7UIQ/difJ1ZrJk6pGECWG2P7S0BlcLuv+Swy35Nh59+cV1Pb7U p4Cs1a4NLFZQ/Q1u92O+nYeEqLLaZ7CadVV7tMbw4MrDUsU8+MjwotoEy0/koOFWJH8f XdBQ==
X-Received: by with SMTP id al1mr7525858pad.111.1367460000383; Wed, 01 May 2013 19:00:00 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id t1sm5948680pab.12.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 May 2013 18:59:59 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Dick Hardt <>
In-Reply-To: <>
Date: Wed, 01 May 2013 18:59:57 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Mike Jones <>
X-Mailer: Apple Mail (2.1503)
Cc: O Auth WG <>
Subject: Re: [OAUTH-WG] JWT: add "iss" and "aud" to Reserved Header Parameter Names in JWE
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 02 May 2013 02:00:05 -0000

Hi Mike

That answer makes the most sense to me as those values are often required when processing a payload as well, and they should be consistent. I'd be interested to hear any other opinions though!

-- Dick

On May 1, 2013, at 3:48 PM, Mike Jones <> wrote:

> Thanks for writing this, Dick.  I think I understand your requirements and why they exist.
> One question you didn't answer that will come up is whether these fields must also be present in the JWT claims set if they're present in the JWE header.  The logical answer to me seems to be something like "All claims MUST be present in the JWT Claims Set; specified claims MAY also be duplicated in the JWE header, and if present there, must have exactly the same values as in the JWT Claims Set."
> Is that the way that you imagined this working?
> 				-- Mike
> -----Original Message-----
> From: [] On Behalf Of Dick Hardt
> Sent: Wednesday, May 01, 2013 2:12 PM
> To: O Auth WG
> Subject: [OAUTH-WG] JWT: add "iss" and "aud" to Reserved Header Parameter Names in JWE
> "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.
> _______________________________________________
> OAuth mailing list