The HTML WG took a look at the whole form authentication situation;
after some exploration, we're inclined to postpone it;
i.e. to not accept a requirement to address it in this go-round.
I'm interested to know if anybody in/around the TAG has
a better idea.
--
Dan Connolly, W3C http://www.w3.org/People/Connolly/
gpg D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E
Forwarded message 1
Issue-13 in our tracker
http://www.w3.org/html/wg/tracker/issues/13
represents something that has been around for over a decade.
In a 20 Nov teleconference, we generated a proposal to
postpone this issue; the action (ACTION-86) fell to me to explain
the history of the issue and relay the proposal.
http://www.w3.org/2008/11/20-html-wg-minutes.html#item04
A few days later, there was a proposal to address
the issue, followed by discussion that persuaded the
editor to withdraw it; Thanks to Mark P. for summarizing:
[[
The big news this week is a radical proposal for integrating HTTP
authentication with HTML forms. r2432 defines a new token for the
WWW-Authenticate header: "HTML".
A common use for forms is user authentication. To indicate that
an HTTP URL requires authentication through such a form before
use, the HTTP 401 response code with a WWW-Authenticate
challenge "HTML" may be used.
For this authentication scheme, the framework defined in RFC2617
is used as follows. [RFC2617]
challenge = "HTML" [ form ]
form = "form" "=" form-name
form-name = quoted-string
The form parameter, if present, indicates that the first form
element in the entity body whose name is the specified string,
in tree order, if any, is the login form. If the parameter is
omitted, then the first form element in the entity body, in tree
order, if any, is the login form.
There is no credentials production for this scheme because the
login information is to be sent as a normal form submission and
not using the Authorization HTTP header.
This idea has been kicked around for more than a decade. Microsoft wrote
User Agent Authentication Forms in 1999. Mark Nottingham asked the
WHATWG to investigate the idea in 2004.
]]
-- November 25th, 2008 by Mark Pilgrim, Google
http://blog.whatwg.org/this-week-in-html-5-episode-14
[[
The big news this week is the disintegration of HTTP authentication from
HTML forms (which was last week's big news). As I predicted, the
proposal generated a healthy discussion, but a combination of security
concerns and concerns about tight coupling ultimately did in the
proposal.
In its place, r2470 includes the following conformance requirement to
allow for the possibility of someone specifying such a scheme in the
future (hat tip: Robert Sayre):
HTTP 401 responses that do not include a challenge recognised by
the user agent must be processed as if they had no challenge,
e.g. rendering the entity body as if the response had been 200
OK.
User agents may show the entity body of an HTTP 401 response
even when the response do include a recognised challenge, with
the option to login being included in a non-modal fashion, to
enable the information provided by the server to be used by the
user before authenticating. Similarly, user agents should allow
the user to authenticate (in a non-modal fashion) against
authentication challenges included in other responses such as
HTTP 200 OK responses, effectively allowing resources to present
HTTP login forms without requiring their use.
]]
-- December 10th, 2008 by Mark Pilgrim, Google
http://blog.whatwg.org/this-week-in-html-5-episode-15
So on behalf of the WG chairs, I propose to postpone issue-13;
i.e. to acknowledge that it's an issue, but to put addressing
this issue out of our critical path for our current deliverable(s).
I think there's sufficient support for this proposal already
recorded that "I agree" messages are best left implicit.
Maybe "I abstain" messages are worthwhile; you can choose for yourself.
Objections should be given in email replies to the WG within a week.
This proposal implies that the chairs believe all the
relevant arguments have been made and that there are
no unexplored arguments available. A line of argument
that the WG has not yet sufficiently explored
would make for a reasonably persuasive objection, especially
if it included cost/benefit analysis that shows that
this issue belongs in our critical path.
If the proposal carries (either because there are no objections
or because the objections do not persuade the chairs that
the proposal should fail) then discussion of this issue would
be closed unless/until new information arises that merits re-opening it.
--
Dan Connolly, W3C http://www.w3.org/People/Connolly/
gpg D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E