Solid Protocol

A data pod is a place for storing documents, with mechanisms for controlling who can access what.

A Solid app is an application that reads or writes data from one or more data pods.

An owner is a person or a social entity that is considered to have the rights and responsibilities of a data storage. An owner is identified by a URI, and implicitly has control over all data in a storage. An owner is first set at storage provisioning time and can be changed.

A read operation entails that information about a resource’s existence or its description can be known. [Source]

A write operation entails that information about resources can be created or removed. [Source]

An append operation entails that information can be added but not removed. [Source]

Prefixes and Namespaces

Prefix	Namespace	Description
rdf	http://www.w3.org/1999/02/22-rdf-syntax-ns#	[rdf-schema]
ldp	http://www.w3.org/ns/ldp#	[LDP]
solid	http://www.w3.org/ns/solid/terms#	Solid Terms
pim	http://www.w3.org/ns/pim/space#	Workspace Ontology
acl	http://www.w3.org/ns/auth/acl#	ACL Ontology

All assertions, diagrams, examples, and notes are non-normative, as are all sections explicitly marked non-normative. Everything else is normative.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

A data pod MUST be an HTTP/1.1 server [RFC7230][RFC7231]. It SHOULD additionally be an HTTP/2 server [RFC7540] to improve performance, especially in cases where individual clients are expected to send high numbers of successive requests.

A data pod SHOULD use TLS connections through the https URI scheme in order to secure the communication between clients and servers. When both http and https are supported, all http URIs MUST redirect to their https counterparts using a response with a 301 status code and a Location header.

A data pod MUST implement the server part of HTTP/1.1 Conditional Requests [RFC7232] to ensure that updates requested by clients will only be applied if given preconditions are met. It SHOULD additionally implement the server part of HTTP/1.1 Caching [RFC7234] to improve performance. A data pod MAY implement the server part of HTTP/1.1 Range Requests [RFC7233] to further improve performance for large representations.

A data pod MUST implement the server part of HTTP/1.1 Authentication [RFC7235]. When a client does not provide valid credentials when requesting a resource that requires it (see WebID), the data pod MUST send a response with a 401 status code (unless 404 is preferred for security reasons).

A Solid server MUST reject PUT, POST and PATCH requests without the Content-Type header with a status code of 400. [Source]

A Solid client MUST be an HTTP/1.1 client [RFC7230][RFC7231]. It MAY additionally be an HTTP/2 client [RFC7540] to improve performance.

A Solid client MAY implement the client parts of HTTP/1.1 Conditional Requests [RFC7232] to only trigger updates when certain preconditions are met. It MAY implement HTTP/1.1 Caching [RFC7234] and HTTP/1.1 Range Requests [RFC7233] to improve performance.

A Solid client MUST implement the client part of HTTP/1.1 Authentication [RFC7235] if it needs to access resources requiring authentication (see WebID). When it receives a response with a 403 or 404 status code, it MAY repeat the request with different credentials.

A Solid client MUST use the Content-Type HTTP header in PUT, POST and PATCH requests [RFC7231]. [Source]

The slash (/) character in the URI path indicates hierarchical relationship segments, and enables relative referencing [RFC3986]. The semantics of the slash character is shared by servers and clients. Paths ending with a slash denote a container resource. [Source]

If two URIs differ only in the trailing slash, and the server has associated a resource with one of them, then the other URI MUST NOT correspond to another resource. Instead, the server MAY respond to requests for the latter URI with a 301 redirect to the former. [Source]. Behaviour pertaining to authorization MUST precede this optional redirect [Source]

This section is non-normative.

Servers should not re-use URIs, regardless of the mechanism by which resources are created. Certain specific cases exist where URIs may be reinstated when it identifies the same resource, but only when consistent with Web architecture’s URI persistence [WEBARCH]. [Source]

Note: Servers that wish to disable URI re-use may want to use the 410 status code.

