Re: WGLC #357: Authentication Exchanges

Dear Mark,

2012/6/20 Mark Nottingham <mnot@mnot.net>:

> That's effectively where we are; note that there aren't any RFC2119 conformance requirements placed around this.

I prefer to be explicit that use of 403 is just a preference
and is not RFC2119 nor other "requirements".
"Ought-to" sounds to be louder than RECOMMENDED, as a natural language.
# correct me if I have an English problem.


P.S. ("Intended Status: Informational")

I'd like to append that, (although I prefer 401 approach as default,)
allowing 403 for authz-failure *is* a good thing for deployability.

HTTP Authentication and authorization are implemented in
various software layers, depending on each software's own design.
If both of them are implemented in the same software layer
(both within Web servers, or both within applications),
there are no problem.   However, if auth is in the Web server,
and if authz in the application logic, it is hard to send
a valid 401 response to the client when
the used authentication scheme is more complex than Basic.
Allowing 403 (or empty 401, alternatively) will solve this problem.

In reality, we have experienced implementation difficulty
exactly in this case for proposed Mutual authentication.
It is because Apache web server has separate sub-layers for
auth and authz, and the same problem arised.
Until version 2.2, Basic and Digest
were hard-coded for error handling in the authz layer.
In the current 2.4 series of Apache, it is fixed by adding
an additional API in the auth layer.


-- 
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 11:31:47 UTC