- From: Yutaka OIWA <y.oiwa@aist.go.jp>
- Date: Fri, 08 Jan 2010 18:56:15 +0900
- To: Tim <tim-projects@sentinelchicken.org>
- Cc: ietf-http-wg@w3.org
Dear Tim,
Currently I am implementing/specifying a log-out feature as a part of
our Mutual authentication protocol proposal: more detail for our
proposal are at
https://tools.ietf.org/html/draft-oiwa-http-mutualauth-05 and
https://www.rcis.aist.go.jp/special/MutualAuth/ .
Because the proposal aims to replace both Basic/Digest AND form-based
authentication in a future, we needed to design a useful log-out
feature, which are required to support many currently-cookie-based web
applications.
Regarding log-out implementation on HTTP authentication,
discarding a username/password pair and all session keys (e.g. nonces
in Digest) associated to that pair should basically be fine.
However, I thought there are a few features needed to be added to current
HTTP protocol, to support various services currently implemented in web
applications. I added such a few features as a part of our proposal.
I currently propose it as a part of our Mutual auth. protocol, but if
people are interested, it can be reorganized as a generic extension to
HTTP 1.1. Please look and tell me your impression if any. We already
have a patch to Mozilla Firefox, based on our proposal.
If you are interested, the following are the detail:
What I added in the proposal are
- a facility for client to request log-out.
- a response header for server to request client to force log-out.
(logout-timeout field, specified in Sections 4.6 and 7.3 of our proposal)
it can either be timeout-based or be immediate.
- a response header for server to request client to be redirected when
user requests a log-out (location-when-logout field, Sec. 7.2).
This will be especially useful when the user requests log-out on
a page served to a POST request.
Federated log-in (Single Sign-on) on domain tree level is supported
natively in Mutual auth proposal, so single-sign-off will also work
(If one server request log-out, the user will be logged out from
all sites within the SSO domain.)
P.S.
I also found a possible mis-concept or mis-parsing on conflict between
caching and log-out. Currently many browsers' caches do not distinguish
authenticated contents and unauthenticated contents on the same URI.
This causes some weired behavior happening on log-out and log-in.
For details, see http://t01.rcis.jp/moz-auth-cache-bug/ and
https://bugzilla.mozilla.org/show_bug.cgi?id=533412 .
I would be happy if HTTP RFC explicitly says that the contents for
different users (distinguished in a user-name of underlying authentication)
should not be served by the caches (both public and private), unless
the server explicitly state it as sharable (by Cache-control: public header).
# I personally think that current HTTP specification for the private cache
# do not consider such situations.
--
Yutaka OIWA, Ph.D. Research Scientist
Research Center for Information Security (RCIS)
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 Friday, 8 January 2010 09:56:51 UTC