When a server supports a data pod, it MUST provide one or more storages (pim:Storage) – a space of URIs in which data can be accessed. A storage is the root container for all of its contained resources (see Resource Containment).

When a server supports multiple storages, the URIs MUST be allocated to non-overlapping space.

Servers exposing the storage resource MUST advertise by including the HTTP Link header with rel="type" targeting http://www.w3.org/ns/pim/space#Storage when responding to storage’s request URI.

Clients can determine a resource is of type storage by making an HTTP HEAD or GET request on the target URL, and checking for the Link header with rel="type" targeting http://www.w3.org/ns/pim/space#Storage.

Clients can determine the storage of a resource by moving up the URI path hierarchy until the response includes a Link header with rel="type" targeting http://www.w3.org/ns/pim/space#Storage. Clients may check the root path of a URI for the storage claim at any time.

Clients can discover a storage by making an HTTP GET request on the target URL to retrieve an RDF representation [RDF11-CONCEPTS], whose encoded RDF graph contains a relation of type http://www.w3.org/ns/pim/space#storage. The object of the relation is the storage (pim:Storage).

[Source] [Source]

Servers MUST keep track of at least one owner of a storage in an implementation defined way.

When a server wants to advertise the owner of a storage, the server MUST include the Link header with rel="http://www.w3.org/ns/solid/terms#owner" targeting the URI of the owner in the response of HTTP HEAD or GET requests targeting the root container.

Note: When a server supports multiple storages, there must be complete trust between its owners.

[Source][Source][Source][Source]

Solid has the notion of containers to represent a collection of linked resources to help with resource discovery and lifecycle management.

There is a 1-1 correspondence between containment triples and relative reference within the path name hierarchy. [Source]. It follows that all resources are discoverable from a container and that it is not possible to create orphan resources. [Source]

The representation and behaviour of containers in Solid corresponds to LDP Basic Container and MUST be supported. [Source]

Solid has the notion of auxiliary resources to provide supplementary information such as descriptive metadata, authorization conditions, data shape constraints, digital rights or provenance record about a given resource (hereafter referred as the subject resource), and affects how resources and others associated with it are processed, served or interpreted.

Server manages the association between a subject resource and auxiliary resources defined by this specification. The lifecycle of auxiliary resources defined by this specification depend on the lifeycle of the subject resource that they are associated with.

Auxiliary resources are represented as RDF documents [RDF11-CONCEPTS]. HTTP interactions on auxiliary resources are subject to the requirements as per Reading and Writing Resources.

Note: Where applicable, to promote self-describing resources, implementations and authors are encouraged to use the subject resource instead of the associated auxiliary resource.

This specification defines the following types of auxiliary resources:

• Web Access Control
• Resource Description

Clients can discover auxiliary resources associated with a subject resource by making an HTTP HEAD or GET request on the target URL, and checking the HTTP Link header with the rel parameter [RFC8288].

Auxiliary Type	Link Relation	Definitions
Web Access Control	acl	[Solid Protocol]
Description Resource	describedby	[LDP]
The possibility of using URIs as relation types interchangeably or as alternate to the tokens above are under consideration: http://www.w3.org/ns/auth/acl#accessControl https://www.w3.org/ns/iana/link-relations/relation#acl https://www.w3.org/ns/iana/link-relations/relation#describedby https://www.w3.org/ns/iana/link-relations/relation#describes Issue

Web Access Control

An auxiliary resource of type Web Access Control provides access control description of a subject resource (Web Access Control).

Description Resource

An auxiliary resource of type Description Resource provides a description of a subject resource ([LDP]).

Servers MUST NOT directly associate more than one description resource to a subject resource.

When an HTTP request targets a description resource, the server MUST apply the authorization rule that is used for the subject resource with which the description resource is associated.

Clients can discover resources that are described by description resources by making an HTTP HEAD or GET request on the target URL, and checking the HTTP Link header with a rel value of describes (inverse of the describedby relation) [RFC6892].

