WebID – Universal Login for the Web

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.

For WebID to be successful, it must work in most of the browsers that are out there already. Unfortunately, the only technologies that are broadly available to implement TLS and client-side certificates are Javascript and Flash. It takes a special kind of crazy to even consider attempting to implement TLS in pure Javascript and Flash. Luckily for the Web, our CTO is that special kind of crazy.

A WebID Implementation in Pure Javascript and Flash

Dave Longley (Digital Bazaar’s CTO) implemented TLS in pure Javascript and Flash over the course of several weeks for another company project. Most of that work was re-used to implement certificate generation and client-side certificates for WebID in pure Javascript and Flash. The primary benefit being that the implementation works in Internet Explorer and every major browser in existence today. This is a huge step forward for WebID.

The benefits as a result of this pure Javascript and Flash implementation of WebID include:

  • 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

Most of these concepts are best demonstrated via a simple demo. In this demonstration, you will create a WebID and then use that WebID to log into a website. Please note that this is all very preliminary and won’t work in some older browsers, like IE6 and IE7, or browsers with very slow Javascript engines. For best results, use a recent version of Google Chrome. That said, it should work in Firefox 3.5+, Chrome 5.0+, and Safari 4+.

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.

First, you will need to get a WebID. We have setup a demonstration WebID provider. Go there, ignore the warnings and accept the certificate, enter your name in the “Name” field and click Create. It will take several seconds to generate the public and private key pair for your certificate. Public/Private key Cerificates are at the core of WebID, and thus require quite a bit of computation to generate. The certificate generation will be faster on browsers that have very fast Javascript engines. Chrome will only take a few seconds whereas Firefox may take 15 seconds or more to generate a certificate. You may get a warning that the script is taking a long time to complete, do not stop the script, it is doing a very hard math problem and will eventually finish. Once the certificate is generated, you will see an entry pop up in the “Your WebIDs” part of the interface with your name attached to it.

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:

  • Generating a X509 Security Certificate using pure Javascript.
  • Storing the certificate using Flash local storage, so that all of your browsers have access to the certificate.
  • Implementation of a WebID provider using pure Javascript and HTML.
  • Secure retrieval of WebIDs on any website using an iframe.
  • Selecting one or more Certificates from Flash local storage.
  • Initiating a TLS connection to verify your WebID using pure Javascript and Flash.
  • 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.

6 Responses to "WebID – Universal Login for the Web"

  1. Great Work Manu. It’s good to see that one can do this with flash and javascript too. This will certainly grow the number of places WebIDs can be applied, which is certainly a revolutionary technology in its simplicity and power. The list of supported tools is very long as described in detail on http://esw.w3.org/foaf+ssl

    There are a couple of your claims above that I think need a little tuning or explaining in more detail.

    First the claim that WebIDs cannot be created in Internet Explorer is not quite true. IE has an Active X component that comes with the operating system and that is available. Creating a WebID using IE from http://webid.myxwiki.org/ should work, though as I don’t have Windows I don’t test it that much to tell the truth. Bruno Harbulot wrote a piece of javascript to change the DOM to replace the HTML form with calls to that Active X component. The advantage of doing it that way is that it is going to be faster. Of course that requires Javascript to be enabled on IE, but so does your solution :-)
    Now the IE Active X solution may have some usability issues, but I think it needs clearly pointing out what those issues are, so that they can be understood clearly,

    Secondly you say “you get the peace of mind that if you lose one of your WebIDs, you can always just deactivate it via your WebID provider and generate a new WebID”. There is in fact a better way still: you can keep your WebID, and just remove the public key from your public profile. In fact you should be able to have any number of public keys associated with one WebID.

    Now when I log in to digital bazaar it asks me for the WebID I already have (I have a few in fact). My browser — Chromium — asks me for my client certificate, but then you don’t use it! If this system should allow me to use either my flash certificate or my browser certificate this would be great — if I have already submitted my browser certificate then it should use that. So hopefully we can get it to that point. Especially as me and many people have disabled flash – I just reinstalled it for your site.

    What I think you have done is to have tied one more keychain into the WebID system: the flash keychain. Flash is really a browser in a browser. Now it would be even better if flash could use the browser keychain, because then the same keychains could be used for logging in from the browser and flash.

    After this tweaking I think we should have something very useful here that will interoperate nicely with the many other WebID implementations.

  2. Now the IE Active X solution may have some usability issues, but I think it needs clearly pointing out what those issues are, so that they can be understood clearly

    I’ve tried to fix the language in the blog post to state that IE needs an ActiveX component to generate a proper certificate in IE.

    Secondly you say “you get the peace of mind that if you lose one of your WebIDs, you can always just deactivate it via your WebID provider and generate a new WebID”. There is in fact a better way still: you can keep your WebID, and just remove the public key from your public profile. In fact you should be able to have any number of public keys associated with one WebID.

    Hmm, that’s what I meant to convey in the blog post, but failed to do so. I’ve fixed up some of the language to make the point you make above, and the one I was trying to make initially, more clear.

    Now when I log in to digital bazaar it asks me for the WebID I already have (I have a few in fact).

    We think that this is an Apache misconfiguration… we set client-side
    certificate support to optional, so we’ll look into this a bit more early next week.

    My browser — Chromium — asks me for my client certificate, but then you don’t use it! If this system should allow me to use either my flash certificate or my browser certificate this would be great — if I have already submitted my browser certificate then it should use that. So hopefully we can get it to that point. Especially as me and many people have disabled flash – I just reinstalled it for your site.

    Yes, I think that’s quite do-able – shouldn’t be difficult to accomplish. I’ll talk with our engineering team and see what they have to say.

    What I think you have done is to have tied one more keychain into the WebID system: the flash keychain. Flash is really a browser in a browser. Now it would be even better if flash could use the browser keychain, because then the same keychains could be used for logging in from the browser and flash.

    Unfortunately, we don’t currently know of any way of retrieving the browser keychain via Flash or Javascript in any sort of reliable fashion across all browsers.

    Our current thinking is to entirely abandon the native browserclient-side certificate generation and selection mechanism because it is complicated and broken. The browser-based interfaces leave much to be desired when viewed from a regular website usability perspective. Having the mechanism live entirely in HTML+Javascript+Flash allows us to make the usability story better when generating and selecting a WebID certificate.

    Waiting on the browser manufacturers to improve their client-side certificate management UIs will take years. That doesn’t mean that people wouldn’t be able to use the browser-based certificate management mechanism for WebID, just that we think that approach is a dead end.

  3. Great Manu. That solves some of the issues. As this conversation is also going on the foaf-protocols mailing list in this archived thread, I won’t just duplicate the thread here

    http://foaf.markmail.org/thread/zwtjz3bxj57rtbuh

    For those wishing to register, go to
    http://lists.foaf-project.org/mailman/listinfo/foaf-protocols

Trackbacks/Pingbacks