Re: WGLC #357: Authentication Exchanges

On 2012-06-20 06:11, Mark Nottingham wrote:
>
> On 20/06/2012, at 1:08 PM, Amos Jeffries wrote:
>
>> On 20.06.2012 14:04, Mark Nottingham wrote:
>>> 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?
>>>
>>
>> second paragraph:  s/The response MUST/ Such responses MUST/ is a bit clearer that its the 407 which "MUST", not any other status which may happen.
>
> OK
>
>> There is also no mention in any of the auth draft about 403 responses being used to terminate authentication attempts or cycles regardless of credentials validity or presence.
>>
>> Something informational in this section would be very useful to clarify that 403 is one of the authentication-related states, for use in halting loops or making N-tries limitations.
>
> How about, after those two paragraphs:
>
> """
> A server receiving credentials that are valid, but not adequate to gain access, ought to respond with the 403 (Forbidden) status code.
> """
>
> ?
> ...

Works for me; with that we have:

261,271c261,275
<  If the origin server does not wish to accept the credentials sent
<  with a request, it SHOULD return a 401 (Unauthorized) response.  The
<  response MUST 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
<  response MUST include a Proxy-Authenticate header field containing a
<  (possibly new) challenge applicable to the proxy for the requested
<  resource.
---
 >  Requests for protected resources that omit credentials, contain
 >  invalid credentials (e.g., a bad password), or partial credentials
 >  (e.g., when the authentication 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.  Such responses MUST
 >  include a Proxy-Authenticate header field containing a (possibly new)
 >  challenge applicable to the proxy.
 >
 >  A server receiving credentials that are valid, but not adequate to
 >  gain access, ought to respond with the 403 (Forbidden) status code.

(<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/357/357.diff>)

Best regards, Julian

Received on Wednesday, 20 June 2012 08:16:52 UTC