Dear Mr. Hammer-Lahav regarding http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02
I was quite happy to find this, since I had overlooked it before and it define the sort of robust HMAC-based auth we have been using for our APIs in various forms, but has the advantage of being a standard that if implemented would make our future implementations much more standardized. 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. 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? 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. -Peter -- Peter M. Wolanin, Ph.D. : Momentum Specialist, Acquia. Inc. peter.wola...@acquia.com : 978-296-5247 "Get a free, hosted Drupal 7 site: http://www.drupalgardens.com"; _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
