[whatwg] HTML Was:HTLM5 - Addressing the Password Craze?

[Anders Rundgren]

Pardon,
I hope that you read the rest in spite of the fact that I screw-up already in the subject line. :-(
Please correct the spelling in answer threads.
Anders

----- Original Message ----- 
From: "Anders Rundgren" <anders.rundgren at telia.com>
To: <whatwg at lists.whatwg.org>
Cc: "Sam Hartman" <hartmans-ietf at mit.edu>
Sent: Thursday, September 07, 2006 08:16
Subject: [whatwg] HTLM5 - Addressing the Password Craze?


Dear all,
As you probably have noticed, practically every site offers a login.for their
members, customers, citizens etc. etc.

There are two problems here.
1.   User-id/password management has become a real nuisance. Once this was
an issue for computer professionals only, now it affects everyone from children
to grandma.

2. There are other and better authentication methods available that become hard
to migrate to without making life hard for end-users by asking them to use another
login method.  The site has no way of detecting the user's options.

It appears, that it may be possible to add some kind of negotiation/option
elements at the HTML level, that if supported by the underlying system could
offer a standardized and potentially more powerful version of the password
caches or external login form "hijacker software" that we currently use. 
Tentative functionality for the AHE (Authentication Helper Extension):

- Find out if the AHE is installed/available

- If the AHE is available, find out if the site in question is in the list

- If in the list, put out a dialog box giving the user an option to login, decline
  or manually enter login information. 

- If the site so requests, the user's authentication options (in case form based
  authentication was used) can be transferred during login, giving the site an
  option to ask/require the user to upgrade their authentication.  This could
  involve anything from digest-authentication to certificates.  The latter
  current lacks a decent provision method but there is some work 
  going on in this area as well.  MS CardSpaces is also an option.

- The authentication stuff would be possible to store in an USB token or
  even better in a mobile phone.  This is of course outside of HTML5
  but will be natural to support within 3-5 years from now.

- The scheme would (if properly implemented) be able to thwart phishing
  since a user-id/password (or other auth solution) could be tied to a
  SSL root + host name (or even better host domain).

In essence the desired result is a portable (mobile) multi-site authentication
 support mechanism that should not only make the web easier, but also
long-term considerably more secure.  

Other Options?
==========
The other option is addressing this problem at the transport level but I think
form-based authentication is a better entrance point since it is already in place.
There is no problem [at all] of having a mechanism [in the proposed scheme]
that switches from form-based authentication to transport-level authentication
like using TLS-client-certificates, while the opposite is impossible.

Sincerely
Anders Rundgren