W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2010

Re: Past Proposals for HTTP Auth Logout

From: Tim <tim-projects@sentinelchicken.org>
Date: Thu, 28 Jan 2010 07:58:25 -0800
To: figroc <figroc@gmail.com>
Cc: ietf-http-wg@w3.org
Message-ID: <20100128155825.GG22430@sentinelchicken.org>
Hello,

Thanks for taking a look through the paper.

>     Rather introducing the new Authentication-Control header, I'd
> prefer utilize the Authentication-Info header. For the current
> request, HTTP server still needs to send the response with
> Authentication-Info header, we can just add a new parameter, such as
> terminate="true" as presented in your paper.

I thought about this, but unfortunately the Authentication-Info header
does not include the realm, so it would be a little weird trying to
adapt it for other authentication schemes.  If the only concern was
giving Digest authentication a log out, then that would be fine, but I
am trying to look at the big picture for other, better authentication
schemes.

>     As for customizable login form, there are some proposals
> suggesting integration with HTML5 form authentication which talk about
> sending authentication information through normal form submission. I'd
> rather let HTML5 capable browsers submit authentication information
> through Authorization header, that'd be more consistent. If we allow
> WWW-Authentication present in 2xx/3xx response, legacy browsers will
> act as usual.

I'm not intimately familiar with the HTML5 process or all possible
proposals, but the ones I've read appear to be a big step backward.
They appear to be trying to create a new authentication scheme to
codify forms-based authentication.  I don't see how that would be
compatible with things like digest authentication.

Note that HTML forms and JavaScript hacks could be relied on for a
rich user interface, but it would still be perfectly acceptable for
legacy browsers or persons with accessibility requirements to directly
access a protected area and receive the standard generic login form.

The logout piece here is more problematic though.  I think achieving
this in HTTP is much more preferable, starting with 401 handling
changes.

>     BTW, why don't we introduce SRP to HTTP authentication? In my
> experience, that servers must store password hashes (A1 values) which
> can be used to authenticate against server directly is a big security
> drawback.

I think Yutaka covered this point.  I think SRP would be great, but
since most browsers already support digest and it's better than
cookies, my thought was to make HTTP auth generally usable again, let
people benefit immediately from digest's security properties and then
later it won't be as difficult to transition to better HTTP auth
schemes.

Thanks for the feedback,
tim
Received on Thursday, 28 January 2010 15:59:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:16 GMT