When creating new resources, servers can determine an effective request URI’s type by examining the URI path ending (URI Slash Semantics).

When a successful PUT or PATCH request creates a resource, the server MUST use the effective request URI to assign the URI to that resource.

When a successful POST request creates a resource, the server MUST assign a URI to that resource. Servers MAY allow clients to suggest the URI of a resource created through POST, using the HTTP Slug header as defined in [RFC5023].

Note: Clients can use PUT and PATCH requests to assign a URI to a resource. Clients can use POST requests to have the server assign a URI to a resource.

[Source][Source].

Servers MUST support the HTTP GET, HEAD and OPTIONS methods [RFC7231] for clients to read resources or to determine communication options. [Source]

When responding to authorized requests:

Servers MUST indicate their support for HTTP Methods by responding to HTTP GET and HEAD requests for the target resource with the HTTP Method tokens in the HTTP response header Allow.

Servers MUST indicate supported media types in the HTTP Accept-Patch [RFC5789], Accept-Post [LDP] and Accept-Put [The Accept-Put Response Header] response headers that correspond to acceptable HTTP methods listed in Allow header value in response to HTTP GET and HEAD requests.

Servers MAY include the HTTP Accept-Patch, Accept-Post and Accept-Put headers in the response of a OPTIONS * request.

[Source] [Source]

When a server supports the HTTP PUT, POST and PATCH methods [RFC7231] this specification imposes the following requirements: [Source]

Servers MUST create intermediate containers and include corresponding containment triples in container representations derived from the URI path component of PUT and PATCH requests. [Source]

Servers MUST allow creating new resources with a POST request to URI path ending /. Servers MUST create a resource with URI path ending /{id} in container /. Servers MUST create a container with URI path ending /{id}/ in container / for requests including the HTTP Link header with rel="type" targeting a valid LDP container type. Servers MUST handle subsequent requests to the newly created container’s URI as if it is a valid LDP container type by including the HTTP response’s Link header. [Source]

When a POST method request targets a resource without an existing representation, the server MUST respond with the 404 status code. [Source]

When a PUT or PATCH method request targets an auxiliary resource, the server MUST create or update it. When a POST method request with the Slug header targets an auxiliary resource, the server MUST respond with the 403 status code and response body describing the error. [Source]

Servers MUST NOT allow HTTP POST, PUT and PATCH to update a container’s containment triples; if the server receives such a request, it MUST respond with a 409 status code. [Source]

Clients MAY use the HTTP If-None-Match header with a value of "*" to prevent an unsafe request method (e.g., PUT, PATCH) from inadvertently modifying an existing representation of the target resource when the client believes that the resource does not have a current representation. [Source] [Source]

Servers MAY use the HTTP ETag header with a strong validator for RDF bearing representations in order to encourage clients to opt-in to using the If-Match header in their requests.

When a server supports the HTTP DELETE method [RFC7231] this specification imposes the following requirements: [Source]

When a DELETE request targets storage’s root container or its associated ACL resource, the server MUST respond with the 405 status code. Server MUST exclude the DELETE method in the HTTP response header Allow in response to requests [RFC7231]. [Source]

When a contained resource is deleted, the server MUST also remove the corresponding containment triple, which has the effect of removing the deleted resource from the containing container. [Source]

When a contained resource is deleted, the server MUST also delete the associated auxiliary resources (see the Auxiliary Resources section).

When a DELETE request is made to a container, the server MUST delete the container if it contains no resources. If the container contains resources, the server MUST respond with the 409 status code and response body describing the error. [Source]

This section is non-normative.

The server might perform additional actions, as described in the normative references like [RFC7231]. For example, the server could remove membership triples referring to the deleted resource, perform additional cleanup tasks for resources it knows are no longer referenced or have not been accessed for some period of time, and so on.

Subsequent GET requests to the deleted resource usually result in a 404 or 410 status code, although HTTP allows others. [Source] [Source]

