Re: [OAUTH-WG] MAC Tokens body hash

[Phillip Hunt]

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

[Eran Hammer-Lahav]

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

[Eran Hammer-Lahav]

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

[Barry Leiba]

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] Device Profile

[Marius Scurtescu]

On Tue, Aug 2, 2011 at 3:19 PM, Aiden Bell  wrote:
> Hi,
>
> I am currently implementing the device profile described at
> http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00
>
> Wanted to check this hadn't been superseded by any other document or
> protocol
> though I did notice the Google implementation is in-line with this document.

Google's implementation is close, but it is not following the
extension to the letter. Mostly because the OAuth 2 spec evolved since
the extension was written. Here is the documentation:
http://code.google.com/apis/accounts/docs/OAuth2ForDevices.html

Marius

> Even though the summary states this is intended for limited input devices in
> combination with a full user agent (PC browser, smartphone browser),
>
> We are finding this extension useful for app authentication when the API
> serving the app is "open". This means that many developers can create
> mobile apps for one API, in conjunction with single users. For example,
> many apps may exist for the same API, and a single user may use many
> apps.
>
> As a result, we want to remove the requirement for ever entering use
> account-specific
> data (passwords etc) into apps, and allow a user to revoke app/device access
> on a per-instance
> basis. The end-user concerns of password security are lessened here.
>
> With OpenID or WebID in the mix, this further enhances the app/device
> authentication
> process as in an OpenID/WebID or similar setting, we can't always do
> resource owner password
> credentals (as in 1.4.3 of OAuth 2.0
> http://tools.ietf.org/html/draft-ietf-oauth-v2-20 )
>
> Unless I am missing another document or flow that provides the above better,
> (most likely I am)
> perhaps it is worth extending the scope/summary of device-00?
>
> Also, typo in the JSON
>
>   HTTP/1.1 200 OK
>   Content-Type: application/json
>   Cache-Control: no-store
>
>   {
>     "device_code":"74tq5miHKB",
>     "user_code":"94248",
>     "verification_uri":"http://www.example.com/device";,
>  "interval"=5
>    }
>
> I think should be:
>
>   HTTP/1.1 200 OK
>   Content-Type: application/json
>   Cache-Control: no-store
>
>   {
>  "device_code":"74tq5miHKB",
>  "user_code":"94248",
>  "verification_uri":"http://www.example.com/device";,
>  "interval":5
>   }
>
> Thanks,
> Aiden
>
> --
> --
> Never send sensitive or private information via email unless it is
> encrypted. http://www.gnupg.org
>
> ___
> 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

[Skylar Woodward]

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-WG] Device Profile

[Aiden Bell]

Hi,

I am currently implementing the device profile described at
http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00

Wanted to check this hadn't been superseded by any other document or
protocol
though I did notice the Google implementation is in-line with this document.

Even though the summary states this is intended for limited input devices in
combination with a full user agent (PC browser, smartphone browser),

We are finding this extension useful for app authentication when the API
serving the app is "open". This means that many developers can create
mobile apps for one API, in conjunction with single users. For example,
many apps may exist for the same API, and a single user may use many
apps.

As a result, we want to remove the requirement for ever entering use
account-specific
data (passwords etc) into apps, and allow a user to revoke app/device access
on a per-instance
basis. The end-user concerns of password security are lessened here.

With OpenID or WebID in the mix, this further enhances the app/device
authentication
process as in an OpenID/WebID or similar setting, we can't always do
resource owner password
credentals (as in 1.4.3 of OAuth 2.0
http://tools.ietf.org/html/draft-ietf-oauth-v2-20 )

Unless I am missing another document or flow that provides the above better,
(most likely I am)
perhaps it is worth extending the scope/summary of device-00?

Also, typo in the JSON

  HTTP/1.1 200 OK
  Content-Type: application/json
  Cache-Control: no-store

  {
"device_code":"74tq5miHKB",
"user_code":"94248",
"verification_uri":"http://www.example.com/device";,
 "interval"=5
   }

I think should be:

  HTTP/1.1 200 OK
  Content-Type: application/json
  Cache-Control: no-store

  {
 "device_code":"74tq5miHKB",
 "user_code":"94248",
 "verification_uri":"http://www.example.com/device";,
 "interval":5
  }

Thanks,
Aiden

-- 
--
Never send sensitive or private information via email unless it is
encrypted. http://www.gnupg.org
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-urn-sub-ns-00.txt

[Brian Campbell]

Thanks Peter & Barry,

I'll proceed under those assumptions.

Also, just fyi that I just posted a new draft of this at
http://tools.ietf.org/html/draft-campbell-oauth-urn-sub-ns-01 that has
only a couple minor editorial changes.

I hope to get to the SAML draft soon.

On Mon, Aug 1, 2011 at 9:03 AM, Peter Saint-Andre  wrote:
> On 7/31/11 8:45 AM, Barry Leiba wrote:
>> Given the progress that the OAuth WG has made, the fact that we're in
>> WGLC on two major documents, and the fact that the SAML draft depends
>> upon what's in here, I have no issue with adding this as a WG item.
>> Stephen, do you agree with that?  (I know that Stephen's away for a
>> bit, and won't be responding for a while.  This can wait until he gets
>> back, and in the meantime the SAML doc can assume that this one is
>> going forward.)
>
> I think that's a good path forward.
>
> Peter
>
>
> --
> Peter Saint-Andre
> https://stpeter.im/
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] MAC Tokens body hash

[Eran Hammer-Lahav]

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
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 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>>
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 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>>
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

__

Re: [OAUTH-WG] MAC Tokens body hash

[Phil Hunt]

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