WebID

From W3C Wiki

WebIDs and the WebID Protocol

The W3C is still exploring better ways to do authentication, for example in the 2014 workshop on authentication. The WebID is a Community Group, and anyone can start a Community Group. A Community Group does not necessarily reflect the endorsement of the W3C, but we encourage grassroots communities to experiment with technology that may become a future standard.

What is a WebID?

A WebID is a way to uniquely identify a person, company, organisation, or other agent using a URI. The term "WebID" was coined by Dan Brickley and Tim Berners-Lee in 2000. (Citation needed)


The WebID Protocol for authentication is being worked on in the WebID Community Group at the W3C. Implementers and other are welcome to join and contribute feedback in a non patent encumbered way. The group is developing the following specs, which should be consulted for the latest on the subject:

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 and link to each of those resources.

Most importantly of all, having a Web ID allows people to reference you and declare social relations on the web (such as that you are their friend, colleague, parent, etc.) even when their profile is hosted on a different web server than yours. This is key to enabling the Social Web, i.e., social networks between individuals, citizens, companies, universities, governments, while allowing each player to remain in control of their data they publish.

To deal with privacy issues, a Profile Server should reveal more or less depending on the identity (WebID) of the viewer, as shown in the WebID spec.

PublicKey WebID

A Public Key WebID (spec) is a URI that refers to a person (Agents or Robots are ok too) that uniquely identifying the user by his relation to a public key.

The Public Key WebID here is http://bblfish.net/#hjs . As stated by the URI specification

The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource

In this case the primary resource is the profile document https://bblfish.net/ and the secondary one is the WebID . This is usually thought of as the profile document.

FOAF is one fairly-commonly used WebID-centered vocabulary, used for profiles of agents (people, organizations, or software). Any GRDDLable format - i.e., pretty much any consistent format (including JSON due to jsonGRDDL) - should work as well.

The value of having a URI as an identifier are:

  • that it can be linked to by other profiles, to create a linked web of trust
  • that it can be tied to information enabling a method of authentication ( such as OpenID or even more directly with WebID Authentication ). The short video WebID and Browsers demonstrates what is being enabled here.

HOWTO

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.

(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 as much as 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.

Adding a certificate

To make your WebId usable as a log in, you need to cross-link it to a certificate. If your Webid does not have one, you can add a certificate:

  • Make the certificate using for example https://my-profile.eu/
  • Use the browser preferences to look inside the certificate to get its private key
  • Put the public key (modulus and exponent) in your FOAF file like below (shown in turtle). You put your own modules hex string in from the public key. The exponent will likely be the same, but check.


@prefix cert:  <http://www.w3.org/ns/auth/cert#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .


<myfoaf#me> cert:key [ 
    cert:exponent 65537;
    cert:modulus "cb24ed85d64d794b69c701c186acc059501e856000f661c93204d8380e07191c5c8b368d2ac32a428acb970398664368dc2a867320220f755e99ca2eecdae62e8d15fb58e1b76ae59cb7ace8838394d59e7250b449176e51a494951a1c366c6217d8768d682dde78dd4d55e613f8839cf275d4c8403743e7862601f3c49a6366e12bb8f498262c3c77de19bce40b32f89ae62c3780f5b6275be337e2b3153ae2ba72a9975ae71ab724649497066b660fcf774b7543d980952d2e8586200eda4158b014e75465d91ecf93efc7ac170c11fc7246fc6ded79c37780000ac4e079f671fd4f207ad770809e0e2d7b0ef5493befe73544d8e1be3dddb52455c61391a1"^^xsd:hexBinary;
          ] .
  • Republish your new FOAF file with the security data in it, and you will be able to log in with the new certificate.

When you have made a certificate in one browser, if you like you can export it (save it with a password on it) as a .p12 file, and import it into other borders, and other devices. See for example this article on getting a certificate onto an iPhone.

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.

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.

What is the WebID Authentication Protocol?

The Authentication 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 could formerly be found in the article which is now on archive.org 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.

Official Specifications

There are no official specifications yet. The following links are editor's drafts, i.e. work in progress.

See also an unofficial index of specs being worked on

Implementations

Related (seeAlso)

Screencasts

Retrieved from "https://www.w3.org/wiki/index.php?title=WebID&oldid=116843"