I think the extended parameter still has use if someone extends the MAC stuff
specifically, whcih the additional hash is useful for a data signature, that's
off the cuff though without implementing somethign to try it out.
________________________________
From: Eran Hammer-Lahav <e...@hueniverse.com>
To: William J. Mills <wmi...@yahoo-inc.com>; OAuth WG <oauth@ietf.org>
Cc: Ben Adida <b...@adida.net>; "'Adam Barth (a...@adambarth.com)'"
<a...@adambarth.com>
Sent: Monday, August 1, 2011 8:59 AM
Subject: RE: [OAUTH-WG] MAC Tokens body hash
Would you still like to see both such app-specific payload hash AND the ext
parameter? I’m thinking of taking your idea and dropping ext. This way, the
application can define anything they want to put in the payload hash.
EHL
From:William J. Mills [mailto:wmi...@yahoo-inc.com]
Sent: Monday, August 01, 2011 8:41 AM
To: Eran Hammer-Lahav; OAuth WG
Cc: Ben Adida; 'Adam Barth (a...@adambarth.com)'
Subject: Re: [OAUTH-WG] MAC Tokens body hash
Instead of "body" hash why not make it a payload hash or additional hash. The
app can include a hash of data there as defined by the app, and you've reserved
a spot for that.
________________________________
From:Eran Hammer-Lahav <e...@hueniverse.com>
To: OAuth WG <oauth@ietf.org>
Cc: Ben Adida <b...@adida.net>; "'Adam Barth (a...@adambarth.com)'"
<a...@adambarth.com>
Sent: Friday, July 29, 2011 6:43 PM
Subject: [OAUTH-WG] MAC Tokens body hash
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
