RE: Reauthentication Requested Revisited

From: Josh Cohen (joshco@microsoft.com)
Date: Mon, Feb 02 1998


Message-ID: <21FD6499922DD111A4F600805FCCD6F2013D09AF@red-86-msg.dns.microsoft.com>
From: Josh Cohen <joshco@microsoft.com>
To: "'Scott Lawrence'" <lawrence@agranat.com>, http-wg@cuckoo.hpl.hp.com, "'ietf-http-ext@w3.org'" <ietf-http-ext@w3.org>
Date: Mon, 2 Feb 1998 19:24:24 -0800 
Subject: RE: Reauthentication Requested Revisited



-> -----Original Message-----
-> From: Scott Lawrence [mailto:lawrence@agranat.com]
-> Sent: Monday, February 02, 1998 6:52 PM
-> To: http-wg@cuckoo.hpl.hp.com
-> Subject: Re: Reauthentication Requested Revisited
-> 
-> 
-> 
-> >>>>> "JC" == Josh Cohen <joshco@MICROSOFT.com> writes:
-> 
-> JC> 1) the server needs a way to send a message to the client saying
-> JC>   please revalidate your credentials with the user
-> 
->   I know that I sound like a broken record here, but the minimal
->   requirement is to instruct the user agent to discard the current
->   credentials - whether or not it should then obtain new ones depends
->   on whether or not it has another request to send that requires
->   them, which might be immediatly or next month.
-> 
->   A 'Logout' function does not require that new credentials be
->   obtained - in fact, doing so would defeat the very purpose of
->   discarding the current set.
-> 
->   A 'Revalidate' function can be accomplished by instructing the user
->   agent to discard current credentials in any redirection or
->   authentication-required response.
-> 
The issue was "reauthentication requested", which implies the ability
to obtain new (or the same) creds again.

I disagree, a simple "discard" mechanism is not sufficient.  What we
need is something which will work with existing browsers.  By that I mean
that the server can tell if the client understood the reauth request.
An old browser will ignore the echo request, and the server will know
that the client understood, at least in some part, the request.

-> JC> 2) the server needs a way to detect that the client has
-> JC>    or is at least claiming to knowingly complete the task
-> JC> ... (else how would you know if the client actually revalidated?)
-> 
->   But the assurance means nothing; in neither case can the 
-> server know
->   anything about what the user agent did.
-> 
Hrm.. technically, your right, you dont know for sure that the client
isnt lying.  However, the idea is that by responding to the echo,
the client is taking responsibility and acknowledging the request..

The echo response works hand in hand with a discard or reauth to 
provide some acknowledgement.  I guess, in a way, you could look at
this as a client capability mechanism.

As far as the minimal functionality needed, Im not thinking in 
terms of "logout".  I joined paul leach in raising this issue
because I want to see a way for a proxy or server to timeout
a credentials "instance".

We are willing to trust the client if it acknowledges the request.
This also provides a safe way to automatically retry a POST.


-> --
-> Scott Lawrence           EmWeb Embedded Server       
-> <lawrence@agranat.com>
-> Agranat Systems, Inc.        Engineering            
-> http://www.agranat.com/
->