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
