- 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
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 UTC