W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1997

Re: REAUTHENTICATION REQUIRED

From: David W. Morris <dwm@xpasc.com>
Date: Tue, 25 Nov 1997 00:14:13 -0800 (PST)
To: Scott Lawrence <lawrence@agranat.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <Pine.GSO.3.96.971125000929.9115D-100000@shell1.aimnet.com>


On Mon, 24 Nov 1997, Scott Lawrence wrote:

> 
> >>>>> "DWM" == David W Morris <dwm@xpasc.com> writes:
> 
> DWM> 2. However, it is incomplete.  W/o a corresponding mechanism, there is
> DWM>    no practical way for a server or proxy to know when the proposed
> DWM>    420/421 reauthentication should be requested.
> 
> DWM> So, the timeout concept must be included, with the server providing the
> DWM> timeout. At least optionally, the timeout should be specified as an
> DWM> idle period, and not absolute value. That is, if the credential isn't
> DWM> used (sent) within X seconds, it must be discarded.
> 
>   I'm not sure that I understand this comment.  The discussion of a
>   timeout in the proposed addition was strictly an example of the use
>   of this code, not a part of the definition of its function.

My point is simply that I believe there are many cases where a site is
secured and the owners are concerned about stale credentials but there is
no reason to impose any form of state management on access to the server.
Without some form of statemanagement, to correlate users to timeout
tables on the server, there is no way for a server to know when to 
issue the reauthentication challange.

Hence my suggestion that the original proposal be extended to provide 
a credential timeout implemented by the client.


> DWM> Secondly, an additonal mechanism is required to allow the server to
> DWM> force flushing of credentials w/o the implication of an immediate user
>[...] 
>   This is an excellent suggestion.  I put forward the following
>   suggested wording.
> 
>    2xx Discard Credentials
> 
>      This status indicates that the request succeeded, but that the user
>      credentials used to construct the Authorization header field for the
>      request MUST be discarded.  This allows web based applications to
>      implement a 'logout' function.  The body of the response should
>      in all other ways be treated as though the response code were
>      '200 Ok'.
> 
>   This is completely backward compatible, since clients that don't
>   understand it should already just treat it as a 200, they just won't
>   discard cached credentials, which is the current situation anyway.
> 
>   Yes - users can just walk away without using an offered 'logout'
>   function, but in my view that is no reason not to provide the
>   capability.  I've been getting 2 or 3 pieces of email a week for
>   the last couple of months from developers trying to figure out how
>   to do this, and I haven't had any answer for them.

Your proposed wording for 2xx sounds OK to me. At least 1 post per week
to the MS IIS/ASP mail list asks the question as well.

Dave Morris
Received on Tuesday, 25 November 1997 00:17:55 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:04 EDT