Subject: Re: [OAUTH-WG] MAC Tokens body hash

From: "William J. Mills" <[email-masked]>
Date: Mon, 1 Aug 2011 08:41:11 -0700 (PDT)

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 <[email-masked]>
To: OAuth WG <[email-masked]>
Cc: Ben Adida <[email-masked]>; "'Adam Barth ([email-masked])'" <[email-masked]>
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
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 1 Aug 2011 08:59:58 -0700

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:[email-masked]]
Sent: Monday, August 01, 2011 8:41 AM
To: Eran Hammer-Lahav; OAuth WG
Cc: Ben Adida; 'Adam Barth ([email-masked])'
Subject: Re: [OAUTH-WG] MAC Tokens body hash

________________________________
From: Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>>
To: OAuth WG <[email-masked]<mailto:[email-masked]>>
Cc: Ben Adida <[email-masked]<mailto:[email-masked]>>; "'Adam Barth ([email-masked]<mailto:[email-masked]>)'" <[email-masked]<mailto:[email-masked]>>
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.

EHL

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: "William J. Mills" <[email-masked]>
Date: Mon, 1 Aug 2011 09:06:43 -0700 (PDT)

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 <[email-masked]>
To: William J. Mills <[email-masked]>; OAuth WG <[email-masked]>
Cc: Ben Adida <[email-masked]>; "'Adam Barth ([email-masked])'" <[email-masked]>
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:[email-masked]] 

From:Eran Hammer-Lahav <[email-masked]>

 
EHL

---

From: Phil Hunt <[email-masked]>
Date: Mon, 1 Aug 2011 22:50:48 -0700

Agree.

-1 on removing the ext parameter.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 1 Aug 2011 23:22:12 -0700

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:[email-masked]]
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.

Phil

@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

To: William J. Mills <[email-masked]<mailto:[email-masked]>>; OAuth WG <[email-masked]<mailto:[email-masked]>>

EHL

From: William J. Mills [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Monday, August 01, 2011 8:41 AM
To: Eran Hammer-Lahav; OAuth WG
Cc: Ben Adida; 'Adam Barth ([email-masked]<mailto:[email-masked]>)'
Subject: Re: [OAUTH-WG] MAC Tokens body hash

EHL

---

From: Phil Hunt <[email-masked]>
Date: Tue, 2 Aug 2011 08:31:22 -0700

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
[email-masked]

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: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 2 Aug 2011 08:43:52 -0700

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:[email-masked]]
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

Phil

@independentid

EHL

