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 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
