Hi, Reading draft -05.
The "normalized request string" contains the request-URI and values extracted from the Host header. Be aware that intermediaries can and do change these; e.g., they may change an absolute URI to a relative URI in the request-line, without affecting the semantics of the request. See [1] for details (it covers other problematic conditions too). It would be more robust to calculate an effective request URI, as in [2]. Also, if you include a hash of the request body, you really need to include a hash of the body media type. Generally, I think that people can and will want to include other headers; just because *some* developers can't get this right doesn't mean we should preclude *all* developers from doing it. It'd be really nice to see this either leverage DOSETA [3][4], or at least offer a clean transition path to it. Regards, 1. http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-4.1.2 2. http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14#section-4.3 3. http://tools.ietf.org/html/draft-crocker-dkim-doseta-00 4. http://tools.ietf.org/html/draft-crocker-doseta-base-02 On 10/05/2011, at 5:22 AM, Eran Hammer-Lahav wrote: > (Please discuss this draft on the Apps-Discuss <apps-disc...@ietf.org> > mailing list) > > http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token > > The draft includes: > > * An HTTP authentication scheme using a MAC algorithm to authenticate > requests (via a pre-arranged MAC key). > * An extension to the Set-Cookie header, providing a method for associating a > MAC key with a session cookie. > * An OAuth 2.0 binding, providing a method of returning MAC credentials as an > access token. > > Some background: OAuth 1.0 introduced an HTTP authentication scheme using > HMAC for authenticating an HTTP request with partial cryptographic protection > of the HTTP request (namely, the request URI, host, and port). The OAuth 1.0 > scheme was designed for delegation-based use cases, but is widely “abused” > for simple client-server authentication (the poorly named ‘two-legged’ use > case). This functionality has been separated from OAuth 2.0 and has been > reintroduced as a standalone, generally applicable HTTP authentication scheme > called MAC. > > Comments and feedback is greatly appreciated. > > EHL > _______________________________________________ > apps-discuss mailing list > apps-disc...@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
