hurrah! (not necessarily for losing a way to sign the body, but for simplicity and avoiding some of the potential inconsistencies w/ bodyhash).
Is your plan to reserve an empty line 6 for the Normalized Request String (which was used for bodyhash) or eliminate it, brining the total to six elements? skylar On Jul 30, 2011, at 3:43 AM, Eran Hammer-Lahav wrote: > I plan to drop support for the bodyhash parameter in the next draft based on > bad implementation experience. Even with simple text body, UTF encoding has > introduced significant issues for us. The current draft does not work using > simple JS code between a browser and node.js even when both use the same v8 > engine due to differences in the body encoding. Basically, the JS string used > to send a request from the browser is not the actual string sent on the wire. > > To fix that, we need to force UTF-8 encoding on both sides. However, that is > very much application specific. This will not work for non-text bodies. > Instead, the specification should offer a simple way to use the ext parameter > for such needs, including singing headers. And by offer I mean give examples, > but leave it application specific for now. > > I am open to suggestions but so far all the solutions I came up with will > introduce unacceptable complexity that will basically make this work useless. > > EHL > _______________________________________________ > 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
