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 <michael.jo...@microsoft.com> 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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
