Social networking, identity and privacy have been at the center of how we interact with the Web in the last decade. The explosion of social networking sites has brought the world closer together as well as created new points of pain regarding ease of use and the Web. Remembering login details, passwords, and sharing private information across the many websites and social groups that we are a part of has become more difficult and complicated than necessary. The Social Web is designed to ensure that control of identity and privacy settings is always simple and under one's control. WebID is a key enabler of the Social Web. This specification outlines a simple universal identification mechanism that is distributed, openly extensible, improves privacy, security and control over how one can identify themselves and control access to their information on the Web.

How to Read this Document

There are a number of concepts that are covered in this document that the reader may want to be aware of before continuing. General knowledge of public key cryptography and RDF [[!RDF-PRIMER]] and RDFa [[!RDFA-CORE]] is necessary to understand how to implement this specification. WebID uses a number of specific technologies like HTTP over TLS [[!HTTP-TLS]], X.509 certificates [[!X509V3]], RDF/XML [[!RDF-SYNTAX-GRAMMAR]] and XHTML+RDFa [[!XHTML-RDFA]].

A general Introduction is provided for all that would like to understand why this specification is necessary to simplify usage of the Web.

The terms used throughout this specification are listed in the section titled Terminology.

Developers that are interested in implementing this specification will be most interested in the sections titled Authentication Sequence and Authentication Sequence Details.

The source code for this document is available via Github at the following URI:


The WebID specification is designed to help alleviate the difficultly that remembering different logins, passwords and settings for websites has created. It is also designed to provide a universal and extensible mechanism to express public and private information about yourself. This section outlines the motivation behind the specification and the relationship to other similar specifications that are in active use today.



Relation to OpenID

This section needs to be re-written. The flow and grammar leaves much to be desired. -- manu

WebID is compatible with OpenID. Both protocols use a URI that dereferences to a Personal Profile Document. This Personal Profile Document is where further information about an identity can be discovered. This mechanism is compatible with both WebID and OpenID. Therefore, WebID does not intend to replace OpenID, but can work beside OpenID by sharing the content in the Personal Profile Document.

That said, there are a number of benefits that WebID achieves over OpenID:

WebID gives people and other agents a WebID URI for identification. OpenID also provides a URI to a Personal Profile Document. However, in the case of WebID, one does not need to remember the URI since the User Agent remembers the URI on behalf of the person browsing. To log in on a WebID web site there is no need to enter any identifier like one has to do for OpenID. Just one click tells the browser to send the WebID URI. The person that is browsing does not need to remember either their WebID URI or the website password, and because no password or other secret credential is exchanged with the website, WebID is immune from phishing attacks.

While WebID works well in a browser environment, it is also very useful outside of the browser environment. WebID can also operate without requiring the use of any passwords. This is useful to developers that may want to use WebID to perform server-to-server or peer-to-peer verification of identity. WebID works for automated agents such as Search Agents, API Agents, and other automated mechanisms that are often found outside of the browser environment.

The WebID protocol requires just one direct network connection to establish identity via the client. The server requires one connection to the client and one connection to retrieve the WebID Profile if it does not have the credential information cached. Compare this to the much more complex OpenID sequence, which requires six connections by the client to establish a login. In a world of distributed data where each site can point to data on any other site, multiple connections become costly to manage.

WebID builds on a number of well established Internet and Web standards; REST, RDF [[RDF-PRIMER]], RDFa [[!RDFA-CORE]], RDF/XML [[!RDF-SYNTAX-GRAMMAR]], TLS [[!HTTP-TLS]], and X.509 [[!X509V3]]. By building on proven technologies which have been integrated into Web browsers for many years, it makes both explaining and implementing WebID easier on developers. As a matter of fact, there were already three interoperable implementations of WebID before this specification was written.

Since WebID is RESTful, you can perform basic HTTP operations to GET your WebID, and if you needed update it, you can use HTTP PUT semantics. You can also create a WebID via POST. This is improved from the OpenID specification, which requires a new set of operations described in the OpenID Attribute Exchange specification.

WebID is built on RDF and thus enables all of the advanced semantic web concepts that RDF enables. For example, a developer may perform machine reasoning with a WebID. One can construct machine-executable statements like "If this WebID claims to be a friend of one of our partner WebIDs that is trusted and the relationship is bi-directional, trust the WebID." While OpenID attempts to support this use case by mapping OpenID to RDF, it's far easier to do with WebID because WebID is natively built on RDF. This also allows to include WebID profiles into HTML documents with RDFa.

It is easy to extend a WebID with new attributes via RDF. The power of RDF allows developers to add extensions to WebID by defining new vocabularies that they publish. There is no authorization process necessary and thus WebID allows for distributed innovation. Every WebID property is a URI, which when clicked, can give you yet more information about what the property means. A developer can create new usage classes by extending their vocabulary at will. A developer can add relationships to a WebID by simply adding more HTML to the developer's page. OpenID does not provide any type of distributed innovation akin to RDF.

WebID is truly decentralized - with WebID you get a web of trust. OpenID only supports the Web of Trust model if you indirectly trust the OpenID provider. In other words - OpenID is not truly decentralized. In OpenID you must trust OpenID providers. With WebID you only have to trust the people and the organizations with which you are communicating. In other words, you don't have to ask anyone whether or not you can trust your friends. You can query people that you trust directly to see if someone is trustworthy or not. There is no need for a central WebID authority.

WebID is fully distributed. Anyone can setup a WebID by placing a single file on a web server of their choosing, for example on their own domain name. There is no need for a special OpenID-like provider service. You can also use a WebID hosting provider, but it's not necessary for WebID to work. While it is possible to run an OpenID server, other OpenID applications may not trust you and thus you won't be able to fully utilize your private OpenID credentials. The reason that there are a few large OpenID providers and very few small OpenID providers is because of this trust design issue related to OpenID.

WebID does not require HTTP redirects. Redirects are problematic on many cell phones because telecommunication companies rely heavily on proxy servers which may selectively block redirects.

A WebID provider is 100% compatible with an OpenID provider and thus can inter-operate with OpenID-powered networks.

This last claim needs to be backed up by some bug reports or documentation on the actual problems.

Relation to OAuth

OAuth and WebID are mutually beneficial when used together. WebID can be used to provide RSA parameters to the RSA-SHA1 signature method required by OAuth 1.0. WebID can also be used to establish the consumer_key and HTTPS connection that will be used to transmit OAuth Tokens in OAuth 2.0.

Change History

2010-07-31 Initial version split from the core WebID specification.


The following people have been instrumental in providing thoughts, feedback, reviews, criticism and input in the creation of this specification: