Hi, In the light of the discussions we had so far - on various modes of authentication and session tracking: cookie, cookieless, form-data, URL-parameter etc etc etc, may I suggest an improvement in HTTP/1.1 - which, again, is open to discussion. Currently, associated with HTTP-Authentication are two (or three) headers: 1. WWW-Authenticate 2. Authorize 3. Optionall, Auth-Info Can we have a header called Auth-ID which may perform the task of a session-ID. Instead of putting in form-data or part-of-URL (which leads to a must-form-on-every-request) or as cookies (sometimes disabled, for good reasons as mentioned in thread), we can have it as a separate header. A small flow can be something like this: 1. Server requets authentication (HTTP-Authentication or simply form based) 2. Client Authenicates 3. Server validates authentication and sets a header (Set-Auth-ID: <some-id>, path='/some/path') 4. Client, when requesting any URL from the server under '/some/path', a header is passed (Auth-ID: <some-id>). 5. Server makes use of this header to dis/allow any protected content. Ok... another extension in HTTP/1.1 may not be on cards... but do we have any other option? Or just live with Cookies? :-( -- Cheers, Gaurav Vaish http://www.mastergaurav.org http://mastergaurav.blogspot.com -------------------------------- On 5/12/05, Keith Moore <moore@xxxxxxxxxx> wrote: > > Simple answer ... there is no easy reliable alternative to: > > a. cookie > > b. Stick it in the request URL and/or data ... many alternatives in the > > details > > ...neither of which are good places to store authentication tokens if exposure > of such tokens would compromise either the resource being accessed > or the user's identity. neither cookies nor URLs are typically well-protected > against accidental exposure. they were not designed to be used for > authentication. > > see RFC 2964 for more on use of cookies. > > Keith _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf