|Author:||Scott Lawrence, Agranat Systems, Inc.|
Paul Leach, Microsoft
This document has been submitted to the World Wide Web Consortium (see Submission Request, W3C Team comment).
This document is a NOTE made available by W3C for discussion only. This indicates no endorsement of its content, nor that W3C has, is, or will be allocating any resources to the issues addressed by the NOTE.
This note proposes a new HTML capability to aid in the development of authenticated web user interfaces.
In current web applications, most user authentication is accomplished by one of three mechanisms:
HTTP/1.x provides a mechanism whereby the server can deny access to a resource and indicate that authentication is required for a request for that resource. The usual result of this denial of access is for the user agent to challenge the user for credentials (all defined HTTP authentication schemes require credentials in the form of a user name and password), but no mechanism is provided by the protocol for controlling the presentation of this challenge other than the realm name (a non-internationalized string value).
The combination of first requiring that access be denied and the lack of any control over the form of the challenge means that the application developer cannot make the authentication an integral part of the application.
HTTP Authentication has the addition problem that there is no mechanism available to the server to cause the browser to 'logout'; that is, to discard its stored credentials for the user. This presents a problem for any web application that may be used from a shared user agent. Requests for how to force 'logout' appear almost daily in the netnews html and cgi authoring groups, and are one of the most common support questions received by Agranat Systems from their customers developing embedded systems web interfaces.
SSL (Secure Socket Layer, or its new IETF descendant, Transport Layer Security [TLS]) can be used to authenticate users by means of the public key certificates used to secure the communications channel. This can be done smoothly and in the normal context of the application, but requires the use of strong cryptography. In many contexts this is too costly and complex a mechanism, and because many countries restrict the export of cryptographic technology, it creates legal difficulties for applications that need to cross certain national boundaries.
SSL/TLS certificates have the same problem with stored credentials as HTTP authentication (there is no mechanism to instruct the user agent to discard them), and the certificates are too large to be entered by a normal user interface, so they are not in practice usable at all by sharable user agents.
In order to overcome the disadvantages of each of the above,
many web based applications have used HTML
request the authentication credentials. This is supported by the
TYPE=PASSWORD input element (which is usually not
displayed when entered). This allows the designer to present the
request for credentials as a normal part of the application and
with all the HTML capabilities for internationalization and
The great disadvantage of both form based credentials and the original HTTP/1.0 'basic' authentication scheme has been that they transmit the user credentials in cleartext on the network. This exposure of the credentials is unacceptable for any application requiring real security, and is forbidden in any new protocol to be considered for the Internet Standards track.
Despite its problems, form based authentication is very widely used because of the cost and complexity of using SSL and the poor user experience of HTTP authentication.
As a part of the development of HTTP/1.1, a new scheme for passing authentication information, called 'Digest', has been developed. Digest authentication can mutually authenticate the user and server without passing the actual credentials on the network in a way usable by an attacker (the details are beyond the scope of this note; see ). This overcomes the worst security weakness of HTTP authentication and makes it possible to meet the guidelines for an Internet Standard protocol, but does not help with its poor user interface nor the problem of discarding credentials that are no longer needed. There are mechanisms in the Digest scheme that make it easier for the server to detect how long it has been since credentials were last used and force a request for new ones, but that does not completely solve the problem.
This proposal suggests extensions to HTML forms to overcome
their present security problems by integrating them with HTTP (or
other security sublayer) mechanisms. It calls for a new type of
AUTHFORM and new values for the
TYPE attribute of the
INPUT element and
AUTHFORM element is defined to specify a
specialized form for collecting authentication information. An
AUTHFORM is not submitted to the server, but is used to initialize
the credentials store of the user agent for subsequent requests to
the server from which it was returned.
An AUTHFORM may contain INPUT elements with the special types AUTHUSER, AUTHSECRET, AUTHLOAD, and AUTHUNLOAD, and a SELECT element with the special type AUTHREALM. Each of these is described below.
SELECT element is extended to allow the
TYPE=AUTHREALM; when specified, this
indicates that the values of the contained
elements select the realm value with which credentials in the form
should be associated.
SUBMITin that it indicates that the form values are complete; the AUTHUSER, AUTHSECRET, and AUTHREALM values should be loaded into the credentials store for the user agent and associated with the server from which the form was returned.
The following shows an authentication form (the HTML column is as proposed, the Example column uses standard HTML to create a normal form with the appearance that approximates those expected for the new elements proposed herein):
<AUTHFORM> User Name: <INPUT TYPE=AUTHUSER><BR> Password: <INPUT TYPE=AUTHSECRET><BR> Realm: <SELECT TYPE=AUTHREALM> <OPTION VALUE=READONLY SELECTED>Read Only</OPTION> <OPTION VALUE=READWRITE>Read/Write</OPTION> </SELECT><BR> <INPUT TYPE=AUTHLOAD VALUE="Log In"> <INPUT TYPE=AUTHUNLOAD VALUE="Log Out"> </AUTHFORM>
An earlier draft of this proposal used the existing FORM element (with a new METHOD=AUTH attribute) rather than a new AUTHFORM element; this was changed to avoid the following backward compatibility problem. If a FORM was used, existing user agents rendered the authentication elements as a normal form. This left open the possibility that such a form might be sent to the server as a GET or POST, exposing the credentials. Since AUTHFORM will not be understood by existing software, the various INPUT elements should not be rendered as a form, and this problem does not occur. A similar case might be made for using new elements where this proposal uses types on INPUT elements.
This proposed mechanism could eventually completely replace the
generic authentication prompts used today by user agents. In the
interim, it is not required that a server know whether or not the
user agent understands this new construct. The AUTHFORM can be
served either in the body of the
response (which user agents should already display), or in a normal
unauthenticated page before the application enters the protected
realm. During the transition period, when most user agents will not
be expected to support the AUTHFORM, application developers can
(either conditionally based on User Agent information or not)
include text to explain the feature is available only if the user
agent supports it. This approach has been demonstrated with
numerous new web content technologies, and users generally
It may well be that the HTML community will decide that the particular extensions proposed here are, for whatever reason, inappropriate. The authors acknowledge that they overload some existing elements in ways that may be seen as too different from the existing definitions. The specific syntax and rules of the approach proposed here are not as important as the quick development of a workable and deployable solution; doing so will substantially improve the security of web applications and users. With this in mind, the authors suggest that the following general characteristics be incorporated into a solution:
 Hypertext Transfer Protocol -- HTTP/1.1 (latest internet draft)
 HTTP Authentication: Basic and Digest Access Authentication