Re: WGLC #357: Authentication Exchanges

On 20/06/2012, at 8:08 PM, Yutaka OIWA wrote:

> Dear Julian,
> 
> 2012/6/20 Julian Reschke <julian.reschke@gmx.de>:
>>> I think this (use 401 instead of 403) should be kept for two reasons:
>>> 
>>>  * Without 401 status, client will not know that changing
>>>     the user name and the password will solve the
>>>     inaccessibility issue.
>> 
>> 
>> Sorry?
>> 
>> "The server understood the request, but refuses to authorize it. Providing
>> different user authentication credentials might be successful, but any
>> credentials that were provided in the request are insufficient. The request
>> SHOULD NOT be repeated with the same credentials." -
>> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-19.html#rfc.section.7.4.3>
> 
> I see.  I noticed now that this was changed incompatibly from RFC 2616.
> Thank you for telling me.
> 
> Now I have a concern with the text for 403 status for two reasons,
> * any recovery from failed authorization (with successful authentication)
>   is completely out of the protocol's provision, and

The client is still able to submit a new request with different credentials (or no credentials, if it needs a new challenge).

> * the new definition is intentionally breaking existing server implementations.
> But it these are under clear consensus and intention,

It doesn't make them non-conformant; they can still choose to use those status codes in the manner they are.

> it's OK for me (but sure?).  Mark, can I ask how do you think?

See:
  http://trac.tools.ietf.org/wg/httpbis/trac/ticket/294

Cheers,

> 
> # With the older semantics to use 401 for authz-failure,
> # failed authorization was recoverable
> # (although in somewhat uncomfortable way).
> 
> Accepting the above consequences, the Mark's text is making sense.
> However, we will not able to define 403 to be "one of the
> authentication-related states" as an original proposal, because
> 403 already has several other use cases which is directly conflicting.
> # More specifically, clients could not assume that 403 has
> # any meaning for authentication-related status.
> 
> Don't we need (do we have a clear way, or do we need to define how)
> to distinguish failed authz from other generic access privilege failures?
> 
> # For example, is "403 response with WWW-Authenticate: header,
> # as a response for request with Authorization: header"
> # restrictive enough for defining such a status?
> 
> -- 
> Yutaka OIWA, Ph.D.              Leader, Software Reliability Research Group
>                              Research Institute for Secure Systems (RISEC)
>    National Institute of Advanced Industrial Science and Technology (AIST)
>                      Mail addresses: <y.oiwa@aist.go.jp>, <yutaka@oiwa.jp>
> OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

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

Received on Wednesday, 20 June 2012 10:25:00 UTC