The following text is included about the potential privacy issue in JWT draft
-10: "It is the responsibility of the application to ensure that only claims
that are safe to be transmitted in an unencrypted manner are replicated as
Header Parameter values in the JWT."
-- Mike
From: [email protected] [mailto:[email protected]] On Behalf Of Dick
Hardt
Sent: Wednesday, May 29, 2013 8:48 AM
To: Anthony Nadalin
Cc: O Auth WG
Subject: Re: [OAUTH-WG] JWT: add "iss" and "aud" to Reserved Header Parameter
Names in JWE
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
<[email protected]<mailto:[email protected]>> wrote:
So there could be privacy issues on why I would not want the ISS or AUD outside
the encrypted payload
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]<mailto:[email protected]>] 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
<[email protected]<mailto:[email protected]>> 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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
