It is a compelling use case, but one that I do not intend on solving within the MAC draft for now. Getting MAC cookies adoption is much higher on my list and anything that makes the specification longer and more complex stands in that way.
However, feel free to propose a mechanism and we can discuss that. EHL > -----Original Message----- > From: Justin Richer [mailto:jric...@mitre.org] > Sent: Tuesday, May 10, 2011 7:40 AM > To: Peter Wolanin > Cc: Eran Hammer-Lahav; Ben Adida; OAuth WG; Adam Barth > (a...@adambarth.com) > Subject: Re: [OAUTH-WG] HTTP MAC Authentication Scheme > > But that's so much work. :-P > > The ease of using a throwaway signed URL as a self-contained information > unit shouldn't be ignored. It requires exactly zero client-side code and can > survive all kinds of HTML repackaging and transit easily. > > -- Justin > > On Mon, 2011-05-09 at 22:11 -0400, Peter Wolanin wrote: > > What about using the cookie header? > > > > We have a sha1-HMAC authentication scheme where we are passing the > > HMAC, nonce, timestamp as parts of the cookie header since scripting > > languages that cannot access arbitrary headers still usually can > > access this header. > > > > -Peter > > > > On Mon, May 9, 2011 at 3:34 PM, Justin Richer <jric...@mitre.org> wrote: > > > I would still like to see a binding of this to use query or form > > > parameters. > > > I have a direct use case for handing out signed URLs to the client, > > > for which we're using the OAuth 1.0 signing mechanism without tokens > > > today. I'd love to switch to something that we could bind to OAuth2, > > > but the restriction of using the Auth header puts the MAC token out > > > of reach for my immediate usecase. > > > > > > -- Justin > > > > > > On 5/9/2011 3:22 PM, 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 > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > > > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
