The Solid Protocol

Editor’s Draft, 2021-01-11

Repository
GitHub
Issues

Abstract

This document connects a set of specifications that, together, provide applications with secure and permissioned access to externally stored data in an interoperable way.

Status of This Document

This section describes the status of this document at the time of its publication.

This document was published by the Solid Community Group as an Editor’s Draft. The sections that have been incorporated have been reviewed following the Solid process. However, the information in this document is still subject to change. You are invited to contribute any feedback, comments, or questions you might have.

Publication as an Editor’s Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.

Introduction

The aims of the Solid project are in line with those of the Web itself: empowerment towards an equitable, informed and interconnected society. Solid adds to existing Web standards to realise a space where individuals can maintain their autonomy, control their data and privacy, and choose applications and services to fulfil their needs.

The Solid ecosystem encapsulates a set of specifications that are guided by the principles we have adopted and also the priority of our values. We acknowledge that every technical decision has ethical implications both for the end user (short-term) as well as society (long-term). To contribute towards a net positive social benefit, we use the Ethical Web Principles to orient ourselves. The consensus on the technical designs are informed by common use cases, implementation experience, and use.

An overarching design goal of the Solid ecosystem is to be evolvable and to provide fundamental affordances for decentralised Web applications for information exchange in a way that is secure and privacy respecting. In this environment, actors allocate identifiers for their content, shape and store data where they have access to, set access control policies, and use preferred applications and services to achieve them.

The general architectural principles of Solid specifications are borrowed from the Architecture of the World Wide Web. The components as described in each specification may evolve independently – according to the principle of orthogonality in order to increase the flexibility and robustness of the Solid ecosystem. With that, the specifications are loosely coupled and indicate which features overlap with those governed by another specification. Extensibility as well as variability also are taken into account in each specification.

The specifications in the ecosystem describe how Solid servers and clients can be interoperable by using Web communication protocols, global identifiers, authentication and authorization mechanisms, data formats and shapes, and query interfaces.

The specifications are accompanied with supplemental documents, such as Primers and Best Practices and Guidelines to help implementers to form a well-rounded understanding of the Solid ecosystem as well as ways to improve their implementations.

Definitions

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.

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]

Namespaces

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

Conformance

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.

Hypertext Transfer Protocol

Solid clients and servers need to exchange data securely over the Internet, and they do so using the HTTP Web standard. This section describes in detail which parts of HTTP must be implemented by clients and servers.

Required Server-Side Implementation

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 § 3.1 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]

Required Client-Side Implementation

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 § 3.1 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]

Uniform Resource Identifier

URI Slash Semantics

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 proceed this optional redirect [Source]

URI Persistence

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.

Resources

Storage

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 § 2.3.2 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]

When using Web Access Control (§ 5.1 Web Access Control):

The root container (pim:Storage) MUST have an ACL auxiliary resource directly associated to it. The associated ACL document MUST include an authorization policy with acl:Control access privilege.

[Source]

Resource Containment

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]

Auxiliary Resources

An auxiliary resource may provide supplementary information about a given Solid resource, or affect how that resource and others associated with it are processed, served, or interpreted. Different auxiliary resource types provide different capabilities. This section introduces a mechanism for linking auxiliary resources with regular Solid resources.

Auxiliary resources are needed to influence the configuration, processing, or interpretation of Solid resources without changing the composition of the resources themselves. To do so would be undesirable in many cases, and not possible in others. Auxiliary resources are not meant to replace the ability of a Solid resource to self-describe.

Examples of auxiliary resources in use include:

  • A binary JPEG image linked to an auxiliary resource that includes information describing that binary JPEG.
  • A container linked to an auxiliary resource that includes access control statements for that container and the resources that belong to it.
  • A resource representation whose shape is constrained by a given ShEx schema that links to an auxiliary resource defining that schema.
  • A resource with an associated set of configurable parameters links to an auxiliary resource where those configurable parameters reside.

Required Server-Side Implementation

For any defined auxiliary resource available for a given Solid resource, all representations of that resource MUST include an HTTP Link header pointing to the location of each auxiliary resource.

