RE: Reauthentication Requested Revisited

> -----Original Message-----
> From: Scott Lawrence [mailto:lawrence@agranat.com]
> Sent: Friday, January 23, 1998 1:46 PM
> To: Josh Cohen
> Cc: ietf-http-ext@w3.org
> Subject: Re: Reauthentication Requested Revisited
> 
> 
> 
> >>>>> "JC" == Josh Cohen <joshco@microsoft.com> writes:
> 
> JC> Reauthenticarion required revisited.
> 
>   This discussion got all mixed up.  The original requirement is that
>   the server wants the client to discard the current credentials (that
>   is, those used in the request to which this is a response).
> 
mixed up ? I dont think so.  I understand your reason and I agree with it.
Thats been my motivation all along.

>   There are (at least) three reasons why the server might want to do
>   this:
> 
>    1) The server wishes to force the user to reenter credentials (it
>       has been too long, or too many requests since those credentials
>       were originally obtained - make sure the same human being is
>       still there).  This would normally accompany a 401 response.
> 
>    2) The user has indicated (by pushing a 'logout' button or
>       following an off-site link of some kind) that the authenticated
>       part of the session is over; the server wants the user agent to
>       get the credentials out of cache so that new ones will be
>       obtained next time (eg.  student is doing registration for
>       next semester from a public browser - pushes the 'commit
>       schedule' button).  Most often will accompany a 2xx response.
>       This is the one that people on the CGI newsgroups ask for
>       several times a week.
> 
ok.. see below..

>    3) Those credentials are known by the server to be no longer valid
>       (the password just got changed).  This might be either a positive
>       or negative response.
>
I beleive that this is not a problem.  If your creds fail the browsers
behavior is to pop up the box and ask again anyway..
(I think this issue is presently behaving as expected without any of this )

>   This also serves to illustrate that the feature should not be a
>   status code.
> 
> JC> Introduce a new response header action-request:
> 
> JC>  action-request ":" ActionID "," "type" "=" value
> JC>   ActionID = OpaqueString
> JC>   value = "AUTH" | "EXEC" | "ECHO"
>
(see below = here )
change to 
value = "REAUTH" | "EXEC" | "PURGEAUTH" | "ECHO"

> JC> EXEC means "execute" the content body, which presumably
> JC>  is a script, ie javascript
> 
>   And if I (the user) don't allow execution of arbitrary code shipped
>   to my browser by strangers (no, I don't have Java enabled)?
Well, it would be disabling javascript, VB or whatever was in the body.
The EXEC can fail, but the server should be aware that it may fail.
All this is saying is 'you need to do something before you can
  do this request, go look for instructions in the body'..

> 
> JC> ECHO perform no action, just echo the ActionID in the
> JC>  next request to this URI
> 
>   Yet another form of cookie?
> 
One might agree, but an extremely limited cookie.
1. only works for the exact same request URI
2. only for the next request only, no persist

> JC> Essentially this is a server to client request acknowledgement
> JC> system.
> 
>   And why is that any more assurance that it actually did anything
>   than you had before? (the kid can still _claim_ to have asked Mom)
> 
I guess really what happens here is that the kid is knowingly lying.
Thats ok, the browser must actively "claim" and that is enough.
client is saying "I understand what you said and I dealt with it 
 appropriately"

Obviously a client can be coded to lie, but what Im assuming that the 
client is coded honestly.
If the request failed with 4xx because something was missing, 
 it will fail again even if the client is lying.
The exception is if its a reauth request, in which case I dont
beleieve there is any way to verify that.


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

Received on Friday, 23 January 1998 20:51:13 UTC