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.commailto:e...@hueniverse.com To: Phil Hunt phil.h...@oracle.commailto:phil.h...@oracle.com Cc: OAuth WG oauth@ietf.orgmailto: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.commailto: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.comhttp://www.independentid.com phil.h...@oracle.commailto: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.commailto: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.commailto:phil.h...@oracle.com To: Eran Hammer-Lahav e...@hueniverse.commailto:e...@hueniverse.com Cc: Ben Adida b...@adida.netmailto:b...@adida.net; OAuth WG oauth@ietf.orgmailto:oauth@ietf.org; Adam Barth(a...@adambarth.commailto:a...@adambarth.com) a...@adambarth.commailto: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.commailto: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
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
Re: [OAUTH-WG] MAC Tokens body hash
+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
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.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 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
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
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 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
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.comhttp://www.independentid.com phil.h...@oracle.commailto: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.commailto:e...@hueniverse.com To: William J. Mills wmi...@yahoo-inc.commailto:wmi...@yahoo-inc.com; OAuth WG oauth@ietf.orgmailto:oauth@ietf.org Cc: Ben Adida b...@adida.netmailto:b...@adida.net; 'Adam Barth (a...@adambarth.commailto:a...@adambarth.com)' a...@adambarth.commailto: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.commailto: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.commailto:e...@hueniverse.com To: OAuth WG oauth@ietf.orgmailto:oauth@ietf.org Cc: Ben Adida b...@adida.netmailto:b...@adida.net; 'Adam Barth (a...@adambarth.commailto:a...@adambarth.com)' a...@adambarth.commailto: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.orgmailto:OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.orgmailto: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
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
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.comhttp://www.independentid.com phil.h...@oracle.commailto: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.comhttp://www.independentid.com/ phil.h...@oracle.commailto: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.commailto:e...@hueniverse.com To: William J. Mills wmi...@yahoo-inc.commailto:wmi...@yahoo-inc.com; OAuth WG oauth@ietf.orgmailto:oauth@ietf.org Cc: Ben Adida b...@adida.netmailto:b...@adida.net; 'Adam Barth (a...@adambarth.commailto:a...@adambarth.com)' a...@adambarth.commailto: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.commailto: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.commailto:e...@hueniverse.com To: OAuth WG oauth@ietf.orgmailto:oauth@ietf.org Cc: Ben Adida b...@adida.netmailto:b...@adida.net; 'Adam Barth (a...@adambarth.commailto:a...@adambarth.com)' a...@adambarth.commailto: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
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
On Tue, Aug 2, 2011 at 2:22 AM, Eran Hammer-Lahav e...@hueniverse.com 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
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
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
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
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.commailto:e...@hueniverse.com To: OAuth WG oauth@ietf.orgmailto:oauth@ietf.org Cc: Ben Adida b...@adida.netmailto:b...@adida.net; 'Adam Barth (a...@adambarth.commailto:a...@adambarth.com)' a...@adambarth.commailto: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.orgmailto: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 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
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
