Subject: Re: [OAUTH-WG] OAuth v2 Mac token spec

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 11 Apr 2011 16:21:31 -0700

> -----Original Message-----
> From: Peter Wolanin [mailto:[email-masked]]
> Sent: Sunday, February 27, 2011 6:59 AM

> I was a little unclear in the spec whether the client can choose not to include
> the body hash in the signature.  I'd hope that the spec ends up clearly
> requiring the client to always send it even if a given server may or may not
> validate the body hash.  Our current implementations include the body
> directly in the HMAC calculation, but considering your current draft I
> appreciate the extra flexibility provided by signing over the body hash rather
> than the body itself.

Yes, we need to figure out when the client is required to include it. The issue is that in some deployments, it is not possible for the client to calculate this value at the point where the header is set.
 
> A downside to the MAC spec for OAuth2 is, as far as I can see, you have to
> send your client secret in the request if you ever need to refresh your OAuth
> token?  I see in some recent messages liek http://www.ietf.org/mail-
> archive/web/oauth/current/msg05214.html  some discussion that suggests
> I'm mistaken?

Nope. Refresh does not require the access token or its secret. Just the refresh code.
 
> Also, as stated in section 7.3, there seems to be no provision for ensuring
> response authenticity except relying on SSL. We have been using protocols
> that include in the response an HMAC of the response body calculated to
> include the client-supplied nonce.  Obviously one could add such a response
> header without breaking the protocol, but I'd like to see an option in the
> MAC credentials an added field that specifies whether the server is expected
> to provide such a response HMAC and a standardized name and construction
> for such a response header.

I will add this later, once the current bits are stable.

EHL