Single Sign-On for the Web – Part 2: The Solution?

Update:

I’ve been catching some heat for this post, as I kind of figured I would.  A couple points of clarification before you read on:

1. Directly authenticating with your  email server would only be used for sites that you trust and want to integrate into your online "identity".  You wouldn’t want to use it to buy a digital camera from a fly by night Internet store, but I would question the wisdom of giving them your credit card info in the first place.  However, I would let Amazon authenticate me like this, provided they agree NOT to store my password (which isn’t needed and would be a huge liability for them anyway).
2. If somebody does use this method to authenticate with a questionable party, all he needs to do to re-secure his identity is change his email password.
3. Client side javascript hashing is already available

I’ve never seen this method presented before in any forum so I wanted to get this out there as an option, however worthless an option it may turn out to be.  Never leave any stone unturned, that’s my motto

************************************************************************

In a previous post, I wrote about WHY single sign-on for the Web is needed–badly.  In this post, I’m going to look at an idea I had about how to make it happen with the infrastructure that’s already in place today.  Whether it flies or not remains to be seen, please shoot holes in it

Microsoft wants us all to install InfoCards on all of the devices we use (including public terminals and kiosks), and OpenID wants us to establish our identity by setting up trusts with different Web sites, and there are a handful of other similar ideas.

However, I think it might actually be simpler than all that. I could (quite possibly) be nuts, but I had an intriguing thought the other day:

1. To authenticate, you need some type of authority.
2. The only real authorities on the Internet at this point are the domain registrars
3. The only user accounts associated with domains are email accounts

This tells me that the only way to achieve universal user authentication on the Internet right now is to use email accounts. The only definitive identification we have on the Internet right now is our email address.  What that doesn’t mean, however, is that every application should use the email address as the username (although I do like this better than another, different, user ID) and create a new password for the account.

What I’m getting at is this: I don’t see any reason why users shouldn’t be authenticated with their email servers. Why can’t sign-on work like this?

1. The user goes to the site’s URL (www.buystuff.com )
2. Before they can buy something, the user has to enter their email username and password ([email protected] and test123)
3. www.buystuff.com looks up the email server for jasonkolb.com from the domain registrar (using the domain’s MX record).  We now have a server that can authoritatively identify the user.
4. www.buystuff.com sends the email server the email address and password that it was given. If it’s able to authenticate, the user can be positively identified as [email protected] without the need for any further logins and passwords (and without even needing to STORE a password, of any kind!).

The problem I see with this is that you have to provide www.buystuff.com with your email password. This could be dangerous if somebody gave their email password to a site they shouldn’t really be trusting.  However, this really isn’t much different than what people are doing every day right now with their credit cards, so I don’t think it’s really that big of a leap.  The sign-on page should be signed with a trusted certificate from a certificate authority anyway, so it’s essentially the same level of trust we have today.

The other alternative is to build hashed password support into the email server. I actually prefer this method, because it would allow the user to authenticate using email without having to tell the site what his password actually is.  If browsers could do the hashing that would be one step better since the user wouldn’t have to send his real password to the site at all.  Today, the only browser-side caching that exists is using Digest Authentication, which is on the browser side, so the only missing piece to making this solution secure end-to-end is email servers that support digest authentication.  Alternatively, I think it’s realistic to set up an authentication authority for each domain. In much the same way that an email server is found by looking up the MX record for a domain, we should be able to look up the authentication authority for a domain. The authentication authority for a domain should return the IP address of a server that supports digest authentication, so that applications could just forward the user’s email address and hashed password to it and receive a response indicating whether the user is authenticated or not.  Or, possibly even a token that identifies the user.

One of the big advantages I see to this approach is that for say, publicly traded companies that need to be Sarbanes-Oxley compliant, their email server generally authenticates against an LDAP repository of some sort such as OpenLDAP or Active Directory. This means that their security policy is enforced for that email account, such as password complexity and expiration. All of the heavy lifting for compliance is done by the LDAP server, so there’s never a risk of any of the user accounts on that server being out of compliance.

The only roadblock I see to this approach is people’s reluctance to share their email account info with another party.  However, people don’t seem very shy about giving their email account away right now anyway, just about every Web desktop such as Netvibes or Goowy requires you to enter your email account information to read your mail.  And the passwords are actually STORED on their servers, this approach doesn’t require that.  Whatever happens, I hope it happens soon, because once we’re able to track our activity against a single ID, the next leap in Web functionality is really going to take off.

FYI I’m planning to build a proof of concept on this very soon, unless somebody wants to volunteer