If nobody does, I could since this is one of the most crucial piece that I need.
=nat @ Tokyo via iPhone On 2010/07/27, at 17:36, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > Is someone going to turn this into an I-D anytime soon? > > > > EHL > > > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > Dirk Balfanz > Sent: Tuesday, July 27, 2010 4:04 PM > To: Nat Sakimura > Cc: oauth > Subject: Re: [OAUTH-WG] OAuth Signature > > > > > > On Tue, Jul 27, 2010 at 3:35 PM, Nat Sakimura <sakim...@gmail.com> wrote: > > On Wed, Jul 28, 2010 at 1:12 AM, Dirk Balfanz <balf...@google.com> wrote: > > > > > > On Tue, Jul 27, 2010 at 12:34 AM, Nat Sakimura <sakim...@gmail.com> wrote: > >> > >> I have a fundamental question. > >> > >> While separating signature and payload by a dot "." seems ok, > >> I still have not the answer for the question "why not make everything > >> into JSON and base64url it?". > >> > >> i.e., Right now, you are proposing: > >> > >> base64url_encode(JSON(payload,envelope)).base64url_encode(signature) > >> > >> Why not > >> > >> base64url_encode(JSON(payload,envelope,signature) > > > > You need to say what exactly the signature is over. Presumably, it's over > > some representation of the payload and envelope, but you need to specify > > exactly which representation. So in this case you would have to say > > something like "the signature is over the concatenation of the > > base64-encodings of the JSON-encodings of the payload and envelope", or > > something along those lines. If you did exactly this, then you would base-64 > > encode twice. Similar issues come up if you change the definition of what > > the signature is over slightly. > > I did not spell out my question correctly. The pseudo code was very > misleading. > By "JSON()" I was meaning something similar to magic signature json encoding > or something similar because I was mainly comparing JSON Token and > Magic Signature. > Of course, that cannot be read from what I wrote. Sorry for that. > > My question is: > "why not just use a profiled/modified version of Magic Signature" > > > > I think that's a fair question - in fact, I was sort of aiming for just that. > Once I get a free minute, I'll see whether there is a way to write this as an > MS profile... > > > > Dirk. > > > > > I do not want to have two signature methods. > If the currently proposed signature method can be unified with magic > signature, > it would be great. > > > > > >> > >> It probably is less hassle in terms of coding. (It is true that some > >> parameters gets base64url encoded twice but > > > > How is encoding things twice "less hassle"? > > > >> > >> BTW, some of the envelope parameters such as alg needs to be signed as > >> well to thwart the algorithm replacing attack. > > > > Yes, of course. Remember that in the current proposal I don't have an > > envelope - everything is in the payload. That's partly because I didn't want > > to decide what gets signed and what doesn't - everything is signed. Which in > > this case is easy (alternatively, I guess, you could just say that both the > > envelope and the payload are signed). But it gets harder when you want to > > encrypt the token. In this case you really need to leave some parts > > unencrypted (so the recipient has _some_ information on how to decrypt the > > thing) - presumably those parts would go into an envelope. > > Dirk. > > > > > >> > >> -- > >> Nat Sakimura (=nat) > >> http://www.sakimura.org/en/ > >> http://twitter.com/_nat_en > > > > > > > > -- > > Nat Sakimura (=nat) > http://www.sakimura.org/en/ > http://twitter.com/_nat_en > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
