[Fwd: OK to postpone ISSUE-13 handling-http-401-status (form authentication...)?]

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

  • From: Dan Connolly <connolly@w3.org>
  • Date: Tue, 16 Dec 2008 12:04:02 -0600
  • Subject: OK to postpone ISSUE-13 handling-http-401-status (form authentication...)?
  • To: "public-html@w3.org WG" <public-html@w3.org>
  • Message-Id: <1229450642.7182.401.camel@pav.lan>
Issue-13 in our tracker 
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.

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

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

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

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

Received on Tuesday, 16 December 2008 18:11:24 UTC