W3C home > Mailing lists > Public > public-html@w3.org > April 2011

Proposal: Authentication Forms

From: Cameron Heavon-Jones <cmhjones@gmail.com>
Date: Mon, 11 Apr 2011 18:02:23 +0100
Message-Id: <3D5B75F7-1385-422D-BC2C-9B67301476BF@gmail.com>
To: public-html@w3.org
In light of recent call for proposals and through the review and discussion of implementing PUT and DELETE on forms, i would like to make a proposal for the specification of additional functionality in HTML forms. 

As a new member to the w3c and the html wg, i would first add a disclaimer to this proposal that it is not attributed to being of precedent, well formed or complete, however it comes from an aspirational objective and perspective on an issue which is controversial and complex given it's long and troubled existence across the web.

The use case to frame this proposal is that which can be seen as a "missing piece" of the web - User Authentication. This is one area which can be seen to have full support on a protocol level however it has been missing the support on the user interface level from which implementation difficulties arise.

Since the technical functionality and mechanisms for security can be regarded to be complete through the application of HTTP Authentication on the protocol level and TLS\SSL on the transport level, i would propose that in order to achieve a full solution all that is required is the specification of the interface for users to interact with these mechanisms as defined by an application implementation.

In order to achieve this goal in HTML the interface element to manipulate HTTP requests must be defined. As noted in discussions on PUT and DELETE, the form element is the natural control for representing the configuration to the user and is capable of directing the UA to initiate HTTP requests as per its established use.

The specific changes required for forms to support User Authentication is driven by the need for the entire HTTP request to be definable and customizable, and feeds back into the specification enabling greater functional control for existing form uses.

A potential implementation is proposed as follows:

* Addition of new Input element type for HTTP headers - proposed name: "header", eg:

	<input type="header" name="HEADER_NAME" value="HEADER_VALUE"/>

	- Header inputs are hidden by default, can be made visible\editable.
	- Headers added to HTTP request as HEADER_NAME: HEADER_VALUE
	- Multiple HEADER_NAME inputs in form have their values concatenated as comma-deliminated string
	
* Addition of header input processing rules (examples: Authorization and Proxy-Authorization), eg:

	<input type="header" name="Authorization" value="BASIC"/>
	<input type="hidden" name="realm" value="authorized@server.example.com"/>
	<input type="text" name="username"/>
	<input type="password" name="password"/>
	
	- Authorization headers require complex construction rules
	- Values for header are substituted by lookup of input elements by name, ie "username", "password", "realm"
	- UA responsible for applying MD5

* Addition of form method type for HTTP CONNECT
	
	- Method provides direct access to initiate HTTP proxy under authentication


The implementation for this is illustrated by example for the main authentication mechanisms BASIC and DIGEST, and for the proxy CONNECT method: 

HTTP BASIC:

The BASIC authentication mechanism can be operated over any of the HTTP methods - GET, PUT, POST, DELETE. 

<form action="/private/index.html" method="GET">

	<!-- Authorization  Declaration -->
	<input type="header" name="Authorization" value="BASIC"/>

	<!-- Hidden Configuration -->		
	<input type="hidden" name="realm" value="authorized@server.example.com"/>
	
	<!-- Visible  Configuration -->
	<input type="email" name="username"/>
	<input type="password" name="password"/>

	<!-- Form Configuration -->
	<input type="year" name="year"/>

	<input type="submit" name="Login"/>
</form>

*** Request ***
GET /private/index.html?year=2011 HTTP/1.1
Host: server.example.com
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==


*** Response ***
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 0



HTTP DIGEST:

The DIGEST authentication mechanism can be operated over the HTTP methods - PUT, POST - requires body payload.

<form action="/login" method="POST">

	<!-- Authorization  Declaration -->
	<input type="header" name="Authorization" value="DIGEST"/>

	<!-- Hidden Configuration -->		
	<input type="hidden" name="realm" value="authorized@server.example.com"/>
	<input type="hidden" name="domain" value="server.example.com"/>
	<input type="hidden" name="domain" value="server_1.example.com"/>
	<input type="hidden" name="domain" value="server_2.example.com"/>
	<input type="hidden" name="algorithm" value="md5"/>
	
	<!-- Visible Configuration -->
	<input type="email" name="username"/>
	<input type="password" name="password"/>

	<input type="submit" name="Login"/>
</form>

*** Request ***
POST /login HTTP/1.1
Host: server.example.com
Authorization: Digest username="user@example.com", realm="authorized@server.example.com",  domain="server.example.com, server_1.example.com, server_2.example.com", uri="/login", qop="auth"


*** Response ***
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 0



HTTP CONNECT:

<form action="server.example.com:80" method="CONNECT">	

	<!-- Authorization  Declaration -->
	<input type="header" name="Proxy-Authorization" value="BASIC"/>

	<!-- Hidden Configuration -->		
	<input type="hidden" name="realm" value="authorized@server.example.com"/>

	<!-- Visible Configuration -->
	<input type="text" name="host" value="server.example.com:80"/>
	<input type="email" name="username"/>
	<input type="password" name="password"/>
	
	<input type="submit" name="Connect"/>
</form>

*** Request ***
CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==


*** Response ***
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 0


The specification will require full scrutiny, however i hope what has been well illustrated is the problem domain and that a clean solution may potentially be feasible.

Thanks,
Cam
Received on Monday, 11 April 2011 17:02:54 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:24 UTC