Re: [OAUTH-WG] OAuth Signature

[Nat Sakimura <[e-mail]>]

On Wed, Jul 28, 2010 at 1:12 AM, Dirk Balfanz <[e-mail]> wrote:
>
>
> On Tue, Jul 27, 2010 at 12:34 AM, Nat Sakimura <[e-mail]> 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