Clients desiring to authenticate

Thanks for your thoughts on the authentication stuff, Joe, but I 
certainly disagree at a most fundamental level about whether it's 
something clients need to be able to do.  Browsers might not need to do 
so, but I can think of cases where that would be useful for browsers 
too, and it's definitely useful for authoring clients where 
authorization info is usually necessary to do write operations.

Consider some of the WebDAV clients that I'm familiar with:
  - When you configure a Network Place in Windows you can provide a 
username and password right up front.
  - Xythos WebFile client has username and password configured when you 
set up the connection to the server, and subsequent connections use 
that preference info.
  - Chandler 0.6 configures sharing servers just like email servers, 
assuming that users have a home directory and should always log in -- 
again, preference info that's reused with later connections.

When any of these clients is directed to a URL that may be publicly 
readable but with results that may differ depending on what permissions 
you have, what are these clients supposed to do?  Some real examples:
  - If a Xythos WebFile server has some resources that are not publicly 
readable, these won't show up in publicly readable parent collections.  
It requires permissions to see the whole set of child resources of a 
collection in a PROPFIND response.  Yet an anonymous request to the 
publicly readable parent collection won't result in a challenge -- just 
a smaller result set.
  - If a Cosmo sharing server has a publicly readable calendar, then 
when Chandler visits that calendar, it will be able to read the 
calendar and ask what permissions it has without ever seeing an 
authentication challenge.  Yet it's quite possible that the Chandler 
user has a username and password that would provide write permissions 
on the calendar.  How does Chandler even know to activate the "add 
event" button when it's anonymous, asks what permissions it has, and is 
told that it has read-only?

Not only is this coming up on the WebDAV list but this and similar 
problems caused us to try to get the "HTTP-Auth" list started recently, 
and the DIX (Digital Identity Exchange) discussion list (DIX is working 
towards a BOF, then they hope a WG).  I've been asked over and over 
again how a client "desiring" to authenticate (OK I agree desiring is 
the wrong word) can do so.

I also disagree about your reading of 2617. The text is "If the origin 
server does not wish to accept the credentials sent with a request, it 
SHOULD return a 401 (Unauthorized) response. "  Isn't ignoring the 
credentials the same thing as "not wish to accept"?  How can you 
justify accepting a bogus username and password except by entirely 
ignoring it?  But we can certainly quibble about *how* the problem is 
solved, I care more *that* the problem is solved -- for HTTP, WebDAV, 
CalDAV and others.  Would you feel it was still a hack if the client 
used what had previously been a legitimate username (at least for 
elsewhere in that domain)?

I do agree both of the approaches outlined in the current appendix are 
hacks.  We had previously specified a non-hack approach -- a 
"Force-Authentication" request header flag that indicated the client 
might have authorization information which it could provide if only the 
server sent a challenge.

Lisa

Received on Thursday, 5 January 2006 18:33:26 UTC