The WebID Protocol & Browsers

Position Paper for W3C Workshop on Identity in the Browser 24/25th May 2011, Mountain View (USA)

Presented by members of the W3C WebID Incubator Group

Authors: Jeff Sayre & Henry Story, WebID Incubator Chair

Reviewers: Peter Williams, Rappatoni; Martin Gaedke, Chemnitz University of Technology; David Chadwick, University of Kent

Andrei Sambra, Stéphane Corlosoquet, Dominik Tomaszuk

1. Position Statement

The browser is the interface to the web and should also serve as the interface to a user’s identity. Identity selection and deselection should be a one-click gesture to cryptographically secure authentication across any site on the  web. It should put the user in control of the information he shares with each site. And it should be available now.

The WebID protocol achieves all of the above. It works in all browsers that correctly implement HTTPS and client-side certificates -- but with a twist: it ties those certificates into the web in a RESTful manner allowing identities to be linked together in a secure social web of trust, that does not require central authorities.  The user can create and control his own identity, self sign his certificates and control how he describes himself.

After explaining how the WebID protocol works, and listing its advantages, we will suggest a roadmap for future improvements in the browser that can take advantage of it.

2. WebID Overview

The WebID protocol is very simple and efficient. It requires only one more connection than the original resource requested, and the results of this connection can be cached.

  1. Bob requests Alice’s protected HTTPS resource
  2. Alice’s web server requests the client certificate on  the TLS connection started above        
  3. Bob’s browser presents him with a selection of identities to choose from  

                  Having selected one, the corresponding X509 certificate is sent to Alice’s server

Public Key Info:

           Public Key Algorithm: rsaEncryption

               Public-Key: (1024 bit)


                  00:e8:f9:   [snip]     :c6:af:2e

               Exponent: 65537 (0x10001)

    X509v3 extensions:  
 X509v3 Subject Alternative Name:

It contains the user’s WebID, shown in bold red above.

  1. Alice’s server
  1. checks that Bob’s browser is in possession of the private key corresponding to the public key sent in the certificate, as specified by TLS
  2. extracts the URI from the Subject Alternative Name field of the certificate, which is known as Bob’s WebID: a global identifier that refers to Bob via a document that describes him

  1. Alice's server fetches Bob’s WebID Profile at in the example if an up to date version is not in the cache
  2. Alice’s server checks that the profile relates Bob’s WebID to the public key found in the certificate. If they match then she knows that she is in communication with the agent referred to by
  3. Bob's identity is then checked as to its position in a graph of relations in order to determine trust according to some criteria decided by Alice.

This is outside the core of WebID, but it is important to understand how it can work. Alice might decide for example that only a group of friends who have given her a WebID personally may have access. Or she may be more lenient, and allow any of the friends of those friends to also access that resource, as specified by them in their profile located on their servers. Or she may only trust employees of her company, or of her deparment, to view that resource. Alice’s server can do a lookup in a local file, crawl the web at intervals, or user web services to gather the data to help make that decision.

  1. Access is granted fully, partially or denied and a representation is returned. Assuming the resource requested is a friend graph, a full representation could be returned to a friend, and a very limited one to an anonymous user.

The WebID placed in the Certificate can be an https URL as shown above, but it could also be any dereferenceable schema such as ftps://, ldaps://, xris://, accnt: (used by webfinger ), and yet to developed ones such as perhaps a future httpk schema that would give up human readable URIs in order to avoid centralisation problems of DNS. Currently HTTPS is the most widely implemented.

3. Advantages of WebID

Issues of identity and privacy have been growing increasingly serious as the web has become social over the last decade. Remembering login details has grown into a serious security issue as more sites asked for them than people had the ability to remember. And the inability to easily share restricted information across websites has become a visible problem to 100s of millions of people as they started finding themselves and those they wished to communicate with split across siloed services.

Specifically, WebID offers the following advantages.

3.1 Overcoming Password Fatigue

Passwords are difficult to remember or they are easy to crack. As a result people tend to re-use them, making  phishing attacks the biggest threat on the web, leading to a mistrust of new services. WebID uses TLS client certificates and public key cryptography as shipped in current browsers in a way that enables the same certificate to be used across sites securely.

