+1 Phil
On 2011-08-15, at 9:46, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > Let’s just keep ‘ext’ and drop ‘bodyhash’. Seems like this should resolve the > issue. > > > > EHL > > > > From: William J. Mills [mailto:wmi...@yahoo-inc.com] > Sent: Monday, August 15, 2011 9:46 AM > To: Eran Hammer-Lahav; Phil Hunt > Cc: OAuth WG > Subject: Re: [OAUTH-WG] MAC Tokens body hash > > > > "add" doesn't really say it to me either. "ah", short for "additional hash" > is somewhat more mnemonic for me, but then I think "ext" isn't horrible > because it's a frequent abbreviation for extension. > > > > -bill > > > > From: Eran Hammer-Lahav <e...@hueniverse.com> > To: William J. Mills <wmi...@yahoo-inc.com>; Phil Hunt <phil.h...@oracle.com> > Cc: OAuth WG <oauth@ietf.org> > Sent: Sunday, August 14, 2011 11:28 PM > Subject: RE: [OAUTH-WG] MAC Tokens body hash > > How about ‘add’? as in “Used to include additional data in the MAC normalized > string”. > > > > EHL > > > > From: William J. Mills [mailto:wmi...@yahoo-inc.com] > Sent: Thursday, August 04, 2011 6:06 PM > To: Eran Hammer-Lahav; Phil Hunt > Cc: OAuth WG > Subject: Re: [OAUTH-WG] MAC Tokens body hash > > > > It's the proverbial 'void *client_data;' equivalent. All names for that to > date suck, my favorite is 'rock'. > > > > From: Eran Hammer-Lahav <e...@hueniverse.com> > To: Phil Hunt <phil.h...@oracle.com> > Cc: OAuth WG <oauth@ietf.org> > Sent: Thursday, August 4, 2011 4:42 PM > Subject: Re: [OAUTH-WG] MAC Tokens body hash > > Ok. We seem to be using different definitions of what application data mean, > but have the same use cases in mind. I'll come up with a different name or > just keep ext. > > > > EHL > > On Aug 3, 2011, at 12:42, "Phil Hunt" <phil.h...@oracle.com> wrote: > > Only allowing (implied or not) app data is needlessly narrow in scope. > > > > Extending MAC to include claims or session information is a perfectly valid > thing to do. It improves scalability and reduces the need to look up artifact > data. > > > > Note: I'd like to share more on this, but I'm prioritizing the Threat Model > document. Never-the-less, the above should be a sufficient example about why > extensibility is useful. > > > > Phil > > > > @independentid > > www.independentid.com > > phil.h...@oracle.com > > > > > > > > On 2011-08-03, at 11:03 AM, Eran Hammer-Lahav wrote: > > > > My proposal is to change ‘ext’ to ‘app’, keep the same prose as ‘ext’, and > add the use case of ‘bodyhash’ as an example. I’m not too stuck on the name, > but my thinking is that ‘app’ relays the right message that this is a place > where developers can stick any application data they want included. ‘ext’ > conveys the idea of extensions which I’m not so thrilled about. > > > > In other words, I’d like a developer reading this to feel comfortable using > it right away for securing addition bits such as a JSON payload, but I don’t > like the idea of someone publishing an I-D with a full syntax and > canonicalization requirements for say, singing an entire request, headers and > all. I feel that would be much better accomplished by defining a new HTTP > authentication scheme. > > > > Philosophically, I think extensible authentication schemes are a bad idea. > > > > EHL > > > > > > From: William J. Mills [mailto:wmi...@yahoo-inc.com] > Sent: Wednesday, August 03, 2011 10:28 AM > To: Phillip Hunt; Eran Hammer-Lahav > Cc: Ben Adida; OAuth WG; Adam Barth(a...@adambarth.com) > Subject: Re: [OAUTH-WG] MAC Tokens body hash > > > > In thinking about this I'm coming around to the viewpoint that a single > additional predefined spot is sufficient. If the app developer wants to > include addtional data there (iun the specified format) that's fine. If what > they want to do is include a signature of other payload that's fine too. > > > > I'm not in love with the name "app" though, "ext" is better. > > > > From: Phillip Hunt <phil.h...@oracle.com> > To: Eran Hammer-Lahav <e...@hueniverse.com> > Cc: Ben Adida <b...@adida.net>; OAuth WG <oauth@ietf.org>; "Adam > Barth(a...@adambarth.com)" <a...@adambarth.com> > Sent: Tuesday, August 2, 2011 7:14 PM > Subject: Re: [OAUTH-WG] MAC Tokens body hash > > > > Phil > > > On 2011-08-02, at 18:02, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > > The idea is to drop 'ext' and 'bodyhash' due to being underspecified and > therefore causing more harm than good. I added 'ext' to allow for application > specific data to be included in the signed content. However, the name > suggests this is an extension point for future specifications. I believe > authentication schemes should not be extensible in ways that affect their > security or interop properties and without additional text (registry, > process, etc) for the 'ext' parameter, it will cause more issues than help. > > Instead of the 'ext' parameter I am suggesting the 'app' parameter which will > do the same, but will be better positioned as an application-specific data. > The prose will go a step further and recommend that the parameter value > include a hash of the data, not the data itself. This is to ensure the > parameter does not become part of the payload which is inappropriate for HTTP > requests. > > -1 what you describe appears to be a separate feature from ext > > > As for the 'bodyhash' parameter, I would like to remove it because it is > underspecified (we had an actual deployment experience showing that it > doesn't produce interoperable implementations due to the many HTTP body > transformation applied in most frameworks). Solving this issue is not > possible due to the many different types of bodies and frameworks (and > clearly operating on the "raw" body doesn't work). Instead, developers can > use the new 'app' parameter to accomplish that. > > > > +1 > > > > > As for the normalized string, it will be adjusted to reflect these changes > when they are made, so no placeholders which will require code change. > Considering this is -00, it is clearly not a stable document. > > Will these changes work with your use cases? > > EHL > > -----Original Message----- > > From: Skylar Woodward [mailto:sky...@kiva.org] > > Sent: Tuesday, August 02, 2011 4:02 PM > > To: Eran Hammer-Lahav > > Cc: OAuth WG; Ben Adida; 'Adam Barth (a...@adambarth.com)' > > Subject: 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 > > > _______________________________________________ > 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 > > > _______________________________________________ > 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
