Something of the sort could be done. But to do so would require the HTTP WG to be re-opened and there are many other proposals that would also have to be considered. I proposed a session-id in 1995 that was similar to Dave Raggets 1992 proposal but with some crypto in it that prevented session ids being correlated across domains. Before any change is made to the HTTP protocol there has to be a strategy for deployment of a new version of the HTTP protocol. None of the IETF protocols have provided a satisfactory answer to the question of how to upgrade after a protocol has become widely used. Version numbers have not proved as useful as some hoped. OSI solved this problem by being a hopeless failure, Web Services might have found an answer with WS-Policy or this might turn out to work no better than earlier proposals. I can't see much point to your proposal if we have to wait ten years before it can be used, particularly when a scheme already exists that gives similar functionality. The deployment strategy has to come first, how can this address a pain point that is recognized by the user? What incentives ar there for Web sites and browser providers? > -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On > Behalf Of Gaurav Vaish > Sent: Thursday, May 12, 2005 3:41 AM > To: Florian Weimer > Cc: David Morris; Keith Moore; ietf@xxxxxxxx > Subject: Re: Authentication/Session tracking question [was: > HTTP/1.1Protocol: Help Needed > > > 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@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf