Hi Dick, interesting point about encrypted payloads.
People more cryptographically-inclined than me might want to chime in, but I do seem to remember that there is a "correct" choice among the "encrypt-then-sign" and "sign-then-encrypt" alternatives. A quick search seems to suggest that the latter is what you want: https://www.pluralsight-training.net/community/blogs/craig/archive/2003/06/30/837.aspx . So I would suggest that encrypted payloads are implemented as an encryption of a JSON Token, as in: encrypted_token = encryption(JSON_Token) || "." || envelope envelope = base64(JSON(everything you need to know to decrypt)) What do you think? Dirk. On Mon, Jun 21, 2010 at 7:43 AM, Dick Hardt <dick.ha...@gmail.com> wrote: > Thanks for writing this up Dirk. > > I would suggest that the token be: > > payload "." envelope "." signature > > This enables the payload to be encrypted and independent from the > envelope. > > Token signing, verification, encryption and decryption code can then be > generic and not understand the payload of the token. > > I would only include issuer, key_id and alg in the envelope. > > Audience, scope, nonce, and validation time information etc. would be in > the payload. > > -- Dick > > On 2010-06-21, at 12:04 AM, Dirk Balfanz wrote: > > Hi guys, > > I think I owe the list a proposal for signatures. > > I wrote something down that liberally borrows ideas from Magic > Signatures<http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html>, > SWT <http://groups.google.com/group/WRAP-WG/files>, and (even the name > from) JSON Web > Tokens<https://groups.google.com/group/WRAP-WG/browse_thread/thread/a99369c4b74d4cd0#> > . > > Here is a short document (called "JSON Tokens") that just explains how to > sign something and verify the signature: > > http://docs.google.com/document/pub?id=1kv6Oz_HRnWa0DaJx_SQ5Qlk_yqs_7zNAm75-FmKwNo4 > > Here is an extension of JSON Tokens that can be used for signed OAuth > tokens:<http://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU> > > http://docs.google.com/document/pub?id=1JUn3Twd9nXwFDgi-fTKl-unDG_ndyowTZW8OWX9HOUU > > Here is a different extension of JSON Tokens that can be used for 2-legged > flows. The idea is that this could be used as a drop-in replacement for SAML > assertions in the OAuth2 assertion flow: > > http://docs.google.com/document/pub?id=1s4kjRS9P0frG0ulhgP3He01ONlxeTwkFQV_pCoOowzc > > I also have started to write some > code<http://code.google.com/p/jsontoken/source/browse/#svn/trunk/src/main/java/net/oauth/signatures>to > implement this as a proof-of-concept. > > Thoughts? Comments? > > Dirk. > > _______________________________________________ > 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