Pertaining to events and loss of control mitigation: https://github.com/solid/specification/issues/41#issuecomment-534679278

When a server creates a resource on HTTP PUT, POST or PATCH requests such that the request’s representation data encodes an RDF document [RDF11-CONCEPTS] (as determined by the Content-Type header), the server MUST accept GET requests on this resource when the value of the Accept header requests a representation in text/turtle or application/ld+json [Turtle] [JSON-LD11]. [Source] Source] [Source] [Source]

When a PUT, POST, PATCH or DELETE method request targets a representation URL that is different than the resource URL, the server MUST respond with a 307 or 308 status code and Location header specifying the preferred URI reference. [Source]

A data pod MUST implement the CORS protocol [FETCH] such that, to the extent possible, the browser allows Solid apps to send any request and combination of request headers to the data pod, and the Solid app can read any response and response headers received from the data pod. If the data pod wishes to block access to a resource, this MUST NOT happen via CORS but MUST instead be communicated to the Solid app in the browser through HTTP status codes such as 401, 403, or 404 [RFC7231].

Note: Since the CORS protocol is part of a Living Standard, it might be changed at any point, which might necessitate changes to data pod implementations for continued prevention of undesired blocking. A proposal to mitigate this has been suggested.

Concretely, whenever a data pod receives an HTTP request containing a valid Origin header [RFC6454], the server MUST respond with the appropriate Access-Control-* headers as specified in the CORS protocol [FETCH]. In particular, the data pod MUST set the Access-Control-Allow-Origin header to the valid Origin value from the request and list Origin in the Vary header value. The data pod MUST make all used response headers readable for the Solid app through Access-Control-Expose-Headers (with the possible exception of the Access-Control-* headers themselves). A data pod MUST also support the HTTP OPTIONS method [RFC7231] such that it can respond appropriately to CORS preflight requests.

Careful attention is warranted, especially because of the many edge cases. For instance, data pods SHOULD explicitly enumerate all used response headers under Access-Control-Expose-Headers rather than resorting to *, which does not cover all cases (such as credentials mode set to include). Data pods SHOULD also explicitly list Accept under Access-Control-Allow-Headers, because values longer than 128 characters (not uncommon for RDF-based Solid apps) would otherwise be blocked, despite shorter Accept headers being allowed without explicit mention.

A WebID is an HTTP URI denoting an agent, for example a person, organisation, or software [WEBID]. When a WebID is dereferenced, server provides a representation of the WebID Profile in an RDF document [RDF11-CONCEPTS] which uniquely describes an agent denoted by a WebID. WebIDs are an underpinning component in the Solid ecosystem and are used as the primary identifier for users and applications.

The Solid OpenID Connect (Solid OIDC) specification defines how resource servers verify the identity of relying parties and end users based on the authentication performed by an OpenID provider [SOLID-OIDC].

This section is non-normative.

The Solid ecosystem initially relied on WebID-TLS for authenticated resource access [WEBID-TLS]. The current recommendation for authentication relies on Solid-OIDC (Solid-OIDC). Implementations can use WebID-TLS just as any other mechanism as an additional authentication method.

Web Access Control (WAC) is a decentralized cross-domain access control system providing a way for Linked Data systems to set authorization conditions on HTTP resources using the Access Control List (ACL) model. Server manages the association between a resource and an ACL resource, and applies the authorization conditions on requested operations. Authorizations are described using the ACL ontology to express and determine access privileges of a requested resource. Applications can discover authorization rules associated with a given resource, and to control such rules, as directed by an agent.

Servers MUST conform to the Web Access Control specification [WAC].

A resource can advertise an ACL document that is directly associated by using the HTTP Link header with a rel value of acl acl. [Source]

In the event that a server can’t apply an ACL to a resource, it MUST deny access. [Source]

Servers exposing client’s access privileges on a resource URL MUST advertise by including the WAC-Allow HTTP header in the response of HTTP HEAD and GET requests.