The rel={relation-type} [RFC8288] will define the relationship to the target URL in the HTTP Link header. URIs are encouraged to indicate Link relation types.

An auxiliary resource linked with a given Solid resource through an HTTP Link header is considered to be directly associated with that resource. It is up to the server to determine how that association affects processing based on the auxiliary resource type.

A given Solid resource MAY link to zero or more auxiliary resources. A given Solid resource MUST NOT link to auxiliary resources on a different server under a different authority.

Is MUST NOT too strong? Related Issue

Access to different types of auxiliary resources require varying levels of authorization, which MUST be specified as part of the definition for a given auxiliary resource type.

An auxiliary resource that resides on a Solid server MUST adhere to the same interaction model used by other regular Solid resources, except where specified in the definition of that auxiliary resource type.

Required Client-Side Implementation

Discovery of Auxiliary Resources

To discover the auxiliary resources directly associated with a given Solid resource, a Solid client MUST issue a HEAD or GET request to the target resource URL and inspect the Link headers in the response.

A client discovers the location of auxiliary resources for § 2.5.3.1 Web Access Control and § 2.5.3.3 Shape Validation through a HEAD request on <https://server.example/resource.ttl>:

HEAD https://server.example/resource.ttl
Link: <https://server.example/acls/24986>; rel="http://www.w3.org/ns/solid/terms#acl"
Link: <https://server.example/shapes/85432>; rel="http://www.w3.org/ns/solid/terms#shape"

A client discovers the § 2.5.3.1 Web Access Control and § 2.5.3.2 Resource Description auxiliary resources through a GET request on <https://server.example/image.png>:

GET https://server.example/image.png
Link: <https://server.example/acls/36789>; rel="http://www.w3.org/ns/solid/terms#acl"
Link: <https://server.example/desc/08744>; rel="https://www.w3.org/ns/iana/link-relations/relation#describedby"
Discovery of Annotated Solid Resources

Certain auxiliary resource types MAY require the auxiliary resource to link back to the Solid resource it is directly associated with, via HTTP Link headers. In these instances, the link relation rel=describes or rel=https://www.w3.org/ns/iana/link-relations/relation#describes MUST be used.

Is MUST too strong, as opposed to encouraging via SHOULD instead? Related Issue

A § 2.5.3.2 Resource Description auxiliary resource <https://server.example/desc/08744> is directly associated with and describes <https://server.example/image.png>. A client that performs a GET request on <https://server.example/desc/08744> would discover the following relation in the Link headers returned in the response.

GET https://server.example/desc/08744
Link: <https://server.example/image.png>; rel="https://www.w3.org/ns/iana/link-relations/relation#describes"

Reserved Auxiliary Resource Types

The following table lists § 2.5.3 Reserved Auxiliary Resource Types and the associated link relation URIs that are used for discovery. Other auxiliary types and relations may also be used, and may be added to the reserved set in the future.

Auxiliary Type Link Relation
§ 2.5.3.1 Web Access Control "acl" or http://www.w3.org/ns/solid/terms#acl
§ 2.5.3.2 Resource Description "describedby" or https://www.w3.org/ns/iana/link-relations/relation#describedby
§ 2.5.3.3 Shape Validation http://www.w3.org/ns/solid/terms#shape

Agree on specific link relation URIs to use for auxiliary types Related Issue

Web Access Control

ACL resources as defined by § 5.1 Web Access Control MUST be supported as an auxiliary type by Solid servers.

The ACL auxiliary resource directly associated with a given resource is discovered by the client via the rel="acl" Link relation in a Link header.

Note: Consider moving some of this information to § 5.1 Web Access Control

A given Solid resource MUST NOT be directly associated with more than one ACL auxiliary resource. A given ACL auxiliary resource MUST NOT be directly associated with more than one Solid resource.

To discover, read, create, or modify an ACL auxiliary resource, an acl:agent MUST have acl:Control privileges per the ACL inheritance algorithm on the resource directly associated with it.

An ACL auxiliary resource MUST be deleted by the Solid server when the resource it is directly associated with is also deleted and the Solid server is authoritative for both resources.

A Solid server SHOULD sanity check ACL auxiliary resources upon creation or update to restrict invalid changes, such as by performing shape validation against authorization statements therein.

