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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
