Thanks for writing this. A few questions... Do we need both `issuer` and `key_id`? Shouldn't we use `client_id` instead at least for OAuth?
Can we write out algorithm instead of `alg`? How do you generate the body hash? Does "websafe-base64-encoded" mean that I can't just blindly use my languages built in base64 encode function? Don't we still have the more fundamental question to answer about decoupling what's being signed from the underlying HTTP request? --David On Mon, Jun 21, 2010 at 12:04 AM, Dirk Balfanz <balf...@google.com> wrote: > Hi guys, > I think I owe the list a proposal for signatures. > I wrote something down that liberally borrows ideas from Magic Signatures, > SWT, and (even the name from) JSON Web Tokens. > 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 > 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 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
