Solid Protocol

Editor’s Draft, 2024-09-03

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 report was not published by the Solid Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.

Publication as an Editor’s Draft does not imply endorsement by anyone. This 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. You are invited to contribute any feedback, comments, or questions you might have.

Introduction

This section is non-normative.

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 [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 controls, 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 [WEBARCH]. 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.

This specification is for:

Resource server developers that want to enable clients to send and retrieve information;
Application developers that want to implement a client to perform operations on resources.

Terminology

This section is non-normative.

The Solid Protocol specification defines the following terms. These terms are referenced throughout this specification.

storage: A storage is a space of URIs that affords agents controlled access to resources.
Solid app: A Solid app is an application that reads or writes data from one or more storages.
URI: A Uniform Resource Identifier (URI) provides the means for identifying resources [RFC3986].
resource: A resource is the target of an HTTP request identified by a URI [RFC9110].
container resource: A container resource is a hierarchical collection of resources that contains other resources, including containers.
root container: A root container is a container resource that is at the highest level of the collection hierarchy.
resource metadata: Resource metadata encompasses data about resources described by means of RDF statements [RDF11-CONCEPTS].
agent: An agent is a person, social entity, or software identified by a URI; e.g., a WebID denotes an agent [WEBID].
owner: An owner is a person or a social entity that is considered to have the rights and responsibilities of a storage. An owner is identified by a URI, and implicitly has control over all resources in a storage. An owner is first set at storage provisioning time and can be changed.
origin: An origin indicates where an HTTP request originates from [RFC6454].
read operation: A read operation entails that information about a resource’s existence or its description can be known. [Source]
write operation: A write operation entails that information about resources can be created or removed. [Source]
append operation: 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
`dcterms`	http://purl.org/dc/terms/	[DC-TERMS]
`stat`	http://www.w3.org/ns/posix/stat	POSIX File Status

Conformance

This section describes the conformance model of the Solid Protocol.

Normative and Informative Content

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”, “SHOULD”, and “MAY” are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

The key words “strongly encouraged”, “strongly discouraged”, “encouraged", “discouraged", “can", “cannot”, “could”, “could not”, “might”, and “might not” are used for non-normative content.

Specification Category

The Solid Protocol identifies the following Specification Category to distinguish the types of conformance: API, notation/syntax, set of events, processor behaviour, protocol.

Classes of Products

The Solid Protocol identifies the following Classes of Products for conforming implementations. These products are referenced throughout this specification.

Server: A server that builds on HTTP server [RFC9110] and [RFC9112] by defining media types, HTTP header fields, and the behaviour of resources, as identified by link relations.
Client: A client that builds on HTTP client [RFC9110], [RFC9112], and [FETCH] by defining behaviour in terms of fetching across the platform.

Interoperability

Interoperability of implementations for servers and clients is tested by evaluating an implementation’s ability to request and respond to HTTP messages that conform to this specification.

Relations

This section is non-normative.

Relationship to LDP

This section is non-normative.

The Solid Protocol and the Linked Data Platform (LDP) [LDP] both use relative referencing of URIs [RFC3986].

As HTTP clients assign a URI to a resource when using PUT and PATCH, relative references in representation content are deterministic in both the Solid Protocol and LDP.

LDP does not specify URI patterns for resources when using the POST method, e.g., POST http://example.org/foo/ may result in creating a resource with URI http://example.org/foo/bar, http://example.org/baz/qux/quxx, http://example.org/{uuid} or something else. In Solid Protocol, the URI of a new resource resulting from, e.g., POST http://example.org/foo/, is in context of the request URI, and therefore http://example.org/foo/bar will be created, and it is not possible to construct the new URI besides under the direct hierarchy of http://example.org/foo/.

Solid Protocol's server behaviour in that regard is compatible with LDP even if only ldp:Container is advertised in the HTTP Link header field of the request URI, i.e., http://example.org/foo/ as the target URI of POST. Thus, it is possible to have a Solid Protocol server as a particular specialisation of LDP with respect to behaviours around POST to containers. Clients that are interoperable with LDP servers would also be interoperable with Solid Protocol servers with respect to relative referencing. Although LDP servers cannot guarantee the URI pattern resulting from POST requests, the fact that Solid Protocol servers can does not impact interoperability between Solid Protocol servers and LDP clients.

Solid Protocol clients may not fully interoperate with LDP servers, e.g., it is possible for an LDP server implementation to assign URIs to new resources that are not compatible with Solid Protocol. An LDP server needs to also conform to Solid Protocol server requirements in order to participate in the Solid ecosystem.

Hypertext Transfer Protocol

Solid servers and clients 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.

HTTP Server

Servers MUST conform to HTTP Semantics [RFC9110]. Servers SHOULD conform to HTTP Caching [RFC9111]. Servers MUST conform to HTTP/1.1 [RFC9112]. Servers SHOULD conform to HTTP/2 [RFC9113].

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

When a client does not provide valid credentials when requesting a resource that requires it (see WebID), servers MUST send a response with a 401 status code (unless 404 is preferred for security reasons).

Server MUST generate a Content-Type header field in a message that contains content.

Server MUST reject PUT, POST, and PATCH requests that contain content but lack the Content-Type header field, with a status code of 400. [Source] [Source]

Server MUST generate a Last-Modified header field in response to GET and HEAD requests.

HTTP Client

Clients MUST conform to HTTP Semantics [RFC9110]. Clients MAY conform to HTTP Caching [RFC9111]. Clients MUST conform to HTTP/1.1 [RFC9112]. Clients MAY conform to HTTP/2 [RFC9113].

When a client receives a response with a 403 or 404 status code, the client MAY repeat the request with different credentials.

Clients MUST use the Content-Type HTTP header field in PUT, POST, and PATCH requests that contain content [RFC9110]. [Source] [Source]

Uniform Resource Identifier

Note: Storage Owner and URI Ownership

This specification does not describe the relationship between a storage owner and Web architecture’s URI ownership [WEBARCH].

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]. Servers MUST authorize prior to 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: URI Reuse

