Re: WGLC #357: Authentication Exchanges

Looking at this, I think this language in the spec isn't very good for other reasons as well:

> If the origin server does not wish to accept the credentials sent with a request, it should return a 401 (Unauthorized) response. The responsemust include a WWW-Authenticate header field containing at least one (possibly new) challenge applicable to the requested resource.
> 
> If a proxy does not accept the credentials sent with a request, it should return a 407 (Proxy Authentication Required) response. The responsemust include a Proxy-Authenticate header field containing a (possibly new) challenge applicable to the proxy for the requested resource.


Because "accept" can be read in so many ways. I think we can fix both problems with something like:

"""
Requests for protected resources that omit credentials, contain invalid credentials (e.g., a bad password), or partial credentials (e.g., when the scheme requires more than one round trip) SHOULD return a 401 (Unauthorized) response. Such responses MUST include a WWW-Authenticate header field containing at least one (possibly new) challenge applicable to the requested resource.

Likewise, requests that require authentication by proxies that omit credentials, or contain invalid or partial credentials SHOULD return a 407 (Proxy Authentication Required) response. The response MUST include a Proxy-Authenticate header field containing a (possibly new) challenge applicable to the proxy.
"""

Thoughts?


On 15/06/2012, at 9:24 AM, Mark Nottingham wrote:
> On 15/06/2012, at 12:50 AM, Yutaka OIWA wrote:
> 
>> Dear Mark,
>> 
>> I'm not Alexey, but (one of) the person(s) proposing an HTTP authentication
>> not happen in just one exchange.
>> 
>>>> If the origin server does not wish to accept the credentials
>>>> sent with a request, it SHOULD return a 401 (Unauthorized) response.
>> 
>> My interpretation of this phrase is "if the origin server does not wish to
>> provide the requested resource with credentials sent within a request"
>> (slightly rephrased).
>> Under this interpretation, we can implement multi-exchange authentication
>> by using the 401 status code as follows:
>> 
>> A non-authenticating request -> 401 Unauthorized (not acceptable)
>> -> ask user a secret
>> -> A request with 1st-credential -> 401 Unauthorized (not satisfied yet)
>> -> A request with 2nd-credential -> 200 Succeed (now satisfied enough)
>> 
>> # Of course, it can be naturally extended for three or more exchanges.
> 
> That was my reading too.
> 
>> As far as I know, 401/407 are the best choice for this case.
>> I also think that there were already multi-exchange HTTP authentications
>> using 401 in this way.
>> 
>> If one thinks the original sentence is bad for this,
>> his/her understanding of the above flow may be
>> "the server is accepting the 1st credential, and just requesting more", I guess.
>> 
>> My proposal is either we can just leave the text as is, or rephrase it
>> like something above.
> 
> "provide the requested resource" isn't correct from an HTTP standpoint, but I see where you're going.
> 
> My (personal) inclination is to leave it as-is, but I'm not against rewording if that'll move us forward.
> 
> Alexey?
> 
>> 
>> # Any rephrasing again with better English is welcome.
>> 
>> 2012/6/8 Mark Nottingham <mnot@mnot.net>:
>>> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/357>
>>> 
>>> Alexey, could you say a little more here? The text as it reads doesn't require authentication to happen in one exchange; it only mandates the status codes and headers to use.
>>> 
>>> Thanks,
> 




--
Mark Nottingham   http://www.mnot.net/

Received on Wednesday, 20 June 2012 02:05:22 UTC