WebID

WebIDs and the WebID Protocol

What is a WebID?

In the simplest technological sense, a WebID is an HTTP URI (that is, a URI using the HTTP scheme) which is used as an Entity Name (rather than its more conventional use as a Resource Address). When an HTTP URI is used to Name an Entity on an HTTP network, that Named Entity may easily be associated with relevant information, such as a structured representation of its description, which representation may use JSON, RDFa, RDF/XML, N3, Turtle, or many other structured data formats.

In other words, WebIDs enable People to obtain Names on HTTP networks that resolve (or de-reference) to structured representations of their electronic descriptions. One common example of an electronic description, generally available in variety of human and machine readable formats, is a structured profile document. Such a profile document conceptually describes entities and relationships, taking its structure from an underlying data model expressed by a schema or vocabulary. FOAF is a one WebID-centered vocabulary used for profiles of agents (people, organizations, or software).

As of November 2010, the term "WebID" is used for a class of solutions, not any one technology. W3C may attempt to standardize one particular identity technology, which may use the term "WebID" more definitively.

Explaining how this is useful in text is difficult. It can be much more easily understood when seen in action. The screen cast Using a FOAF+SSL WebID on the emerging Social Web should help reveal what is being enabled here.

Why should I get a WebID?

People often publish data about themselves on the Web, such as:

• Who they know
• What they are interested in
• Photos they have taken
• Projects they work on
• Their curriculum vitae or employment history
• Their publications

Having a Web ID can allow you to identify yourself when you publish this sort of information online. Because Web IDs are based on the Domain Name System (DNS), they are more distributed by nature than identifiers issued by a central authority and do not require everyone to sign up to a particular service. If you create your own Web ID, you can also control what information is returned when someone looks up that Web ID.

Do I already have a WebID?

If you are already a member of a number of social networking sites, you may already have a WebID which they have given you automatically (but be aware that some sites, e.g., LiveJournal, currently expose FOAF data without creating WebIDs for each user; MyOpera and MyOpenLink are sites which do assign and use URIs for all users).

These sites export (some of) the data which you have put into them. It is normally a subset -- perhaps just the social graph (i.e., who knows whom on the site). This is useful, but it doesn't mean you can use the social networking site to manage all the data you may want in your public profile on the web.

An important question about any site which exports your data is: Does it allow me to make a link to data on another site? If so, your data becomes linked together from site to site, and people and crawlers can find all of it which you choose to expose. If a site does not allow you to link your data in this way, they are effectively confining your data to only being used within their service, which some people find restrictive.

Best Practices for Sites Providing WebIDs for Users

• Allow your users to tell your site their existing Web ID(s). Publish these Web IDs in your data.
  • Use owl:sameAs to associate their existing Web IDs with the Web ID you provide for them; or
  • Use their existing Web ID in your data instead of the Web ID you would normally provide them.
• Be careful to distinguish between your user as a person, and your user's account. In SIOC, these are represented as foaf:Person and sioc:UserAccount respectively. These two classes are disjoint (i.e., an entity can't be both at the same time).

Can I make my own Web ID?

You can use any web server you have authorization to publish your files to.

First you must decide on a stable place to host your profile document. If you have your own domain name, that is perfect as you can change providers without changing your Web ID. If you don't have your own domain, you'll need to pick a provider where you can host a file. The file you make will be named foaf.rdf. (Not all Web IDs will use foaf.rdf, but this is an easy example.)

Your Web ID is made up of the URL of that file on the Web, plus #ABC, where you replace ABC with your initials. (Technically, you can use #me, #this, or any other fragment identifier; initials are currently being recommended.) (<-- recommended by whom? and how to handle suffixes, e.g., Jr., Sr., III, IV?)

So your Web ID looks something like:

http://your.isp.com/whatever/~yourusername/foaf.rdf#ABC

You can consult the Best Practice Recipes for Publishing RDF Vocabularies for some options on how to do this.

