Re: Proposal for two new authentication schemes...

Dave writes:

>This is functionally equivalent to Netscape's cookie scheme, a
>derivative of which is being standardized as an HTTP "state management"
>proposal.  For the current set of documents, see

I'm not so sure that this is the case, was the proposal for an authentication
token to be created by the client or by the server? If the token is created by 
the client then there is nothing to distinguish this scheme from cookies.

There is a significant advantage to having the client create an opaque, 
unlinkable session identifier to avoid the need to use cookies. Client created 
session ids are much more cache friendly than cookies. There is no way a cache 
can know to create a cookie itself where cookies are being used as 
authentication tokens. On the other hand a client generated token can be 
recorded by the client and forwarded (if necessary) to the origin server in a 
log file exchange scheme.

See the following drafts for details:


Received on Tuesday, 7 May 1996 09:08:31 UTC