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
>
>
> On Fri, Jun 25, 2010 at 1:36 PM, John Panzer <jpan...@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
> jpan...@google.com / 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.demedei...@gmail.com> wrote:
> On Fri, Jun 25, 2010 at 10:49 AM, Luke Shepard <lshep...@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
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
