If there is one thing that is universal to all websites, it is the login process. Almost every website requires you to create an account, enter your e-mail address, verify your account, and log in before you can use any of the advanced features of the website.
Wouldn’t it be great if there was a universal login mechanism for the web? One where you just had to click a login button and your browser would take care of filling out your account details? What if you didn’t need to remember different passwords to log into websites? What if we could do all of this and ensure that only you and the website you are communicating with would be able to see the data you are sending?
The good news is that there are some very smart people working on this problem. The solution is called WebID. The bad news is that there remained one problem that would take the browser vendors years to solve. That is, until Dave Longley (our CTO), discovered a way to make WebID work in all the current browsers in use today, including Internet Explorer.
The Website Login Problem
Before we get too involved with WebID, we must identify the problems with website login:
- Most websites require a username and password to use non-basic features.
- It’s best to use different passwords on different websites and change the password every couple of months, but nobody does that. It’s just too difficult to remember all the different username and password combinations. We tend to use a variety of usernames and a single password, that we never change, on all of our websites.
- Your e-mail address is required on almost every website. Your address information is often required for credit card transactions. Filling out identification forms over and over on the web is time consuming and unnecessary. Computers were supposed to be doing these monotonous tasks for us by now.
- Changing your avatar image or e-mail address requires you to update this information on every website that you use. You should only have to change it once and then that change should propagate to all of your websites.
- If you lose your password or forget your username then you’re locked out and usually have to reset your password. That is, as long as you can remember what e-mail address you used to sign up to the site in the first place. Sometimes you won’t even have access to that e-mail address if you’ve moved e-mail providers.
This problem isn’t new and many people have attempted to solve it over the past decade. Microsoft tried with Passport and Windows Live ID, but failed because Microsoft didn’t release the technology under an open license. Facebook is doing well with Facebook Connect, but requires that you have a Facebook account. Several large websites have adopted OpenID, which is better and compatible with WebID, but is still too restrictive for many of the scenarios that WebID addresses. The issue with all of these services is that they don’t work with the fundamental architecture of the web, which is distributed. WebID is distributed and is designed to work in concert with the principles that have made the Web flourish – data portability, data ownership and decentralization.
WebID solves all of these problems by providing a single universal identification mechanism that is controlled by you at all times. Just like you have a set of keys to get into your home, WebID provides you with a set of keys to access your favorite websites. There is no more registration on websites and no more passwords. Changes to your profile can be done in one place and the changes propagate to all your WebID-enabled websites. With WebID, there’s no more filling out identification information. You also get the peace of mind that if someone steals your laptop or your WebID keys, you can always just deactivate the keys that were stolen via your WebID provider and continue to use your WebID with a new set of keys. In the real world, if you lose your keys you don’t have to change your house, you just have to replace the locks and get a new set of keys. The same analogy applies to WebID.
WebID solves all of these problems by providing you with a single web page with a set of computer-generated keys that you can publish anywhere on the Web. When you go to a WebID-enabled website, it will ask your browser for your WebID and then go to your WebID page to get all the information that is necessary to log in. Your browser, in cooperation with your WebID page, works with WebID-enabled websites to ensure that you and only you can access your account on the WebID-enabled website. The browser does this by using something called Transaction Layer Security (TLS) and client-side certificates. That’s just a fancy way of saying that your browser has a very special key that can be used to log into WebID-enabled websites. Nobody else has that key and that key identifies you to the WebID-enabled website.
We’ll be posting more details on how WebID works in a future blog post, but we wanted to focus on an important breakthrough in this blog post.
The Largest Technical Hurdle
Many of the technical hurdles have already been overcome with WebID, but there remained one final piece of the puzzle. We couldn’t move forward with WebID without the agreement from every single one of the browser vendors. Getting browser vendors to agree on new features is a very long, multi-year process. Most of the successful Web technologies get traction outside of the web browser and eventually make it into the web browser in time.
There are two vital browser-based technologies required for WebID to work; the <keygen> element and client-side certificate support. This support has been in Firefox, Safari and Chrome for quite a while now while Internet Explorer provides its own proprietary ActiveX mechanism. It could be half a decade before <keygen>, and thus proper WebID support is integrated into IE. This was holding WebID adoption back in a very bad way.
The problem was that TLS implementations in the browser don’t surface the proper application programming interfaces to developers that want to modify the connection process – a requirement for WebID to work properly. Asking the browser vendors to allow this would kick off years of work for all parties involved. One way to direct the TLS connection would be to write a custom plugin for the browser, but then you would require everyone that wanted to use WebID to download a custom browser plugin. Developing plugins for all the major browsers would also be a difficult undertaking.
- WebID now works in a standard way in recent versions of all major browsers, including Internet Explorer.
- WebID now has a consistent interface for selecting WebIDs across all WebID-enabled websites.
- The source code will be released to the WebID community in the coming week, which can be integrated by sites like Facebook, Twitter and other sites that want to support WebID-based login.
The WebID Demo
You will also see security errors when you click on the two links below. This is because we haven’t purchased SSL Certificates for either site. If we had purchased SSL Certificates for either site, you wouldn’t see the warning, but this is a demo after all, so just ignore this minor nuisance for now. When WebID is deployed in a production setting, the sites would have real SSL Certificates.
After you have generated your certificate, go to the WebID-enabled website and ignore the warnings and accept the website certificate. To log into the website, click on “Digital Bazaar WebID” and then click on the blue “Select” button beside the WebID that you would like to use to identify yourself to the website. If everything goes well, you should see a Welcome screen.
That’s it. That is how easy it is to generate a WebID and log into a WebID-enabled Website. The demo proves the following WebID concepts:
- Storing the certificate using Flash local storage, so that all of your browsers have access to the certificate.
- Secure retrieval of WebIDs on any website using an iframe.
- Selecting one or more Certificates from Flash local storage.
- Successful login using WebID via TLS.
There are a few more features that we need to implement to make the demo more useful, namely:
- Adding more features to the WebID management page like certificate revocation, OpenID support and adding things like friends, photos and address information.
- Ensuring that the public keys in the client certificate match the ones published by the WebID URL.
- Distributing the Flash Policy file via Apache.
- Usability improvements in browsers like Internet Explorer and Firefox.
- Expressing the WebID using structured data (like RDFa or Microdata).
We’ll follow this blog post up with a couple posts about WebID implementation details and how the specification is progressing. If you find this stuff interesting, please join us on our bi-monthly teleconferences. The audio recording of the first call is available as are the minutes from the meeting. We’re having another “open to the public” meeting this coming Tuesday at 12PM EDT. If you have a SIP-capable phone, feel free to join us and listen in on the discussion.