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