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

So my litmus test was looking on the web for "web base 64" or "web base64".
Both yield nothing useful. Looking at the docs for PHP, it doesn't seem to
support it, Python does, Ruby doesn't seem to. Java doesn't seem to have a
native base64, and the C# one doesn't seem to have the web version (a bit
unsure about these two). The point I'm trying to make is to someone who
comes and reads the docs for an API where we're talking about signature, web
base64 will need to be explained in detail.

I agree eliminating encoding problems is a good goal. But if we do have to
teach the developer a new, or slightly modified encoding scheme, why not
have it be URL encoding? It seems more valuable in the long term, since it's
a spec that shows up more frequently on the web. And OAuth 1 has already
taught this spec to at least some of the target audience.

While encoding/decoding with any format will result in some learning, I
think if we sign a JSON blob sans urlencoding or web-base64, it might work
out to be easier. The fact that it's still mostly plain text is also a plus
imho.

-Naitik

On Fri, Jun 25, 2010 at 1:36 PM, John Panzer <jpanzer@google.com> wrote:

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