Fwd: [Moderator Action] Re: [Ietf-http-auth] Clients desiring to authenticate

FYI. I have added Joe's email to the accept2 list.

- Jim

Begin forwarded message:

> From: Joe Orton <jorton@redhat.com>
> Date: January 5, 2006 2:24:02 PM PST
> To: Lisa Dusseault <lisa@osafoundation.org>
> Cc: HTTP authentication list <ietf-http-auth@osafoundation.org>,  
> webdav WG <w3c-dist-auth@w3.org>
> Subject: [Moderator Action] Re: [Ietf-http-auth] Clients desiring  
> to authenticate
>
>
>
> On Thu, Jan 05, 2006 at 10:33:13AM -0800, Lisa Dusseault wrote:
>> 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:
> ...
>
> None of this has anything to do with "pre-authenticating" in HTTP.
>
> If your application is designed such that it cannot interactively  
> prompt
> users for credentials when challenged, fine, the app must request  
> those
> credentials from the user ahead of time.  That is purely an  
> application
> design problem, it doesn't imply that the user agent must send those
> credentials to the server *before it is challenged to 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?
>
> The server has no basis on which to validate the credentials, and  
> hence
> do anything other than ignore them.  It *cannot* form a valid WWW-Auth
> challenge because it has not been configured to do so.  Follow your
> argument through as if you were going to implement it server-side:  
> what
> challenge do you expect the server to send?  It cannot make one up out
> of thin air.
>
>> 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)?
>
> If we're not talking about the "I don't want to have to send the 100MB
> PUT body twice in case I get a 401 the first time" problem (which is
> what I presumed that Appendix D was really about), I don't know what
> problem you're talking about.
>
> joe