The problem isn’t anything new, really – most people have hundreds of accounts on different websites.

The username is usually their email address, and the password…well the password tends to be the same on all of the sites, and it is usually eight characters or less.

It is simply too hard for most people to memorize passwords much longer than that.

So they use something simple like “12345678”, and the next thing they know, they’ve been well and truly pwnz0red.

A few people have tried solving the issue with a single password sign-on.

There’s OpenID, and Facebook and Twitter logins, etcetera, and they’re all used by a few websites. Pretty much every big company has a system like this now.

The issue is that both users and websites who use these services are handing over the keys to their kingdoms to other proprietors.

They sometimes go down (occasionally quite famously), and then websites that rely on them have an issue.

Even when working perfectly, it isn’t helpful to hand over all knowledge of one’s userbase to somebody else, and then just pray for the best.

And then with all of the proliferation of single signons, users still have the same password issue.

What is needed is an open, transparent, decentralized login system that also doesn’t rely on the same old, same old username (email) slash password nonsense.

The thing is, we already have a piece of software that is specifically designated as the user’s agent. It’s called a web browser.

We also have a workable (some flaws which we’ll discuss below) authentication system called a certificate. They’re used for validating a whole bunch of things, from SSL on websites, to SSH sessions.

So why don’t we put it all together?

It’s really this simple:

1. We need to make a place for user profiles in the browser. Since it is unlikely that we’ll ever get all of the browser vendors to agree on a single standard, a plugin will do nicely for now. Users should be able to create many different profiles from their browsers. Each profile can store a variety of sorts of information about themselves, which they can choose their own privacy settings for. When they create a profile, a private key certificate would be generated, and stored safely somewhere else on their computer (because browser memory stores aren’t necessarily safe from malware). The browser store would then save one or more public key certificates that are generated by the private one. These would be shared with websites during authentication.

2. When a user comes to a website that requires a login, the site would send an authentication request over to the user’s browser. The user would then select a profile to share with the site. The site would receive the public key certificate for the profile, along with whatever info the user chooses to share with it. The website could then store a cookie in the browser or whatever other method it uses to maintain an active session. Logging out would remove the cookie, the same way that existing sessions are managed.

3. The user would be able to see a list of websites that have been authenticated with a given profile, right from their browser – and more importantly, they could manage the list, along with privacy settings, regardless of whether they are logged into those sites.

4. The site would still have all of the info necessary to deal with user profiles. Ideally some kind of mechanism would be in play to negotiate which pieces of info (i.e. email addresses) are actually required by the site.

5. The entire process would be fairly transparent to users. They would never need to type in a username or password, and the login process becomes a single button click. Obviously there should be some form of strong security on the browser side – this is much easier to do though, given that the software is installed on the user’s computer. A password or iris scan or finger swipe would do the trick nicely. No need for a third-party password wallet (outside the browser, that is).

6. Privacy is maintained, because users can create whatever profiles they want, set whatever privacy settings they want for them, and share them only with whomever they want.

There are some caveats, of course:

1. The system would need to be implemented properly, otherwise security flaws will creep in. A widely supported open source project is in order.

2. It would still be somewhat susceptible to malware or man-in-the-middle attacks (same as existing authentication systems). Ensuring that signup and login only occurs via SSL may somewhat mitigate this, but it will still be an issue. The advantage of permanently doing away with passwords still outweighs this.

3. We need to ensure that the public key certificates are unique. Hopefully somebody with better understanding of this sort of system than me will chime in here. One possible future extension would be an optional certificate signing system, like we have with SSL certs. I say optional, because there are privacy issues pertaining, as well as a cost factor. Some people may benefit strongly from having a third-party authenticated profile though (i.e. celebrities).

I’d be interested in hearing feedback from people on this. I don’t think it would be terribly hard to build a proof of concept system, but it will take a lot of eyes to make something like this bulletproof.

Also, it is very important that there is a single standard for how this should work. It doesn’t matter if there are many different projects implementing it, but standards are necessary for this to become a global system.