Not sure I understand. How does 'app' change the issue about internal format and register?
Is it not for the user of the field to use and document its use as appropriate? I think the text that you had for ext was just fine. Cutting the field out, eliminates any possibility of extensibility -- and that would close a door that dead-ends the MAC design --> likely causing another MAC variant IMHO. That may be what you are looking for. Just want to make sure that's what you intend. Phil @independentid www.independentid.com phil.h...@oracle.com On 2011-08-01, at 11:22 PM, Eran Hammer-Lahav wrote: > I am going to drop both ‘bodyhash’ and ‘ext’, and instead add ‘app’. ‘app’ > allows you to include any data you want. ‘ext’ without an internal format and > register is just asking for trouble, and I have no intention of adding that > level of complexity. There are other proposals in the IETF for full HTTP > message signatures, and I’ll leave these more complex use cases to them. > > If you can demonstrate actual need (with examples) of both ‘app’ and ‘ext’, > I’m willing to reconsider but you can clearly accomplish the same end result > with just one, application-specific parameter. > > EHL > > From: Phil Hunt [mailto:phil.h...@oracle.com] > Sent: Monday, August 01, 2011 10:51 PM > To: William J. Mills > Cc: Eran Hammer-Lahav; OAuth WG > Subject: Re: [OAUTH-WG] MAC Tokens body hash > > Agree. > > -1 on removing the ext parameter. > > Phil > > @independentid > www.independentid.com > phil.h...@oracle.com > > > > > > On 2011-08-01, at 9:06 AM, William J. Mills wrote: > > > 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 >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
