Disclaimer: this is a living spec. Expect it to change often!
Current Spec version: v.0.7.0 (see CHANGELOG.md)
- Overview
- Identity
- Profiles
- Authentication
- Authorization and Access Control
- Content Representation
- Reading and Writing Resources
- Social Web App Protocols
- Recommendations for Server Implementation
- Recommendations for Client App Implementation
- Examples
- Current Implementations
Solid (derived from "social linked data") is a proposed set of conventions and tools for building decentralized social applications based on Linked Data principles. Solid is modular and extensible. It relies as much as possible on existing W3C standards and protocols.
See Also:
Solid uses WebID URIs
as universal usernames or actor identifiers. Frequently referred to simply as
WebIDs, these URIs form the basis of most other Solid-related technologies,
such as authentication, authorization, access control, user profiles, discovery
of user preferences and server capabilities, and more.
WebIDs provide globally unique decentralized identifiers, enable cross-service federated signin, prevent service provider lock-in, and give users control over their own identity. The WebID URI's primary function is to point to the location of a public WebID Profile document (see below).
Example WebIDs: https://alice.databox.com/profile/card#me or
http://somepersonalsite.com/#webid
Solid uses WebID Profile Documents for management of user identity and security credentials (such as public keys), and user preferences discovery.
Although here we mostly refer to them in the context of user profiles, other types of actors use these profiles as well, such as groups, organizations, devices, and software applications.
A WebID URI, when dereferenced, yields a WebID Profile Document in a Linked Data format (Turtle by default, but often available as JSON-LD or HTML+RDFa). Parsing this document provides a client application with useful information, such as the user's name and profile image, links to user preferences and related documents, and lists of public key certificates or other relevant identity credentials.
See component spec: Solid WebID Profiles Specification
Authentication is the process of determining a user’s identity, of asking the question “How do I know you are who you say?”.
How do web applications typically authenticate users (that is, how do they verify identity)? The most common method is usernames and passwords. A username uniquely identifies a user (and ties them to a user profile), and a password verifies that the user is who they say they are. Many applications or services also have a secondary authentication mechanism (usually an external email address) that they use for account recovery (in case the user forgets or loses their primary authentication tokens, username and password).
Solid currently uses WebID-TLS as its primary authentication mechanism. Alternative complementary mechanisms are also being actively investigated. In addition, Solid recommends that server implementations also offer secondary authentication available for users for Account Recovery (via email or some other out-of-band mechanism).
Solid, being a decentralized web application platform, has a set of requirements for its authentication mechanisms that are not commonly encountered by most platforms and ecosystems. Specifically, it requires cross-domain, de-centralized authentication mechanisms not tied to any particular identity provider or certificate authority.
Note: Several browser vendors (Chrome, Firefox) have removed support
for the KEYGEN element, on which WebID-TLS relied for in-browser certificate
generation.
Solid uses the WebID-TLS protocol as one of its primary authentication mechanism. Instead of usernames, it uses WebIDs as unique identifiers, as previously mentioned. And instead of using passwords as bearer tokens, it uses cryptographic certificates (stored and managed by the user's web browser) to prove a user's identity.
When accessing a Solid server using WebID-TLS, a user is presented by their web browsers with a popup asking them to select an appropriate security certificate for that site. After a user makes their selection, the server securely matches the private key stored by the browser with the public key stored in that user's WebID Profile Document, and authenticates them.
See component spec: Solid WebID-TLS Specification
The Solid team is currently implementing support for WebID-OIDC as another primary authentication mechanism. It is based on the OAuth2/OpenID Connect protocols, adapted for WebID based decentralized use cases.
See component spec: WebID-OIDC Specification
There are several other authentication mechanisms that are currently being investigated, such as combinations of traditional username-and-password authentication and WebID-TLS Delegation).
Regardless of the primary authentication mechanism, bearer tokens and other proofs of identity tend to get lost by users. Passwords can be forgotten, browser certificates can be lost to hardware failure, and so on. Solid recommends that secondary Account Recovery mechanisms are provided by server implementers, to aid in these scenarios.
Authorization is the process of deciding whether a user has access to a particular resource. If authentication asks "who is the user?", authorization is concerned with "what is the user allowed to do?".
Solid currently uses the Web Access Control (WAC) mechanism for cross-domain authorization for all its resources.
Web Access Control (WAC) is a decentralized system that allows different users and groups various forms of access to resources where users and groups are identified by HTTP URIs. The system is similar to the access control system used within many file systems except that the documents controlled, the users, and the groups, are all identified by URIs. Users are identified by WebIDs. Groups of users are identified by the URI of a class of users which, if you look it up, returns a list of users in the class. This means a WebID hosted by any server can be a member of a group hosted some other server.
Users do not need to have an account (i.e. WebID) on a given server to have access to documents on it.
See component spec: Solid WAC Specification
Solid deals with reading and writing two kinds of resources:
- Linked Data resources (RDF in the form of JSON-LD, Turtle, HTML+RDFa, etc)
- Everything else (binary data and non-linked-data structured text)
While you can build Solid applications with non-linked data resources, using actual RDF-based Linked Data provides you with considerable benefits in terms of interoperability with the rest of the Solid app ecosystem.
Resources are grouped in directory-like Containers (currently conforming to the LDP Basic Container spec).
See component spec: Solid Content Representation
Solid extends the Linked Data Platform spec to provide a simple REST API for CRUD operations on resources and containers.
See component spec: HTTPS REST API
Solid also provides a WebSockets based API for a PubSub (Publish/Subscribe) mechanism, through which clients can be notified in real time of changes affecting a give resource.
See component spec: WebSockets API
In addition to read/write operations on resources, Solid provides a number of specs and recommendations to help developers achieve interoperability between various social web applications that are part of the ecosystem.
See component spec: Linked Data Notifications
API recommendations for managing subscriptions and friends lists are still being discussed. TBD.
See component spec: Recommendations for Server Implementations
See component spec: Recommendations for Client Implementations
Server Implementations: See
solid/solid-platform for a
list of Solid servers and developer tools.
Note: The Solid team uses
node-solid-server as
its main server implementation.
Client App Implementations: See
solid-client for the main client
library, and solid/solid-apps for an
example list of Apps built using Solid.