There are a number of ways to make a FOAF file.

• Use Tabulator (version supporting this action has not yet been released, as of 2008-11)
• Use a template and edit it for your own use
• FOAF builder, a recent service that allows you to create a FOAF file to place where you want, or to be saved on their servers (which currently requires an OpenID).
• Use FOAF-a-Matic
• Get A URI in 5 Minutes or Less via ODS from OpenLink Software
• Use FOAF-o-Matic, a recent service for creating FOAF profiles in which you may decide to reuse pre-existing URIs for you or your friends, this way improving the integration of the FOAF social network. This service is empowered by the Entity Name System (ENS) which is developed as part of the OKKAM EU-funded project.

It is good to pick a hosting service which allows you to edit the file in place using WebDAV. WebDAV is an extension for HTTP which lets you edit as well as read web pages, without needing to learn how to download and upload files with that host.

See EditingData for details of how to make an editable web site.

How does a WebID compare with my social networking site?

When you get an account on your favorite social networking site, like Facebook, MySpace, LinkedIn and so on, you spend a lot of time telling that site about yourself, who your friends are, what photos include you, and so on. This information is re-used to provide, within that site, services like showing you photos of your friends. The trouble is, each site is a silo. When you want to use info you gave to one site on another, you have to negotiate for each site to access your data on the other.

But this is your data. You can publish it anywhere you can publish web content.

• See also: Steven Pemberton: Why You Should Have a Web Site

That said, these silos are slowly opening; technologies like OpenID, OAuth, OpenSocial, PortableContacts, and so on, are being deployed on many such sites. A Web ID is an identifier that you can use to tie together information exposed by such services, in a portable and future-proof way.

I have a home page, is that a Web ID?

No, your Web Page URL identifies the location of a document that is associated with you, in a sense it is similar to your drivers license or social security card, both of these artifacts identify you indirectly.

In DBMS parlance, an indirect identifier takes the form of a Unique Key, and in Semantic Web parlance indirect identifiers are values associated with Inverse Functional Properties (IFPs).

Since you aren't a Document, a Web Page URL cannot be used to construct an Identifier that uniquely identifies you. It cannot be the Naming mechanism used by other Web users to accurately reference you.

A Web ID looks similar to a home page URL, but it specifically identifies Entity You of Type: Person. Typically, the definition of Type: Person, comes from a vocabulary or ontology or data dictionary. One such vocabulary is FOAF, which is the basis of this effort.

When you get a Web ID, it can be used to accurately reference "You". It is also the conduit to all information associated with "You" which includes things you've created -- Blog Posts, Shared Bookmarks, Music, Photos etc. -- and relationships you have with other people (your social network for example).

Can I use a Web ID for Federated Single Sign-on?

Yes! WebIDs form the basis of the WebID Protocol, an innovative approach to federated single sign-on, which is discussed below.

What is the WebID Protocol?

The WebID Protocol authenticates a digital identity (a WebID) by allowing an Agent (e.g., a Web Browser) to prove possession of or access to a private key, whose corresponding public key is tightly bound to that WebID. The private key is usually associated with a "certificate" on the user's computer, while the public key and WebID are part of that certificate and tightly bound to its subject.  Likewise, the public key and WebID are both tightly bound into the profile-oriented document(s) that describe the identity being authenticated.

This proof is accomplished by adding an invisible look-up step into the standard client-side certificate verification process (that is, the TLS Handshake Protocol) used by the SSL protocol -- which is in use anytime you see an https:// link.  This look-up reveals the user accessing the site (i.e., the owner of the WebID) in the overall Web of Linked Data, against which the server can then query to determine the level of trust that user should be granted. Note: This process works with self-signed certificates, so it does not require the participation of Certificate Authorities to grow.

The WebID Protocol promises to be more fine grained than other Federated Single Sign-on methods. Federation generally implies large entities that work together toward a common goal. The WebID Protocol lets individuals participate at the same level as large entities.

