Re: [OAUTH-WG] OAuth Signature

[Nat <[e-mail]>]

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-mail]> wrote:

> Is someone going to turn this into an I-D anytime soon?
> 
>  
> 
> EHL
> 
>  
> 
> From: [e-mail] [mailto:[e-mail]] 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 <[e-mail]> wrote:
> 
> 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 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
> 
>