Re: [OAUTH-WG] MAC Tokens body hash
+1 Phil On 2011-08-15, at 9:46, Eran Hammer-Lahav 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 > To: William J. Mills ; Phil Hunt > Cc: OAuth WG > 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 > To: Phil Hunt > Cc: OAuth WG > 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" 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 > To: Eran Hammer-Lahav > Cc: Ben Adida ; OAuth WG ; "Adam > Barth(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 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
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 To: William J. Mills ; Phil Hunt Cc: OAuth WG 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 To: Phil Hunt Cc: OAuth WG 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" 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 >To: Eran Hammer-Lahav >Cc: Ben Adida ; OAuth WG ; "Adam >Barth(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 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 b
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 mailto:e...@hueniverse.com>> To: Phil Hunt mailto:phil.h...@oracle.com>> Cc: OAuth WG mailto: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" mailto: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<http://www.independentid.com> phil.h...@oracle.com<mailto: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]<mailto:[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<mailto: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 mailto:phil.h...@oracle.com>> To: Eran Hammer-Lahav mailto:e...@hueniverse.com>> Cc: Ben Adida mailto:b...@adida.net>>; OAuth WG mailto:oauth@ietf.org>>; "Adam Barth(a...@adambarth.com<mailto:a...@adambarth.com>)" mailto: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 mailto: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 iss
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 To: Phil Hunt Cc: OAuth WG 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" 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.comphil.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 >>To: Eran Hammer-Lahav >>Cc: Ben Adida ; OAuth WG ; "Adam >>Barth(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 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 o
Re: [OAUTH-WG] MAC Tokens body hash
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 > To: Eran Hammer-Lahav > Cc: Ben Adida ; OAuth WG ; "Adam > Barth(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 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
Re: [OAUTH-WG] MAC Tokens body hash
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 mailto:phil.h...@oracle.com>> To: Eran Hammer-Lahav mailto:e...@hueniverse.com>> Cc: Ben Adida mailto:b...@adida.net>>; OAuth WG mailto:oauth@ietf.org>>; "Adam Barth(a...@adambarth.com<mailto:a...@adambarth.com>)" mailto: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 mailto: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]<mailto:[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<mailto: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 t
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 To: Eran Hammer-Lahav Cc: Ben Adida ; OAuth WG ; "Adam Barth(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 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
Re: [OAUTH-WG] MAC Tokens body hash
Phil On 2011-08-02, at 18:02, Eran Hammer-Lahav 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
Re: [OAUTH-WG] MAC Tokens body hash
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. 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. 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
Re: [OAUTH-WG] MAC Tokens body hash
Yes, tone is important and I agree that this is a working group document and should follow process. This draft has shown practically no interest from this working group (last count it was 3 people other than me). If there was no requirement from the AD to include this as part of the OAuth 2.0 "package", it would have stayed as an individual submission. Given that this is largely my work (to-date) and that the working group engagement is almost non-existent, moving forward is more likely going to come from me putting forward proposals in the document with [[ Pending Consensus ]] labels than from trying to get engagement. Unless the chairs are going to actively poke the group to engage (which I have seen no sign of), I'm not expecting much to change. At this point we have established the practice of suggesting text within the document itself as long as it is clearly marked and we have an open issue in the tracker. I'm going to follow that practice and make the proposed changes in order to move things along at a practical pace. I'll also adjust my tone to address any concerns. EHL > -Original Message- > From: barryleiba.mailing.li...@gmail.com > [mailto:barryleiba.mailing.li...@gmail.com] On Behalf Of Barry Leiba > Sent: Tuesday, August 02, 2011 5:28 PM > To: Eran Hammer-Lahav > Cc: Phil Hunt; William J. Mills; OAuth WG > Subject: Re: [OAUTH-WG] MAC Tokens body hash > > On Tue, Aug 2, 2011 at 2:22 AM, 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. > > Just a word of process stuff, here: draft-ietf-oauth-v2-http-mac is a working > group document, not an individual submission. That means that the working > group decides what gets changed, and we need to see consensus to make a > change like this. "I am going to", "I have no intention of", and "I'm > willing to > reconsider" aren't appropriate. > > It might be that making this change is the right thing to do, but so far we > have > no one voicing support for the change (Skylar responded favourably to the > initial message, but no one's supported removing "ext" in favour of "app"). > Let's have more discussion before any decisions are made. And, in general, > for all documents, let's please have editors making suggestions, not > pronouncements. Tone is important. > > Barry, as chair ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] MAC Tokens body hash
On Tue, Aug 2, 2011 at 2:22 AM, 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. Just a word of process stuff, here: draft-ietf-oauth-v2-http-mac is a working group document, not an individual submission. That means that the working group decides what gets changed, and we need to see consensus to make a change like this. "I am going to", "I have no intention of", and "I'm willing to reconsider" aren't appropriate. It might be that making this change is the right thing to do, but so far we have no one voicing support for the change (Skylar responded favourably to the initial message, but no one's supported removing "ext" in favour of "app"). Let's have more discussion before any decisions are made. And, in general, for all documents, let's please have editors making suggestions, not pronouncements. Tone is important. Barry, as chair ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
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
Re: [OAUTH-WG] MAC Tokens body hash
Yep. I would like to allow each application to extend what is being signed, such as payload or specific headers. I don't want to open the door for additional specifications defining how to use the ext parameter. If there is enough consensus for an extended signing model, we should define a new scheme. EHL From: Phil Hunt [mailto:phil.h...@oracle.com] Sent: Tuesday, August 02, 2011 8:31 AM To: Eran Hammer-Lahav Cc: William J. Mills; OAuth WG Subject: Re: [OAUTH-WG] MAC Tokens body hash 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<http://www.independentid.com> phil.h...@oracle.com<mailto: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]<mailto:[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<http://www.independentid.com/> phil.h...@oracle.com<mailto: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 mailto:e...@hueniverse.com>> To: William J. Mills mailto:wmi...@yahoo-inc.com>>; OAuth WG mailto:oauth@ietf.org>> Cc: Ben Adida mailto:b...@adida.net>>; "'Adam Barth (a...@adambarth.com<mailto:a...@adambarth.com>)'" mailto: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]<mailto:[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<mailto: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 mailto:e...@hueniverse.com>> To: OAuth WG mailto:oauth@ietf.org>> Cc: Ben Adida mailto:b...@adida.net>>; "'Adam Barth (a...@adambarth.com<mailto:a...@adambarth.com>)'" mailto: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 suggesti
Re: [OAUTH-WG] MAC Tokens body hash
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 > To: William J. Mills ; OAuth WG > Cc: Ben Adida ; "'Adam Barth (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 > To: OAuth WG > Cc: Ben Adida ; "'Adam Barth (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
Re: [OAUTH-WG] MAC Tokens body hash
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<http://www.independentid.com> phil.h...@oracle.com<mailto: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 mailto:e...@hueniverse.com>> To: William J. Mills mailto:wmi...@yahoo-inc.com>>; OAuth WG mailto:oauth@ietf.org>> Cc: Ben Adida mailto:b...@adida.net>>; "'Adam Barth (a...@adambarth.com<mailto:a...@adambarth.com>)'" mailto: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]<mailto:[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<mailto: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 mailto:e...@hueniverse.com>> To: OAuth WG mailto:oauth@ietf.org>> Cc: Ben Adida mailto:b...@adida.net>>; "'Adam Barth (a...@adambarth.com<mailto:a...@adambarth.com>)'" mailto: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<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
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 > To: William J. Mills ; OAuth WG > Cc: Ben Adida ; "'Adam Barth (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 > To: OAuth WG > Cc: Ben Adida ; "'Adam Barth (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
Re: [OAUTH-WG] MAC Tokens body hash
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 To: William J. Mills ; OAuth WG Cc: Ben Adida ; "'Adam Barth (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 To: OAuth WG Cc: Ben Adida ; "'Adam Barth (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
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 mailto:e...@hueniverse.com>> To: OAuth WG mailto:oauth@ietf.org>> Cc: Ben Adida mailto:b...@adida.net>>; "'Adam Barth (a...@adambarth.com<mailto:a...@adambarth.com>)'" mailto: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<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
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 To: OAuth WG Cc: Ben Adida ; "'Adam Barth (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
