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