The syntax for the WAC-Allow header, using the ABNF syntax defined in Section 1.2 of [RFC7231], is:

wac-allow        = "WAC-Allow" ":" OWS #access-param OWS
access-param     = permission-group OWS "=" OWS access-modes
permission-group = 1*ALPHA
access-modes     = DQUOTE OWS *1(access-mode *(RWS access-mode)) OWS DQUOTE
access-mode      = "read" / "write" / "append" / "control"

The WAC-Allow HTTP header’s field-value is a comma-separated list of access-params. access-param is a whitespace-separated list of access-modes granted to a permission-group.

This specification defines the following permission-groups:

user

Permissions granted to the agent requesting the resource.

public

Permissions granted to the public.

access-mode corresponds to the modes of access as defined in the ACL ontology (acl:Read, acl:Write, acl:Append, acl:Control).

Clients can discover access privileges on a resource by making an HTTP HEAD or GET request on the target URL, and checking the WAC-Allow header value for access parameters listing the allowed access modes per permission group.

Clients' parsing algorithm for the WAC-Allow header should incorporate error handling. When the received message fails to match an allowed pattern, finds unrecognised access parameters or access modes, clients MUST ignore the received WAC-Allow header-field.

[Source] [Source] Source] Source]

The Accept-Put Response Header

This specification introduces a new HTTP response header Accept-Put used to specify the document formats accepted by the server on HTTP PUT requests. It is modelled after the Accept-Patch header defined in [RFC5789] and the Accept-Post header defined in [LDP].

The syntax for Accept-Put, using the ABNF syntax defined in Section 1.2 of [RFC7231], is:

Accept-Put = "Accept-Put" ":" # media-range

The Accept-Put header specifies a comma-separated list of media ranges (with optional parameters) as defined by [RFC7231], Section 5.3.2. The Accept-Put header, in effect, uses the same syntax as the HTTP Accept header minus the optional accept-params BNF production, since the latter does not apply to Accept-Put.

The presence of the Accept-Put header in response to any method is an implicit indication that PUT is allowed on the resource identified by the request URI. The presence of a specific document format in this header indicates that that specific format is allowed on PUT requests to the resource identified by the request URI.

IANA Registration Template:

The Accept-Put response header must be added to the permanent registry (see [RFC3864]).

Header field name

Accept-Put

Applicable Protocol

HTTP

Author/Change controller

W3C Solid Community Group

Specification document

This specification

The intent is that these link relations will be registered with IANA per [RFC8288].

acl

The contents of this section were originally taken from Web Access Control.

The following Link Relationship will be submitted to IANA for review, approval, and inclusion in the IANA Link Relations registry.

Relation Name

acl

Description

The relationship A acl B asserts that resource B provides access control description of resource A. There are no constraints on the format or representation of either A or B, neither are there any further constraints on either resource.

Reference

This specification.

Notes

Consumers of ACL resources should be aware of the source and chain of custody of the data.

[Source] [Source]

This section is non-normative.

While this section attempts to highlight a set of security considerations, it is not a complete list. Implementers are urged to seek the advice of security professionals when implementing mission critical systems using the technology outlined in this specification.

Implementations are subject to the same security considerations that are found in HTTP/1.1 [RFC7230] and [RFC7231].

Servers are strongly discouraged from assuming that HTTP request headers’ field-values are valid or non-malicious. Servers are strongly encouraged to sanitize requests before processing them or incorporating them in messages sent to others. Servers are encouraged to reject bad requests that conflict with this specification's normative requirements. Servers are encouraged to apply normalization and canonicalization algorithms where applicable. Servers are encouraged to take measures to mitigate potential timing attacks attempting to discover resource existence even if requesting agent has no access to the resource(s). Servers are strongly discouraged from exposing information beyond the minimum amount necessary to enable a feature.