Servers that wish to disable URI re-use might want to use the 410 status code.

Resources

Storage Resource

Servers MUST provide one or more storages. The storage resource (pim: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 MUST advertise the storage resource by including the HTTP Link header field 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 field 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 field with rel="type" targeting http://www.w3.org/ns/pim/space#Storage.

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 include the Link header field with rel="http://www.w3.org/ns/solid/terms#storageDescription" targeting the URI of the storage description resource in the response of HTTP GET, HEAD and OPTIONS requests targeting a resource in a storage.

Servers MUST include statements about the storage as part of the storage description resource.

Storage description statements include the properties:

rdf:type: A class whose URI is http://www.w3.org/ns/pim/space#Storage.

[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 field 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.

[Source][Source][Source][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 by server. [Source]

Servers can determine the field value of the HTTP Last-Modified header field in response to HEAD and GET requests targeting a container based on changes to containment triples.

Note: Container Last-Modified Comparison

The Last-Modified of a container will not change when other parts of the container changes. This is to avoid instant propagation of changes all the way to the root container. As Last-Modified cannot be reliably used to check whether the container representation has changed in any way, relying on it for change detection is not meaningful. In future versions of this specification, this design may be revisited.

Contained Resource Metadata

Container descriptions are not limited to containment triples. To further support client navigation and application interaction, servers can include resource metadata about contained resources as part of the container description, as described below.

Servers SHOULD include resource metadata about contained resources as part of the container description, unless that information is inapplicable to the server.

Contained resource metadata statements include the properties:

rdf:type: A class whose URI is the expansion of the URI Template [RFC6570] http://www.w3.org/ns/iana/media-types/{+iana-media-type}#Resource, where iana-media-type corresponds to a value from the IANA Media Types [IANA-MEDIA-TYPES].
stat:size: A non-negative integer giving the size of the resource in bytes.
dcterms:modified: The date and time when the resource was last modified.
stat:mtime: The Unix time when the resource was last modified.

The dcterms:modified value of a contained resource corresponds with the Last-Modified header field value of the contained resource. If one were to perform HEAD or GET requests on the URI of the contained resource at the time of the HTTP message’s generation, then a response with the 200 status code including the Last-Modified header field would indicate the same date and time.

Note: Contained Resource Metadata Considerations

The generation of contained resource metadata might be inapplicable to some servers, for example, when that information does not exist or is expensive to determine.

Contained resource metadata is protected by the server.

[Source] [Source] [Source]

Auxiliary Resources

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.

Servers MUST support auxiliary resources defined by this specification and manage the association between a subject resource and auxiliary resources. When a subject resource is deleted its auxiliary resources are also deleted by the server (Server Deleting Auxiliary Resources).

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: Self-describing Resources

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

Note: URI Origin

The resource and the associated auxiliary resource can be on different origins [RFC6454].

This specification defines the following types of auxiliary resources:

Web Access Control
Description Resource

Servers MUST advertise auxiliary resources associated with a subject resource by responding to HEAD and GET requests by including the HTTP Link header field with the rel parameter [RFC8288].

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 field with the rel parameter [RFC8288].

Auxiliary Type	Link Relation	Definitions
Web Access Control	`acl`	[WAC]
Description Resource	`describedby`	[POWDER-DR]

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.

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 field with a rel value of describes (inverse of the describedby relation) [RFC6892].

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 a target URI’s type by examining the URI path ending (URI Slash Semantics).

When a successful POST request creates a resource, the server MUST assign a URI to that resource.

Note: URI Allocation

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

Reading Resources

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

Servers MUST indicate the HTTP methods supported by the target resource by generating an Allow header field in successful responses.

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

[Source] [Source] [Source]

Writing Resources

Servers MUST support the HTTP PUT, POST and PATCH methods [RFC9110]. [Source] [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 creation of new resources by a POST request to a URI path ending with /. Servers MUST create resources with URI paths ending with /{id} in container /. [Source] [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 request targets an auxiliary resource, the server MUST create or update it. [Source]

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

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

Note: Conditional Update

Clients are encouraged to use the HTTP If-None-Match header field 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] [Source]

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

Modifying Resources Using N3 Patches

Servers MUST accept a PATCH request with an N3 Patch body when the target of the request is an RDF document [RDF11-CONCEPTS]. Servers MUST indicate support of N3 Patch by listing text/n3 as a field value of the Accept-Patch header field [RFC5789] of relevant responses. [Source]

An N3 Patch is a document in the Notation3 (N3) format [N3], identified by the media type text/n3, conforming to the following constraints:

A patch document MUST contain one or more patch resources.
A patch resource MUST be identified by a URI or blank node, which we refer to as ?patch in the remainder of this section.
A patch resource MAY contain a triple [RDF11-CONCEPTS] ?patch rdf:type solid:Patch.
A patch resource MUST contain at most one triple of the form ?patch solid:deletes ?deletions.
A patch resource MUST contain at most one triple of the form ?patch solid:inserts ?insertions.
A patch resource MUST contain at most one triple of the form ?patch solid:where ?conditions.
When present, ?deletions, ?insertions, and ?conditions MUST be non-nested cited formulae [N3] consisting only of triples and/or triple patterns [SPARQL11-QUERY]. When not present, they are presumed to be the empty formula {}.

While other specifications might provide a structure and interpretation for a wider class of N3 Patch documents, the present specification only governs the application of N3 Patch documents that additionally adhere to the following constraints:

The patch document MUST contain exactly one patch resource, identified by one or more of the triple patterns described above, which all share the same ?patch subject.
A patch resource MUST contain a triple ?patch rdf:type solid:InsertDeletePatch.
The ?insertions and ?deletions formulae MUST NOT contain variables that do not occur in the ?conditions formula.
The ?insertions and ?deletions formulae MUST NOT contain blank nodes.

Servers MUST respond with a 422 status code [RFC4918] if a patch document does not satisfy all of the above constraints.

When ?conditions is non-empty, servers MUST treat the request as a Read operation. When ?insertions is non-empty, servers MUST (also) treat the request as an Append operation. When ?deletions is non-empty, servers MUST treat the request as a Read and Write operation.

Servers MUST process a patch resource against the target document as follows:

Start from the RDF dataset in the target document, or an empty RDF dataset if the target resource does not exist yet.
If ?conditions is non-empty, find all (possibly empty) variable mappings such that all of the resulting triples occur in the dataset.
If no such mapping exists, or if multiple mappings exist, the server MUST respond with a 409 status code. [Source]
The resulting variable mapping is propagated to the ?deletions and ?insertions formulae to obtain two sets of resulting triples.
If the set of triples resulting from ?deletions is non-empty and the dataset does not contain all of these triples, the server MUST respond with a 409 status code. [Source]
The triples resulting from ?deletions are to be removed from the RDF dataset.
The triples resulting from ?insertions are to be added to the RDF dataset, with each blank node from ?insertions resulting in a newly created blank node.
The combination of deletions followed by insertions then forms the new resource state of the RDF document, and the server responds with the appropriate status code.

Example: Applying an N3 patch

@prefix solid: <http://www.w3.org/ns/solid/terms#>.
@prefix ex: <http://www.example.org/terms#>.

_:rename a solid:InsertDeletePatch;
  solid:where   { ?person ex:familyName "Garcia". };
  solid:inserts { ?person ex:givenName "Alex". };
  solid:deletes { ?person ex:givenName "Claudia". }.

This N3 Patch instructs to rename Claudia Garcia into Alex Garcia, on the condition that no other Garcia family members are present in the target RDF document.

Deleting Resources

Servers MUST support the HTTP DELETE method [RFC9110]. [Source] [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 field value of the Allow header field, in response to requests to these resources [RFC9110]. [Source]

When a contained resource is deleted, the server MUST also remove the corresponding containment triple. [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 targets 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 [RFC9110]. For example, the server could 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]

Resource Representations

When a server creates an RDF source [RDF11-CONCEPTS] on HTTP PUT, POST, or PATCH requests, the server MUST satisfy GET requests on this resource when the field value of the Accept header field 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 field specifying the preferred URI reference. [Source]

Constraints and Problem Details

This section is non-normative.

Servers are encouraged to publish any constraints on clients’ ability to create or update resources by adding a Link header field with an appropriate context URI, a link relation of http://www.w3.org/ns/ldp#constrainedBy, and a target URI identifying a set of constraints [RFC8288], to responses to requests that fail due to violation of those constraints. The same Link header field can be provided in other responses.

Servers are encouraged to use the URIs of the constraints that are defined by specifications or other constraint URIs within its authority depending on the request's semantics on a target resource.

Constraints are intended to be protected and persistent resources and therefore cannot be modified by clients. To facilitate better client interactions, it is encouraged to express constraints in RDF.

[Source]

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

Live Update

Solid Notifications Protocol

Entities in a Solid ecosystem use the Solid Notifications Protocol to communicate about changes affecting a resource.

Servers MUST conform to the Solid Notifications Protocol [SOLID-NOTIFICATIONS-PROTOCOL] by implementing the Resource Server to enable clients to discover subscription resources and notification channels available to a given resource or storage.

Servers MUST conform to the Solid Notifications Protocol [SOLID-NOTIFICATIONS-PROTOCOL] by implementing the Subscription Server to process and produce instructions for subscription requests.

Servers MUST conform to the Solid Notifications Protocol [SOLID-NOTIFICATIONS-PROTOCOL] by implementing the Notification Sender to produce and send messages to a Notification Receiver.

Servers MUST conform to the Solid Notifications Protocol [SOLID-NOTIFICATIONS-PROTOCOL] by implementing the Notification Receiver to receive and process messages that conform to a notification channel type.

The following is non-normative.

The Solid WebSockets API (Unofficial Draft) [SOLID-WEBSOCKETS-API] has been the common notification protocol for many years. That draft does not include an authentication mechanism, and therefore this Protocol has transitioned to require the Solid Notifications Protocol.

Existing client and server implementations should begin providing support for the new notification protocol while supporting backwards compatibility, as appropriate.

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://guinan.example/ or https://darmok.example/, even when Guinan and Darmok 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, storages 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 header fields, servers can indicate which actions are allowed for a given resource. For Solid, the goal is to allow all actions on the CORS level, such that the deeper Authorization layer can exert full control over the app’s allowed permissions. The next section describes how to achieve this through the right HTTP header field configuration.

CORS Server

A server 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 server, and the Solid app can read any response and response headers received from the server. If the server 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 [RFC9110].

Note: CORS Protocol Blocking

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

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

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

Identity

WebID

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.

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

Authorization

Servers MUST conform to either or both Web Access Control [WAC] and Access Control Policy [ACP] specifications.

Web Access Control

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 with the acl Link Relation, 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.

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

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

Access Control Policy

Access Control Policy (ACP) is a language for describing, controlling, and granting access to resources. Authorizations are described using the ACP ontology to express and determine access privileges of a requested resource.

Clients MUST conform to the Access Control Policy specification [ACP].

[Source]

HTTP Definitions

HTTP Headers

The Accept-Put Response Header

This specification introduces the Accept-Put header field 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 2.1 of [RFC9110], is:

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

The Accept-Put header field specifies a comma-separated list of media ranges (with optional parameters) as defined by [RFC9110], Section 12.5.1. The Accept-Put header field, in effect, uses the same syntax as the HTTP Accept header.

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

IANA Registration Template:

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

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.

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

Security Considerations

This section is non-normative.

While this section attempts to highlight a set of security considerations, it is not a complete list. Implementers are strongly encouraged to seek the advice of security professionals when developing systems that require robust protection and reliability using the technology outlined in this specification.

Implementations are encouraged to adhere to the same security considerations that are found in HTTP Semantics [RFC9110] and HTTP/1.1 [RFC9112].

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 restrict untrusted requests. 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 encouraged to implement additional security measures to protect sensitive information found in identity documents, such as trust anchors, identity provider configurations, and client application properties, ensuring that modifications to this information are only made with proper authorization or under controlled conditions, in compliance with relevant regulatory requirements and standards.

Servers are strongly discouraged from assuming that the user agent is a regular Web browser, even when requests contain familiar field values in header fields 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 server is behind a reverse proxy that terminates a secure connection.

Privacy Considerations

This section is non-normative.

Privacy is one of the ethical values that underpin the web. To empower people with needs to have strong privacy protections with respect to information flows, implementers as well as developers of specifications in the Solid ecosystem are encouraged to consider privacy-related design choices as per W3C Privacy Principles [PRIVACY-PRINCIPLES].

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

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

The decision to include or exclude any information (e.g., storage, inbox) in a WebID Profile served from a Solid storage lies with the Agent controlling the WebID (or the URI owner). A URI allocated to a WebID in a Solid storage does not imply that the WebID is the storage owner. Owners of a WebID hosted from Solid storage are encouraged to consider information related to themselves that could be readable from other resources in the storage, even if that information (e.g., storage, inbox) is not part of the WebID Profile itself (see Storage Owner and URI Ownership and Self-describing Resources.)

Accessibility Considerations

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.1 [DPUB-ARIA-1.1].; 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].

Internationalization Considerations

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.

Security and Privacy Review

This section is non-normative.

These questions provide an overview of security and privacy considerations for this specification as guided by [SECURITY-PRIVACY-QUESTIONNAIRE].

What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?: There are no known security impacts of the features in this specification.
Do features in your specification expose the minimum amount of information necessary to enable their intended uses?: Yes.
How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?: Access to a resource is only granted to authorized agents. HTTP request content can contain any data including that which identifies or refers to the user of the application. Relevant permissions for storing personal data that applications include is extended by the client to the server. In this process, applications are encouraged to consider aspects such as designing trustable user interfaces and using identity appropriately in context, while also taking into account other relevant factors, including obtaining meaningful consent where relevant or necessary.
How do the features in your specification deal with sensitive information?: The features do not require obtaining or exposing sensitive information.
Do the features in your specification introduce new state for an origin that persists across browsing sessions?: No.
Do the features in your specification expose information about the underlying platform to origins?: No.
Does this specification allow an origin to send data to the underlying platform?: No. Resources are described within the framework of HTTP, where some kinds of resources are required to be RDF documents. Servers might be able to redirect to other resources, e.g., the https: URLs to file:, data:, or blob: URLs, but no behaviour is defined by this specification.
Do features in this specification allow an origin access to sensors on a user’s device: No.
What data do the features in this specification expose to an origin? Please also document what data is identical to data exposed by other features, in the same or different contexts.: No detail about another origin’s state is exposed. As the association between a resource and its auxiliary resource is at the discretion of the server, they can be on different origins (URI Origin). When a server participates in the CORS protocol [FETCH], HTTP requests from different origins may be allowed. This feature does not add any new attack surface above and beyond normal CORS requests, so no extra mitigation is deemed necessary.
Do features in this specification enable new script execution/loading mechanisms?: No.
Do features in this specification allow an origin to access other devices?: No.
Do features in this specification allow an origin some measure of control over a user agent’s native UI?: No.
What temporary identifiers do the features in this specification create or expose to the web?: None.
How does this specification distinguish between behaviour in first-party and third-party contexts?: Inapplicable.
How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?: No different than browser’s 'normal' state.
Does this specification have both "Security Considerations" and "Privacy Considerations" sections?: Yes, in Security Considerations and Privacy Considerations.
Do features in your specification enable origins to downgrade default security protections?: No.
How does your feature handle non-"fully active" documents?: Inapplicable.

Societal Impact Review

This section is non-normative.

These questions provide an overview of ethical considerations and societal impact as guided by [SOCIETAL-IMPACT-QUESTIONNAIRE].

What kinds of activities do you anticipate your specification becoming a critical part of?: ..
What kinds of activities could your specification become a part of that you are not designing for?: ..
What risks do you see in features of your specification being misused, or used differently from how you intended?: ..
Can users of the Web Platform choose not to use features of your specification?: ..
What groups of people are excluded from using features of your specification?: ..
What effect may features of your specification have on minority groups?: ..
What are the power dynamics at play in implementations of your specification?: ..
What points of centralization does your feature bring to the web platform?: ..
To what extent do the features in your specification impact the natural environment?: ..
What is the expected lifetime of your specification feature(s)?: ..
Have you completed the Security & Privacy Self-review Questionnaire?: Yes, in Security Considerations and Privacy Considerations.

Changelog

This section is non-normative.

This document is based on Solid Protocol, Version 0.11.0. A list of issues addressed, a diff from Solid Protocol, Version 0.11.0 to this latest version, as well as a detailed log of changes are available.

The following summary of editorial, substantive, and registry changes are classified using the W3C Process Document Classes of Changes [W3C-PROCESS]:

Changes since Solid Protocol, Version 0.11.0
Change Class	Subject	Description
1	Document	Amend broken links, style sheets, or invalid markup.
2	Document	Amend language and document details.
2	#protect-sensitive-information	Add advisement for protecting sensitive information.
4	#server-last-modified-includes	Add requirement for server to include the Last-Modified header field.
1 No changes to text content 2 Corrections that do not affect conformance 3 Corrections that do not add new features 4 New features 5 Changes to the contents of a registry table

Changes since earlier versions of the Solid Protocol are detailed in the changes section of the previous version of the Solid Protocol.

Acknowledgements

Thanks to Tim Berners-Lee for inventing HTTP, URI, and HTML, without which none of this would exist.

The Community Group gratefully acknowledges the work that led to the creation of this specification, and extends sincere appreciation to those individuals that worked on technologies and specifications that deeply influenced our work.

The Community Group would like to thank the following individuals for their useful comments, both large and small, that have led to changes to this specification over the years:

Aaron Coburn
Abdurrahman Ghanem
Alain Bourgeois
Alan Jenkins
Alexandre Bourlier
Amy Guy
Andreas Kuckartz
Andrei Sambra
Andrew Wittrock
André Jaenisch
Angelo Veltens
Arne Hassel
Ashraf Aboulnaga
Auke van Slooten
Avi Flax
Beatriz Esteves
Ben Peachey
Benjamin Goering
Benoît Alessandroni
Christoph Braun
Cristian Vasquez
Daniel Friedman
Davi Ottenheimer
David Faveris
Dmitri Zagidulin
Dörthe Arndt
elf Pavlik
Emelia Smith
Emmet Townsend
Eric Prud'hommeaux
Essam Mansour
Evan Prodromou
Fabian Cook
Frederick Gibson
Geoff Ford
George Svarovsky
Gordana Halavanja
Graham Klyne
Gregory Todd Williams
Harshvardhan Pandit
Henry Story
Herbert Van de Sompel
Hindia M. Mohammed
humont
Ian Davis
Ian Jacobs
Jackson Morgan
Jacopo Scazzosi
Jakub Klímek
Jan Schill
Jarlath Holleran
Jean Jordaan
Jeff Zucker
Jeffry Waters
jibe-b
Joachim Van Herwegen
Joep Meindertsma
Jon Richter
Jonas Smedegaard
Jordan Shurmer
Jos De Roo
Joseph Guillaume
Justin Bingham
Jørn Wildt
Kevin Howard
Kingsley Idehen
Kjetil Kjernsmo
Leo Sauermann
lin onetwo
Maged Zereba
Manu Sporny
Markus Sabadello
Martynas Jusevičius
Matthias Evering
Matthieu Bosquet
Max Dor
Maxime Lecoq
Melvin Carvalho
Michael Herman
Michael L. Nelson
Michael Thornburgh
Michiel de Jong
Miel Vander Sande
Mike Adams
Mitzi László
mrkvon
Nicola Greco
Nicolas Mondada
Nicolas Seydoux
Noel De Martin
Otto-AA
Pat McBennett
Patrick Hochstenbach
Paul Friedman
Pete Edwards
Petra Jaros
phtyson
Pierre-Antoine Champin
Pieter Colpaert
QuadrupleA
Rahul Gupta
Reese Hodge
Reto Gmür
Ross Horne
Ruben Taelman
Ruben Verborgh
Rui Zhao
Samu Lang
Sander Van Dooren
Sandro Hawke
Sarven Capadisli
Sebastian Lasse
Simon Steyskal
Sjoerd van Groning
surilindur
Sylvain Le Bon
Ted Thibodeau Jr
Tim Berners-Lee
Timea Turdean
Timothy Holborn
Tobias Käfer
Tom Gallivan
Tom Haegemans
Vincent Tunru
Virginia Balseiro
Wes Turner
WhyINeedToFillUsername
Wouter Termont
Yvo Brevoort
Zoggy
దామోదర

References

Normative References

[ACP]: Access Control Policy. Matthieu Bosquet. W3C Solid Community Group. 18 May 2022. Version 0.9.0. URL: https://solidproject.org/TR/acp
[DC-TERMS]: Dublin Core Metadata Terms, version 1.1. DCMI Usage Board. DCMI. 11 October 2010. DCMI Recommendation. URL: http://dublincore.org/documents/2010/10/11/dcmi-terms/
[FETCH]: Fetch Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://fetch.spec.whatwg.org/
[IANA-MEDIA-TYPES]: Media Types. IANA. URL: https://www.iana.org/assignments/media-types/
[JSON-LD11]: JSON-LD 1.1. Gregg Kellogg; Pierre-Antoine Champin; Dave Longley. W3C. 16 July 2020. W3C Recommendation. URL: https://www.w3.org/TR/json-ld11/
[LDN]: Linked Data Notifications. Sarven Capadisli; Amy Guy. W3C. 2 May 2017. W3C Recommendation. URL: https://www.w3.org/TR/ldn/
[LDP]: Linked Data Platform 1.0. Steve Speicher; John Arwe; Ashok Malhotra. W3C. 26 February 2015. W3C Recommendation. URL: https://www.w3.org/TR/ldp/
[N3]: Notation3. William Van Woensel; Dörthe Arndt; Pierre-Antoine Champin; Dominik Tomaszuk; Gregg Kellogg. W3C. 19 March 2024. Draft Community Group Report. URL: https://w3c.github.io/N3/spec/
[POWDER-DR]: Protocol for Web Description Resources (POWDER): Description Resources. Phil Archer; Kevin Smith; Andrea Perego. W3C. 1 September 2009. W3C Recommendation. URL: https://www.w3.org/TR/powder-dr/
[RDF-SCHEMA]: RDF Schema 1.1. Dan Brickley; Ramanathan Guha. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf-schema/
[RDF11-CONCEPTS]: RDF 1.1 Concepts and Abstract Syntax. Richard Cyganiak; David Wood; Markus Lanthaler. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf11-concepts/
[RFC2119]: Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
[RFC3986]: Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL: https://datatracker.ietf.org/doc/html/rfc3986
[RFC4918]: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV). L. Dusseault, Ed. IETF. June 2007. Proposed Standard. URL: https://datatracker.ietf.org/doc/html/rfc4918
[RFC5023]: The Atom Publishing Protocol. J. Gregorio, Ed.; B. de hOra, Ed.. IETF. October 2007. Proposed Standard. URL: https://datatracker.ietf.org/doc/html/rfc5023
[RFC5789]: PATCH Method for HTTP. L. Dusseault; J. Snell. IETF. March 2010. Proposed Standard. URL: https://httpwg.org/specs/rfc5789.html
[RFC6454]: The Web Origin Concept. A. Barth. IETF. December 2011. Proposed Standard. URL: https://datatracker.ietf.org/doc/html/rfc6454
[RFC6455]: The WebSocket Protocol. I. Fette; A. Melnikov. IETF. December 2011. Proposed Standard. URL: https://datatracker.ietf.org/doc/html/rfc6455
[RFC6570]: URI Template. J. Gregorio; R. Fielding; M. Hadley; M. Nottingham; D. Orchard. IETF. March 2012. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc6570
[RFC6892]: The 'describes' Link Relation Type. E. Wilde. IETF. March 2013. Informational. URL: https://datatracker.ietf.org/doc/html/rfc6892
[RFC8174]: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc8174
[RFC8288]: Web Linking. M. Nottingham. IETF. October 2017. Proposed Standard. URL: https://httpwg.org/specs/rfc8288.html
[RFC9110]: HTTP Semantics. R. Fielding, M. Nottingham, J. Reschke, Eds. IETF. June 2022. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc9110
[RFC9111]: HTTP Caching. R. Fielding, M. Nottingham, J. Reschke, Eds. IETF. June 2022. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc9111
[RFC9112]: HTTP/1.1. R. Fielding, M. Nottingham, J. Reschke, Eds. IETF. June 2022. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc9112
[RFC9113]: HTTP/2. M. Thomson, C. Benfield, Eds. IETF. June 2022. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc9113
[SOLID-NOTIFICATIONS-PROTOCOL]: Solid Notifications Protocol. Sarven Capadisli. W3C Solid Community Group. 12 May 2024. Draft Community Group Report, Version 0.3.0. URL: https://solidproject.org/TR/notifications-protocol
[SOLID-OIDC]: SOLID-OIDC. Aaron Coburn; elf Pavlik; Dmitri Zagidulin. W3C Solid Community Group. 28 March 2022. Version 0.1.0. URL: https://solidproject.org/TR/oidc
[SPARQL11-QUERY]: SPARQL 1.1 Query. Steve Harris; Andy Seaborne; Eric Prud'hommeaux. W3C. 21 March 2013. W3C Recommendation. URL: https://www.w3.org/TR/sparql11-query/
[Turtle]: RDF 1.1 Turtle. Eric Prud'hommeaux; Gavin Carothers. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/turtle/
[W3C-HTML]: HTML. W3C. 28 January 2021. W3C Recommendation. URL: https://www.w3.org/TR/html/
[WAC]: Web Access Control. Sarven Capadisli. W3C Solid Community Group. 12 May 2024. Draft Community Group Report, Version 1.0.0. URL: https://solidproject.org/TR/wac
[WEBARCH]: Architecture of the World Wide Web, Volume One. Ian Jacobs; Norman Walsh. W3C. 15 December 2004. W3C Recommendation. URL: https://www.w3.org/TR/webarch/
[WEBID]: WebID 1.0. Andrei Sambra; Stéphane Corlosquet. W3C WebID Community Group. 5 March 2014. W3C Editor’s Draft. URL: https://www.w3.org/2005/Incubator/webid/spec/identity/

Informative References

[ATAG20]: Authoring Tool Accessibility Guidelines (ATAG) 2.0. Jan Richards; Jeanne F Spellman; Jutta Treviranus. W3C. 24 September 2015. W3C Recommendation. URL: https://www.w3.org/TR/ATAG20/
[COGA-USABLE]: Making Content Usable for People with Cognitive and Learning Disabilities. Lisa Seeman-Horwitz; Rachael Bradley Montgomery; Steve Lee; Ruoxi Ran. W3C. 29 April 2021. W3C Working Group Note. URL: https://www.w3.org/TR/coga-usable/
[DPUB-ARIA-1.0]: Digital Publishing WAI-ARIA Module 1.1. Matt Garrish; Tzviya Siegman. W3C. 27 February 2024. W3C Candidate Recommendation Snapshot. URL: https://www.w3.org/TR/dpub-aria-1.1/
[GRAPHICS-ARIA-1.0]: WAI-ARIA Graphics Module. Amelia Bellamy-Royds; Joanmarie Diggs; Michael Cooper. W3C. 2 October 2018. W3C Recommendation. URL: https://www.w3.org/TR/graphics-aria-1.0/
[PRIVACY-PRINCIPLES]: Privacy Principles. Robin Berjon; Jeffrey Yasskin. W3C. 18 May 2024. W3C Group Draft Note. URL: https://www.w3.org/TR/privacy-principles/
[SECURITY-PRIVACY-QUESTIONNAIRE]: Self-Review Questionnaire: Security and Privacy. Theresa O'Connor; Peter Snyder. W3C. 16 December 2021. W3C Group Note. URL: https://www.w3.org/TR/security-privacy-questionnaire/
[SOCIETAL-IMPACT-QUESTIONNAIRE]: Self-Review Questionnaire: Societal Impact. Amy Guy. W3C. 09 February 2023. W3C Draft TAG Finding. URL: https://w3ctag.github.io/societal-impact-questionnaire/
[SOLID-WEBSOCKETS-API]: Solid WebSockets API. Nicola Greco; Dmitri Zagidulin; Ruben Verborgh. W3C Solid Community Group. 17 June 2020. Unofficial Draft. URL: https://github.com/solid/solid-spec/blob/master/api-websockets.md
[UAAG20]: User Agent Accessibility Guidelines (UAAG) 2.0. James Allan; Greg Lowney; Kimberly Patch; Jeanne F Spellman. W3C. 15 December 2015. W3C Note. URL: https://www.w3.org/TR/UAAG20/
[WAI-ARIA-1.2]: Accessible Rich Internet Applications (WAI-ARIA) 1.2. Joanmarie Diggs; James Nurthen; Michael Cooper; Carolyn MacLeod. W3C. 6 June 2023. W3C Recommendation. URL: https://www.w3.org/TR/wai-aria-1.2/
[WCAG-3.0]: W3C Accessibility Guidelines (WCAG) 3.0. Jeanne F Spellman; Alastair Campbell; Kevin White; Rachael Bradley Montgomery; Charles Adams. W3C. 16 May 2024. W3C Working Draft. URL: https://www.w3.org/TR/wcag-3.0/
[ETHICAL-WEB-PRINCIPLES]: W3C TAG Ethical Web Principles. Daniel Appelquist; Hadley Beeman; Amy Guy. W3C. 19 March 2024. W3C Group Draft Note. URL: https://www.w3.org/TR/ethical-web-principles/
[W3C-PROCESS]: W3C Process Document. Elika J. Etemad / fantasai; Florian Rivoal; W3C Process Community Group. 3 November 2023. URL: https://www.w3.org/policies/process/
[WEBID-TLS]: WebID Authentication over TLS. Henry Story; Stéphane Corlosquet; Andrei Sambra. W3C WebID Community Group. W3C Editor's Draft. URL: https://www.w3.org/2005/Incubator/webid/spec/tls/