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

There are 2 characters that are different between base64 and base64url.
 Many good libraries support both (as they're both useful, and both are in
the base64 RFC spec); the ability to eliminate a class of encoding problems
seems like a good trade-off for, in some languages without full base64
support, an additional substitution of 2 characters.

--
John Panzer / Google
jpanzer@google.com / abstractioneer.org <http://www.abstractioneer.org/> /
@jpanzer

On Fri, Jun 25, 2010 at 12:15 PM, Naitik Shah <n@daaku.org> wrote:

> On Fri, Jun 25, 2010 at 11:39 AM, Breno <breno.demedeiros@gmail.com>wrote:
>
>> On Fri, Jun 25, 2010 at 10:49 AM, Luke Shepard <lshepard@facebook.com>
>> 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
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>