From: Phil Hunt [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
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.

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

EHL

EHL

---

From: Skylar Woodward <[email-masked]>
Date: Wed, 3 Aug 2011 01:01:58 +0200

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

---

From: Barry Leiba <[email-masked]>
Date: Tue, 2 Aug 2011 20:28:24 -0400

On Tue, Aug 2, 2011 at 2:22 AM, Eran Hammer-Lahav <[email-masked]> 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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 2 Aug 2011 17:54:24 -0700

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: [email-masked]
> [mailto:[email-masked]] 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
> > 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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 2 Aug 2011 18:02:39 -0700

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

> From: Skylar Woodward [mailto:[email-masked]]
> Sent: Tuesday, August 02, 2011 4:02 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG; Ben Adida; 'Adam Barth ([email-masked])'
> (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
> 
> > 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

---

From: Phillip Hunt <[email-masked]>
Date: Tue, 2 Aug 2011 19:14:51 -0700

Phil

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

+1

---

From: "William J. Mills" <[email-masked]>
Date: Wed, 3 Aug 2011 10:27:54 -0700 (PDT)

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 <[email-masked]>
To: Eran Hammer-Lahav <[email-masked]>
Cc: Ben Adida <[email-masked]>; OAuth WG <[email-masked]>; "Adam Barth([email-masked])" <[email-masked]>
Sent: Tuesday, August 2, 2011 7:14 PM
Subject: Re: [OAUTH-WG] MAC Tokens body hash

Phil

+1

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 3 Aug 2011 11:03:12 -0700

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:[email-masked]]
Sent: Wednesday, August 03, 2011 10:28 AM
To: Phillip Hunt; Eran Hammer-Lahav
Cc: Ben Adida; OAuth WG; Adam Barth([email-masked])
Subject: Re: [OAUTH-WG] MAC Tokens body hash

________________________________
From: Phillip Hunt <[email-masked]<mailto:[email-masked]>>
To: Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>>
Cc: Ben Adida <[email-masked]<mailto:[email-masked]>>; OAuth WG <[email-masked]<mailto:[email-masked]>>; "Adam Barth([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>
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 <[email-masked]<mailto:[email-masked]>> 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.

+1

EHL

-----Original Message-----
From: Skylar Woodward [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Tuesday, August 02, 2011 4:02 PM
To: Eran Hammer-Lahav
Cc: OAuth WG; Ben Adida; 'Adam Barth ([email-masked]<mailto:[email-masked]>)'
Subject: Re: [OAUTH-WG] MAC Tokens body hash

hurrah!

skylar

EHL

---

From: Phil Hunt <[email-masked]>
Date: Wed, 3 Aug 2011 12:42:20 -0700

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
[email-masked]

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 4 Aug 2011 16:42:45 -0700

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" <[email-masked]<mailto:[email-masked]>> wrote:

Phil

@independentid
<http://www.independentid.com>www.independentid.com<http://www.independentid.com>
<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>

EHL

Cc: Ben Adida; OAuth WG; Adam Barth(<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>)

________________________________
From: Phillip Hunt <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>
To: Eran Hammer-Lahav <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>
Cc: Ben Adida <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>; OAuth WG <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>; "Adam Barth(<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>)" <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, August 2, 2011 7:14 PM
Subject: Re: [OAUTH-WG] MAC Tokens body hash

Phil

On 2011-08-02, at 18:02, Eran Hammer-Lahav <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> 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.

+1

EHL

-----Original Message-----
From: Skylar Woodward [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Tuesday, August 02, 2011 4:02 PM
To: Eran Hammer-Lahav
Cc: OAuth WG; Ben Adida; 'Adam Barth (<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>)'
Subject: Re: [OAUTH-WG] MAC Tokens body hash

hurrah!

skylar

EHL
_______________________________________________
OAuth mailing list
<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>
<https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>
<https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>
<https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth

---

From: "William J. Mills" <[email-masked]>
Date: Thu, 4 Aug 2011 18:06:15 -0700 (PDT)

It's the proverbial 'void *client_data;' equivalent.  All names for that to date suck, my favorite is 'rock'.

________________________________
From: Eran Hammer-Lahav <[email-masked]>
To: Phil Hunt <[email-masked]>
Cc: OAuth WG <[email-masked]>
Sent: Thursday, August 4, 2011 4:42 PM
Subject: Re: [OAUTH-WG] MAC Tokens body hash

EHL

On Aug 3, 2011, at 12:42, "Phil Hunt" <[email-masked]> wrote:

>[email-masked]
>
>
>
>
>
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 14 Aug 2011 23:28:58 -0700

How about ‘add’? as in “Used to include additional data in the MAC normalized string”.

EHL

From: William J. Mills [mailto:[email-masked]]
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

________________________________
From: Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>>
To: Phil Hunt <[email-masked]<mailto:[email-masked]>>
Cc: OAuth WG <[email-masked]<mailto:[email-masked]>>
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

Phil

@independentid

EHL

Cc: Ben Adida; OAuth WG; Adam Barth([email-masked]<mailto:[email-masked]>)

Phil

+1

EHL

-----Original Message-----
From: Skylar Woodward [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Tuesday, August 02, 2011 4:02 PM
To: Eran Hammer-Lahav
Cc: OAuth WG; Ben Adida; 'Adam Barth ([email-masked]<mailto:[email-masked]>)'
Subject: Re: [OAUTH-WG] MAC Tokens body hash

hurrah!

skylar

EHL

---

From: "William J. Mills" <[email-masked]>
Date: Mon, 15 Aug 2011 09:46:03 -0700 (PDT)

"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 <[email-masked]>
To: William J. Mills <[email-masked]>; Phil Hunt <[email-masked]>
Cc: OAuth WG <[email-masked]>
Sent: Sunday, August 14, 2011 11:28 PM
Subject: RE: [OAUTH-WG] MAC Tokens body hash

EHL

 
EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 15 Aug 2011 09:46:56 -0700

Let’s just keep ‘ext’ and drop ‘bodyhash’. Seems like this should resolve the issue.

EHL

From: William J. Mills [mailto:[email-masked]]
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

-bill

To: William J. Mills <[email-masked]<mailto:[email-masked]>>; Phil Hunt <[email-masked]<mailto:[email-masked]>>

EHL

EHL

Phil

@independentid

EHL

Phil

+1

EHL
-----Original Message-----
From: Skylar Woodward [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Tuesday, August 02, 2011 4:02 PM
To: Eran Hammer-Lahav
Cc: OAuth WG; Ben Adida; 'Adam Barth ([email-masked]<mailto:[email-masked]>)'
Subject: Re: [OAUTH-WG] MAC Tokens body hash

hurrah!

skylar

EHL

---

From: Phillip Hunt <[email-masked]>
Date: Mon, 15 Aug 2011 22:16:04 -0700

+1

Phil