Hi Florian, Thanks for the finding. > Your proposal does not address one of the problems raised in Section > 2.2.2 of RFC 2964: > > Nowadays, this is called "Cross-Site Request Forgery", or "Session > Riding". Standardizing some cookie-lookalike which doesn't address > this problem seems rather pointless to me. Cookies can be persisted. This header should not be. This header does not have any expiry associated with it - it expires immediately after the browser is closed (or may be an extension of my original recommendation - "Set-Auth-ID: unset". Unset may be reserved auth-ID for logout). It's similar to what Authorize header but with an exception that the value of the header is set by the server and not by the client. And also, it can be unset. I mean, if u look at how present browsers work is that once authentication happens (thru NTML/Basic/Digest et al), they'd continue to send these headers and they don't know when to stop. The only way to logout is to close that instance. This problem deepens with clients that insist to have only one application instance running (for example Mozilla/Firefox). It may be argued that it's the problem with application and not protocol - but the problem IS with protocol that is does not tell WHEN to logout / unset / not send the header. Critics / comments appreciated... :-) -- Cheers, Gaurav Vaish http://www.mastergaurav.org http://mastergaurav.blogspot.com -------------------------------- _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf