Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5354F11E80EA for ; Mon, 1 Aug 2011 09:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtvgP1CtIPuB for ; Mon, 1 Aug 2011 09:00:53 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 9F1B211E80C4 for ; Mon, 1 Aug 2011 09:00:53 -0700 (PDT) Received: (qmail 27571 invoked from network); 1 Aug 2011 16:01:00 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 1 Aug 2011 16:00:58 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 1 Aug 2011 09:00:47 -0700 From: Eran Hammer-Lahav To: "William J. Mills" , OAuth WG Date: Mon, 1 Aug 2011 08:59:58 -0700 Thread-Topic: [OAUTH-WG] MAC Tokens body hash Thread-Index: AcxQYXNdxYV0yO+wRn+DWCW6hHx9SwAAnBkw Message-ID: <90C41DD21FB7C64BB94121FBBC2E723450245F61F2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723450245F611B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1312213271.20715.YahooMailNeo@web31813.mail.mud.yahoo.com> In-Reply-To: <1312213271.20715.YahooMailNeo@web31813.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723450245F61F2P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: Ben Adida , "'Adam Barth \(adam@adambarth.com\)'" Subject: Re: [OAUTH-WG] MAC Tokens body hash X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 16:00:55 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723450245F61F2P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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, th= e application can define anything they want to put in the payload hash. EHL From: William J. Mills [mailto:wmills@yahoo-inc.com] Sent: Monday, August 01, 2011 8:41 AM To: Eran Hammer-Lahav; OAuth WG Cc: Ben Adida; 'Adam Barth (adam@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 (adam@ada= mbarth.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 o= n bad implementation experience. Even with simple text body, UTF encoding h= as introduced significant issues for us. The current draft does not work us= ing simple JS code between a browser and node.js even when both use the sam= e v8 engine due to differences in the body encoding. Basically, the JS stri= ng 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 i= s very much application specific. This will not work for non-text bodies. I= nstead, the specification should offer a simple way to use the ext paramete= r for such needs, including singing headers. And by offer I mean give examp= les, but leave it application specific for now. I am open to suggestions but so far all the solutions I came up with will i= ntroduce unacceptable complexity that will basically make this work useless= . EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E723450245F61F2P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Would you= still like to see both such app-specific payload hash AND the ext paramete= r? I’m thinking of taking your idea and dropping ext. This way, the a= pplication can define anything they want to put in the payload hash.

 

EHL

 

From: William J. Mills [mailto:wmills@yahoo-inc.com]
Sent: Monday, A= ugust 01, 2011 8:41 AM
To: Eran Hammer-Lahav; OAuth WG
Cc:<= /b> Ben Adida; 'Adam Barth (adam@adambarth.com)'
Subject: Re: [OA= UTH-WG] MAC Tokens body hash

 

Instead o= f "body" hash why not make it a payload hash or additional hash.&= nbsp; The app can include a hash of data there as defined by the app, and y= ou've reserved a spot for that.

 

From: Era= n Hammer-Lahav <eran@hueniverse.c= om>
To: OAuth WG <oau= th@ietf.org>
Cc: Ben Adida <ben@adida.net>; "'Adam Barth (adam@adambarth.com)'" <adam@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 ha= s introduced significant issues for us. The current draft does not work usi= ng 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 strin= g 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 b= odies. Instead, the specification should offer a simple way to use the ext = parameter for such needs, including singing headers. And by offer I mean gi= ve examples, but leave it application specific for now.

 

I am open to suggesti= ons 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

= --_000_90C41DD21FB7C64BB94121FBBC2E723450245F61F2P3PW5EX1MB01E_--