looks good to me!
On Sun, Jul 14, 2013 at 7:56 PM, Mike Jones <michael.jo...@microsoft.com>wrote: > 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:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *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 <tony...@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-boun...@ietf.org [mailto:oauth-boun...@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.ha...@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 **** >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