Resource Description

Note: Consider where there are any common parameters that would be ubiquitous across resource descriptions that should be defined as part of the specification.

Resource description is a general mechanism to provide descriptive metadata for a given resource. It MUST be supported as an auxiliary type by Solid servers.

The Descriptive auxiliary resource directly associated with a given resource is discovered by the client via the rel="describedby" Link relation in a Link header. Conversely, the resource being described by a Descriptive auxiliary resource is discovered by the client via the rel="describes" Link relation in a Link header.

Consider whether a given Solid resource should be allowed to have multiple resource description auxiliary resources. Related Issue

A given Solid resource MUST NOT be directly associated with more than one Descriptive auxiliary resource.

Determine what the default permissions should be on resource description auxiliary resources, or whether we should have them at all. Related Issue

To create or modify a Descriptive auxiliary resource, a given acl:agent MUST have acl:Write privileges per the ACL inheritance algorithm on the resource directly associated with it.

To discover or read a Descriptive auxiliary resource, an acl:agent MUST have acl:Read privileges per the ACL inheritance algorithm on the resource directly associated with it.

An Descriptive auxiliary resource MUST be deleted by the Solid server when the resource it is directly associated with is also deleted and the Solid server is authoritative for both resources.

Shape Validation

Shape Validation auxiliary resources as defined by (link to shape validation) SHOULD be supported as an auxiliary type by Solid servers.

The Shape validation auxiliary resource directly associated with a given resource is discovered by the client via the rel=http://www.w3.org/ns/solid/terms#shape Link relation in a Link header. Conversely, the resource being described by a Shape validation auxiliary resource is discovered by the client via the rel=describes Link relation in a Link header.

Note: Consider moving some of this information to the Shape Validation section

A given Solid resource MUST NOT be directly associated with more than one Shape Validation auxiliary resource.

Determine what the default permissions should be on shape validation auxiliary resources, or whether we should have them at all. Related Issue

To create or modify a Shape validation auxiliary resource, an acl:agent MUST have acl:Write privileges per the ACL inheritance algorithm on the resource directly associated with it.

To discover or read a Shape validation auxiliary resource, an acl:agent MUST have acl:Read privileges per the ACL inheritance algorithm on the resource directly associated with it.

A Shape validation auxiliary resource MUST be deleted by the Solid server when the resource it is directly associated with is also deleted and the Solid server is authoritative for both resources.

Provide a shape to validate a shape validation auxiliary resource. May include the shape language, shape url, and any additional parameters to be used in shape validation by the server implementation.

A Solid server SHOULD sanity check Shape validation auxiliary resources upon creation or update to restrict invalid changes.

Reading and Writing Resources

Servers MUST respond with the 405 status code to requests using HTTP methods that are not supported by the target resource. [Source]

Resource Type Heuristics

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

Clients who want to assign a URI to a resource, MUST use PUT and PATCH requests. Servers MAY allow clients to suggest the URI of a resource created through POST, using the HTTP Slug header as defined in [RFC5023].

Clients who want the server to assign a URI of a resource, MUST use the POST request.

[Source].

Reading Resources

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 [§ 2.8.1.1 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]

Writing Resources

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 (eg. 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 using Web Access Control (§ 5.1 Web Access Control):

To create or update an ACL resource (see § 2.5.3.1 Web Access Control), an acl:agent MUST have acl:Control privileges per the ACL inheritance algorithm on the resource directly associated with it. [Source]

Deleting Resources

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 safe method 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 resources (see the § 2.5 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]

When using Web Access Control (§ 5.1 Web Access Control):

To delete a resource, an acl:agent MUST have acl:Write privilege per the ACL inheritance algorithm on the resource and the containing container. [Source]

To delete an ACL resource (see § 2.5.3.1 Web Access Control), an acl:agent MUST have acl:Control privileges per the ACL inheritance algorithm on the resource directly associated with it. [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]

As deleted resources can be reinstated with the same URI, access controls on the reinstated resource can change per the ACL inheritance algorithm. [Source]

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

Resource Representations

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]

Notifications

