Some have complained that HTTP Authentication has a poor user interface. This article addresses this.

The Problems

The problem of not having a logout button will be considered in a separate article.

User interface not themed with site

Some have complained that the fact that the user interface is themed with the browser, rather than the site is "jarring". Others, in the words of the W3C XForms Group Wiki HTTP Authentication [10] page, have argued that "this might give form authors access to the authentication data, or might cause users confusion since the browser-controlled look-and-feel was no longer present". This is the traditional tradeoff of security vs. usability.

Inadequate descriptivness

The current HTTP Authentication system does not allow adequate descriptions to be sent. For example, if you want to refer to the username as an "E-mail address", or the password as a PIN number, this is currently impossible.

No non-clunky way to support forgotten passwords

If the user has forgotten their password (or even their username), there should be a way to have this sent to their e-mail address. This currently requires escaping from the HTTP Authentication prompt and then using another method to do this. It would be much better if HTTP Authentication would support this.

No non-clunky way to support creation of new accounts

The only way to create new accounts follows much the same process as the forgotten passwords problem above.

The Solutions

Two solutions have previously been proposed. I propose a new, more secure alternative. The added security may not be worth it, though.

Immediate, somewhat clunky solution

This solution was suggested by Mr. Prasad Chodavarapu, on the article HTTP Authentication Woes [11], by Mr. Bill Venners.

The basic idea is to have one page that isn't password protected, and has options including:

• Create account
• Forgot password
• Log me in

The "Log me in" link would then point at a page that requires HTTP Authentication.

This is a moderately good solution, but there's still plenty of room for improvement.

Long-term flexible solution: XForms-based

The basic solution here is to change the HTTP RFC to support the use of a form in HTTP Authentication. Variations on this have been suggested in:

1. User Agent Authentication Form Elements [12] was submitted as an IETF draft in 1999. It was deemed to be related to the "Next Generation Forms" (I'm assuming this is XForms).
2. Saving HTTP Authentication [13], by Mr. Charles Miller, in December 2003

At the time of "User Agent Authentication Form Elements [14]", it was forwarded to the XForms committee. What's happend since then:

1. The "XForms Requirements" (2001) have a comment about HTTP Auth [15], but this is listed as "non-normative"
2. XForms 1.0 is issued in 2003
3. XForms 1.0 (Third Edition) is issued in 2007

As far as I can see, nothing has been done to actually try to get "User Agent Authentication Form Elements" updated to comply with XForms 1.0.

The W3C XForms Group Wiki's page on HTTP Authentication [16] states that XForms 1.0 did not support HTTP Authentication. They're considering revisiting that decision for XForms 1.1. But only considering. Feel free to help them consider.

Their basic concerns were that they were uncertain about abandoning the following advantages of the status quo:

1. User interfaces for authentication in web browsers are separate from the page, and (supposedly) easily recognizable as bona fide requests (rather than eg. password sniffing attacks)
2. The user is assured that the form author does not have access to the password

If CSS and Javascript were disallowed on the HTTP Authentication form, some of these problems might be avoidable.

I would suggest that XForms 1.1 be altered as necessary to support HTTP Authentication, but that it be left up to the HTTP RFC to specify the necessary alterations to HTTP. This means that the steps from here are:

• Get XForms 1.1 to support HTTP Authentication
• After that happens, get HTTP 1.2 to upgrade HTTP Authentication to work with XForms 1.1

Long-term more secure solution: Expand current standard

The basic idea here is to allow the following information to be sent with the HTTP Authentication request:

• Name of username field
• Name of password field
• General description to go below realm
• Should a "Forgot Password" button be included
• Should a "Create New User" button be included

This solution is obviously more secure, but most definitely less flexible than the other. For example, it doesn't allow additional fields, such as might be desired when creating a new user. I personally would prefer the XForms-based solution, but the above would go a long way towards remedying the existing faults.