On Thu, May 12, 2005 at 12:42:23PM +0530, Gaurav Vaish wrote: > 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, I may be dumb as a sack of hammers, but I am not seeing how this is different from a cookie, except that (a) Your Auth-ID cannot be persistent across browser executions, where cookies can be (but don't have to be, as specified by the server). (Of course, the server does not know when the browser is terminated, so non-persistence only marginally addresses privacy issues.) (b) The Auth-ID is not currently blocked by existing anti-cookie approaches. (Call me cynical, but....) Now, if you were to insert a step 3.5, where the client applies a suitable cryptographic function to compute a some-id' and returned that to the server in step 4, and the server generated a new some-id every time around, you might have an interesting idea. Of course, that still doesn't address sections 2.2.1 and section 3 (especially 3.2) of RFC2964. And unless you can address those, your pseudo-cookies will be blocked shortly. -- Tommy McGuire _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf