- 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