A Solid server MUST conform to the LDN specification by implementing the Receiver parts to receive notifications and make Inbox contents available [LDN].

A Solid client MUST conform to the LDN specification by implementing the Sender or Consumer parts to discover the location of a resource’s Inbox, and to send notifications to an Inbox or to retrieve the contents of an Inbox [LDN].

Cross-Origin Resource Sharing

Solid apps typically access data from multiple sources. However, Web browsers by default prevent apps that run on one origin from accessing data on other origins. This cross-origin protection is a security mechanism that ensures malicious websites cannot simply read your profile or banking details from other websites. However, this reasonable default poses a problem even for benevolent Solid apps, which might have good reasons to access data from different places. For instance, a Solid app at https://app.example/ would be prevented from accessing data on https://alice-data-pod.example/ or https://bob-data-pod.example/, even when Alice and Bob have given the user of the app their permission to see some of their data.

For cases where the other origins have their own access protection mechanism—like within Solid— the browser’s built-in cross-origin protection is actually an obstacle rather than a feature. After all, data pods already ensure through access control that certain documents can only be accessed by specific people or applications. Preventively blocking apps from different origins thus introduces an unnecessary barrier.

Fortunately, Web servers can indicate to the browser that certain documents do not require cross-origin protection. This mechanism to selectively disable that protection is called Cross-Origin Resource Sharing or CORS [FETCH]. By responding to browser requests with a specific combination of HTTP headers, servers can indicate which actions are allowed for a given resource. For a Solid data pod, the goal is to allow all actions on the CORS level, such that the deeper access control layer can exert full control over the app’s allowed permissions. The next section describes how to achieve this through the right HTTP header configuration.

Required Server-Side Implementation

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.

Identity

WebID

A WebID is a 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. The WebID Profile can be used by controlling agents to link with others to grant access to identity resources as they see fit. WebIDs are an underpinning component in the Solid ecosystem and are used as the primary identifier for users and client application.

When using Web Access Control (§ 5.1 Web Access Control):

Agents accessing non-public Solid resources need to authenticate with a WebID.

Authentication

Solid-OIDC

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].

WebID-TLS

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 (§ 4.1 Solid-OIDC). Implementations can use WebID-TLS just as any other mechanism as an additional authentication method.

Authorization

Web Access Control

Web Access Control (WAC) is a decentralized cross-domain access control system. The WAC mechanism is concerned with giving access to agents denoted by a § 3.1 WebID to perform various kinds of read-write operations on resources identified by URLs. The Access Control List (ACL) ontology is used to describe authorization policies about authorized agents with modes of access on target resources.

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 § 2.8.2.1 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     = *1DQUOTE OWS *1(access-mode *(RWS access-mode)) OWS *1DQUOTE
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.

The quoted and unquoted values for access-modes are equivalent. Servers are recommended to use quoted values in the response. Clients' are recommended to be able to parse both quoted and unquoted values.

[Source] [Source] [Source]

HTTP Definitions

HTTP Headers

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

Considerations

This section details security, privacy, accessibility and internationalization considerations.

Security Considerations

Some of the normative references with this specification point to documents with a Living Standard or Draft status, meaning their contents can still change over time. It is advised to monitor these documents, as such changes might have security implications.

A data pod MUST NOT assume that HTTP request headers sent by a client are valid, and MUST reject or sanitize invalid header values before processing them or incorporating them in messages sent to others. For example, values for Host and Origin MUST NOT be assumed to be free of possibly malicious sequences such as /.. or others, and invalid Origin values MUST NOT be echoed into the Access-Control-Allow-Origin response header.

A data pod MUST NOT assume 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.

Solid data pods disable all cross-origin protections in browsers because resource access is governed explicitly by Web Access Control. As such, data pods MUST NOT rely on browser-based cross-origin protection mechanisms for determining the authentication status or representation of a resource. In particular, they MUST ignore HTTP cookies from untrusted origins. Additional security measures MAY be taken to prevent metadata in error responses from leaking. For instance, a malicious app 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 data pod MAY set the status code of error responses to 404 and/or anonymize or censor their contents.

Data pods SHOULD 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.

Privacy Considerations

Identifiable Information

