On Fri, Jun 25, 2010 at 11:39 AM, Breno <[email protected]> wrote:
> On Fri, Jun 25, 2010 at 10:49 AM, Luke Shepard <[email protected]> > 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 [email protected] https://www.ietf.org/mailman/listinfo/oauth
