A global distributed Social Web requires that each person be able to control their identity, that this identity be linkable across sites - placing each person in a Web of relationships - and that it be possible to authenticate globally with such identities.

This specification outlines a simple universal identification mechanism that is distributed, openly extensible, improves privacy, security and control over how each person can identify themselves in order to allow fine grained access control to their information on the Web. It does this by applying the best practices of Web Architecture whilst building on well established widely deployed protocols and standards including HTML, URIs, HTTP, and RDF Semantics.

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 RDF [[!RDF-PRIMER]] is necessary to understand how to implement this specification. WebID uses a number of specific technologies like Turtle [[!TURTLE-TR]] and RDFa [[!RDFA-CORE]].

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.

Introduction

A WebID is an HTTP URI containing a URI fragment identifier (i.e. a # symbol) and which uniquely denotes an Agent (Person, Organization, Group, Device, etc.). The URI without the fragment identifier denotes the WebID Profile Page document.

A WebID Profile is a Web resource that MUST be available as Turtle [[!TURTLE-TR]], but MAY be available in other RDF serialization formats (e.g. [[!RDFA-CORE]]) if requested through content negotiation.

WebIDs can be used to build a Web of trust using vocabularies such as FOAF [[!FOAF]] by allowing people to link together their profiles in a public or protected manner. Such a web of trust can then be used by a Service to make authorization decisions, by allowing access to resource depending on the properties of an agent, such that he/she is known by some relevant people, works at a given company, is a family member, is part of some group, etc..

Outline

This specification is divided in the following sections.

This section gives a high level overview of WebID, and presents the organization of the specification and the conventions used throughout the document.

Section 2 provides a short description for the most commonly used terms in this document.

Section 3 describes what a WebID URI is.

Section 4 presents an overview of WebID.

Section 5 deals with the publishing of a WebID Profile.

Section 6 describes how a request for a WebID Profile should be handled.

Terminology

Requesting Agent: The Requesting Agent initiates a request to a Service listening on a specific port using a given protocol on a given Server.
Server: A Server is a machine contactable at a domain name or IP address that hosts a number of globally accessible Services.
Service: A Service is a an agent listening for requests at a given IP address on a given Server.
WebID: A WebID is a URI with an HTTP or HTTPS scheme which uniquely denotes an Agent (Person, Organization, Group, Device, etc.). This URI SHOULD include a fragment identifier. For WebIDs with fragment identifiers the URI without the fragment denotes the Profile Document. For WebIDs without fragment identifiers an HTTP request on the WebID MUST return a 303 with a Location header URI denoting the Profile Document.
WebID Profile or Profile Page: A WebID Profile is an RDF document that is found by dereferencing the WebID HTTP URI. This document MUST be available as Turtle [[!TURTLE-TR]]. This document MAY be available in other RDF serialization formats, such as RDFa [[!RDFA-CORE]], RDF/XML [[!RDF-PRIMER]], or N3 [[!N3]] if so requested through content negotiation. Any other serializations that intend to be used by WebID MUST be transformable automatically and in a standard manner to an RDF Graph, using technologies such as GRDDL [[!GRDDL-PRIMER]].

Namespaces

Examples assume the following namespace prefix bindings unless otherwise stated:

Prefix	IRI
`foaf`	http://xmlns.com/foaf/0.1/

The HTTP URI

This URI must be one that dereferences to a document the user controls.

For example, if a user Bob controls https://bob.example/profile, then his WebID can be https://bob.example/profile#me.

Implementers are highly encouraged to use hash URIs for the WebID HTTP URI. Even though 303 redirects can be used instead, experience has shown that they can be difficult to deploy and can have an impact on performance. However WebID Verifiers MUST NOT fail when dereferencing hashless URIs, though they MAY flag them as potentially impacting on performance.

Publishing the WebID Profile Document

WebID requires that servers MUST at least be able to provide Turtle representation of profile documents, but other serialization formats of the graph are allowed, provided that agents are able to parse that serialization and obtain the graph automatically. Technologies such as GRDDL [[!GRDDL-PRIMER]] for example permit any XML format to be transformed automatically to a graph of relations. HTTP Content Negotiation can be employed to aid in publication and discovery of multiple distinct serializations of the same graph at the same URL, as explained by the working group note Best Practice Recipes for Publishing RDF Vocabularies [[!SWBP-VOCAB-PUB]]

HTTP 303 redirects should be avoided (needs further discussion). Since WebIDs contain a URI fragment identifier, it is not nessary to use HTTP 303 redirects in order to make the difference between the identifier and the document it points to; the relationship becomes obvious.

It is particularly useful to have one of the representations be in HTML even if it is not marked up in RDFa as this allows people using a web browser to understand what the information at that URI represents.

WebID Profile Vocabulary

WebID RDF graphs are built using vocabularies identified by URIs, that can be placed in subject, predicate or object position of the relations constituting the graph. The definition of each URI should be found at the namespace of the URI, by dereferencing it.

Personal Information

Personal details are the most common requirement when registering an account with a website. Some of these pieces of information include an e-mail address, a name and perhaps an avatar image. This section includes properties that SHOULD be used when conveying key pieces of personal information but are NOT REQUIRED to be present in a WebID Profile:

foaf:name: The name of the individual or agent.
foaf:knows: The WebID URI of a known person.
foaf:weblog: The person or agent's blog URI

Publishing a WebID Profile using Turtle

A widely used format for writing RDF graphs by hand is the Turtle [[!TURTLE-TR]] notation. It is easy to learn, and very handy for communicating over e-mail and on mailing lists. The syntax is very similar to the SPARQL query language. Turtle profile documents should be served with the text/turtle content type.

Take for example the WebID https://bob.example/profile#me, for which the WebID Profile document contains the following Turtle representation:

 @prefix foaf: <http://xmlns.com/foaf/0.1/> .

 <#me> a foaf:Person;
   foaf:name "Bob";
   foaf:knows <https://example.edu/p/Alice#MSc>;
   foaf:weblog <http://bob.example/blog>.

Publishing a WebID Profile using the RDFa HTML notation

RDFa in HTML [[!RDFA-CORE]] is a way to markup HTML with relations that have a well defined semantics and mapping to an RDF graph. There are many ways of writing out the above graph using RDFa in HTML. Here is just one example of what a WebID profile could look like.

<div vocab="http://xmlns.com/foaf/0.1/" about="#me" typeof="foaf:Person">
  <p>My name is <span property="name">Bob</span> and I like to <a property="weblog" href="http://bob.example/blog">blog fun stuff</a>
  </p>
  <h2>My Good Friends</h2>
  <ul>
    <li property="knows" href="https://example.edu/p/Alice#MSc">Alice</li>
  </ul>
</div>

If a WebID provider would rather prefer not to mark up his data in RDFa, but just provide a human readable format for users and have the RDF graph appear in a machine readable format such as RDF/XML then a link from the HTML to a machine readable format MAY be published as follows:

<html>
<head>
<link rel="alternate" type="application/rdf+xml" href="profile.rdf"/>
</head>
<body> ... </body>
</html>

Privacy

A WebID Profile document does not need to contain only public resources. A possible way of protecting its contents can be achieved by separating parts of the profile information into separate documents, each protected by access control policies. In the following example, Bob is limiting access to his list of friends, by placing all foaf:knows relations into a separate document.

 @prefix foaf: <http://xmlns.com/foaf/0.1/> .
 @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
 
 <#me> a foaf:Person;
   foaf:name "Bob";
   rdfs:seeAlso <https://bob.example/friends>;
   foaf:weblog <http://bob.example/blog>.

Where https://bob.example/friends is a reference to an ACL protected document containing:

 @prefix foaf: <http://xmlns.com/foaf/0.1/> .
 
 <https://bob.example/profile#me> a foaf:Person;
   foaf:knows <https://example.edu/p/Alice#MSc>;
   foaf:knows <https://example.com/people/Mary/card#me>.

Having the following corresponding ACL rule, expressed using the WebAccessControl ontology:

 @prefix acl: <http://www.w3.org/ns/auth/acl#> .
 
 <#FriendsOnly>
    <acl:accessTo> <https://bob.example/friends>;
    <acl:agent> <http://example.edu/p/Alice#Msc>, <http://example.com/people/Mary/card#me>;
    <acl:mode> <acl:Read>.

Processing the WebID Profile

The Requesting Agent needs to fetch the document, if it does not have a valid one in cache. The Agent requesting the WebID document MUST be able to parse documents in Turtle [[!TURTLE-TR]], but MAY also be able to parse documents in RDF/XML [[!RDF-SYNTAX-GRAMMAR]] and RDFa [[!RDFA-CORE]]. The result of this processing should be a graph of RDF relations that is queryable, as explained in the next section.

It is important that the Requesting Agent should set the Accept-Header to request text/turtle with a higher priority than application/xhtml+xml(RDFa) and application/rdf+xml (RDF/XML). The reason is that it is quite likely that many sites will produce non marked up HTML and leave the graph in pure RDF formats.

If the Requesting Agent wishes to have the most up-to-date Profile document for an HTTPS URL, it can use the HTTP cache control headers to get the latest versions.