In order to prevent leakage of non-resource data, error responses SHOULD NOT contain identifiable information.

Accessibility Considerations

..

Internationalization Considerations

..

Security and Privacy Review

..

References

Normative References

[FETCH]
Anne van Kesteren. Fetch Standard. Living Standard. URL: https://fetch.spec.whatwg.org/
[JSON-LD11]
Gregg Kellogg; Pierre-Antoine Champin. JSON-LD 1.1. 9 September 2019. WD. URL: https://www.w3.org/TR/json-ld11/
[LDN]
Sarven Capadisli; Amy Guy. Linked Data Notifications. 2 May 2017. REC. URL: https://www.w3.org/TR/ldn/
[LDP]
Steve Speicher; John Arwe; Ashok Malhotra. Linked Data Platform 1.0. 26 February 2015. REC. URL: https://www.w3.org/TR/ldp/
[RDF-SCHEMA]
Dan Brickley; Ramanathan Guha. RDF Schema 1.1. 25 February 2014. REC. URL: https://www.w3.org/TR/rdf-schema/
[RDF11-CONCEPTS]
Richard Cyganiak; David Wood; Markus Lanthaler. RDF 1.1 Concepts and Abstract Syntax. 25 February 2014. REC. URL: https://www.w3.org/TR/rdf11-concepts/
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[RFC3864]
G. Klyne; M. Nottingham; J. Mogul. Registration Procedures for Message Header Fields. September 2004. Best Current Practice. URL: https://tools.ietf.org/html/rfc3864
[RFC3986]
T. Berners-Lee; R. Fielding; L. Masinter. Uniform Resource Identifier (URI): Generic Syntax. January 2005. Internet Standard. URL: https://tools.ietf.org/html/rfc3986
[RFC5023]
J. Gregorio, Ed.; B. de hOra, Ed.. The Atom Publishing Protocol. October 2007. Proposed Standard. URL: https://tools.ietf.org/html/rfc5023
[RFC5789]
L. Dusseault; J. Snell. PATCH Method for HTTP. March 2010. Proposed Standard. URL: https://httpwg.org/specs/rfc5789.html
[RFC6454]
A. Barth. The Web Origin Concept. December 2011. Proposed Standard. URL: https://tools.ietf.org/html/rfc6454
[RFC7230]
R. Fielding, Ed.; J. Reschke, Ed.. Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7230.html
[RFC7231]
R. Fielding, Ed.; J. Reschke, Ed.. Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7231.html
[RFC7232]
R. Fielding, Ed.; J. Reschke, Ed.. Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7232.html
[RFC7233]
R. Fielding, Ed.; Y. Lafon, Ed.; J. Reschke, Ed.. Hypertext Transfer Protocol (HTTP/1.1): Range Requests. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7233.html
[RFC7234]
R. Fielding, Ed.; M. Nottingham, Ed.; J. Reschke, Ed.. Hypertext Transfer Protocol (HTTP/1.1): Caching. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7234.html
[RFC7235]
R. Fielding, Ed.; J. Reschke, Ed.. Hypertext Transfer Protocol (HTTP/1.1): Authentication. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7235.html
[RFC7540]
M. Belshe; R. Peon; M. Thomson, Ed.. Hypertext Transfer Protocol Version 2 (HTTP/2). May 2015. Proposed Standard. URL: https://httpwg.org/specs/rfc7540.html
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://tools.ietf.org/html/rfc8174
[RFC8288]
M. Nottingham. Web Linking. October 2017. Proposed Standard. URL: https://httpwg.org/specs/rfc8288.html
[SOLID-OIDC]
Solid-OIDC. URL: https://solid.github.io/authentication-panel/solid-oidc/
[Turtle]
Eric Prud'hommeaux; Gavin Carothers. RDF 1.1 Turtle. 25 February 2014. REC. URL: https://www.w3.org/TR/turtle/
[WAC]
Web Access Control. URL: https://solid.github.io/web-access-control-spec/
[WEBARCH]
Ian Jacobs; Norman Walsh. Architecture of the World Wide Web, Volume One. 15 December 2004. REC. URL: https://www.w3.org/TR/webarch/

Informative References