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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf