W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2002

RE: Interop issue: how can clients force authentication?

From: Jason Crawford <nn683849@smallcue.com>
Date: Wed, 18 Sep 2002 11:33:10 -0400
To: "Lisa Dusseault" <lisa@xythos.com>
Cc: "'Ilya Kirnos'" <ilya.kirnos@oracle.com>, "'Julian Reschke'" <julian.reschke@gmx.de>, "'Webdav WG'" <w3c-dist-auth@w3c.org>
Message-ID: <OF2694B2AD.F04AA33C-ON85256C38.00531AF3@us.ibm.com>




On Tuesday, 09/17/2002 at 11:12 MST, "Lisa Dusseault" wrote:
> > -----Original Message-----
> > > There may be other methods which an unauthenticated user can
> > > receive a
> > > success response, but which would work even better if the user were
> > > authenticated.
> >
> > Shouldn't the server just ask for authentication for those methods?
> >
>
> Not necessarily; if it's possible for the request to return a success
> response if the user is unauthenticated, then the server must do so
> right away or it may never be able to give a success response.
>
> If a 401 error is returned the first time a client asks to do one of
> these methods (like a PROPFIND to a partially-readable collection), how
> does the server know the client will ever make the same request?  Maybe
> the user doesn't know a username/password and so hits "cancel", and the
> client doesn't retry.  And if the client software retries, again without
> a username/password, by your logic the server would just respond 401
> again.

So let me turn this around.  Instead of a client asking to be
authenticated, what if the approach becomes that the client asks
not to be authenticated.   Three options...

1) The client just has a header saying that he choses to be unauthenticated
on a given request.   If the server doesn't see this, and the method could
change it's behavior if authenticated, the server asks for authentication.

or

2) The server simply tries to authenticate and the client responds with
something that indicates that he choses not to authenticate or choses
to authenticate anonymously.  The way to do that can be standardized
or the server can pass info to indicate how to do that... which can be
standardized.

or

3) The user is simply told by other means what userid and password
to use to authenticate themselves as an underprivledged (probably
anonymous) user.   And if they subsequently want to change who they
are authenticated as, the user does that in their client GUI.
Subsequent requests are submitted unauthenticated and when the
server finally wants authentication info for a request, it will ask.

I assume this takes care of this one test case.  Will it take care of the
other test cases?

Please forgive me if the above options seem silly, but I don't really
know what the other test cases are.   I could come up with one, but
I don't want to create a red herring.   Could we clearly state what the
scenarios are that we'd like to address?    Lisa has done a good job
outlining this one, but I haven't seen any other scenerio clearly
outlined.

J.
Received on Wednesday, 18 September 2002 11:35:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:01 GMT