Re: [OAUTH-WG] Understanding the reasoning for Base64

[Naitik Shah <[e-mail]>]

On Fri, Jun 25, 2010 at 11:39 AM, Breno <[e-mail]> wrote:

> On Fri, Jun 25, 2010 at 10:49 AM, Luke Shepard <[e-mail]>
> wrote:
> > Brian, Dirk - just wondering if you had thoughts here?
> >
> > The only strong reason I can think of for base64 encoding is that it
> allows for a delimiter between the body and the signature. Is there any
> other reason?
>
> Without base64 encoding we have to define canonicalization procedures
> around spaces and we still have to URL encode separator characters
> such as {. There is also the risk that developers might be confused
> whether the URL encoding is to be performed before or after
> computation of the signature.  If you say that the signature is
> computed on the base64 encoded blob, there's less scope for confusion
> and interoperability issues.
>
>
Yep, I get that the "web" version makes the url encoding a no op. But I fear
we're trading one spec (urlencoding) to another one (web base64). I'm
imagining the sample code (that does not rely on an SDK) we'ed give out to
developers in our docs, and the thing that stands out is the "web" part in
the web_base64. It means that our sample code will look like

  str_replace("+", "_", base64(json_encode(data))))

or for validating signatures:

  json_decode(decode64(str_replace("_", "+", data)))

The str_replace() really stands out. From my quick read, it seemed like
there were one or two other characters that needed to get replaced too.
While some languages (like PHP) support arrays to specify multiple
replacement patterns, in other languages you'll end up with a few
str_replace calls. It would be nice if that wasn't necessary.

I'm wondering if we can get away with "urlencode(json_encode(data) + '.' +
sig)" as the value. then, instead of str_replace for getting normal base64
logic to work, we would instead need a rsplit or something, since the dot is
not a reserved character in the json blob. Was that approach considered?


-Naitik