3.2 Comparison to OpenID

OpenID reduces the account multiplication issue by allowing users to login to every site using the same global indentifier. WebID was inspired by OpenID but improves it in a  number of meaningful ways:

  1. Protocol simplicity: the WebID protocol is a lot simpler, requiring only one more connection over and above the connection to the requested resource, where the result is cacheable. OpenID requires seven TLS connections, significantly more than WebID. These additional steps create opportunities for denial of service attacks, making it more difficult to secure and to debug.
  2. User-interaction simplicity: OpenID requires the user to remember and type an OpenID URL. WebID hides this in the X509 certificate allowing the browser to offer select-and-click interaction. This is very helpful anywhere, but especially on cell phones and small devices.

These protocol simplifications create a cascade of additional benefits. The most interesting is that by being completely compliant with Web Architecture the trust can be moved from the Identity Provider to the Web of relations, solving the trust problem - the biggest issue of WebID - by decentralising it.

Nevertheless OpenID and WebID can work well together. OpenID is especially important for a number of devices (cell phones often) that have not implemented client side certificates properly yet.

3.3 Transport Layer Security

TLS-client certificates have been available in the browser since 1996, but their usage has been limited to a small number of sites. The organisation which generates the certificate is usually the same as the one that consumes it, giving the user little advantage over username/passwords layered on server-side https. Outside of very large and well funded Defence related organisations, client side certificates have thus had very poor adoption.

The missing link is the global naming system that OpenID takes advantage of with URIs, and that allows one to potentially authenticate to all sites. What failed TLS was that X500 names were not Universal Identifiers, were not designed to form an interlinked web, and hence were not useable to authenticate to sites without those first having a federated agreement. By webifying TLS we enable global authentication and authorization through the creation of a distributed linked web of trust, at a much finer granularity level than has been worked with before.

4. Browser Support & Benefits

All current browser-based authentication methods fail to give full control over identity to the user. We declare that browsers MUST give the user full visible control of their identity. With TLS, as with cookies, one should be able to see clearly which identity one is logged in under and be able to easily become anonymous again, as far as that is possible of course. The Firefox Weave team have shown what this could look like,  making use of the URL bar’s existing role as guarantor of server identity and extending it to client identity.

Here the user can see  what persona he presents to the site or if  he is anonymous. It also permits the user to change identity or  to log out. The browser could then make use of the information found in the WebID profile, linked to from the X509 certificate, such as finding a link to a picture which could then be displayed, or linking to the account management page as shown above.

This WebID anchor can then be used by browsers to improve the user experience

  1. by using bookmarking service linked to from the profile
  2. by using the linked social graph to provide real time changes to address books, social web spam protection, ...
  3. building micropayments by using the TLS cryptography layer

WebID’s protocols is very similar to IETF Dane. Where WebID improves client side security and useability, DANE improves server certs. Dane will enable widespread server side TLS deployment by making self signed server certs meaningfully. By lowering the entry barrier to using cryptography, both will help bring about  an increasingly secure Web.

5. Interest to Web Services

WebID allows users to authenticate cheaply and securely to any website in the world, without needing to fill out any new forms, whilst giving that site conditional access to their social graph ( see Sketch of a RESTful photo Printing service ). This will allow innumerable applications to be built that improve relations between individuals and their friends, co-workers, employers, and vendors across domain and organizational boundaries.

Best of all WebID uses only open and well established standards. With a little extra effort on the User Interface, browser vendors could help speed the web’s transformation into a fully global distributed and secure Social Web.

6. Information Assurance

WebID assumes that the market requirements for Information Assurance will evolve. The initiative enables the deploying community to use the web as it exists today accepting that there are vulnerabilities in DNS, in consumer grade operating systems and hardware. With the rollout of critical infrastructure element such as DNSsec and IPV6, WebID should rise to meet changing social expectations that encompass everything from fictitious IDs, personally controlled identities (FreedomBox), employee identities all the way to National ID cards. WebID’s enable all of these to function in an International context creating a global borderless flexible secure and user controlled identity space, where server owners can decide what trust logic they wish to apply to protect their resources.

6. Additional Resources

  1. WebID Draft Spec
  2. WebID Frequently Asked Questions
  3. WebID Wiki