Re: [OAUTH-WG] MAC Tokens body hash

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