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: Sat, 22 Nov 1997 23:13:41 -0800 (PST)
To: Paul Leach <paulle@microsoft.com>
Cc: 'http-wg' <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>, 'Jim Gettys' <jg@w3.org>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <Pine.GSO.3.96.971122230246.6199G-100000@shell1.aimnet.com>

1. I agree that this facility is required.
2. However, it is incomplete.  W/o a corresponding mechanism, there is
   no practical way for a server or proxy to know when the proposed 
   420/421 reauthentication should be requested.

So, the timeout concept must be included, with the server providing the
timeout. At least optionally, the timeout should be specified as an
idle period, and not absolute value. That is, if the credential isn't
used (sent) within X seconds, it must be discarded.

Secondly, an additonal mechanism is required to allow the server to
force flushing of credentials w/o the implication of an immediate user
prompt. In many applications, there is an explicit notion of logoff.
Some form of response header to say flush credentials. Might be as
simple as the challenge header with a 2xx response to mean this is
a valid response but a new user interaction is required before sending
credentials to the server.

Dave Morris

On Thu, 20 Nov 1997, Paul Leach wrote:

> Based on feedback, and the epiphany that screen savers do the same thing as
> I proposed the browser do, I withdraw the proposed modification to section
> 11. Something like it should go in the security considerations section --
> Jim, can you mark it as an editorial issue, not for this revision?
> 
> I also added text about an error message, and what happens with browsers
> that don't understand the new status code.
> 
> Revised proposal:
> 
> > Add sections 10.4.19 and 10.4.20
> > 
> > ==============================
> > 
> > 10.4.19 420 Reauthentication Required
> > 
> > This header is similar to "401 Unauthorized", except that the user agent
> > MUST request credentials from the user before resubmitting the request,
> > even
> > if the challenge is the same as on a prior response or if the user agent
> > has
> > already obtained credentials from the user. The user agent should not
> > assume
> > that the current credentials are invalid if the request contained an
> > Authorization header. The server can use this status code to cause the
> > browser to verify that the current user is the same as the one who
> > supplied
> > the original credentials (say, after a period of inactivity). The server
> > SHOULD send an entity-body
> explaining the reason for requiring reauthentication, because user agents
> that do not understand the status code will treat it as a generic 400 error
> and display
> the message.
> 
> > 10.4.20 421 Proxy Reauthentication Required
> > 
> > This header is similar to "407 Proxy Aauthentication Required", except
> > that
> > the user agent MUST request credentials from the user before resubmitting
> > the request, even if the challenge is the same as on a prior response or
> > if
> > the user agent has already obtained credentials from the user.  The user
> > agent should not assume that the current credentials are invalid if the
> > request contained an Proxy-Authorization header. The server can use this
> > status code to cause the browser to verify that the current user is the
> > same
> > as the one who supplied the original credentials (say, after a period of
> > inactivity). The server SHOULD send an entity-body
> > explaining the reason for requiring reauthentication, because user agents
> > that do not understand the status code will treat it as a generic 400
> > error and display
> > the message.
> > 
> > 
> > ==================================
> > 
> 
> 
Received on Saturday, 22 November 1997 23:15:40 EST

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