W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2012

Re: WGLC #357: Authentication Exchanges

From: Yutaka OIWA <y.oiwa@aist.go.jp>
Date: Wed, 20 Jun 2012 19:08:26 +0900
Message-ID: <CAMeZVwuc0D8JChqNu7ziWeQuniLCruQY13D5c0dsJ33wMQQ5Aw@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Mark Nottingham <mnot@mnot.net>, Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
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 new definition is intentionally breaking existing server implementations.
But it these are under clear consensus and intention,
it's OK for me (but sure?).  Mark, can I ask how do you think?

# 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]
Received on Wednesday, 20 June 2012 10:09:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:00 UTC