Servers are strongly discouraged from assuming that the user agent is a regular Web browser, even when requests contain familiar values in headers such as User-Agent or Origin. Such an assumption could lead to incorrect conclusions about the security model of the application making the request, since the request might actually come from a non-browser actor unaffected by browser security constraints.

Servers disable all cross-origin protections in browsers because resource access is governed explicitly by the Authorization component. As such, servers cannot rely on browser-based cross-origin protection mechanisms for determining the authentication status or representation of a resource. In particular, servers are strongly encouraged to ignore HTTP cookies from untrusted origins. Additional security measures can be taken to prevent metadata in error responses from leaking. For instance, a malicious application could probe multiple servers to check whether the response status code is 401 or 403, or could try to access an error page from an intranet server within the user agent’s private network to extract company names or other data. To mitigate this, when a request from an untrusted Origin arrives, the server may want to set the status code of error responses to 404 and/or anonymize or censor their contents.

Servers are encouraged to use TLS connections to protect the contents of requests and responses from eavesdropping and modification by third parties. Unsecured TCP connections without TLS may be used in testing environments or when the data pod is behind a reverse proxy that terminates a secure connection.

This section is non-normative.

Servers are encouraged to use authorization techniques to prevent unwanted access to resources, rather than depending on the relative obscurity of their resource names.

Identifiable Information

In order to prevent leakage of non-resource data, servers are strongly discouraged from including identifiable information in error responses.

This section is non-normative.

We acknowledge the diversity of people using the Web, anyone that may create or use information. Our aim is to have inclusive designs for wide range of people and their abilities. This section details general accessibility considerations to take into account for Web content accessibility, accessible applications, authoring tools, and accessible user agents that uses this specification.

Web Content Accessibility: As with implementation of any Web standard or protocol, ignoring accessibility issues makes information unusable by a large subset of the population. It is strongly encouraged to follow accessibility guidelines and standards, such as the W3C Accessibility Guidelines [WCAG-3.0] to cover an array of recommendations to make content accessible to a wider range of people regardless of any disability, limitation, or sensitivity. It is also strongly encouraged to follow the guidance of Making content usable for people with cognitive and learning disabilities [COGA-USABLE].

Accessible Applications: To help assistive technologies to provide a consistent user interface and understanding of the objects, it is strongly encouraged to follow the Accessible Rich Internet Applications [WAI-ARIA-1.2] recommendations. To enable semantic navigation, styling and interactive features in context of digital publishing, it is encouraged to follow the Digital Publishing WAI-ARIA Module 1.0 [DPUB-ARIA-1.0]. To support structured graphics such as charts, graphs, technical drawings and scientific diagrams, to assistive technologies in order improve accessibility of graphics or diagrams through detailed annotations, it is encouraged to follow the WAI-ARIA Graphics Module [GRAPHICS-ARIA-1.0].

Authoring Tool Accessibility: To contribute to the proliferation of Web content that is accessible to a broad range of people, it is strongly encouraged to follow the Authoring Tool Accessibility Guidelines [ATAG20] in the design of authoring tools to support the production of accessible content through accessible user interfaces.

User Agent Accessibility Guidelines: To support the general principles for the development of accessible user agents, i.e., any software that retrieves, renders and facilitates end-user interaction with web content, it is strongly encouraged to follow the User Agent Accessibility Guidelines [UAAG20].

This section is non-normative.

Adaptability of content and software to the needs of target audiences helps towards accessibility. The mechanisms to cater information and interfaces so that people from any culture, region, or language preference can participate better. Towards this end, it is strongly encouraged to apply the recommendations and best practices of W3C Internationalization Activity. For example, content authors can:

• include links to navigate to different languages of the content;
• declare the base language of a document, indicate multiple languages and their directional flow – to help with translations;
• use Unicode character encoding, e.g., UTF-8, in data forms and text to ensure correct effects;
• check and minimise inappropriate cultural bias, and improve translatability;
• restrict markup use to structure and semantics.

..