On Tue, Jun 22, 2010 at 2:36 AM, Ben Laurie <b...@google.com> wrote: > On 22 June 2010 07:03, David Recordon <record...@gmail.com> wrote: > > 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? > > No, you need the websafe alphabet, which substitutes '-' and '_' for > '+' and '/' in the standard alphabet. Which reminds me, Dirk needs to > specify whether padding is used. >
(Padding _is_ part of the base64 specification IIRC; I think it'd be sufficient to artfully include it in the primary example -- and have a second example crafted so that there happens to be zero padding :) ). You can construct base64url() from base64() plus a substitution pass for -+ and _/ so it doesn't seem too onerous. (Make sure to include one of these characters in the examples too.) > > > Don't we still have the more fundamental question to answer about > > decoupling what's being signed from the underlying HTTP request? > Aside/my $.02: This is a key issue which Salmon+Magic Signatures evades by essentially treating the HTTP request (the method, URL, headers, etc.) as advisory/transport hints, to be ignored when reading the data, and making sure the protocol works even if the data is sent via carrier pigeon; all important information must be contained in the signed, structured body. This is much much harder if you have to deal with totally arbitrary kinds of requests with arbitrary semantics. This also means that you're effectively using HTTP as a simple transport to move envelopes around, in much the same way you can use the ocean to transport messages in bottles around, but a bit more efficiently. I've banged my head against this a bit and have not come up with a better solution but if there is one I'd love to hear it. > > > > --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 > > > _______________________________________________ > 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