Some Protocol Details

An excerpt from the introduction of the Transport Layer Security (TLS) Protocol specification may help clarify matters somewhat.

  The TLS Record Protocol is used for encapsulation of various higher-
  level protocols.  One such encapsulated protocol, the TLS Handshake
  Protocol, allows the server and client to authenticate each other and
  to negotiate an encryption algorithm and cryptographic keys before
  the application protocol transmits or receives its first byte of
  data.  The TLS Handshake Protocol provides connection security that
  has three basic properties:
  
  -  The peer's identity can be authenticated using asymmetric, or
     public key, cryptography (e.g., RSA [RSA], DSA [DSS], etc.).  This
     authentication can be made optional, but is generally required for
     at least one of the peers.
  
  -  The negotiation of a shared secret is secure: the negotiated
     secret is unavailable to eavesdroppers, and for any authenticated
     connection the secret cannot be obtained, even by an attacker who
     can place himself in the middle of the connection.
  
  -  The negotiation is reliable: no attacker can modify the
     negotiation communication without being detected by the parties to
     the communication.

The WebID Protocol simply adds a check to the existing TLS Handshake, authenticating the identity of the client-side peer. That check is a look up against the WebID for the public key received during a successful handshake.

Why is the WebID Protocol Viable?

The simple answer is that URLs can be used to name anything, including, in particular, people. In the LinkedData pattern one places information about the object at the URL of the object named. This helps in finding the meaning of any URI: you just need to click it, to GET it. The same pattern is applied here. Someone names themselves with a URL, and places a document containing structured data about themselves, typically including links to the people they know, at that URL. Each link they add is a vote of trust in the information at which they are pointing; in this case, trusting that the URL they are using for their friend really is one that reliably and stably refers to and describes their friend — since their friend wants to use that URL to keep track of the information about theirself. This builds a network of trust.

WebID Protocol is just a technology that leverages X.509 Certificates, already in common (and largely invisible) use. By placing that same URL in the certificate that identifies the user, and then placing information at that URL about the public key of the certificate, a web server that receives a user request can verify that the user has write access to that URL. If that can be proven then the server may as well agree that the user is the person in question described by the resource. The value of the trust the server puts into what this person says can then be established by the position of that URL in the network of trust. A more detailed version of this explanation can be found in the article FOAF+SSL: Creating a Web of Trust Without Key Signing Parties.

How does the WebID Protocol compare with OpenID?

OpenID is also a single-sign-on system.

However, while it does give you an identity for sign on, it does not give you an identity for all the types of networks mentioned above, such as Friend Of A Friend (FOAF), Description Of A Project (DOAP), and so on.

OpenIDs serve as fine indirect identifiers. Much as you can talk about "the Person who has the blog at example.org" or "the Company whose homepage is at example.com", you can use an OpenID page identifier as an indirect identifier for the person who controls that OpenID page. In fact, this in a way OpenID works — by demonstrating OpenID control over some identifying page, you can assure other sites of your real-world identity. OpenID is decentralized in that it allows you to arrange for any page (e.g., your longstanding homepage or blog) to serve as an indirect person-identifying page.

Additionally, because OpenID allows you to demonstrate control of your page to other sites, it can also be used to help those sites know what the preferred Web ID is for any OpenID user whose pages link to a FOAF description. In other words, once you have the combination of OpenID/FOAF set up, you can log in elsewhere using your OpenID and it will also make clear what your preferred Web ID is.

It is possible to connect your Web ID to your OpenID in both directions.

For a detailed protocol-level discussion, see A comparison of FOAF+SSL and OpenID.

Related (seeAlso)

• Personal URIs & Data Spaces from Kingsley Idehen's blog
• Social Networks Workshop (Barcelona 2009)
• How FOAF+SSL works
• Give yourself a URI - on Tim Berners-Lee's blog

Screencasts

• Using a WebID on the emerging Social Web, from Henry Story
• several more, from Kingsley Idehen