> -----Original Message----- > From: Peter Wolanin [mailto:[email protected]] > 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 _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
