On Mon, Jun 13, 2011 at 7:17 PM, Manger, James H <james.h.man...@team.telstra.com> wrote: >>> This is a bit hacky, too hacky. Wouldn't it be better for a client that >>> recognizes a special MAC cookie to use it to construct Authorization headers >>> and omit it from Cookie headers? > >> Nope. Sending the value in the Cookie header is important to help >> servers implement this scheme without breaking themselves. > > Why? How? Could you explain this a bit more? > > Is this so the cookie can be reused as a session id that load balancers can > use to implement "sticky" sessions? A key id doesn't sound like a great > session id. Wouldn't a separate session cookie be better? > > Is this so a server can issue MAC credentials, but still accept clients that > are unaware of the MAC scheme? That seems possible either way. > > Is this so a central security server can start issuing MAC credentials while > some of its content servers don't understand MAC and just treat the key id as > a bearer token? That sounds bad -- client's think they are getting MAC > security when they are not.
Most folks who run web sites use cookies to generate sessions. These folks will layer the MAC protections on top of their existing systems by adding a couple cookie attributes and verifying an HMAC. If we removed the MAC cookie from the Cookie header, the Cookie header would be different in supporting and legacy user agents, causing pain and misery. It might be instructive to try using MAC in a real deployment. You'll see immediately why this behavior is preferable. Adam _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
