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

From: Naitik Shah <[email-masked]>
Date: Thu, 24 Jun 2010 11:33:59 -0700

I've been following some of the discussions wrt the new Signature proposal,
and I think I get the reason for needing Base64, but wasn't quite sure if I
understood it correctly (allows the use of a separator?). Would someone
mind elaborating?

The payload looks is urlencode(web_base64(json_encode(data))) -- and the
urlencode in this case should be an identity function.

I'm wondering if urlencode(json_encode(data)) would be acceptable.

Thanks,
-Naitik

---

From: Luke Shepard <[email-masked]>
Date: Fri, 25 Jun 2010 10:49:05 -0700

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?

On Jun 24, 2010, at 11:33 AM, Naitik Shah wrote:

> I've been following some of the discussions wrt the new Signature proposal, and I think I get the reason for needing Base64, but wasn't quite sure if I understood it correctly (allows the use of a separator?). Would someone mind elaborating?
> 
> The payload looks is urlencode(web_base64(json_encode(data))) -- and the urlencode in this case should be an identity function.
> 
> <ATT00001..txt>

---

From: Breno <[email-masked]>
Date: Fri, 25 Jun 2010 11:39:49 -0700

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

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
Breno de Medeiros

---

From: Naitik Shah <[email-masked]>
Date: Fri, 25 Jun 2010 12:15:31 -0700

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

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

---

From: John Panzer <[email-masked]>
Date: Fri, 25 Jun 2010 13:36:12 -0700

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
[email-masked] / abstractioneer.org <http://www.abstractioneer.org/> /
@jpanzer

On Fri, Jun 25, 2010 at 12:15 PM, Naitik Shah <[email-masked]> wrote:

> On Fri, Jun 25, 2010 at 11:39 AM, Breno <[email-masked]>wrote:
>
> 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

---

From: Naitik Shah <[email-masked]>
Date: Fri, 25 Jun 2010 16:42:13 -0700

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

---

From: Dick Hardt <[email-masked]>
Date: Fri, 25 Jun 2010 17:21:40 -0700

The RFC term is base64url which turns up much better results when searching. "URL safe base64" is also a good search term.

Note that the token may also be included in the HTTP header. base64url encoding works well for HTTP headers. Note that the token is opaque to the client, so being plain text is not as useful as it may seem. Unlike URL encoding, it is pretty easy to see if a string is base64url or not. With URL encoding, it may or may not be encoded which sometimes leads to double encoding / mismatched encoding.

-- Dick

On 2010-06-25, at 4:42 PM, Naitik Shah wrote:

> 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
> 
> 
> 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
> [email-masked] / abstractioneer.org / @jpanzer
> 
> 
> 
> 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
> 
> 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
>