Chapter 1 - Profiles

Profiles

Identity management as well as unique identifiers are the core of any social system. Solid uses WebID, an HTTP(S) URI, to uniquely refer to users (people or agents). The advantage of WebID is that the URI can be dereferenced to a WebID profile document, in order to reveal useful information about the user. Also, since WebID profiles can be hosted anywhere (including your basement server), users are no longer trapped inside Identity Provider Silos (e.g. Twitter, Facebook, Google+, etc.).

The WebID profile document should be the first resource created by the server after receiving a request for a new account. The reason is that other resources such as the preferencesFile document will be linked to from the profile document as soon as they are created.

The profile document follows the structure and schema described by the WebID specification document. A bare profile document only needs to contain a minimum number of relations, such as the one pointing to the preferencesFile and to the inbox (notifications) container. During account creation, the user may provide a full name or a profile picture, but those profile elements are not mandatory, and can be added in a future request (i.e. through a PATCH).

A typical (bare) profile document (i.e. https://alice.example.org/profile/card) will look as follows:

<>
    a <http://xmlns.com/foaf/0.1/PersonalProfileDocument> ;
    <http://xmlns.com/foaf/0.1/maker> <#me> ;
    <http://xmlns.com/foaf/0.1/primaryTopic> <#me> .

<#me>
    a <http://xmlns.com/foaf/0.1/Person> ;
    <http://www.w3.org/ns/pim/space#preferencesFile> <../Preferences/prefs.ttl> ;
    <http://www.w3.org/ns/pim/space#storage> <../> ;
    <http://www.w3.org/ns/solid/terms#inbox> <../Inbox/> .

Linking the account URI to the user's WebID

An optional, but recommended step in the account creation workflow is to link the account (i.e. https://alice.example.org/) to the account owner's WebID.

To do that, the server may add a triple to the root container's meta file (i.e. /.meta), in which it adds the following triple:

<profile/card#me>
    <http://xmlns.com/foaf/0.1/account> <> .

Personal data workspaces

Upon account creation, a series of dedicated workspaces (i.e. LDP containers) are created in the user's data space, together with their corresponding ACL resources. At the moment, the list contains the following workspaces:

  • Applications
  • Inbox
  • Preferences
  • Private
  • profile
  • Public
  • Shared
  • Work

Please note that these workspace names are just placeholders and they do not reflect the ACL policies that come with them -- i.e. Public does not necesarily imply a read-all or write-all ACL policy. Time and effort should be dedicated to making sure that multiple languages (i18n) are supported.

Workspaces are considered to be basic containers, which store application-specific data. For example, one of the reasons we decided to use this concept of workspaces is that complicated ACL logic can be set per workspace, and then all data inside the workspace will inherit the same policies.

Preferences document

The preferences document is a protected resource that extends the WebID profile and it is used to describe useful information about the user and the data server, which can later on be used by applications. This resource currently lists basic information such as the workspaces that were just created. In the future it may contain user preferences such as a preferred language, date format, etc.

By default, the preferences resource is created in the Preferences workspaces -- i.e. https://user.example.org/Preferences/prefs -- and a relation of type http://www.w3.org/ns/pim/space#preferencesFile is added to the WebID profile, which points to the preferences resource.

In the WebID profile:

<https://user.example.org/profile/card#me>
    <http://www.w3.org/ns/pim/space#preferencesFile> <https://user.example.org/profile/prefs> .

To discover the user's workspaces, an app will follow its nose starting with the WebID profile document, to find all relations of type http://www.w3.org/ns/pim/space#workspace having the user's WebID as the subject. Of course, this means following the http://www.w3.org/ns/pim/space#preferencesFile relation to get to the preferences resource.

Here is an example of a preferences file:

<>
    a <http://www.w3.org/ns/pim/space#ConfigurationFile> ;
    <http://purl.org/dc/terms/title> "Preferences file" .

<../Applications/>
    <http://purl.org/dc/terms/title> "Applications workspace" ;
    a <http://www.w3.org/ns/pim/space#PreferencesWorkspace>, <http://www.w3.org/ns/pim/space#Workspace> .

<../Inbox/>
    <http://purl.org/dc/terms/title> "Inbox" ;
    a <http://www.w3.org/ns/pim/space#Workspace> .

<.>
    <http://purl.org/dc/terms/title> "Preferences workspace" ;
    a <http://www.w3.org/ns/pim/space#Workspace> .

<../Private/>
    <http://purl.org/dc/terms/title> "Private workspace" ;
    a <http://www.w3.org/ns/pim/space#PrivateWorkspace>, <http://www.w3.org/ns/pim/space#Workspace> .

<../Public/>
    <http://purl.org/dc/terms/title> "Public workspace" ;
    a <http://www.w3.org/ns/pim/space#PublicWorkspace>, <http://www.w3.org/ns/pim/space#Workspace> .

<../Shared/>
    <http://purl.org/dc/terms/title> "Shared workspace" ;
    a <http://www.w3.org/ns/pim/space#SharedWorkspace>, <http://www.w3.org/ns/pim/space#Workspace> .

<../Work/>
    <http://purl.org/dc/terms/title> "Work workspace" ;
    a <http://www.w3.org/ns/pim/space#Workspace> .

<../profile/card#me>
    a <http://xmlns.com/foaf/0.1/Person> ;
    <http://www.w3.org/ns/pim/space#preferencesFile> <> ;
    <http://www.w3.org/ns/pim/space#workspace> <../Applications/>, <../Inbox/>, <.>, <../Private/>, <../Public/>, <../Shared/>, <../Work/> .

Creating new accounts

Before creating new accounts, client applications must be able to check whether or not an account exists. To do that, clients only need to send a HEAD request to the account root URI. For example, let's assume the user Alice wants to create an account on example.org, using the username alice. The client will perform a HEAD request to the alice.example.org subdomain.

REQUEST:

HEAD / HTTP/1.1
Host: alice.example.org

RESPONSE:

HTTP/1.1 200 OK

If the HTTP status code returned is 200, then it means an account with that name exists already.

If the status code returned is 404, it means that the account is available.

Once the client application has verified that the account is available, it can now proceed to create it. To do so, it must submit a form (or emulate it) to the account URI it previously checked (e.g. alice.example.org), containing at least the following form parameter names:

  • username (required) - the account name that will be used as the subdomain -- i.e. alice
  • email (optional) - the email of the user, which may be used for account recovery and/or account validation

IMPORTANT At this point, the server should also automatically consider the user to be authenticated, and issue a cookie. This will allow the user to properly manage the following steps that may require authentication.

Once submitted, the server will take charge of creating the necessary workspaces, setting the access control policies and creating the user's WebID profile document.

Issuing the client certificate

Attention! Because creating client certificates requires the <KEYGEN> HTML element, which does not work with AJAX requests, the client must submit a form to the account host URI -- i.e. https://user.example.org/. This restriction means that a predefined set of form element names must be respected on the server. Here is minumum list of form element names (case sensitive!) that MUST be sent by signup applications, in order to achieve interoperability:

  • spkac - contains the certificate signing request (CSR) generated by the KEYGEN element
  • webid - the WebID of the user
  • name - the name (CN) that will be used in the certificate

The server will update the user's profile by adding a representation of the public key (as modulus and exponent) it obtained from the certificate, according to the WebID-TLS specification.

IMPORTANT Servers should only return the certificate in the response, while also setting the Content-Type header to the proper mime type value (as seen below), otherwise the certificate will fail to install in the browser.

Content-Type: application/x-x509-user-cert

Unfortunately, there is currently no browser API to discover whether or not a certificate was properly installed in the browser.

Finding out the identity currently used

Regardless of the authentication mechanism that was used during an HTTP request, the server must always return a User header, which contains a URI representing the user's identity. For example, the User header may contain either an HTTP URI (i.e. the WebID of the user that was just authenticated), or a different URI (e.g. mailto:, dns:, tel:, etc.).

The User header can also be used to verify that a user has successfully authenticated (if an HTTP URI what dereferences to a WebID profile is present), as well as to bootstrap the way apps personalize the user experience, since apps have an easy way of discovering the user's identity.

Here is an example:

REQUEST:

GET /data/ HTTP/1.1
Host: example.org

RESPONSE:

HTTP/1.1 200 OK
...
User: https://alice.example.org/card#me