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(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On
Behalf Of Gaurav Vaish
Sent: Thursday, May 12, 2005 3:41 AM
To: Florian Weimer
Cc: David Morris; Keith Moore; ietf(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf