diff --git a/.travis.yml b/.travis.yml new file mode 100644 index 00000000..aa44e084 --- /dev/null +++ b/.travis.yml @@ -0,0 +1,25 @@ +sudo: false +language: python +python: + - "3.7" + +install: + - pushd /tmp + - git clone https://github.com/tabatkins/bikeshed.git --depth 1 + - pip install --editable bikeshed + - bikeshed update + - popd + +script: + - ./build + +before_deploy: + - rm .gitignore + +deploy: + provider: pages + skip_cleanup: true + github_token: $GITHUB_TOKEN + keep_history: true + on: + branch: master diff --git a/2021/protocol-20211217.test.html b/2021/protocol-20211217.test.html new file mode 100644 index 00000000..3a29686d --- /dev/null +++ b/2021/protocol-20211217.test.html @@ -0,0 +1,1402 @@ + + + + + Solid Protocol + + + + + + + + +
+
+ +
+
+ +
+
+

Solid Protocol

+

Version 0.9.0, 2021-12-17

+ +
+ More details about this document + +
+
This version
+
https://solidproject.org/TR/2021/protocol-20211217
+
+ +
+
Original resource
+
https://solidproject.org/TR/protocol
+
+ +
+
Editor’s draft
+
https://solidproject.org/ED/protocol
+
+ +
+
TimeMap
+
https://solidproject.org/TR/protocol.timemap
+
+ +
+
Editors
+
Sarven Capadisli
+ +
Tim Berners-Lee
+ +
Ruben Verborgh
+ +
Kjetil Kjernsmo
+
+ +
+
Contributors
+
Justin Bingham
+ +
Dmitri Zagidulin
+ +
Aaron Coburn
+
+ +
+
Published
+
+
+ +
+
Modified
+
+
+ +
+
Repository
+
GitHub
+
Issues
+
+ +
+
Language
+
English
+
+ +
+
License
+
MIT License
+
+ +
+
Document Status
+
Published
+
+ +
+
Resource State
+
Memento
+
+ +
+
In Reply To
+
Solid Origin
+
+ +
+
Policy
+
+
+
Rule
+
Offer
+
Unique Identifier
+
https://solidproject.org/TR/protocol#document-policy-offer
+
Target
+
https://solidproject.org/TR/protocol
+
Permission
+
+
+
Assigner
+
W3C Solid Community Group
+
Action
+
+ +
+
+
+
+
+
+
+ +

MIT License. Copyright © 2019–2021 W3C Solid Community Group.

+ +
+
+

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 Version 0.9.0. 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 Version 0.9.0 does not imply endorsement by the W3C Membership. 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.

+ +

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.

+ +

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.

+ + + +
+
data pod
+
A data pod is a place for storing documents, with mechanisms for controlling who can access what.
+ +
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 [RFC7231].
+ +
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 data storage. An owner is identified by a URI, and implicitly has control over all data in a storage. An owner is first set at storage provisioning time and can be changed.
+ +
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
PrefixNamespaceDescription
rdfhttp://www.w3.org/1999/02/22-rdf-syntax-ns#[rdf-schema]
ldphttp://www.w3.org/ns/ldp#[LDP]
solidhttp://www.w3.org/ns/solid/terms#Solid Terms
pimhttp://www.w3.org/ns/pim/space#Workspace Ontology
aclhttp://www.w3.org/ns/auth/acl#ACL Ontology
dctermshttp://purl.org/dc/terms/[DC-TERMS]
stathttp://www.w3.org/ns/posix/statPOSIX File Status
+
+
+ +
+

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.

+ +
+

HTTP Server

+
+

Servers MUST conform to HTTP/1.1 Message Syntax and Routing [RFC7230] and HTTP/1.1 Semantics and Content [RFC7231]. Servers SHOULD conform to HTTP/2 [RFC7540].

+ +

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.

+ +

Servers MUST conform to HTTP/1.1 Conditional Requests [RFC7232]. Servers SHOULD conform to HTTP/1.1 Caching [RFC7234]. Servers MAY conform to HTTP/1.1 Range Requests [RFC7233].

+ +

Servers MUST conform to HTTP/1.1 Authentication [RFC7235]. 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 reject PUT, POST and PATCH requests without the Content-Type header with a status code of 400. [Source]

+
+
+ +
+

HTTP Client

+
+

Clients MUST conform to HTTP/1.1 Message Syntax and Routing [RFC7230] and HTTP/1.1 Semantics and Content [RFC7231]. Clients MAY conform to HTTP/2 [RFC7540].

+ +

Clients MAY conform to HTTP/1.1 Conditional Requests [RFC7232]. Clients MAY conform to HTTP/1.1 Caching [RFC7234]. Clients MAY conform to HTTP/1.1 Range Requests [RFC7233].

+ +

Clients MUST conform to HTTP/1.1 Authentication [RFC7235] if it needs to access resources requiring authentication (see WebID). 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 in PUT, POST and PATCH requests [RFC7231]. [Source]

+
+
+
+
+ +
+

Uniform Resource Identifier

+
+
+

Note: Storage Owner and URI Ownership

+
+

This specification does not describe the relationship between a Solid 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 may want to use the 410 status code.

+
+
+
+
+
+
+ +
+

Resources

+
+
+

Storage

+
+

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

+ +

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

+ +

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

+ +

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

+ +

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

+ +

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

+ +

[Source] [Source]

+ +

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

+ +

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

+ +
+

Note: Trust Between Owners

+
+

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

+
+
+ +

[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 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. 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 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 would indicate the same date and time.

+ +
+
Note: Contained Resource Metadata Considerations
+
+

The generation of contained resource metadata may 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.

+ +

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

+ +

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

+ +
+

Note: 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.

+
+
+ +

This specification defines the following types of auxiliary resources:

+ + + +

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

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
Auxiliary TypeLink RelationDefinitions
Web Access Controlacl[WAC]
Description Resourcedescribedby[LDP]
+
+

The possibility of using URIs as relation types interchangeably or as alternate to the tokens above are under consideration:

+ +
    +
  • http://www.w3.org/ns/auth/acl#accessControl
    • +
  • https://www.w3.org/ns/iana/link-relations/relation#acl
    • +
  • https://www.w3.org/ns/iana/link-relations/relation#describedby
    • +
  • https://www.w3.org/ns/iana/link-relations/relation#describes
    • +
+ +

Issue

+
+
+ +
+

Web Access Control

+
+

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

+
+
+ +
+

Description Resource

+
+

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

+ +

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

+ +

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

+ +

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

+
+
+
+
+
+
+ +
+

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 (URI Slash Semantics).

+ +

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

+ +

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

+ +
+

Note: 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 [RFC7231] for clients to read resources or to determine communication options. [Source]

+ +

When responding to authorized requests:

+ +

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

+ +

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

+ +

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

+ +

[Source] [Source]

+
+
+ +
+

Writing Resources

+
+

Servers MUST support the HTTP PUT, POST and PATCH methods [RFC7231]. [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 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. [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 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 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 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 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.

+
+ +
+

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 value of the Accept-Patch header [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:

+ +
    +
  1. Start from the RDF dataset in the target document, or an empty RDF dataset if the target resource does not exist yet.
    2. +
  2. If ?conditions is non-empty, find all (possibly empty) variable mappings such that all of the resulting triples occur in the dataset.
    3. +
  3. If no such mapping exists, or if multiple mappings exist, the server MUST respond with a 409 status code. [Source]
    4. +
  4. The resulting variable mapping is propagated to the ?deletions and ?insertions formulae to obtain two sets of resulting triples.
    5. +
  5. 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]
    6. +
  6. The triples resulting from ?deletions are to be removed from the RDF dataset.
    7. +
  7. 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.
    8. +
  8. 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.
    9. +
+
+ +
+

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 [RFC7231]. [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 HTTP response header Allow in response to requests to these resources [RFC7231]. [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 [RFC7231]. For example, the server could remove membership triples referring to the deleted resource, perform additional cleanup tasks for resources it knows are no longer referenced or have not been accessed for some period of time, and so on.

+ +

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

+ +

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

+
+
+ +
+

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

+
+
+ +
+

Live Update

+
+
+

WebSockets

+
+

For real-time collaborative communication between client and server about changes affecting a resource, this Solid Protocol uses the WebSocket API [W3C-HTML] and the WebSocket Protocol.

+ +

Servers SHOULD implement the Solid WebSockets API [SOLID-WEBSOCKETS-API].

+ +

Clients SHOULD implement the Solid WebSockets API [SOLID-WEBSOCKETS-API].

+ +

The following is non-normative.

+ +

The Solid WebSockets API (Unofficial Draft) has been the common protocol for many years. That draft does not include an authentication mechanism, and therefore the Protocol will transition to a new design. The new design is currently at Solid Notifications Protocol [SOLID-NOTIFICATIONS-PROTOCOL]. It is planned to include both security through authentication, and also common formats with other forms of real-time notification in the Solid ecosystem.

+ +

Both client and server implementations should provide the existing protocol, and should transition to providing both protocols as the new one becomes available..

+ +

The future directions of the protocol include moving from a simple one-bit notification that a resource has changed, requiring the client to reload the resource, to adding PATCH information in the notification so the client can calculate the new state immediately.

+
+
+
+
+ +
+

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 headers, 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 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 [RFC7231].

+ +
+

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-* headers as specified in the CORS protocol [FETCH]. In particular, the server 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 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-* headers themselves). A server 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, server 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). Servers 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 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

+
+
+

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, and applies the authorization conditions on requested operations. Authorizations are described using the ACL ontology to express and determine access privileges of a requested resource. Applications can discover authorization rules associated with a given resource, and to control such rules, as directed by an agent.

+ +

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

+ +

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

+ +

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

+ +

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 urged to seek the advice of security professionals when implementing mission critical systems using the technology outlined in this specification.

+ +

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

+ +

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

+ +

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

+ +

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

+ +

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

+
+
+ +
+

Privacy Considerations

+
+

This section is non-normative.

+ +

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

+ +
+

Identifiable Information

+
+

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

+
+
+
+
+ +
+

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.0 [DPUB-ARIA-1.0]. To support structured graphics such as charts, graphs, technical drawings and scientific diagrams, to assistive technologies in order improve accessibility of graphics or diagrams through detailed annotations, it is encouraged to follow the WAI-ARIA Graphics Module [GRAPHICS-ARIA-1.0].

+ +

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

+ +

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

+
+
+ +
+

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?
+
..
+ +
Do features in your specification expose the minimum amount of information necessary to enable their intended uses?
+
..
+ +
How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?
+
..
+ +
How do the features in your specification deal with sensitive information?
+
..
+ +
Do the features in your specification introduce new state for an origin that persists across browsing sessions?
+
..
+ +
Do the features in your specification expose information about the underlying platform to origins?
+
..
+ +
Does this specification allow an origin to send data to the underlying platform?
+
..
+ +
Do features in this specification allow an origin access to sensors on a user’s device?
+
..
+ +
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.
+
..
+ +
Do features in this specification enable new script execution/loading mechanisms?
+
..
+ +
Do features in this specification allow an origin to access other devices?
+
..
+ +
Do features in this specification allow an origin some measure of control over a user agent’s native UI?
+
..
+ +
What temporary identifiers do the features in this specification create or expose to the web?
+
..
+ +
How does this specification distinguish between behaviour in first-party and third-party contexts?
+
..
+ +
How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?
+
..
+ +
Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
+
..
+ +
Do features in your specification enable origins to downgrade default security protections?
+
..
+ +
How does your feature handle non-"fully active" documents?
+
..
+
+
+
+ +
+

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 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 result in increased power consumption or emissions?
+
..
+ +
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.
+
+
+
+
+
+ +
+

References

+
+
+

Normative References

+
+
+
[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. Dörthe Arndt; William Van Woensel;Dominik Tomaszuk; Gregg Kellogg. W3C. 5 September 2021. Draft Community Group Report. URL: https://w3c.github.io/N3/spec/
+
[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
+
[RFC3864]
+
Registration Procedures for Message Header Fields. G. Klyne; M. Nottingham; J. Mogul. IETF. September 2004. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc3864
+
[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
+
[RFC7230]
+
Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7230.html
+
[RFC7231]
+
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7231.html
+
[RFC7232]
+
Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7232.html
+
[RFC7233]
+
Hypertext Transfer Protocol (HTTP/1.1): Range Requests. R. Fielding, Ed.; Y. Lafon, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7233.html
+
[RFC7234]
+
Hypertext Transfer Protocol (HTTP/1.1): Caching. R. Fielding, Ed.; M. Nottingham, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7234.html
+
[RFC7235]
+
Hypertext Transfer Protocol (HTTP/1.1): Authentication. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7235.html
+
[RFC7540]
+
Hypertext Transfer Protocol Version 2 (HTTP/2). M. Belshe; R. Peon; M. Thomson, Ed.. IETF. 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://datatracker.ietf.org/doc/html/rfc8174
+
[RFC8288]
+
Web Linking. M. Nottingham. IETF. October 2017. Proposed Standard. URL: https://httpwg.org/specs/rfc8288.html
+
[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
+
[SOLID-OIDC]
+
SOLID-OIDC. Aaron Coburn; elf Pavlik; Dmitri Zagidulin. W3C Solid Community Group. 13 December 2021. W3C Editor's Draft. URL: https://solid.github.io/solid-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. 11 July 2021. Draft. 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. 11 December 2020. W3C Working Draft. URL: https://www.w3.org/TR/coga-usable/
+
[DPUB-ARIA-1.0]
+
Digital Publishing WAI-ARIA Module 1.0. Matt Garrish; Tzviya Siegman; Markus Gylling; Shane McCarron. W3C. 14 December 2017. W3C Recommendation. URL: https://www.w3.org/TR/dpub-aria-1.0/
+
[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/
+
[SECURITY-PRIVACY-QUESTIONNAIRE]
+
Self-Review Questionnaire: Security and Privacy. Theresa O'Connor; Peter Snyder. W3C. 23 March 2021. W3C Note. URL: https://www.w3.org/TR/security-privacy-questionnaire/
+
[SOCIETAL-IMPACT-QUESTIONNAIRE]
+
Self-Review Questionnaire: Societal Impact. Amy Guy. W3C. 13 Dec 2021. W3C Draft TAG Finding. URL: https://w3ctag.github.io/societal-impact-questionnaire/
+
[SOLID-NOTIFICATIONS-PROTOCOL]
+
Solid Notifications Protocol. Aaron Coburn; Sarven Capadisli. W3C Solid Community Group. 16 December 2021. W3C Editor’s Draft. URL: https://solid.github.io/notifications/protocol
+
[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. W3C. 2 March 2021. W3C Candidate Recommendation. URL: https://www.w3.org/TR/wai-aria-1.2/
+
[WCAG-3.0]
+
W3C Accessibility Guidelines (WCAG) 3.0. Jeanne F Spellman; Rachael Bradley Montgomery; Shawn Lauriat; Michael Cooper. W3C. 21 January 2021. W3C Working Draft. URL: https://www.w3.org/TR/wcag-3.0/
+
[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/
+
+
+
+
+
+
+
+
+ + + + + + diff --git a/2022/acp-20220513.html b/2022/acp-20220513.html new file mode 100644 index 00000000..84d7f5ac --- /dev/null +++ b/2022/acp-20220513.html @@ -0,0 +1,3018 @@ + + + + + + + Access Control Policy (ACP) + + + + + +
+ +

Access Control Policy (ACP)

+

+ Version 0.9.0, + +

+
+ More details about this document +
+
This version
+
+ https://solidproject.org/TR/2022/acp-20220513 +
+
Latest version
+
+ https://solidproject.org/TR/acp +
+
Editor's draft
+
+ https://solid.github.io/authorization-panel/acp-specification +
+
Source repository
+
+ https://github.com/solid/authorization-panel +
+
Issue tracking
+
+ https://github.com/solid/authorization-panel/issues +
+
License
+
+ MIT License +
+
Editors
+
+ +
+
+
+ +
+ +
+

Abstract

+

+ This document defines the + Access Control Policy Language (ACP). + ACP is a language for describing, controlling and granting access to + resources. +

+
+ +
+

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

+
+ +
+
+

+ 1. Introduction +

+

+ This section introduces ACP with an overview of key terminology, an + explanation of the conventions used in this document, example graphs + to illustrate basic concepts of resource access description and + validation, a diagram representing the main elements of the ACP data + model, and a non-normative RDF representation of the ACP ontology. +

+ +
+

+ 1.1. RDF terminology +

+

+ This document uses the terms + resource, + property, + RDF vocabulary, + namespace, + namespace IRI, + namespace prefix, + RDF graph, + RDF triple, + IRI, + literal, + blank node, + node + of an RDF graph, + RDF term, + subject, + predicate, and + object + of RDF triples, + datatype, and + IRI + and + literal term equality + as defined in RDF 1.1 Concepts and Abstract Syntax + RDF11 CONCEPTS. +

+
+ +
+

+ 1.2. RDF vocabularies and namespace IRIs +

+

+ This document uses the following RDF vocabularies and corresponding + namespace prefix bindings: +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PrefixNamespace
+ acp: + + http://www.w3.org/ns/solid/acp# +
acl: + http://www.w3.org/ns/auth/acl# +
ex: + https://example.org/ +
ldp: + http://www.w3.org/ns/ldp# +
rdf: + http://www.w3.org/1999/02/22-rdf-syntax-ns# +
rdfs: + http://www.w3.org/2000/01/rdf-schema# +
owl: + http://www.w3.org/2002/07/owl# +
+
+ +
+

+ 1.3. ACP terminology +

+

This section is non-normative.

+ +
+
Context graph
+
+ Context graphs describe the + attributes of resource access instances. Those attributes can be + matched to sets of conditions defined in the form of an + authorization graph + in order to determine Access Modes granted over resources. +
+
Authorization graph
+
+ Authorization graphs + authoritatively define the conditions for granting Access Modes + over resources through Access Controls, Policies and Matchers. The + result of applying an authorization graph to a described instance + of resource access is an + access grant graph. +
+
Access grant graph
+
+ Access grant graphs describe + sets of granted access modes over resources in the context of + resource access instances. +
+
+
+ +
+

+ 1.4. Example graphs +

+

This section is non-normative.

+ +

+ Throughout this document, color-coded boxes contain the RDF + representation of example context graphs, authorization graphs, and + access grant graphs serialized in Turtle. Those graphs use a mix of + IRIs and blank nodes where applicable to better show the range of + possible representations. +

+ +

+ The following example + context graph describes an + instance of resource access and could be translated as: + "Bob is trying to access resource X using client application Y + with his identity asserted by identity provider Z.". +

+ + 
+# This box contains a context graph
+# It describes an instance of resource access  
+
+[]
+  acp:agent ex:Bob ;
+  acp:target ex:resourceX ;
+  acp:client ex:ClientApplicationY ;
+  acp:issuer ex:IdentityProviderZ .
+
+ +

+ The following example + authorization graph + authoritatively defines the conditions of access to resource X and + could be translated as: + "Access to resource X is mandated by one Access Control that + applies one Policy which allows access mode + acl:Read when the agent matcher is satisfied that + Alice or Bob are the agent trying to access resource X.". +

+ + 
+# This box contains an authorization graph
+# It describes the conditions required for accessing a resource  
+
+[]
+  a acp:AccessControlResource ;
+  acp:resource ex:resourceX ;
+  acp:accessControl [
+    a acp:AccessControl ;
+    acp:apply [
+      a acp:Policy ;
+      acp:allow acl:Read ;
+      acp:anyOf [
+        a acp:AgentMatcher ;
+        acp:agent ex:Alice, ex:Bob ;
+      ]
+    ]
+  ] .
+
+ +

+ The following example + access grant graph is + the result of applying the previous example authorization graph + which defines access to resource X to the previous example context + graph which describes an instance of access to target resource X. + Bob is matched as the context agent and since it defines no further + restrictions, the policy allowing acl:Read is + satisfied. The following access grant graph could be read as: + "The access mode acl:Read is granted to Bob whom + requested access to resource X using client application Y and + whose identity was asserted by identity provider Z.". +

+ + 
+# This box contains an access grant graph
+# It describes in context the granted access over a resource  
+
+[]
+  acp:grant acl:Read ;
+  acp:context [
+    acp:agent ex:Bob ;
+    acp:target ex:resourceX ;
+    acp:client ex:ClientApplicationY ;
+    acp:issuer ex:IdentityProviderZ ;
+  ] .
+
+
+ +
+

+ 1.5. Data model +

+

This section is non-normative.

+

The following diagram illustrates the main elements of ACP.

+ ACP Data Model +
+ +
+

+ 1.6. Ontology +

+

+ All terms defined by the Access Control Policy Language are present + in a non-normative RDF representation of the + ACP ontology serialized in turtle. +

+
+
+ +
+

+ 2. Conformance +

+

+ All assertions, diagrams, examples, pseudocode 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 defined in + RFC 2119. +

+ +

+ Only UPPERCASE usage of the key words defined in RFC 2119 have special + meanings, as per + RFC 8174. +

+
+ +
+

+ 3. Context Graph +

+

+ This section introduces the ACP terms used to describe instances of + resource access. +

+ +
+

+ 3.1. Context +

+
+
+ acp:Context +
+
+ Instances of the Context class + describe instances of resource access. +
+ +
+ acp:attribute +
+
+ The attribute properties + defined by ACP describe + instances + of + resource + access. +
+ +
+ acp:target +
+
+ The target + attribute + describes requested resources. +
+ +
+ acp:mode +
+
+ The mode + attribute + describes requested modes of access. +
+ +
+ acp:agent +
+
+ The agent + attribute + describes agents initiating requests. +
+ +
+ acp:creator +
+
+ The creator + attribute + describes creators of requested resources. +
+ +
+ acp:owner +
+
+ The owner + attribute + describes owners of requested resources. +
+ +
+ acp:client +
+
+ The client + attribute + describes client applications used to request resources. +
+ +
+ acp:issuer +
+
+ The issuer + attribute + describes identity providers used to assert the identity of agents + requesting resources. +
+ +
+ acp:time +
+
+ The time + attribute + describes times of resource access requests. +
+ +
+ acp:vc +
+
+ The vc + attribute + describes verifiable credentials presented as part of resource + access requests. +
+
+ +
+

+ 3.1.1. Example Context +

+ +

+ The following example context graph denotes instances of resource + access over resource X initiated by Bob. +

+ + 
+[]
+  a acp:Context ;
+  acp:agent ex:Bob .  
+
+ +

+ The following example context graph denotes instances of resource + access over resource X initiated by Bob using client application Y + where Bob's identity is asserted by identity provider Z, Bob is + the owner of resource X, and Alice is the creator of resource X. +

+ + 
+ex:contextA
+  acp:agent ex:Bob ;
+  acp:target ex:resourceX ;
+  acp:owner ex:Bob ;
+  acp:creator ex:Alice ;
+  acp:client ex:ClientApplicationY ;  
+  acp:issuer ex:IdentityProviderZ .
+
+ +

+ The following example context graph denotes instances of resource + access where client application X or client application Y are used + and identity is asserted by identity provider Z. +

+ + 
+[
+  acp:client ex:ClientApplicationX, ex:ClientApplicationY ;  
+  acp:issuer ex:IdentityProviderZ ;
+] .
+
+
+
+ +
+

+ 3.2. Context extensibility +

+

+ Sub-properties of acp:attribute can be created to fit + the specific resource access description requirements of + applications. +

+ +
+

+ 3.2.1. Example Context extension +

+

+ Let's imagine a property ex:tag defined as a an + rdfs:subPropertyOf acp:attribute that would describe + tags applied to requested resources. If such a property was + defined, then the following example context graph would denote + instances of resource access over resource X initiated by Bob + where resource X was tagged ex:Music and + ex:FavouriteRecord. +

+ + 
+ex:contextA
+  acp:agent ex:Bob ;
+  acp:target ex:resourceX ;
+  ex:tag ex:Music, ex:FavouriteRecord .  
+
+
+
+
+ +
+

+ 4. Authorization Graph +

+

+ This section introduces the ACP terms used to control access to + resources. +

+ +
+

+ 4.1. Access Control Resource +

+
+
+ acp:AccessControlResource +
+
+ Instances of the + Access Control Resource (ACR) + class connect resources to their Access Controls. +
+ +
+ acp:resource +
+
+ The resource property connects + ACRs + to + resources + they control. It is the inverse of + acp:accessControlResource. +
+ +
+ acp:accessControl +
+
+ The access control property + connects + ACRs + to + Access Controls. +
+ +
+ acp:memberAccessControl +
+
+ The + member access control property + transitively connects + ACRs + of member resources to + Access Controls. +
+
+ +
+

+ 4.1.1. Example Access Control Resource +

+

+ The following example authorization graph means that access to + resource X is controlled by both Access Controls B and C; + furthermore, access to members of resource X is controlled by + Access Control D. +

+ + 
+ex:accessControlResourceA
+  acp:resource ex:resourceX ;
+  acp:accessControl ex:accessControlB, ex:accessControlC ;  
+  acp:memberAccessControl ex:accessControlD .
+
+
+
+ +
+

+ 4.2. Access Control +

+
+
+ acp:AccessControl +
+
+ Instances of the + Access Control class connect + Access Control Resources to their Policies. +
+ +
+ acp:apply +
+
+ The apply property connects + Access Controls + to the + Policies + they apply to resources. +
+
+ +
+

+ 4.2.1. Example Access Control +

+

+ The following example authorization graph means that access to + resource X is controlled by Policy C. +

+ + 
+ex:accessControlResourceA
+  acp:resource ex:resourceX ;  
+  acp:accessControl [
+    acp:apply ex:policyC ;
+  ] .
+
+ +

+ The following two example authorization graphs mean that access to + resource X is controlled by Policy D and Policy E. +

+ + 
+ex:accessControlResourceA
+  acp:resource ex:resourceX ;
+  acp:accessControl ex:accessControlB, ex:accessControlC .  
+
+ex:accessControlB
+  acp:apply ex:policyD .
+
+ex:accessControlC
+  acp:apply ex:policyE .
+
+ + 
+[]
+  acp:resource ex:resourceX ;
+  acp:accessControl ex:accessControlF .  
+
+ex:accessControlF
+  acp:apply ex:policyD, ex:policyE .
+
+
+
+ +
+

+ 4.3. Policy +

+
+
+ acp:Policy +
+
+ Instances of the Policy class + connect Access Controls to allowed and denied Access Modes as well + as sets of Matchers describing instances of resource access. +
+ +
+ acp:allow +
+
+ The allow property connects + Policies + to the + Access Modes + they allow if satisfied. +
+ +
+ acp:deny +
+
+ The deny property connects + Policies + to the + Access Modes + they deny if satisfied. +
+ +
+ acp:allOf +
+
+ The all of property connects + Policies + to the set of + Matchers + all of which MUST must be satisfied for the Policy to be + satisfied. +
+ +
+ acp:anyOf +
+
+ The any of property connects + Policies + to the set of + Matchers + at least one of which MUST be satisfied for the Policy to be + satisfied. +
+ +
+ acp:noneOf +
+
+ The none of property connects + Policies + to the set of + Matchers + all of which MUST NOT be satisfied for the Policy to be satisfied. +
+
+ +
+

+ 4.3.1. Example Policy +

+

+ The following example authorization graph means that Policy A will + allow Read for instances of resource access satisfying both + Matcher B and Matcher C. +

+ + 
+ex:policyA
+  acp:allow acl:Read ;
+  acp:allOf ex:matcherB, ex:matcherC .  
+
+ +

+ The following example authorization graph means that a Policy will + deny Write for instances of resource access satisfying either + Matcher B or Matcher C. +

+ + 
+[]
+  acp:deny acl:Write ;
+  acp:anyOf ex:matcherB, ex:matcherC .  
+
+ +

+ The following example authorization graph means that Reading and + Writing resource X will be allowed for instances of resource + access satisfying Matcher A and not Matcher B. +

+ + 
+[
+  acp:resource ex:resourceX ;
+  acp:accessControl [
+    acp:apply [
+      acp:allow acl:Read, acl:Write ;  
+      acp:anyOf ex:matcherA ;
+      acp:noneOf ex:matcherB ;
+    ] ;
+  ] ;
+] .
+
+
+
+ +
+

+ 4.4. Matcher +

+
+
+ acp:Matcher +
+
+ Instances of the Matcher class + are descriptions of matching resource access Contexts. To satisfy + a Matcher, every described resource access attribute must match + the resource access Context. +
+ +
+ acp:agent +
+
+ The agent attribute used in a Matcher defines a set of agents, at + least one of which MUST match the resource access Context for the + agent restriction to be satisfied. +
+ +
+ acp:PublicAgent +
+
+ The Public Agent named + individual used in an agent restriction means that the restriction + is always satisfied. +
+ +
+ acp:AuthenticatedAgent +
+
+ The Authenticated Agent named + individual used in an agent restriction means that any agent in + the Context satisfies the restriction. +
+ +
+ acp:CreatorAgent +
+
+ The Creator Agent named + individual used in an agent restriction means that the restriction + is satisfied if the Context contains an agent that is also a + creator. +
+ +
+ acp:OwnerAgent +
+
+ The Owner Agent named + individual used in an agent restriction means that the restriction + is satisfied if the Context contains an agent that is also an + owner. +
+ +
+ acp:client +
+
+ The client attribute used in a Matcher defines a set of clients, + at least one of which MUST match the resource access Context for + the client restriction to be satisfied. +
+ +
+ acp:PublicClient +
+
+ The Public Client named + individual used in a client restriction means that the restriction + is always satisfied. +
+ +
+ acp:issuer +
+
+ The issuer attribute used in a Matcher defines a set of issuers, + at least one of which MUST match the resource access Context for + the issuer restriction to be satisfied. +
+ +
+ acp:PublicIssuer +
+
+ The Public Issuer named + individual used in an issuer restriction means that the + restriction is always satisfied. +
+ +
+ acp:time +
+
+ The time attribute used in a Matcher defines a set of times, at + least one of which MUST match the resource access Context for the + time restriction is satisfied. +
+ +
+ acp:vc +
+
+ The vc attribute used in a Matcher defines a set of types of + Verifiable Credentials + (VC), at least one of which MUST match the resource access Context + for the vc restriction to be satisfied. +
+ +
+ acp:AlwaysSatisfiedRestriction +
+
+ Defined instances of the + Always Satisfied Restriction + class are used in Matcher restrictions to indicate that the + restriction is always satisfied. The default behaviour of a + Matcher is to not be satisfied, so this is the only way to make a + Matcher always satisfied. +
+
+ +
+

+ 4.4.1. Example Matcher +

+

+ The following example authorization graph means that Agent Matcher + A will be satisfied when either Alice or the owner of the access + controlled resource are requesting access. +

+ + 
+ex:matcherA
+  a acp:Matcher ;
+  acp:agent ex:Alice, acp:OwnerAgent .  
+
+ +

+ The following example authorization graph means that the defined + Client Matcher will be satisfied when matched against a context + graph where the client used to access the access controlled + resource is client B. +

+ + 
+[
+  a acp:Matcher ;
+  acp:client ex:clientB ;  
+] .
+
+ +

+ The following example authorization graph means that Issuer + Matcher A will be satisfied when matched against a context graph + where the identity provider used to assert the identity of the + agent requesting access to the access controlled resource is + issuer B. +

+ + 
+ex:matcherA
+  a acp:Matcher ;
+  acp:issuer ex:issuerB .  
+
+ +

+ The following example authorization graph means that the defined + Verifiable Credentials (VC) Matcher A will be satisfied when + matched against a context graph where one of the presented + verifiable credentials is an instance of credential B, is valid + and has been issued to the agent requesting the resource. +

+ + 
+[]
+  a acp:Matcher ;
+  acp:vc ex:credentialB .  
+
+ +

+ The following example authorization graph means that matcher A + will be satisfied only if either Alice or Bob are the agent + requesting resource access and their identity was asserted by + Identity Provider B. +

+ + 
+ex:matcherA
+  a acp:Matcher ;
+  acp:agent ex:Bob, ex:Alice ;
+  acp:issuer ex:IdentityProviderB .  
+
+ +

+ The following example authorization graph means that the defined + matcher will be satisfied only if Alice, whose identity is + asserted by Identity Provider B, is the agent requesting resource + access and is doing so presenting a VC that is a verified instance + of credential A issued to Alice. +

+ + 
+[
+  a acp:Matcher ;
+  acp:agent ex:Alice ;
+  acp:issuer ex:IdentityProviderB ;  
+  acp:vc ex:credentialA ;
+] .
+
+ +

+ The following example authorization graph means that Policy A + denies Read and Write access to all clients but client C and + policy B allows read to all clients. If Policy A and B control + access to a resource, then anyone using client C will have Read + access to that resource. +

+ + 
+ex:policyA
+  acp:deny acl:Read, acl:Write ;
+  acp:anyOf [
+    acp:client acp:PublicClient ;  
+  ] ,
+  acp:noneOf [
+    acp:client ex:clientC
+  ] .
+
+ex:policyB
+  acp:allow acl:Read ;
+  acp:anyOf [
+    acp:client:PublicClient ;
+  ] .
+
+
+
+ +
+

+ 4.5. Matcher extensibility +

+

+ All sub-properties of acp:attribute correspond + implicitly to their own type of Matcher restriction. If applications + support additional sub-properties of + acp:attribute other than the ones defined by ACP, then, + they MUST also implement corresponding matching algorithms. +

+ +
+

+ 4.5.1. Example Matcher extension +

+

+ Given the property ex:tag previously defined in the + example context extension + as a an rdfs:subPropertyOf acp:attribute that + describes tags applied to requested resources; the following + example context graph would mean that Policy 1 allows Read and is + satisfied by instances of resource access initiated over a + resource that was tagged ex:FavouriteRecord or + ex:Wishlist. +

+ + 
+ex:policy1
+  acp:allow acl:Read ;
+  acp:anyOf [
+    ex:tag ex:FavouriteRecord, ex:Wishlist ;  
+  ] .
+
+
+
+
+ +
+

+ 5. Access Grant Graph +

+

+ This section introduces the ACP terms used to grant access to + resources. +

+ +
+

+ 5.1. Access Grant +

+
+
+ acp:AccessGrant +
+
+ Instances of the + Access Grant class define sets + of Access Modes granted in particular Contexts. +
+ +
+ acp:context +
+
+ The context property connects + Access Grants + to the + Contexts + in which they're given. +
+ +
+ acp:grant +
+
+ The grant property connects + Access Grants + to the + Access Modes + they grant. +
+
+ +
+

+ 5.1.1. Example Access Grant +

+

+ The following example access grant graph means that Access Modes + acl:Read and acl:Write have been granted + to Bob for accessing resource X. +

+ + 
+[]
+  acp:grant acl:Read, acl:Write ;  
+  acp:context [
+    acp:agent ex:Bob ;
+    acp:target ex:resourceX ;
+  ] .
+
+
+
+ +
+

+ 5.2. Access Mode extensibility +

+
+
+ acp:AccessMode +
+
+ The ACP specification does not define specific Access Modes. + Instead, any Access Mode granted is an instance of the + Access Mode class. Access Modes + and their granularity can be tailored to the needs of an + application. Access Modes defined in other vocabularies (for example ACL) can also be used. +
+
+ +
+

+ 5.2.1. Example Access Mode +

+

+ The following example access grant graph means that + acl:Read and ex:Delete are Access Modes; + furthermore, it means that acl:Read and + ex:Delete have been granted to Bob for accessing + resource X. +

+ + 
+[]
+  acp:grant acl:Read, ex:Delete ;  
+  acp:context [
+    acp:agent ex:Bob ;
+    acp:target ex:resourceX ;
+  ] .
+
+
+
+
+ +
+

+ 6. Access Control resolution +

+

+ This section introduces the ACP access control resolution algorithm + for resolving permissions to access controlled resources. +

+ +
+

+ 6.1. Effective Policies +

+

+ Both the acp:resource property and its inverse + acp:accessControlResource MUST be taken into account in + determining the Access Control Resources controlling access to + resources. +

+ +

+ All Access Controls controlling member resources access via the + acp:memberAccessControl property MUST be included in + the set of Access Controls linked as + acp:accessControl in the effective authorization graph + of a resource. +

+ +

+ The set of Policies controlling access to a resource MUST contain + all Policies that are linked to a resource via the + property path + acp:accessControlResource/acp:accessControl/acp:apply + SPARQL11 QUERY. +

+ +
+

+ 6.1.1. Effective Policies example +

+

+ The following example authorization graph means that access to + resource X is controlled by both Access Controls B and C, access + to resource X is therefore controlled by Policy E and Policy F. + The member Access Controls are not taken into account at this + level. Member Access Control D will be included in the effective + authorization graph of resource X's members' ACRs both as an + Access Control and a member Access Control. Therefore, Policy G + will be part of the set of effective Policies controlling access + to resource X's members and transitively to further members of + member resources. +

+ + 
+  ex:accessControlResourceA
+    acp:resource ex:X ;
+    acp:accessControl ex:accessControlB, ex:accessControlC ;  
+    acp:memberAccessControl ex:accessControlD .
+
+  ex:accessControlB
+    acp:apply ex:PolicyE .
+
+  ex:accessControlC
+    acp:apply ex:PolicyF .
+
+  ex:accessControlD
+    acp:apply ex:PolicyG .
+
+
+
+ +
+

+ 6.2. Granted Access Modes +

+
+

+ An Access Mode MUST be granted over a resource if and only if in + the set of Policies controlling access to it: +

+
    +
  • A satisfied policy allows the Access Mode; and
    • +
  • No satisfied policy denies the Access Mode.
    • +
+
+ +
+

+ 6.2.1. Granted Access Modes example +

+

+ The following example authorization graph means that access to + resource X is controlled by Policy B and Policy C. Depending on + the satisfaction of Policies B and C, different access modes will + be granted. +

+
    +
  • + If only Policy B is satisfied, then Access Modes + acl:Read and acl:Write will be + granted. +
    • +
  • + If both Policy B and Policy C are satisfied, then only Access + Mode acl:Read will be granted. +
    • +
  • + If only Policy C is satisfied, then no Access Mode will be + granted. +
    • +
+ + 
+[
+  acp:resource ex:X ;
+  acp:accessControl [
+    acp:apply ex:policyB, ex:policyC ;  
+  ]
+] .
+
+ex:policyB
+  acp:allow acl:Read, acl:Write .
+
+ex:policyC
+  acp:deny acl:Write .
+
+
+ +
+

+ 6.2.2. Granted Access Modes pseudocode +

+ 
function grantAccessModes(policies, context) {
+  const allow = new Set, deny = new Set
+
+  // Gather allowed and denied access modes from satisfied policies  
+  for (const policy of policies)
+      if (isSatisfiedPolicy(policy, context)) {
+          for (const mode of policy.allow)
+              allow.add(mode)
+
+          for (const mode of policy.deny)
+              deny.add(mode)
+      }
+
+  // Deny overrules allow.
+  for (const mode of deny)
+      allow.delete(mode)
+
+  return allow
+}
+
+
+
+ +
+

+ 6.3. Satisfied Policy +

+

+ Policies are satisfied via the acp:allOf, + acp:anyOf and acp:noneOf properties which + act respectively as intersection, union and exclusion operators. +

+ +
+

A Policy MUST be considered satisfied if and only if:

+
    +
  • + It references at least one Matcher via a + acp:allOf or acp:anyOf property; and +
    • +
  • + At least one Matcher it references matches the given resource + access description; and +
    • +
  • + The acp:allOf, acp:anyOf and + acp:noneOf of conditions it defines are satisfied. +
    • +
+
+ +

+ Given that the acp:noneOf condition excludes matches, a + policy without a satisfied acp:allOf or + acp:anyOf condition is never satisfied. +

+ +
+

+ 6.3.1. Satisfied Policy example +

+

+ The following example authorization graph means that access to + resource X is controlled by Policy A. Depending on the + satisfaction of Matchers B, C, D, E and F, Policy A will be + satisfied or not. +

+
    +
  • + If either Matcher B or Matcher C are not satisfied, then Policy + A will not be satisfied. +
    • +
  • + If both Matcher D and Matcher E are not satisfied, then Policy A + will not be satisfied. +
    • +
  • + If Matcher F is satisfied, then Policy A will not be satisfied. +
    • +
  • + If both Matcher B and Matcher C are satisfied, and, either + Matcher D or Matcher E are satisfied, and, Matcher F is not + satisfied, then Policy A will be satisfied. +
    • +
+ + 
+[
+  acp:resource ex:X ;
+  acp:accessControl [
+    acp:apply ex:policyA ;
+  ]
+] .
+
+ex:policyA
+  acp:allOf ex:matcherB, ex:matcherC ;  
+  acp:anyOf ex:matcherD, matcherE ;
+  acp:noneOf ex:matcherF .
+
+
+ +
+

+ 6.3.2. Satisfied Policy pseudocode +

+ 
function isSatisfiedPolicy(policy, context) {
+  // If any 'none of' matcher is satisfied then the policy is not satisfied.
+  for (const matcher of policy.noneOf)
+      if (isSatisfiedMatcher(matcher, context))
+          return false
+
+  // If any 'all of' matcher is not satisfied then the policy is not satisfied.  
+  for (const matcher of policy.allOf)
+      if (!isSatisfiedMatcher(matcher, context))
+          return false
+
+  // If any 'any of' matcher is satisfied then the policy is satisfied.
+  for (const matcher of policy.anyOf)
+      if (isSatisfiedMatcher(matcher, context))
+          return true
+
+  // At this point there are
+  // - no satisfied 'none of' matchers,
+  // - no unsatisfied 'all of' matchers and
+  // - no satisfied 'any of' matchers.
+
+  // Hence, the policy is satisfied if it has
+  // - an 'all of' condition and
+  // - no 'any of' condition.
+  return policy.allOf.size !== 0 && policy.anyOf.size === 0
+}
+
+
+
+ +
+

+ 6.4. Satisfied Matcher +

+

+ The default operation of matching is based on + IRI + and + literal term equality + as defined in the RDF 1.1 Concepts and Abstract Syntax + RDF11 CONCEPTS. +

+ +
+

A Matcher MUST be considered satisfied if and only if:

+
    +
  • It defines at least one matching attribute; and
    • +
  • + All the attributes defined find a match in the given resource + access description. +
    • +
+
+ +
+

+ 6.4.1. Satisfied Matcher example +

+
+ +
+

+ 6.4.2. Satisfied Matcher pseudocode +

+
+
+
+ +
+

+ 7. Server implementation +

+

+ This section introduces ACP server capability and ACR discovery, as + well as ACR editing, and ACP resources lifecycle management. +

+ +
+

+ 7.1. Capability discovery +

+

+ When a server wants to enable applications to discover its ACP + capabilities, it MUST do so via link headers. +

+ +

+ The server MUST advertise the access modes it supports by responding + to HTTP OPTIONS requests over ACP access control resources including + a Link header with the rel value of + http://www.w3.org/ns/solid/acp#grant and the full URI + of an access mode as link target [RFC8288]. The server MUST produce + one such Link header for each access mode it supports. +

+ +

+ For example, if a server supports the ACL read, write and append + access modes, it should advertise it by responding to HTTP OPTIONS + requests over ACP access control resources including three link + headers with rel value of + http://www.w3.org/ns/solid/acp#grant and respectively + targets of http://www.w3.org/ns/auth/acl#Read, + http://www.w3.org/ns/auth/acl#Write and + http://www.w3.org/ns/auth/acl#Append in order to make + it explicit which set of access modes are understood and relevant + when editing ACP policies. +

+ +

+ The server MUST advertise the request attributes it supports by + responding to HTTP OPTIONS requests over ACP access control + resources including a Link header with the rel value of + http://www.w3.org/ns/solid/acp#attribute and the full + URI of an acp attribute as link target [RFC8288]. The server MUST + produce one such Link header for each request attribute it supports. +

+ +

+ For example, if a server supports the ACP agent, client and issuer + request attributes, it should advertise it by responding to HTTP + OPTIONS requests over ACP access control resources including three + link headers with rel value of + http://www.w3.org/ns/solid/acp#attribute and + respectively targets of + http://www.w3.org/ns/solid/acp#agent, + http://www.w3.org/ns/solid/acp#client and + http://www.w3.org/ns/solid/acp#issuer in order to make + it explicit which set of request attributes are understood and + relevant when editing ACP matchers. +

+
+ +
+

+ 7.2. ACR discovery +

+

+ When a server wants to enable applications to discover the ACP + access control resource associated with a given resource, the server + MUST advertise the ACP access control resource that is associated + with that resource by responding to HTTP requests over the resource + including a Link header with the rel value + of acl (acl Link Relation) and the ACP access control + resource as the link target [RFC8288]. The same mechanism is used in + Web Access Control resource discovery. +

+

+ A server responding to an HTTP request over an ACP access control + resource MUST include a Link header with the + rel value of type and the + acp:AccessControlResource URI as link target. +

+
+ +
+

+ 7.3. ACR editing +

+

+ The owner of a storage is implicitly considered an owner of all the + resources in the URI space corresponding to the storage. +

+ +

+ An owner of a resource is implicitly considered an owner of its + associated Access Control Resource. +

+ +

+ An owner of an Access Control Resource implicitly has full read and + write access over it. +

+ +

+ To add or remove an Access Control from an ACR, agents that are not + owners of said ACR need read and write access to both the ACR itself + and to the resource where said Access Control is defined. In other + words, Access Controls defined as part of a separate resource can be + protected from unwanted edits in and out of ACRs by setting adequate + permissions in their own ACR. +

+
+ +
+

+ 7.4. Resource management +

+

Access Control Resources MUST be server managed.

+ +

+ There is a one to one relationship between a resource and its + authoritative source of access control. Therefore, when resources + are created or deleted, the corresponding ACRs MUST be created or + deleted accordingly. +

+ +

+ Access Controls, Policies and Matchers MAY all be access controlled + via their own ACR. +

+ +

+ As long as an Access Control, a Policy or a Matcher is referenced by + an ACR, it MUST not be deleted. However, if such consistency failed + to be enforced or if an Access Control, a Policy or a Matcher is not + accessible for any other reason, then access permissions resolution + MUST fail to its default behaviour of only granting read and write + access to the invalid ACR to its owners; read and write access MUST + not be implicitly granted to a resource whose access control + resolution fails, even to owners of that resource. +

+
+
+
+ +
+

Acknowledgements

+

This section is non-normative.

+
+ +
+

References

+ +
+

Normative references

+
+
[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. +
+
[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. +
+
[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/. +
+
+
+ +
+

Informative references

+
+
+ + + + + + diff --git a/2022/acp-code-20220513.css b/2022/acp-code-20220513.css new file mode 100644 index 00000000..a24f809d --- /dev/null +++ b/2022/acp-code-20220513.css @@ -0,0 +1,289 @@ +.highlight table td { + padding: 5px; +} + +.highlight table pre { + margin: 0; +} + +.highlight .cm { + color: #999988; + font-style: italic; +} + +.highlight .cp { + color: #999999; + font-weight: bold; +} + +.highlight .c1 { + color: #999988; + font-style: italic; +} + +.highlight .cs { + color: #999999; + font-weight: bold; + font-style: italic; +} + +.highlight .c, +.highlight .ch, +.highlight .cd, +.highlight .cpf { + color: #999988; + font-style: italic; +} + +.highlight .err { + color: #a61717; + background-color: #e3d2d2; +} + +.highlight .gd { + color: #000000; + background-color: #ffdddd; +} + +.highlight .ge { + color: #000000; + font-style: italic; +} + +.highlight .gr { + color: #aa0000; +} + +.highlight .gh { + color: #999999; +} + +.highlight .gi { + color: #000000; + background-color: #ddffdd; +} + +.highlight .go { + color: #888888; +} + +.highlight .gp { + color: #555555; +} + +.highlight .gs { + font-weight: bold; +} + +.highlight .gu { + color: #aaaaaa; +} + +.highlight .gt { + color: #aa0000; +} + +.highlight .kc { + color: #000000; + font-weight: bold; +} + +.highlight .kd { + color: #000000; + font-weight: bold; +} + +.highlight .kn { + color: #000000; + font-weight: bold; +} + +.highlight .kp { + color: #000000; + font-weight: bold; +} + +.highlight .kr { + color: #000000; + font-weight: bold; +} + +.highlight .kt { + color: #445588; + font-weight: bold; +} + +.highlight .k, +.highlight .kv { + color: #000000; + font-weight: bold; +} + +.highlight .mf { + color: #009999; +} + +.highlight .mh { + color: #009999; +} + +.highlight .il { + color: #009999; +} + +.highlight .mi { + color: #009999; +} + +.highlight .mo { + color: #009999; +} + +.highlight .m, +.highlight .mb, +.highlight .mx { + color: #009999; +} + +.highlight .sa { + color: #000000; + font-weight: bold; +} + +.highlight .sb { + color: #d14; +} + +.highlight .sc { + color: #d14; +} + +.highlight .sd { + color: #d14; +} + +.highlight .s2 { + color: #d14; +} + +.highlight .se { + color: #d14; +} + +.highlight .sh { + color: #d14; +} + +.highlight .si { + color: #d14; +} + +.highlight .sx { + color: #d14; +} + +.highlight .sr { + color: #009926; +} + +.highlight .s1 { + color: #d14; +} + +.highlight .ss { + color: #990073; +} + +.highlight .s, +.highlight .dl { + color: #d14; +} + +.highlight .na { + color: #008080; +} + +.highlight .bp { + color: #999999; +} + +.highlight .nb { + color: #0086B3; +} + +.highlight .nc { + color: #445588; + font-weight: bold; +} + +.highlight .no { + color: #008080; +} + +.highlight .nd { + color: #3c5d5d; + font-weight: bold; +} + +.highlight .ni { + color: #800080; +} + +.highlight .ne { + color: #990000; + font-weight: bold; +} + +.highlight .nf, +.highlight .fm { + color: #990000; + font-weight: bold; +} + +.highlight .nl { + color: #990000; + font-weight: bold; +} + +.highlight .nn { + color: #555555; +} + +.highlight .nt { + color: #000080; +} + +.highlight .vc { + color: #008080; +} + +.highlight .vg { + color: #008080; +} + +.highlight .vi { + color: #008080; +} + +.highlight .nv, +.highlight .vm { + color: #008080; +} + +.highlight .ow { + color: #000000; + font-weight: bold; +} + +.highlight .o { + color: #000000; + font-weight: bold; +} + +.highlight .w { + color: #bbbbbb; +} + +.highlight { + background-color: #f8f8f8; +} diff --git a/2022/acp-data-model-20220513.svg b/2022/acp-data-model-20220513.svg new file mode 100644 index 00000000..8be693cc --- /dev/null +++ b/2022/acp-data-model-20220513.svg @@ -0,0 +1 @@ + diff --git a/2022/acp-main-20220513.css b/2022/acp-main-20220513.css new file mode 100644 index 00000000..f6421438 --- /dev/null +++ b/2022/acp-main-20220513.css @@ -0,0 +1,136 @@ +:root { + --lightest-yellow: hsl(47, 100%, 97%); + --lighter-yellow: hsl(47, 100%, 87%); + --light-yellow: hsl(47, 100%, 77%); + --light-green: #b6fdad; + --light-red: #ffdede; +} + +h1 { + font-size: 220%; + font-weight: bold; + margin: 0 0 .1em; +} + +header { + border-bottom: 1px solid; +} + +header li { + margin: 0; +} + +dl dd { + margin: 0 0 .5em 2em; +} + +dd ul { + padding: 0; +} + +dd li { + list-style: none; +} + +table { + border-collapse: collapse; + border-color: #000000; +} + +td, +th { + border-width: 1px; + border-style: solid; + padding: 0.4em 0.6em; +} + +.bibref::before { + content: "["; +} + +.bibref::after { + content: "]"; +} + +.heading { + position: relative; +} + +.self-link { + border: none; + font-size: 83%; + height: 2em; + left: calc(-1 * (3.5rem - 26px)); + opacity: .5; + position: absolute; + text-align: center; + top: 0; + transition: opacity .2s; + width: calc(3.5rem - 26px); +} + +.self-link:hover { + opacity: 1; +} + +.self-link::before { + content: "§"; +} + +.rfc2119 { + text-transform: lowercase; + font-style: normal; + color: #900; +} + +.example, +.pseudocode { + border: 1px solid #999; + margin-left: 0; + margin-top: 1.5em; + padding: 2em; +} + +.example::before, .pseudocode::before { + background: white; + border: 1px solid #bbb; + color: #666; + display: block; + font-family: sans-serif; + margin: -2em 0 1em -2em; + padding: 0.2em 2em; + text-transform: none; + width: 14em; +} + +.pseudocode::before { + content: "Example JavaScript code"; +} + +.example-context-graph { + background-color: var(--lightest-yellow); +} + +.example-context-graph::before { + content: "Example context graph"; +} + +.example-authorization-graph { + background-color: var(--lighter-yellow); +} + +.example-authorization-graph::before { + content: "Example authorization graph"; +} + +.example-access-grant-graph { + background-color: var(--light-yellow); +} + +.example-access-grant-graph::before { + content: "Example access grant graph"; +} + +.example-well-known::before { + content: "Example well known configuration"; +} diff --git a/2022/protocol-20221231.test.html b/2022/protocol-20221231.test.html new file mode 100644 index 00000000..3a35abfe --- /dev/null +++ b/2022/protocol-20221231.test.html @@ -0,0 +1,1596 @@ + + + + + Solid Protocol + + + + + + + + +
+
+ +
+
+ +
+
+

Solid Protocol

+ +

Version 0.10.0,

+ +
+ More details about this document + +
+
This version
+
https://solidproject.org/TR/2022/protocol-20221231
+
+ +
+
Latest published version
+
https://solidproject.org/TR/protocol
+
+ +
+
Previous version
+
https://solidproject.org/TR/2021/protocol-20211217
+
+ +
+
Editor’s draft
+
https://solidproject.org/ED/protocol
+
+ +
+
TimeMap
+
https://solidproject.org/TR/protocol.timemap
+
+ +
+
Editors
+
Sarven Capadisli
+ +
Tim Berners-Lee
+ +
Ruben Verborgh
+ +
Kjetil Kjernsmo
+
+ + +
+
Published
+
+
+ +
+
Modified
+
+
+ +
+
Repository
+
GitHub
+
Issues
+
+ +
+
Language
+
English
+
+ +
+
License
+
MIT License
+
+ +
+
Document Status
+
Published
+
+ +
+
Resource State
+
Memento
+
+ +
+
In Reply To
+
Solid Origin
+
+ +
+
Document Type
+
Article
+
+ +
+
Policy
+
+
+
Rule
+
Offer
+
Unique Identifier
+
https://solidproject.org/TR/protocol#document-policy-offer
+
Target
+
https://solidproject.org/TR/protocol
+
Permission
+
+
+
Assigner
+
W3C Solid Community Group
+
Action
+
+ +
+
+
+
+
+
+
+ +

MIT License. Copyright © 2019–2022 W3C Solid Community Group.

+ +
+
+

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 Version 0.10.0. 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 Version 0.10.0 does not imply endorsement by the W3C Membership. This document 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

+
+

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 [RFC7231].
+ +
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
PrefixNamespaceDescription
rdfhttp://www.w3.org/1999/02/22-rdf-syntax-ns#[rdf-schema]
ldphttp://www.w3.org/ns/ldp#[LDP]
solidhttp://www.w3.org/ns/solid/terms#Solid Terms
pimhttp://www.w3.org/ns/pim/space#Workspace Ontology
aclhttp://www.w3.org/ns/auth/acl#ACL Ontology
dctermshttp://purl.org/dc/terms/[DC-TERMS]
stathttp://www.w3.org/ns/posix/statPOSIX 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 [RFC7230] and [RFC7231] 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 [RFC7230], [RFC7231], 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.

+
+
+
+
+
+
+ +
+

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/1.1 Message Syntax and Routing [RFC7230] and HTTP/1.1 Semantics and Content [RFC7231]. Servers SHOULD conform to HTTP/2 [RFC7540].

+ +

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.

+ +

Servers MUST conform to HTTP/1.1 Conditional Requests [RFC7232]. Servers SHOULD conform to HTTP/1.1 Caching [RFC7234]. Servers MAY conform to HTTP/1.1 Range Requests [RFC7233].

+ +

Servers MUST conform to HTTP/1.1 Authentication [RFC7235]. 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 reject PUT, POST and PATCH requests without the Content-Type header with a status code of 400. [Source]

+
+
+ +
+

HTTP Client

+
+

Clients MUST conform to HTTP/1.1 Message Syntax and Routing [RFC7230] and HTTP/1.1 Semantics and Content [RFC7231]. Clients MAY conform to HTTP/2 [RFC7540].

+ +

Clients MAY conform to HTTP/1.1 Conditional Requests [RFC7232]. Clients MAY conform to HTTP/1.1 Caching [RFC7234]. Clients MAY conform to HTTP/1.1 Range Requests [RFC7233].

+ +

Clients MUST conform to HTTP/1.1 Authentication [RFC7235] if it needs to access resources requiring authentication (see WebID). 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 in PUT, POST and PATCH requests [RFC7231]. [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 may 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 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 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 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 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 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. 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 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 would indicate the same date and time.

+ +
+
Note: Contained Resource Metadata Considerations
+
+

The generation of contained resource metadata may 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:

+ + + +

Servers MUST advertise auxiliary resources associated with a subject resource by responding to HEAD and GET requests by including the HTTP Link header 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 with the rel parameter [RFC8288].

+ + + + + + + + + + + + + + + + + + + + + +
Auxiliary TypeLink RelationDefinitions
Web Access Controlacl[WAC]
Description Resourcedescribedby[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 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 an effective request URI’s type by examining the URI path ending (URI Slash Semantics).

+ +

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

+ +

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

+ +
+

Note: 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 [RFC7231] 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 headers that correspond to acceptable HTTP methods listed in Allow header 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 [RFC7231]. [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 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. [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 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 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 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 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.

+
+ +
+

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 value of the Accept-Patch header [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:

+ +
    +
  1. Start from the RDF dataset in the target document, or an empty RDF dataset if the target resource does not exist yet.
    2. +
  2. If ?conditions is non-empty, find all (possibly empty) variable mappings such that all of the resulting triples occur in the dataset.
    3. +
  3. If no such mapping exists, or if multiple mappings exist, the server MUST respond with a 409 status code. [Source]
    4. +
  4. The resulting variable mapping is propagated to the ?deletions and ?insertions formulae to obtain two sets of resulting triples.
    5. +
  5. 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]
    6. +
  6. The triples resulting from ?deletions are to be removed from the RDF dataset.
    7. +
  7. 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.
    8. +
  8. 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.
    9. +
+
+ +
+

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 [RFC7231]. [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 HTTP response header Allow in response to requests to these resources [RFC7231]. [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 [RFC7231]. 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 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]

+
+
+ +
+

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 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 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 headers, 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 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 [RFC7231].

+ +
+

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-* headers as specified in the CORS protocol [FETCH]. In particular, the server 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 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-* headers themselves). A server 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, servers 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). Servers 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 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 ACL 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 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.

+ +

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 urged to seek the advice of security professionals when implementing mission critical systems using the technology outlined in this specification.

+ +

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

+ +

Servers are strongly discouraged from assuming that HTTP request headers’ field-values are valid or non-malicious. Servers are strongly encouraged to sanitize requests before processing them or incorporating them in messages sent to others. Servers are encouraged to reject bad requests that conflict with this specification's normative requirements. Servers are encouraged to 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 discouraged from assuming that the user agent is a regular Web browser, even when requests contain familiar values in headers such as User-Agent or Origin. Such an assumption could lead to incorrect conclusions about the security model of the application making the request, since the request might actually come from a non-browser actor unaffected by browser security constraints.

+ +

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

+ +

Servers are encouraged to use TLS connections to protect the contents of requests and responses from eavesdropping and modification by third parties. Unsecured TCP connections without TLS may be used in testing environments or when the 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.

+ +
+

Identifiable Information

+
+

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

+
+
+
+
+ +
+

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.0 [DPUB-ARIA-1.0]. To support structured graphics such as charts, graphs, technical drawings and scientific diagrams, to assistive technologies in order improve accessibility of graphics or diagrams through detailed annotations, it is encouraged to follow the WAI-ARIA Graphics Module [GRAPHICS-ARIA-1.0].

+ +

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

+ +

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

+
+
+ +
+

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 payloads can contain any data including that which identifies or refers to the user of the application. Meaningful consent to any personal data that applications include is extended by the client to the server.
+ +
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.
+
+
+
+
+
+ +
+

Change Log

+
+

This section is non-normative.

+ +

The summary of editorial and substantive changes in this section are based on W3C Process Document Classes of Changes [W3C-PROCESS].

+ +

protocol-20221231 ← protocol-20211217

+ +
+

Changes from protocol-20211217 to this version

+
+ +
+
+
+
+ +
+

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. Dörthe Arndt; William Van Woensel;Dominik Tomaszuk; Gregg Kellogg. W3C. 5 September 2021. 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
+
[RFC3864]
+
Registration Procedures for Message Header Fields. G. Klyne; M. Nottingham; J. Mogul. IETF. September 2004. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc3864
+
[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
+
[RFC7230]
+
Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7230.html
+
[RFC7231]
+
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7231.html
+
[RFC7232]
+
Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7232.html
+
[RFC7233]
+
Hypertext Transfer Protocol (HTTP/1.1): Range Requests. R. Fielding, Ed.; Y. Lafon, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7233.html
+
[RFC7234]
+
Hypertext Transfer Protocol (HTTP/1.1): Caching. R. Fielding, Ed.; M. Nottingham, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7234.html
+
[RFC7235]
+
Hypertext Transfer Protocol (HTTP/1.1): Authentication. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7235.html
+
[RFC7540]
+
Hypertext Transfer Protocol Version 2 (HTTP/2). M. Belshe; R. Peon; M. Thomson, Ed.. IETF. 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://datatracker.ietf.org/doc/html/rfc8174
+
[RFC8288]
+
Web Linking. M. Nottingham. IETF. October 2017. Proposed Standard. URL: https://httpwg.org/specs/rfc8288.html
+
[SOLID-NOTIFICATIONS-PROTOCOL]
+
Solid Notifications Protocol. Sarven Capadisli. W3C Solid Community Group. 31 December 2022. Version 0.2.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. 5 July 2022. Version 1.0.0-cr-1. 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. 11 December 2020. W3C Working Draft. URL: https://www.w3.org/TR/coga-usable/
+
[DPUB-ARIA-1.0]
+
Digital Publishing WAI-ARIA Module 1.0. Matt Garrish; Tzviya Siegman; Markus Gylling; Shane McCarron. W3C. 14 December 2017. W3C Recommendation. URL: https://www.w3.org/TR/dpub-aria-1.0/
+
[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. 12 May 2022. 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. 23 March 2021. W3C Note. URL: https://www.w3.org/TR/security-privacy-questionnaire/
+
[SOCIETAL-IMPACT-QUESTIONNAIRE]
+
Self-Review Questionnaire: Societal Impact. Amy Guy. W3C. 13 Dec 2021. 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. W3C. 2 March 2021. W3C Candidate Recommendation. URL: https://www.w3.org/TR/wai-aria-1.2/
+
[WCAG-3.0]
+
W3C Accessibility Guidelines (WCAG) 3.0. Jeanne F Spellman; Rachael Bradley Montgomery; Shawn Lauriat; Michael Cooper. W3C. 21 January 2021. 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. 12 May 2022. W3C Group Draft Note. URL: https://www.w3.org/TR/security-privacy-questionnaire/
+
[W3C-PROCESS]
+
W3C Process Document. Elika J. Etemad / fantasai; Florian Rivoal; W3C Process Community Group. 2 November 2021. URL: https://www.w3.org/Consortium/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/
+
+
+
+
+
+
+
+
+ +

↑

+ + + + + + diff --git a/2022/protocol-20221231.test.html.meta$.ttl b/2022/protocol-20221231.test.html.meta$.ttl new file mode 100644 index 00000000..72a871bc --- /dev/null +++ b/2022/protocol-20221231.test.html.meta$.ttl @@ -0,0 +1 @@ +<> . diff --git a/ED/p.conformance.html b/ED/p.conformance.html new file mode 100644 index 00000000..1cc7b7f0 --- /dev/null +++ b/ED/p.conformance.html @@ -0,0 +1,1573 @@ + + + + + Solid Protocol + + + + + + + + +
+
+ +
+
+ +
+
+

Solid Protocol

+

Version 0.9.1 Editor’s Draft, 2022-11-05

+ +
+ More details about this document + +
+
This version
+
https://solidproject.org/ED/protocol
+
+ +
+
Latest version
+
https://solidproject.org/ED/protocol
+
+ +
+
Latest published version
+
https://solidproject.org/TR/protocol
+
+ +
+
Editors
+
Sarven Capadisli
+ +
Tim Berners-Lee
+ +
Ruben Verborgh
+ +
Kjetil Kjernsmo
+
+ +
+
Contributors
+
Justin Bingham
+ +
Dmitri Zagidulin
+ +
Aaron Coburn
+
+ +
+
Published
+
+
+ +
+
Modified
+
+
+ +
+
Repository
+
GitHub
+
Issues
+
+ +
+
Language
+
English
+
+ +
+
License
+
MIT License
+
+ +
+
Document Status
+
Editor’s Draft
+
+ +
+
In Reply To
+
Solid Origin
+
+ +
+
Policy
+
+
+
Rule
+
Offer
+
Unique Identifier
+
https://solidproject.org/TR/protocol#document-policy-offer
+
Target
+
https://solidproject.org/TR/protocol
+
Permission
+
+
+
Assigner
+
W3C Solid Community Group
+
Action
+
+ +
+
+
+
+
+
+
+ +

MIT License. Copyright © 2019–2022 W3C Solid Community Group.

+ +
+
+

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

+
+

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 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 [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 [RFC7231].
+ +
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
PrefixNamespaceDescription
rdfhttp://www.w3.org/1999/02/22-rdf-syntax-ns#[rdf-schema]
ldphttp://www.w3.org/ns/ldp#[LDP]
solidhttp://www.w3.org/ns/solid/terms#Solid Terms
pimhttp://www.w3.org/ns/pim/space#Workspace Ontology
aclhttp://www.w3.org/ns/auth/acl#ACL Ontology
dctermshttp://purl.org/dc/terms/[DC-TERMS]
stathttp://www.w3.org/ns/posix/statPOSIX 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.

+
+
+ +
+

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 [RFC7230] and [RFC7231] 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 [RFC7230], [RFC7231], and [FETCH] by defining behaviour in terms of fetching across the platform.
+
+
+
+ +
+

Specification Category

+
+

The Solid Protocol identifies the following Specification Category to distinguish the types of conformance: APIs, Notation/syntax, Set of events, Processor behaviour, Protocol.

+
+
+ +
+

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.

+
+
+
+
+
+
+ +
+

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/1.1 Message Syntax and Routing [RFC7230] and HTTP/1.1 Semantics and Content [RFC7231]. Servers SHOULD conform to HTTP/2 [RFC7540].

+ +

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.

+ +

Servers MUST conform to HTTP/1.1 Conditional Requests [RFC7232]. Servers SHOULD conform to HTTP/1.1 Caching [RFC7234]. Servers MAY conform to HTTP/1.1 Range Requests [RFC7233].

+ +

Servers MUST conform to HTTP/1.1 Authentication [RFC7235]. 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 reject PUT, POST and PATCH requests without the Content-Type header with a status code of 400. [Source]

+
+
+ +
+

HTTP Client

+
+

Clients MUST conform to HTTP/1.1 Message Syntax and Routing [RFC7230] and HTTP/1.1 Semantics and Content [RFC7231]. Clients MAY conform to HTTP/2 [RFC7540].

+ +

Clients MAY conform to HTTP/1.1 Conditional Requests [RFC7232]. Clients MAY conform to HTTP/1.1 Caching [RFC7234]. Clients MAY conform to HTTP/1.1 Range Requests [RFC7233].

+ +

Clients MUST conform to HTTP/1.1 Authentication [RFC7235] if it needs to access resources requiring authentication (see WebID). 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 in PUT, POST and PATCH requests [RFC7231]. [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 may 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 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 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 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 with rel="http://www.w3.org/ns/solid/terms#owner" targeting the URI of the owner in the response of HTTP HEAD or GET requests targeting the root container.

+ +
+

Note: Trust Between Owners

+
+

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

+
+
+ +

[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 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. 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 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 would indicate the same date and time.

+ +
+
Note: Contained Resource Metadata Considerations
+
+

The generation of contained resource metadata may 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.

+
+
+ +

This specification defines the following types of auxiliary resources:

+ + + +

Servers MUST advertise auxiliary resources associated with a subject resource by responding to HEAD and GET requests by including the HTTP Link header 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 with the rel parameter [RFC8288].

+ + + + + + + + + + + + + + + + + + + + + +
Auxiliary TypeLink RelationDefinitions
Web Access Controlacl[WAC]
Description Resourcedescribedby[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 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 an effective request URI’s type by examining the URI path ending (URI Slash Semantics).

+ +

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

+ +

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

+ +
+

Note: 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 [RFC7231] 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 headers that correspond to acceptable HTTP methods listed in Allow header value in response to HTTP GET, HEAD and OPTIONS requests.

+ +

[Source] [Source]

+
+
+ +
+

Writing Resources

+
+

Servers MUST support the HTTP PUT, POST and PATCH methods [RFC7231]. [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 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. [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 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 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 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 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.

+
+ +
+

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 value of the Accept-Patch header [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:

+ +
    +
  1. Start from the RDF dataset in the target document, or an empty RDF dataset if the target resource does not exist yet.
    2. +
  2. If ?conditions is non-empty, find all (possibly empty) variable mappings such that all of the resulting triples occur in the dataset.
    3. +
  3. If no such mapping exists, or if multiple mappings exist, the server MUST respond with a 409 status code. [Source]
    4. +
  4. The resulting variable mapping is propagated to the ?deletions and ?insertions formulae to obtain two sets of resulting triples.
    5. +
  5. 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]
    6. +
  6. The triples resulting from ?deletions are to be removed from the RDF dataset.
    7. +
  7. 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.
    8. +
  8. 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.
    9. +
+
+ +
+

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 [RFC7231]. [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 HTTP response header Allow in response to requests to these resources [RFC7231]. [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 [RFC7231]. 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 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]

+
+
+ +
+

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 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 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 implement the Solid Notifications Protocol [SOLID-NOTIFICATIONS-PROTOCOL]. +

+ +

+ Clients MUST implement the Solid Notifications Protocol[SOLID-NOTIFICATIONS-PROTOCOL]. +

+ +

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 headers, 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 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 [RFC7231].

+ +
+

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-* headers as specified in the CORS protocol [FETCH]. In particular, the server 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 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-* headers themselves). A server 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, servers 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). Servers 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 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

+
+
+

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, and applies the authorization conditions on requested operations. Authorizations are described using the ACL ontology to express and determine access privileges of a requested resource. Applications can discover authorization rules associated with a given resource, and to control such rules, as directed by an agent.

+ +

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

+ +

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

+ +

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

+ +

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 urged to seek the advice of security professionals when implementing mission critical systems using the technology outlined in this specification.

+ +

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

+ +

Servers are strongly discouraged from assuming that HTTP request headers’ field-values are valid or non-malicious. Servers are strongly encouraged to sanitize requests before processing them or incorporating them in messages sent to others. Servers are encouraged to reject bad requests that conflict with this specification's normative requirements. Servers are encouraged to 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 discouraged from assuming that the user agent is a regular Web browser, even when requests contain familiar values in headers such as User-Agent or Origin. Such an assumption could lead to incorrect conclusions about the security model of the application making the request, since the request might actually come from a non-browser actor unaffected by browser security constraints.

+ +

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

+ +

Servers are encouraged to use TLS connections to protect the contents of requests and responses from eavesdropping and modification by third parties. Unsecured TCP connections without TLS may be used in testing environments or when the 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.

+ +
+

Identifiable Information

+
+

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

+
+
+
+
+ +
+

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.0 [DPUB-ARIA-1.0]. To support structured graphics such as charts, graphs, technical drawings and scientific diagrams, to assistive technologies in order improve accessibility of graphics or diagrams through detailed annotations, it is encouraged to follow the WAI-ARIA Graphics Module [GRAPHICS-ARIA-1.0].

+ +

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

+ +

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

+
+
+ +
+

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?
+
..
+ +
Do features in your specification expose the minimum amount of information necessary to enable their intended uses?
+
..
+ +
How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?
+
..
+ +
How do the features in your specification deal with sensitive information?
+
..
+ +
Do the features in your specification introduce new state for an origin that persists across browsing sessions?
+
..
+ +
Do the features in your specification expose information about the underlying platform to origins?
+
..
+ +
Does this specification allow an origin to send data to the underlying platform?
+
..
+ +
Do features in this specification allow an origin access to sensors on a user’s device?
+
..
+ +
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.
+
..
+ +
Do features in this specification enable new script execution/loading mechanisms?
+
..
+ +
Do features in this specification allow an origin to access other devices?
+
..
+ +
Do features in this specification allow an origin some measure of control over a user agent’s native UI?
+
..
+ +
What temporary identifiers do the features in this specification create or expose to the web?
+
..
+ +
How does this specification distinguish between behaviour in first-party and third-party contexts?
+
..
+ +
How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?
+
..
+ +
Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
+
..
+ +
Do features in your specification enable origins to downgrade default security protections?
+
..
+ +
How does your feature handle non-"fully active" documents?
+
..
+
+
+
+ +
+

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 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 result in increased power consumption or emissions?
+
..
+ +
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.
+
+
+
+
+
+ +
+

Change Log

+
+

This section is non-normative.

+ +

The summary of editorial and substantive changes in this section are based on W3C Process Document Classes of Changes [W3C-PROCESS].

+ +

ED ← protocol-20211217

+ +
+

Changes from protocol-20211217 to this version

+
+ +
+
+
+
+ +
+

References

+
+
+

Normative References

+
+
+
[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. Dörthe Arndt; William Van Woensel;Dominik Tomaszuk; Gregg Kellogg. W3C. 5 September 2021. 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
+
[RFC3864]
+
Registration Procedures for Message Header Fields. G. Klyne; M. Nottingham; J. Mogul. IETF. September 2004. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc3864
+
[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
+
[RFC7230]
+
Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7230.html
+
[RFC7231]
+
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7231.html
+
[RFC7232]
+
Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7232.html
+
[RFC7233]
+
Hypertext Transfer Protocol (HTTP/1.1): Range Requests. R. Fielding, Ed.; Y. Lafon, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7233.html
+
[RFC7234]
+
Hypertext Transfer Protocol (HTTP/1.1): Caching. R. Fielding, Ed.; M. Nottingham, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7234.html
+
[RFC7235]
+
Hypertext Transfer Protocol (HTTP/1.1): Authentication. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7235.html
+
[RFC7540]
+
Hypertext Transfer Protocol Version 2 (HTTP/2). M. Belshe; R. Peon; M. Thomson, Ed.. IETF. 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://datatracker.ietf.org/doc/html/rfc8174
+
[RFC8288]
+
Web Linking. M. Nottingham. IETF. October 2017. Proposed Standard. URL: https://httpwg.org/specs/rfc8288.html
+
[SOLID-NOTIFICATIONS-PROTOCOL]
+
Solid Notifications Protocol. Aaron Coburn; Sarven Capadisli. W3C Solid Community Group. 09 May 2022. Version 0.1.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. 11 July 2021. Draft. 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. 11 December 2020. W3C Working Draft. URL: https://www.w3.org/TR/coga-usable/
+
[DPUB-ARIA-1.0]
+
Digital Publishing WAI-ARIA Module 1.0. Matt Garrish; Tzviya Siegman; Markus Gylling; Shane McCarron. W3C. 14 December 2017. W3C Recommendation. URL: https://www.w3.org/TR/dpub-aria-1.0/
+
[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. 12 May 2022. 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. 23 March 2021. W3C Note. URL: https://www.w3.org/TR/security-privacy-questionnaire/
+
[SOCIETAL-IMPACT-QUESTIONNAIRE]
+
Self-Review Questionnaire: Societal Impact. Amy Guy. W3C. 13 Dec 2021. 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. W3C. 2 March 2021. W3C Candidate Recommendation. URL: https://www.w3.org/TR/wai-aria-1.2/
+
[WCAG-3.0]
+
W3C Accessibility Guidelines (WCAG) 3.0. Jeanne F Spellman; Rachael Bradley Montgomery; Shawn Lauriat; Michael Cooper. W3C. 21 January 2021. 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. 12 May 2022. W3C Group Draft Note. URL: https://www.w3.org/TR/security-privacy-questionnaire/
+
[W3C-PROCESS]
+
W3C Process Document. Elika J. Etemad / fantasai; Florian Rivoal; W3C Process Community Group. 2 November 2021. URL: https://www.w3.org/Consortium/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/
+
+
+
+
+
+
+
+
+ + + + + + diff --git a/ED/p.html.meta b/ED/p.html.meta new file mode 100644 index 00000000..0e1fced7 --- /dev/null +++ b/ED/p.html.meta @@ -0,0 +1,3 @@ + _:n3-44. +_:n3-44 "charset"; + "utf-8". diff --git a/ED/p.test.html b/ED/p.test.html new file mode 100644 index 00000000..03125073 --- /dev/null +++ b/ED/p.test.html @@ -0,0 +1,1566 @@ + + + + + Solid Protocol + + + + + + + + +
+
+ +
+
+ +
+
+

Solid Protocol

+

Version 0.9.1 Editor’s Draft, 2022-12-06

+ +
+ More details about this document + +
+
This version
+
https://solidproject.org/ED/protocol
+
+ +
+
Latest version
+
https://solidproject.org/ED/protocol
+
+ +
+
Latest published version
+
https://solidproject.org/TR/protocol
+
+ +
+
Editors
+
Sarven Capadisli
+ +
Tim Berners-Lee
+ +
Ruben Verborgh
+ +
Kjetil Kjernsmo
+
+ +
+
Contributors
+
Justin Bingham
+ +
Dmitri Zagidulin
+ +
Aaron Coburn
+
+ +
+
Published
+
+
+ +
+
Modified
+
+
+ +
+
Repository
+
GitHub
+
Issues
+
+ +
+
Language
+
English
+
+ +
+
License
+
MIT License
+
+ +
+
Document Status
+
Editor’s Draft
+
+ +
+
In Reply To
+
Solid Origin
+
+ +
+
Policy
+
+
+
Rule
+
Offer
+
Unique Identifier
+
https://solidproject.org/TR/protocol#document-policy-offer
+
Target
+
https://solidproject.org/TR/protocol
+
Permission
+
+
+
Assigner
+
W3C Solid Community Group
+
Action
+
+ +
+
+
+
+
+
+
+ +

MIT License. Copyright © 2019–2022 W3C Solid Community Group.

+ +
+
+

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

+
+

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 [RFC7231].
+ +
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
PrefixNamespaceDescription
rdfhttp://www.w3.org/1999/02/22-rdf-syntax-ns#[rdf-schema]
ldphttp://www.w3.org/ns/ldp#[LDP]
solidhttp://www.w3.org/ns/solid/terms#Solid Terms
pimhttp://www.w3.org/ns/pim/space#Workspace Ontology
aclhttp://www.w3.org/ns/auth/acl#ACL Ontology
dctermshttp://purl.org/dc/terms/[DC-TERMS]
stathttp://www.w3.org/ns/posix/statPOSIX 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.

+
+
+ +
+

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 [RFC7230] and [RFC7231] 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 [RFC7230], [RFC7231], and [FETCH] by defining behaviour in terms of fetching across the platform.
+
+
+
+ +
+

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.

+
+
+ +
+

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.

+
+
+
+
+
+
+ +
+

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/1.1 Message Syntax and Routing [RFC7230] and HTTP/1.1 Semantics and Content [RFC7231]. Servers SHOULD conform to HTTP/2 [RFC7540].

+ +

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.

+ +

Servers MUST conform to HTTP/1.1 Conditional Requests [RFC7232]. Servers SHOULD conform to HTTP/1.1 Caching [RFC7234]. Servers MAY conform to HTTP/1.1 Range Requests [RFC7233].

+ +

Servers MUST conform to HTTP/1.1 Authentication [RFC7235]. 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 reject PUT, POST and PATCH requests without the Content-Type header with a status code of 400. [Source]

+
+
+ +
+

HTTP Client

+
+

Clients MUST conform to HTTP/1.1 Message Syntax and Routing [RFC7230] and HTTP/1.1 Semantics and Content [RFC7231]. Clients MAY conform to HTTP/2 [RFC7540].

+ +

Clients MAY conform to HTTP/1.1 Conditional Requests [RFC7232]. Clients MAY conform to HTTP/1.1 Caching [RFC7234]. Clients MAY conform to HTTP/1.1 Range Requests [RFC7233].

+ +

Clients MUST conform to HTTP/1.1 Authentication [RFC7235] if it needs to access resources requiring authentication (see WebID). 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 in PUT, POST and PATCH requests [RFC7231]. [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 may 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 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 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 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 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 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. 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 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 would indicate the same date and time.

+ +
+
Note: Contained Resource Metadata Considerations
+
+

The generation of contained resource metadata may 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.

+
+
+ +

This specification defines the following types of auxiliary resources:

+ + + +

Servers MUST advertise auxiliary resources associated with a subject resource by responding to HEAD and GET requests by including the HTTP Link header 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 with the rel parameter [RFC8288].

+ + + + + + + + + + + + + + + + + + + + + +
Auxiliary TypeLink RelationDefinitions
Web Access Controlacl[WAC]
Description Resourcedescribedby[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 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 an effective request URI’s type by examining the URI path ending (URI Slash Semantics).

+ +

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

+ +

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

+ +
+

Note: 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 [RFC7231] 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 headers that correspond to acceptable HTTP methods listed in Allow header value in response to HTTP GET, HEAD and OPTIONS requests.

+ +

[Source] [Source]

+
+
+ +
+

Writing Resources

+
+

Servers MUST support the HTTP PUT, POST and PATCH methods [RFC7231]. [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 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. [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 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 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 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 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.

+
+ +
+

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 value of the Accept-Patch header [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:

+ +
    +
  1. Start from the RDF dataset in the target document, or an empty RDF dataset if the target resource does not exist yet.
    2. +
  2. If ?conditions is non-empty, find all (possibly empty) variable mappings such that all of the resulting triples occur in the dataset.
    3. +
  3. If no such mapping exists, or if multiple mappings exist, the server MUST respond with a 409 status code. [Source]
    4. +
  4. The resulting variable mapping is propagated to the ?deletions and ?insertions formulae to obtain two sets of resulting triples.
    5. +
  5. 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]
    6. +
  6. The triples resulting from ?deletions are to be removed from the RDF dataset.
    7. +
  7. 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.
    8. +
  8. 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.
    9. +
+
+ +
+

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 [RFC7231]. [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 HTTP response header Allow in response to requests to these resources [RFC7231]. [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 [RFC7231]. 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 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]

+
+
+ +
+

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 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 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 implement the Solid Notifications Protocol [SOLID-NOTIFICATIONS-PROTOCOL]. +

+ +

+ Clients MUST implement the Solid Notifications Protocol[SOLID-NOTIFICATIONS-PROTOCOL]. +

+ +

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 headers, 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 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 [RFC7231].

+ +
+

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-* headers as specified in the CORS protocol [FETCH]. In particular, the server 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 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-* headers themselves). A server 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, servers 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). Servers 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 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

+
+
+

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, and applies the authorization conditions on requested operations. Authorizations are described using the ACL ontology to express and determine access privileges of a requested resource. Applications can discover authorization rules associated with a given resource, and to control such rules, as directed by an agent.

+ +

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

+ +

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

+ +

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

+ +

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 urged to seek the advice of security professionals when implementing mission critical systems using the technology outlined in this specification.

+ +

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

+ +

Servers are strongly discouraged from assuming that HTTP request headers’ field-values are valid or non-malicious. Servers are strongly encouraged to sanitize requests before processing them or incorporating them in messages sent to others. Servers are encouraged to reject bad requests that conflict with this specification's normative requirements. Servers are encouraged to 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 discouraged from assuming that the user agent is a regular Web browser, even when requests contain familiar values in headers such as User-Agent or Origin. Such an assumption could lead to incorrect conclusions about the security model of the application making the request, since the request might actually come from a non-browser actor unaffected by browser security constraints.

+ +

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

+ +

Servers are encouraged to use TLS connections to protect the contents of requests and responses from eavesdropping and modification by third parties. Unsecured TCP connections without TLS may be used in testing environments or when the 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.

+ +
+

Identifiable Information

+
+

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

+
+
+
+
+ +
+

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.0 [DPUB-ARIA-1.0]. To support structured graphics such as charts, graphs, technical drawings and scientific diagrams, to assistive technologies in order improve accessibility of graphics or diagrams through detailed annotations, it is encouraged to follow the WAI-ARIA Graphics Module [GRAPHICS-ARIA-1.0].

+ +

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

+ +

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

+
+
+ +
+

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?
+
..
+ +
Do features in your specification expose the minimum amount of information necessary to enable their intended uses?
+
..
+ +
How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?
+
..
+ +
How do the features in your specification deal with sensitive information?
+
..
+ +
Do the features in your specification introduce new state for an origin that persists across browsing sessions?
+
..
+ +
Do the features in your specification expose information about the underlying platform to origins?
+
..
+ +
Does this specification allow an origin to send data to the underlying platform?
+
..
+ +
Do features in this specification allow an origin access to sensors on a user’s device?
+
..
+ +
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.
+
..
+ +
Do features in this specification enable new script execution/loading mechanisms?
+
..
+ +
Do features in this specification allow an origin to access other devices?
+
..
+ +
Do features in this specification allow an origin some measure of control over a user agent’s native UI?
+
..
+ +
What temporary identifiers do the features in this specification create or expose to the web?
+
..
+ +
How does this specification distinguish between behaviour in first-party and third-party contexts?
+
..
+ +
How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?
+
..
+ +
Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
+
..
+ +
Do features in your specification enable origins to downgrade default security protections?
+
..
+ +
How does your feature handle non-"fully active" documents?
+
..
+
+
+
+ +
+

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 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 result in increased power consumption or emissions?
+
..
+ +
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.
+
+
+
+
+
+ +
+

Change Log

+
+

This section is non-normative.

+ +

The summary of editorial and substantive changes in this section are based on W3C Process Document Classes of Changes [W3C-PROCESS].

+ +

ED ← protocol-20211217

+ +
+

Changes from protocol-20211217 to this version

+
+ +
+
+
+
+ +
+

References

+
+
+

Normative References

+
+
+
[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. Dörthe Arndt; William Van Woensel;Dominik Tomaszuk; Gregg Kellogg. W3C. 5 September 2021. 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
+
[RFC3864]
+
Registration Procedures for Message Header Fields. G. Klyne; M. Nottingham; J. Mogul. IETF. September 2004. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc3864
+
[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
+
[RFC7230]
+
Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7230.html
+
[RFC7231]
+
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7231.html
+
[RFC7232]
+
Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7232.html
+
[RFC7233]
+
Hypertext Transfer Protocol (HTTP/1.1): Range Requests. R. Fielding, Ed.; Y. Lafon, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7233.html
+
[RFC7234]
+
Hypertext Transfer Protocol (HTTP/1.1): Caching. R. Fielding, Ed.; M. Nottingham, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7234.html
+
[RFC7235]
+
Hypertext Transfer Protocol (HTTP/1.1): Authentication. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7235.html
+
[RFC7540]
+
Hypertext Transfer Protocol Version 2 (HTTP/2). M. Belshe; R. Peon; M. Thomson, Ed.. IETF. 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://datatracker.ietf.org/doc/html/rfc8174
+
[RFC8288]
+
Web Linking. M. Nottingham. IETF. October 2017. Proposed Standard. URL: https://httpwg.org/specs/rfc8288.html
+
[SOLID-NOTIFICATIONS-PROTOCOL]
+
Solid Notifications Protocol. Aaron Coburn; Sarven Capadisli. W3C Solid Community Group. 09 May 2022. Version 0.1.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. 11 July 2021. Draft. 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. 11 December 2020. W3C Working Draft. URL: https://www.w3.org/TR/coga-usable/
+
[DPUB-ARIA-1.0]
+
Digital Publishing WAI-ARIA Module 1.0. Matt Garrish; Tzviya Siegman; Markus Gylling; Shane McCarron. W3C. 14 December 2017. W3C Recommendation. URL: https://www.w3.org/TR/dpub-aria-1.0/
+
[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. 12 May 2022. 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. 23 March 2021. W3C Note. URL: https://www.w3.org/TR/security-privacy-questionnaire/
+
[SOCIETAL-IMPACT-QUESTIONNAIRE]
+
Self-Review Questionnaire: Societal Impact. Amy Guy. W3C. 13 Dec 2021. 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. W3C. 2 March 2021. W3C Candidate Recommendation. URL: https://www.w3.org/TR/wai-aria-1.2/
+
[WCAG-3.0]
+
W3C Accessibility Guidelines (WCAG) 3.0. Jeanne F Spellman; Rachael Bradley Montgomery; Shawn Lauriat; Michael Cooper. W3C. 21 January 2021. 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. 12 May 2022. W3C Group Draft Note. URL: https://www.w3.org/TR/security-privacy-questionnaire/
+
[W3C-PROCESS]
+
W3C Process Document. Elika J. Etemad / fantasai; Florian Rivoal; W3C Process Community Group. 2 November 2021. URL: https://www.w3.org/Consortium/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/
+
+
+
+
+
+
+
+
+ + + + + + diff --git a/ED/protocol.fpwd.html b/ED/protocol.fpwd.html new file mode 100644 index 00000000..4d1eaa2f --- /dev/null +++ b/ED/protocol.fpwd.html @@ -0,0 +1,1646 @@ + + + + + Solid Protocol + + + + + + + + + +
+
+
+ W3C + +

Solid Protocol

+ +

W3C First Public Working Draft

+ +
+ More details about this document + +
+
This version
+
https://www.w3.org/TR/2023/WD-solid-protocol-20231231/
+
+ +
+
Latest version
+
https://www.w3.org/TR/solid-protocol/
+
+ +
+
Previous version
+
https://solidproject.org/TR/2022/protocol-20221231
+
+ +
+
History
+
https://www.w3.org/standards/history/solid-protocol
+
+ +
+
Editors
+
Sarven Capadisli
+ +
Tim Berners-Lee
+ +
Ruben Verborgh
+ +
Kjetil Kjernsmo
+
+ +
+
Feedback
+
+ GitHub solid/specification + (pull requests, + new issue, + open issues) +
+
public-solid@w3.org with subject line [solid-protocol] … message topic … (archives)
+
+ +
+
Published
+
+
+ +
+
Modified
+
+
+ +
+
Repository
+
GitHub
+
Issues
+
+ +
+
Language
+
English
+
+ +
+
License
+
MIT License
+
+ +
+
Document Status
+
Editor’s Draft
+
+ +
+
In Reply To
+
Solid Origin
+
+ +
+
Policy
+
+
+
Rule
+
Offer
+
Unique Identifier
+
https://solidproject.org/TR/protocol#document-policy-offer
+
Target
+
https://solidproject.org/TR/protocol
+
Permission
+
+
+
Assigner
+
W3C Solid Community Group
+
Action
+
+ +
+
+
+
+
+
+
+ +

MIT License. Copyright © 2019–2023 W3C Solid Community Group.

+ +
+ +
+ +
+
+

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

+
+

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 [RFC7231].
+ +
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
PrefixNamespaceDescription
rdfhttp://www.w3.org/1999/02/22-rdf-syntax-ns#[rdf-schema]
ldphttp://www.w3.org/ns/ldp#[LDP]
solidhttp://www.w3.org/ns/solid/terms#Solid Terms
pimhttp://www.w3.org/ns/pim/space#Workspace Ontology
aclhttp://www.w3.org/ns/auth/acl#ACL Ontology
dctermshttp://purl.org/dc/terms/[DC-TERMS]
stathttp://www.w3.org/ns/posix/statPOSIX 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 [RFC7230] and [RFC7231] 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 [RFC7230], [RFC7231], 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 of the request URI, i.e., http://example.org/foo/ as the effective request 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/1.1 Message Syntax and Routing [RFC7230] and HTTP/1.1 Semantics and Content [RFC7231]. Servers SHOULD conform to HTTP/2 [RFC7540].

+ +

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.

+ +

Servers MUST conform to HTTP/1.1 Conditional Requests [RFC7232]. Servers SHOULD conform to HTTP/1.1 Caching [RFC7234]. Servers MAY conform to HTTP/1.1 Range Requests [RFC7233].

+ +

Servers MUST conform to HTTP/1.1 Authentication [RFC7235]. 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 a payload body.

+ +

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

+
+
+ +
+

HTTP Client

+
+

Clients MUST conform to HTTP/1.1 Message Syntax and Routing [RFC7230] and HTTP/1.1 Semantics and Content [RFC7231]. Clients MAY conform to HTTP/2 [RFC7540].

+ +

Clients MAY conform to HTTP/1.1 Conditional Requests [RFC7232]. Clients MAY conform to HTTP/1.1 Caching [RFC7234]. Clients MAY conform to HTTP/1.1 Range Requests [RFC7233].

+ +

Clients MUST conform to HTTP/1.1 Authentication [RFC7235] if it needs to access resources requiring authentication (see WebID). 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 in PUT, POST and PATCH requests [RFC7231]. [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 may 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 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 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 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 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 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. 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 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 would indicate the same date and time.

+ +
+
Note: Contained Resource Metadata Considerations
+
+

The generation of contained resource metadata may 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:

+ + + +

Servers MUST advertise auxiliary resources associated with a subject resource by responding to HEAD and GET requests by including the HTTP Link header 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 with the rel parameter [RFC8288].

+ + + + + + + + + + + + + + + + + + + + + +
Auxiliary TypeLink RelationDefinitions
Web Access Controlacl[WAC]
Description Resourcedescribedby[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 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 an effective request URI’s type by examining the URI path ending (URI Slash Semantics).

+ +

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

+ +

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

+ +
+

Note: 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 [RFC7231] 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 headers that correspond to acceptable HTTP methods listed in Allow header 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 [RFC7231]. [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 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. [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 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 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 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 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.

+
+ +
+

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 value of the Accept-Patch header [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:

+ +
    +
  1. Start from the RDF dataset in the target document, or an empty RDF dataset if the target resource does not exist yet.
    2. +
  2. If ?conditions is non-empty, find all (possibly empty) variable mappings such that all of the resulting triples occur in the dataset.
    3. +
  3. If no such mapping exists, or if multiple mappings exist, the server MUST respond with a 409 status code. [Source]
    4. +
  4. The resulting variable mapping is propagated to the ?deletions and ?insertions formulae to obtain two sets of resulting triples.
    5. +
  5. 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]
    6. +
  6. The triples resulting from ?deletions are to be removed from the RDF dataset.
    7. +
  7. 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.
    8. +
  8. 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.
    9. +
+
+ +
+

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 [RFC7231]. [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 HTTP response header Allow in response to requests to these resources [RFC7231]. [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 [RFC7231]. 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 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]

+
+
+ +
+

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 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 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 headers, 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 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 [RFC7231].

+ +
+

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-* headers as specified in the CORS protocol [FETCH]. In particular, the server 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 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-* headers themselves). A server 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, servers 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). Servers 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 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 ACL 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 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.

+ +

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 urged to seek the advice of security professionals when implementing mission critical systems using the technology outlined in this specification.

+ +

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

+ +

Servers are strongly discouraged from assuming that HTTP request headers’ field-values are valid or non-malicious. Servers are strongly encouraged to sanitize requests before processing them or incorporating them in messages sent to others. Servers are encouraged to reject bad requests that conflict with this specification's normative requirements. Servers are encouraged to 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 discouraged from assuming that the user agent is a regular Web browser, even when requests contain familiar values in headers such as User-Agent or Origin. Such an assumption could lead to incorrect conclusions about the security model of the application making the request, since the request might actually come from a non-browser actor unaffected by browser security constraints.

+ +

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

+ +

Servers are encouraged to use TLS connections to protect the contents of requests and responses from eavesdropping and modification by third parties. Unsecured TCP connections without TLS may be used in testing environments or when the 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.

+ +
+

Identifiable Information

+
+

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

+
+
+
+
+ +
+

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.0 [DPUB-ARIA-1.0]. To support structured graphics such as charts, graphs, technical drawings and scientific diagrams, to assistive technologies in order improve accessibility of graphics or diagrams through detailed annotations, it is encouraged to follow the WAI-ARIA Graphics Module [GRAPHICS-ARIA-1.0].

+ +

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

+ +

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

+
+
+ +
+

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 payloads can contain any data including that which identifies or refers to the user of the application. Meaningful consent to any personal data that applications include is extended by the client to the server.
+ +
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.10.0. A list of issues addressed, a diff from Solid Protocol, Version 0.10.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.10.0
Change ClassSubjectDescription
1DocumentAmend broken links, style sheets, or invalid markup.
2DocumentAmend language and document details.
4#server-content-type-payloadAdd requirement for server to include Content-Type in messages with payload.
2#relationship-to-ldpAdd section describing the the relationship between Solid Protocol and LDP.
+
+
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.

+
+
+ +
+

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. Dörthe Arndt; William Van Woensel; Dominik Tomaszuk; Gregg Kellogg. W3C. 3 July 2023. 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
+
[RFC3864]
+
Registration Procedures for Message Header Fields. G. Klyne; M. Nottingham; J. Mogul. IETF. September 2004. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc3864
+
[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
+
[RFC7230]
+
Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7230.html
+
[RFC7231]
+
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7231.html
+
[RFC7232]
+
Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7232.html
+
[RFC7233]
+
Hypertext Transfer Protocol (HTTP/1.1): Range Requests. R. Fielding, Ed.; Y. Lafon, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7233.html
+
[RFC7234]
+
Hypertext Transfer Protocol (HTTP/1.1): Caching. R. Fielding, Ed.; M. Nottingham, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7234.html
+
[RFC7235]
+
Hypertext Transfer Protocol (HTTP/1.1): Authentication. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7235.html
+
[RFC7540]
+
Hypertext Transfer Protocol Version 2 (HTTP/2). M. Belshe; R. Peon; M. Thomson, Ed.. IETF. 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://datatracker.ietf.org/doc/html/rfc8174
+
[RFC8288]
+
Web Linking. M. Nottingham. IETF. October 2017. Proposed Standard. URL: https://httpwg.org/specs/rfc8288.html
+
[SOLID-NOTIFICATIONS-PROTOCOL]
+
Solid Notifications Protocol. Sarven Capadisli. W3C Solid Community Group. 31 December 2022. Version 0.2.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. 5 July 2022. Version 1.0.0-cr-1. 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. 11 December 2020. W3C Working Draft. URL: https://www.w3.org/TR/coga-usable/
+
[DPUB-ARIA-1.0]
+
Digital Publishing WAI-ARIA Module 1.0. Matt Garrish; Tzviya Siegman; Markus Gylling; Shane McCarron. W3C. 14 December 2017. W3C Recommendation. URL: https://www.w3.org/TR/dpub-aria-1.0/
+
[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. 12 May 2022. 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. 23 March 2021. W3C Note. URL: https://www.w3.org/TR/security-privacy-questionnaire/
+
[SOCIETAL-IMPACT-QUESTIONNAIRE]
+
Self-Review Questionnaire: Societal Impact. Amy Guy. W3C. 13 Dec 2021. 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. W3C. 2 March 2021. W3C Candidate Recommendation. URL: https://www.w3.org/TR/wai-aria-1.2/
+
[WCAG-3.0]
+
W3C Accessibility Guidelines (WCAG) 3.0. Jeanne F Spellman; Rachael Bradley Montgomery; Shawn Lauriat; Michael Cooper. W3C. 21 January 2021. 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. 12 May 2022. W3C Group Draft Note. URL: https://www.w3.org/TR/security-privacy-questionnaire/
+
[W3C-PROCESS]
+
W3C Process Document. Elika J. Etemad / fantasai; Florian Rivoal; W3C Process Community Group. 12 June 2023. URL: https://www.w3.org/Consortium/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/
+
+
+
+
+
+
+
+
+ + + + + + diff --git a/ED/protocol.html b/ED/protocol.html index 8d2636a1..dd9e1462 100644 --- a/ED/protocol.html +++ b/ED/protocol.html @@ -1468,6 +1468,11 @@

Changelog

#server-representation-turtle-jsonld Amend server-representation-turtle-jsonld requirement with emphasis on the created RDF source. + + 2 + #server-put-patch-uri-assignment + Remove the requirement for implicit and inherited URI assignment after HTTP PUT PATCH requests that is already defined in referenced specifications. + diff --git a/ED/protocol.html.meta b/ED/protocol.html.meta new file mode 100644 index 00000000..dd57c68c --- /dev/null +++ b/ED/protocol.html.meta @@ -0,0 +1,3 @@ + _:n3-3. +_:n3-3 "charset"; + "utf-8". diff --git a/ED/qa.test.html b/ED/qa.test.html new file mode 100644 index 00000000..9eb27774 --- /dev/null +++ b/ED/qa.test.html @@ -0,0 +1,1052 @@ + + + + + Solid QA + + + + + + + + +
+
+ +
+
+ +
+
+

Solid QA

+ +

Version 0.2.0 Editor’s Draft,

+ +
+ More details about this document + +
+
This version
+
https://solidproject.org/ED/qa
+
+ +
+
Latest version
+
https://solidproject.org/ED/qa
+
+ +
+
Editors
+
Sarven Capadisli
+
+ +
+
Authors
+
Sarven Capadisli
+
Pete Edwards
+
Michiel de Jong
+
+ +
+
Created
+
+
+ +
+
Published
+
+
+ +
+
Modified
+
+
+ +
+
Repository
+
GitHub
+
Issues
+
+ +
+
Language
+
English
+
+ +
+
License
+
MIT License
+
+ +
+
Document Status
+
Editor’s Draft
+
+ +
+
In Reply To
+
Solid Origin
+
Test Suite Panel Charter
+
+ +
+
Policy
+
+
+
Rule
+
Offer
+
Unique Identifier
+
https://solidproject.org/ED/qa#document-policy-offer
+
Target
+
https://solidproject.org/ED/qa
+
Permission
+
+
+
Assigner
+
W3C Solid Community Group
+
Action
+
+ +
+
+
+
+
+
+
+ +

MIT License. Copyright © 2023 W3C Solid Community Group.

+ +
+
+

Abstract

+
+

This document describes the Solid Quality Assurance (QA) policy, processes, and procedures. The document details the requirements and advisements towards the publication and consumption of Solid technical reports, test suites, test cases, test assessments, and test reports to: improve the quality of technical reports at critical stages of their development; promote wide deployment and proper implementation of technical reports with open implementation reports; help produce quality test suites; and, advance the development and assessment of test cases.

+
+
+ +
+

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

+
+

This section is non-normative.

+ +

Specifications in the Solid ecosystem Solid Technical Reports [SOLID-TECHNICAL-REPORTS] describe how implementations can be interoperable by using Web communication protocols, global identifiers, authentication and authorization mechanisms, data formats and shapes, notifications, and query interfaces.

+ +

Writing tests in a way that allows implementations to conform to the requirements of a technical report gives Solid projects confidence that their software is compatible with other implementations. This in turn gives authors of technical reports and software implementers confidence that they can rely on the Solid ecosystem to deliver on the promise of interoperability based on open standards. Implementation and interoperability experience can be verified by reporting on implementations passing open test suites.

+ +

The goal of this document is to describe the Solid Quality Assurance (QA) policy, processes, and procedures. The document details the requirements and advisements towards the publication and consumption of Solid technical reports, test suites, test cases, test assessments, and test reports to:

+ +
    +
  • improve the quality of technical reports at critical stages of their development;
    • +
  • promote wide deployment and proper implementation of technical reports with open implementation reports;
    • +
  • help produce quality test suites;
    • +
  • advance the development and assessment of test cases.
    • +
+ +

This document is influenced by the W3C Quality Assurance activity work encompassing W3C processes, specification authoring and publishing, and quality assurance, including: W3C Process Document, Variability in Specifications, QA Framework: Specification Guidelines, The QA Handbook, Test Metadata, Evaluation and Report Language (EARL) 1.0 Schema.

+ +

This document is for:

+ +
    +
  • Test software developers.
    • +
  • Contributors to technical reports.
    • +
  • Product implementers.
    • +
+ +
+

Data Formats

+
+

This specification uses the RDF language to describe technical reports, test reports, test suites, and test cases. Implementers are encouraged to produce human-visible and machine-readable representations with RDFa in host languages such as HTML and SVG.

+
+
+ +
+

Terminology

+
+

This section is non-normative.

+ +

The Solid QA defines the following terms. These terms are referenced throughout this document.

+ + + +
+
URI
+
A Uniform Resource Identifier (URI) provides the means for identifying resources [RFC3986].
+
+
+
+ +
+

Namespaces

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Prefixes and Namespaces
PrefixNamespaceDescription
dctermshttp://purl.org/dc/terms/[DC-TERMS]
doaphttp://usefulinc.com/ns/doap#DOAP
earlhttp://www.w3.org/ns/earl#[EARL10-Schema]
provhttp://www.w3.org/ns/prov#[prov-o]
rdfhttp://www.w3.org/1999/02/22-rdf-syntax-ns#[rdf-schema]
skoshttp://www.w3.org/2004/02/skos/core#[skos-reference]
solidhttp://www.w3.org/ns/solid/terms#Solid Terms
spechttp://www.w3.org/ns/spec#Spec Terms
tdhttp://www.w3.org/2006/03/test-description#Test Description
+
+
+
+
+ +
+

Conformance

+
+

This section describes the conformance model of the Solid QA.

+ +
+

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 QA 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 QA identifies the following Classes of Products for conforming implementations. These products are referenced throughout this specification.

+ +
+
Technical Report
+
..
+ +
Test Case
+
..
+ +
Test Report
+
A Test Report is a resource that describes the level of conformance of a project’s tests against Test Cases [test-metadata].
+ +
Test Suite
+
A Test Suite is software that, .., and consumes Technical Reports and produces Test Cases.
+
+
+
+ +
+

Interoperability

+
+

Interoperability of implementations for Test Suite and Technical Report is tested by evaluating an implementation’s ability to consume and process data that conform to this specification.

+
+
+
+
+ +
+

Technical Report

+
+
+

Technical Report Description

+
+

The Solid Technical Reports Contributing Guide provides the recommendations for publishing technical reports following the Linked Data design principles, where significant units of information, such as concepts and requirements, are given an identifier, and described with a concrete RDF syntax. The Spec Terms vocabulary provides classes and properties that can be used to describe any significant unit of information in technical reports, as well as supporting the description of test cases and test reports. The SKOS data model can be used to identify, describe, and link concepts and definitions across technical reports.

+ +

Add other requirements from Spec Terms and SKOS.

+ + + +

Defining URI Templates for implementation report, e.g.,https://solidproject.org/test-reports/{technical-report-short-name}/summary, and test report, e.g., https://solidproject.org/test-reports/{technical-report-short-name}/{uuid}

+
+
+
+
+ +
+

Test Report

+
+

This section describes the requirements for publishing test reports and summaries.

+ +
+

Test Report Description

+
+

solid/test-suite-panel/issues/5

+ +

The Test Report Description includes information pertaining to conformance and interoperability of an implementation.

+ +

Document metadata:

+ +
    +
  • One dcterms:license property to indicate the license of the report.
    • +
  • One dcterms:created property to indicate the date and time of the report.
    • +
  • One publication status property (TBD) to state the publication status of the report.
    • +
  • One activity association property (TBD) to indicate the agent that had a role in the production of the report.
    • +
  • One submitted by property (TBD) to indicate the entity that proposed the report for publication.
    • +
  • One approved by (TBD) property to indicate the entity that accepted the report for publication.
    • +
  • Zero or one dcterms:description property to include additional notes about the report from the submitter.
    • +
+ +

Additional notes about the report can be expressed as a Web Annotation (oa:Annotation).

+ +

Agent (person or software) that had a role in the production of the test report can be expressed as a PROV-O activity association (prov:wasAssociatedWith).

+ +

For publication status, some TRs use pso:holdsStatusInTime with pso:withStatus - is there something from a common vocabulary? What visual cues should be required to indicate publication status at a glance?

+ +

Implementations that are software projects MUST be described with the Description of a Project vocabulary [DOAP].

+ +

Description of a project:

+ +
    +
  • One rdf:type property whose object is doap:Project.
    • +
  • Zero or one doap:name property to state the name of the project.
    • +
  • Zero or one doap:repository property to indicate the location of of project's source code.
    • +
  • Zero or one doap:release property to indicate the version information of a project release.
    • +
  • Zero or one doap:maintainer property to refer to the maintainers of a project.
    • +
+ +
+

Note: Test Report Description: Description of a Project

+
+

The subject of the doap:Project for Test Report Description coincides with the object of the earl:subject in Test Assertion Description.

+ +

To help distinguish project releases in test reports, it is encouraged to use versioned URIs for projects.

+ +

While some information about the project can be accompanied with the test report, it is encouraged that projects are self-describing documents.

+
+
+ +

What should be the recommendation for implementations that are not software projects? Perhaps equivalent to a top concept of spec:ClassesOfProducts?

+ +

Test assertions:

+ +

Test reports MUST incorporate additional information about test criteria indicating test authors and reviewers, review status, version of the test criterion, software and setup used to run the tests, provenance and coverage and test suite (see also Test Assertion Description).

+ +

Test reports with approved status MUST NOT include assertions related to test criteria with rejected review status (td:rejected).

+ +
+

Note: Test Report Description: Test Assertion

+
+

To help distinguish test criteria, it is encouraged to use versioned URIs for criteria.

+ +

To convey association between a test criterion and its reviews, it is encouraged to use the Web Annotation Vocabulary with the oa:assessing motivation.

+
+
+ +

Should Web Annotation Vocabulary be required to convey the relationship between test criteria and reviews?

+
+
+ +
+

Test Case Description

+
+
    +
  • One rdf:type whose object is td:TestCase.
    • +
  • One spec:requirementReference property to refer to the specification requirement that the test case is testing.
    • +
  • One td:reviewStatus property to indicate the status of a test (at the time when the test was run) with an object one of: td:unreviewed, td:onhold, td:assigned, td:accepted, td:approved, td:rejected.
    • +
  • Zero or one td:input property to indicate the parameter or data that are needed for the test execution.
    • +
  • One td:expectedResults property to indicate the results that a conformant implementation is expected to produce when this test is executed.
    • +
  • Zero or one td:preCondition property to indicate that a condition must be met before the test is executed.
    • +
  • Zero or one td:purpose property to state the reason for the test with additional context.
    • +
  • Zero or one dcterms:title property to provide a human-oriented name for the test.
    • +
  • Zero or one dcterms:description property to provide a description of the nature and characteristic of the test.
    • +
  • One or more dcterms:contributors to indicate individuals or organisations that contributed to this test.
    • +
+ +

spec:testScript may need to be rdfs:subPropertyOf td:input or td:informationResourceInput, or use those properties instead.

+ +

When referencing a requirement with spec:requirementReference, it is strongly encouraged to use versioned URLs of technical reports where available with preference to URLs covered by a persistence policy.

+ +
+

Example: Test Case

+ + 
@prefix sopr: <https://solidproject.org/TR/2022/protocol-20221231#> .
+
+:server-content-type-reject
+  a td:TestCase ;
+  spec:requirementReference sopr:server-content-type ;
+  td:reviewStatus td:unreviewed ;
+  td:expectedResults :server-content-type-expected-result ;
+  dcterms:contributor <https://csarven.ca/#i> .
+ +
A test case for server rejecting requests with reference to expected results.
+
+
+
+ +
+

Test Assertion Description

+
+

A Test Assertion indicates measurable or testable statements of behaviour, action, or condition derived from specification's requirements. A test assertion is stated by an entity carrying out the test; indicating contextual result of a test; with a particular process; based on a criterion; that is used to evaluate an implementation.

+ +

Test assertions MUST use the Evaluation and Report Language 1.0 Schema [EARL10-Schema].

+ +

Test Suite implementers are encouraged to follow the Developer Guide for Evaluation and Report Language 1.0 [EARL10-Guide].

+
+
+ +
+

Test Report Notification

+
+

GitHub repo/directory and/or report sent as an LDN (TBD: either including or requesting maintainer’s approval.)

+ +

Should Activity Vocabulary and Linked Data Notifications be one of the ways to submit test reports as a notification?

+ +

Publication of reports can be pre-authorized for approved tests.

+
+
+ +
+

Project Maintainer Input and Review

+
+

Project maintainer will be notified to review the publication of a report, and if no objection within a certain time (TBD), it can be approved for publication by the submitter (or test suite panel). During the review process, maintainers will be given the opportunity to provide explanatory notes to go with the report.

+
+
+ +
+

Implementation Report Description

+ +
+

The Implementation Report Description refers to the criteria and resolutions set forth by the Group publishing a Technical Report to demonstrate implementation experience; refers to test reports; provides a summary.

+ +

Document metadata:

+ +

Similar to Test Report Description document metadata. Reuse or redefine?

+ +

Referencing individual test reports:

+ +
    +
  • One or more spec:testReports to refer to test reports.
    • +
+
+
+
+
+ +
+

Test Suite

+
+

This section describes the requirements for test suite and test metadata.

+ +

solid/test-suite-panel/issues/6

+ +
+

Test Suite Description

+
+

Description of test suites (e.g., license, date, written by, reviewed by), the software (e.g., repository, version, maintainers), setup (e.g., platform, configuration), provenance (e.g., activity, entity, agent), input about environment (e.g., combination of subject and setup). Meet the requirements of reporting (issue 5) and test review checklist (issue 7).

+ +
    +
  • One rdf:type property whose object is spec:TestSuite (TBD).
    • +
  • One or more spec:testCases to refer to test cases.
    • +
+
+
+ +
+

Test Environment

+
+

Documentation on:

+ +
    +
  • how to set up a test environment, how to build the test system (if necessary).
    • +
  • how to write tests that are in general, short, self-contained, and maybe provide best practices and guidelines.
    • +
  • how to run tests (provide a set of steps to test and obtain the result). Tests may be run in different ways depending on the specification requirement, e.g., command-line, containers, Web browser.
    • +
+
+
+ +

Do preliminary checks against multiple implementations to catch anomalies or to tease out issues with the tests themselves. Tests authors and specification authors should coordinate regarding the test design.

+ +

PR the updated test, mark what it replaces, mark it as to be reviewed, request reviews.

+ +

Notify specification authors and editors (and other group of contributors) about new tests and request reviews, e.g., tagging on GitHub.

+ +

Tagging the project maintainer (issue 5).

+ +

Provide information indicating to what extent the test suite completely or proportionally covers the specification it aims to support (issue 5).

+ +

Link to project maintainer’s WebID or GitHub account.

+
+
+ +
+

Test Assessment

+
+

This section describes the process for authoring and reviewing tests.

+ +

solid/test-suite-panel/issues/7

+ +
+

Test Review Policy

+
+
    +
  • Test review has a URI and its contents are publicly accessible when dereferenced.
    • +
  • Test reviewer can be anyone (other than the original test author) that has the required experience with the specification. TBD whether at least one reviewer must be the author of the specification.
    • +
+
+
+ +
+

Test Review Criteria

+
+
    +
  • The test has a URI and its contents are publicly accessible when dereferenced.
    • +
  • The test links to specification requirements.
    • +
  • The CI jobs on the pull request have passed. (TBD)
    • +
  • It is obvious what the test is trying to test.
    • +
  • The test passes when it’s supposed to pass.
    • +
  • The test fails when it’s supposed to fail.
    • +
  • The test is testing what it thinks it’s testing.
    • +
  • The specification backs up the expected behaviour in the test.
    • +
  • The test is automated as - TBD - unless there’s a very good reason for it not to be.
    • +
  • The test does not use external resources. (TBD)
    • +
  • The test does not use proprietary features (vendor-prefixed or otherwise).
    • +
  • The test does not contain commented-out code
    • +
  • The test is placed in the relevant location.
    • +
  • The test has a reasonable and concise (file)name.
    • +
  • If the test needs to be run in some non-standard configuration or needs user interaction, it is a manual test.
    • +
  • The title is descriptive but not too wordy.
    • +
+
+
+
+
+ +
+

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.

+
+
+ +
+

Privacy Considerations

+
+

This section is non-normative.

+
+
+ +
+

Accessibility Considerations

+
+

This section is non-normative.

+
+
+ +
+

Internationalization Considerations

+
+

This section is non-normative.

+
+
+ +
+

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?
+
..
+ +
Do features in your specification expose the minimum amount of information necessary to enable their intended uses?
+
..
+ +
How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?
+
..
+ +
How do the features in your specification deal with sensitive information?
+
..
+ +
Do the features in your specification introduce new state for an origin that persists across browsing sessions?
+
..
+ +
Do the features in your specification expose information about the underlying platform to origins?
+
..
+ +
Does this specification allow an origin to send data to the underlying platform?
+
..
+ +
Do features in this specification allow an origin access to sensors on a user’s device
+
..
+ +
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.
+
..
+ +
Do features in this specification enable new script execution/loading mechanisms?
+
..
+ +
Do features in this specification allow an origin to access other devices?
+
..
+ +
Do features in this specification allow an origin some measure of control over a user agent’s native UI?
+
..
+ +
What temporary identifiers do the features in this specification create or expose to the web?
+
..
+ +
How does this specification distinguish between behaviour in first-party and third-party contexts?
+
..
+ +
How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?
+
..
+ +
Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
+
..
+ +
Do features in your specification enable origins to downgrade default security protections?
+
..
+ +
How does your feature handle non-"fully active" documents?
+
..
+
+
+
+
+
+ +
+

Change Log

+
+

This section is non-normative.

+ +

The summary of editorial and substantive changes in this section are based on W3C Process Document Classes of Changes [W3C-PROCESS].

+
+
+ +
+

References

+
+
+

Normative References

+
+
+
[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/
+
[DOAP]
+
DOAP: Description of a Project. URL: https://github.com/ewilderj/doap
+
[EARL10-Schema
+ Evaluation and Report Language (EARL) 1.0 Schema. Shadi Abou-Zahra. W3C. 2 February 2017. W3C Working Group Note. URL: https://www.w3.org/TR/EARL10-Schema/
+
[LDN]
+
Linked Data Notifications. Sarven Capadisli; Amy Guy. W3C. 2 May 2017. W3C Recommendation. URL: https://www.w3.org/TR/ldn/
+
[prov-o]
+
PROV-O: The PROV Ontology. Timothy Lebo; Satya Sahoo; Deborah McGuinness. W3C. 30 April 2013. W3C Recommendation. URL: https://www.w3.org/TR/prov-o/
+
[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
+
[RFC7231]
+
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7231.html
+
[RFC7540]
+
Hypertext Transfer Protocol Version 2 (HTTP/2). M. Belshe; R. Peon; M. Thomson, Ed.. IETF. 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://datatracker.ietf.org/doc/html/rfc8174
+
[skos-reference]
+
SKOS Simple Knowledge Organization System Reference. Alistair Miles; Sean Bechhofer. W3C. 18 August 2009. W3C Recommendation. URL: https://www.w3.org/TR/skos-reference/
+
[test-metadata]
+
Test Metadata. Patrick Curran; Karl Dubost. W3C. 14 September 2005. W3C Working Group Note. URL: https://www.w3.org/TR/test-metadata/
+
[W3C-HTML]
+
HTML. W3C. 28 January 2021. W3C Recommendation. URL: https://www.w3.org/TR/html/
+
[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

+
+
+
[EARL10-Guide]
+
Developer Guide for Evaluation and Report Language (EARL) 1.0. Carlos A. Velasco; Shadi Abou-Zahra. W3C. 2 February 2017. W3C Working Group Note. URL: https://www.w3.org/TR/EARL10-Guide/
+
[qa-handbook]
+
The QA Handbook. Lofton Henderson. W3C. 6 September 2005. W3C Working Group Note. URL: https://www.w3.org/TR/qa-handbook/
+
[qaframe-spec]
+
QA Framework: Specification Guidelines. Karl Dubost; Lynne Rosenthal; Dominique Hazaël-Massieux; Lofton Henderson et al. W3C. 17 August 2005. W3C Recommendation. URL: https://www.w3.org/TR/qaframe-spec/
+
[SECURITY-PRIVACY-QUESTIONNAIRE]
+
Self-Review Questionnaire: Security and Privacy. Theresa O'Connor; Peter Snyder. W3C. 23 March 2021. W3C Note. URL: https://www.w3.org/TR/security-privacy-questionnaire/
+
[SOLID-TECHNICAL-REPORTS]
+
Solid Technical Reports. Sarven Capadisli. W3C Solid Community Group. 5 January 2023. Living Document. URL: https://solidproject.org/TR/
+
[W3C-PROCESS]
+
W3C Process Document. Elika J. Etemad (fantasai); Florian Rivoal. W3C. 12 June 2023. URL: https://www.w3.org/Consortium/Process/
+
+
+
+
+
+
+
+
+ + + + + + diff --git a/build b/build new file mode 100755 index 00000000..f503b2f3 --- /dev/null +++ b/build @@ -0,0 +1,8 @@ +#!/usr/bin/env bash +set -e + +for index in */index.bs; do + bikeshed spec $index; +done + +cp main/*.html . diff --git a/cg.solid.participations.json b/cg.solid.participations.json new file mode 100644 index 00000000..2188cefa --- /dev/null +++ b/cg.solid.participations.json @@ -0,0 +1,1002 @@ +{ + "page": 1, + "limit": 1000, + "pages": 1, + "total": 245, + "_links": { + "up": { + "href": "https://api.w3.org/groups/cg/solid" + }, + "participations": [ + { + "href": "https://api.w3.org/participations/26821", + "title": "Roy Leon" + }, + { + "href": "https://api.w3.org/participations/26822", + "title": "Arnav Bansal" + }, + { + "href": "https://api.w3.org/participations/26823", + "title": "Melvin Carvalho" + }, + { + "href": "https://api.w3.org/participations/26824", + "title": "Omnijar" + }, + { + "href": "https://api.w3.org/participations/26827", + "title": "Agency for Digitisation" + }, + { + "href": "https://api.w3.org/participations/26831", + "title": "IPTC - International Press Telecommunications Council" + }, + { + "href": "https://api.w3.org/participations/26839", + "title": "Simon Louvet" + }, + { + "href": "https://api.w3.org/participations/26845", + "title": "Pavlik elf" + }, + { + "href": "https://api.w3.org/participations/26849", + "title": "RJ Herrick" + }, + { + "href": "https://api.w3.org/participations/26856", + "title": "Fabio Barone" + }, + { + "href": "https://api.w3.org/participations/26859", + "title": "Spec-Ops" + }, + { + "href": "https://api.w3.org/participations/26860", + "title": "OpenLink Software Inc." + }, + { + "href": "https://api.w3.org/participations/26861", + "title": "Brad Jones" + }, + { + "href": "https://api.w3.org/participations/26862", + "title": "Mischa Tuffield" + }, + { + "href": "https://api.w3.org/participations/26866", + "title": "imec" + }, + { + "href": "https://api.w3.org/participations/26867", + "title": "Samy Vincent" + }, + { + "href": "https://api.w3.org/participations/26868", + "title": "Matt Wallis" + }, + { + "href": "https://api.w3.org/participations/26872", + "title": "Apache Software Foundation" + }, + { + "href": "https://api.w3.org/participations/26880", + "title": "Verizon" + }, + { + "href": "https://api.w3.org/participations/26884", + "title": "Frank Kroon" + }, + { + "href": "https://api.w3.org/participations/26887", + "title": "Ganesh Kumble" + }, + { + "href": "https://api.w3.org/participations/26896", + "title": "North Carolina A&T State University" + }, + { + "href": "https://api.w3.org/participations/26909", + "title": "Eric Woodward" + }, + { + "href": "https://api.w3.org/participations/26912", + "title": "Skemu" + }, + { + "href": "https://api.w3.org/participations/26920", + "title": "Knut-Olav Hoven" + }, + { + "href": "https://api.w3.org/participations/26931", + "title": "Open Consent Group" + }, + { + "href": "https://api.w3.org/participations/26939", + "title": "Mark Hughes" + }, + { + "href": "https://api.w3.org/participations/26957", + "title": "HM Government" + }, + { + "href": "https://api.w3.org/participations/27069", + "title": "Wiley" + }, + { + "href": "https://api.w3.org/participations/27155", + "title": "Google LLC" + }, + { + "href": "https://api.w3.org/participations/27219", + "title": "Janeiro Digital" + }, + { + "href": "https://api.w3.org/participations/27340", + "title": "Augusto Mathurin" + }, + { + "href": "https://api.w3.org/participations/27356", + "title": "Angelo Veltens" + }, + { + "href": "https://api.w3.org/participations/27365", + "title": "Phoster, Inc" + }, + { + "href": "https://api.w3.org/participations/27541", + "title": "Stichting Adaptant Foundation" + }, + { + "href": "https://api.w3.org/participations/27613", + "title": "Werk7" + }, + { + "href": "https://api.w3.org/participations/27821", + "title": "Alain Bourgeois" + }, + { + "href": "https://api.w3.org/participations/27844", + "title": "Inrupt Inc." + }, + { + "href": "https://api.w3.org/participations/27881", + "title": "Mike Adams" + }, + { + "href": "https://api.w3.org/participations/28114", + "title": "Eduardo Ibacache Rodriguez" + }, + { + "href": "https://api.w3.org/participations/28194", + "title": "OpenInc" + }, + { + "href": "https://api.w3.org/participations/28226", + "title": "Reihoo" + }, + { + "href": "https://api.w3.org/participations/28274", + "title": "Jeff Zucker" + }, + { + "href": "https://api.w3.org/participations/28297", + "title": "Khalid Alnuaim" + }, + { + "href": "https://api.w3.org/participations/28306", + "title": "Teodora Petkova" + }, + { + "href": "https://api.w3.org/participations/28307", + "title": "Thomas Gallagher" + }, + { + "href": "https://api.w3.org/participations/28309", + "title": "WU (Wirschaftsuniversität Wien) - Vienna University of Economics and Business" + }, + { + "href": "https://api.w3.org/participations/28310", + "title": "Chris Min" + }, + { + "href": "https://api.w3.org/participations/28320", + "title": "Daphne Muller" + }, + { + "href": "https://api.w3.org/participations/28332", + "title": "Christian Buggedei" + }, + { + "href": "https://api.w3.org/participations/28336", + "title": "Startin'blox" + }, + { + "href": "https://api.w3.org/participations/28342", + "title": "Armando Ramos" + }, + { + "href": "https://api.w3.org/participations/28344", + "title": "david mason" + }, + { + "href": "https://api.w3.org/participations/28439", + "title": "Elettra Bietti" + }, + { + "href": "https://api.w3.org/participations/28555", + "title": "Jon Pederson" + }, + { + "href": "https://api.w3.org/participations/28577", + "title": "Mark Weiler" + }, + { + "href": "https://api.w3.org/participations/28584", + "title": "Matthias Evering" + }, + { + "href": "https://api.w3.org/participations/28588", + "title": "Sébastien Dubois" + }, + { + "href": "https://api.w3.org/participations/28591", + "title": "Sina Bahram" + }, + { + "href": "https://api.w3.org/participations/28593", + "title": "Raúl R. Pearson" + }, + { + "href": "https://api.w3.org/participations/28689", + "title": "Paul Worrall" + }, + { + "href": "https://api.w3.org/participations/28695", + "title": "Iron Horse Software, LLC" + }, + { + "href": "https://api.w3.org/participations/28711", + "title": "Yehua Chen" + }, + { + "href": "https://api.w3.org/participations/28726", + "title": "Adobe" + }, + { + "href": "https://api.w3.org/participations/28847", + "title": "Wageningen University" + }, + { + "href": "https://api.w3.org/participations/28929", + "title": "Fraunhofer Gesellschaft" + }, + { + "href": "https://api.w3.org/participations/28940", + "title": "Christine Perey" + }, + { + "href": "https://api.w3.org/participations/29037", + "title": "Sylvain Saint-André" + }, + { + "href": "https://api.w3.org/participations/29059", + "title": "Fundacion CTIC" + }, + { + "href": "https://api.w3.org/participations/29337", + "title": "Electronics and Telecommunications Research Institute (ETRI)" + }, + { + "href": "https://api.w3.org/participations/29344", + "title": "Noel De Martin" + }, + { + "href": "https://api.w3.org/participations/29354", + "title": "Mark Thompson" + }, + { + "href": "https://api.w3.org/participations/29425", + "title": "Mark Senefsky" + }, + { + "href": "https://api.w3.org/participations/29476", + "title": "Aron Homberg" + }, + { + "href": "https://api.w3.org/participations/29603", + "title": "Kayode Ezike" + }, + { + "href": "https://api.w3.org/participations/30092", + "title": "Daniel Zuckerman" + }, + { + "href": "https://api.w3.org/participations/30531", + "title": "Charity Langley" + }, + { + "href": "https://api.w3.org/participations/30681", + "title": "david faveris" + }, + { + "href": "https://api.w3.org/participations/30682", + "title": "Ali Method" + }, + { + "href": "https://api.w3.org/participations/30960", + "title": "X-Line Consulting" + }, + { + "href": "https://api.w3.org/participations/31105", + "title": "Massachusetts Institute of Technology (MIT)" + }, + { + "href": "https://api.w3.org/participations/31168", + "title": "FPS BOSA" + }, + { + "href": "https://api.w3.org/participations/31394", + "title": "Rishabh Gupta" + }, + { + "href": "https://api.w3.org/participations/31532", + "title": "Rahul Gupta" + }, + { + "href": "https://api.w3.org/participations/31942", + "title": "Leon Porter" + }, + { + "href": "https://api.w3.org/participations/32035", + "title": "CERN" + }, + { + "href": "https://api.w3.org/participations/32062", + "title": "Edwin Steiner" + }, + { + "href": "https://api.w3.org/participations/32069", + "title": "Dana Scott" + }, + { + "href": "https://api.w3.org/participations/32534", + "title": "kofi kyei" + }, + { + "href": "https://api.w3.org/participations/32541", + "title": "Underwriters Laboratories - Transaction Security" + }, + { + "href": "https://api.w3.org/participations/32587", + "title": "REDPENCIL" + }, + { + "href": "https://api.w3.org/participations/32752", + "title": "Malta College of Arts, Science and Technology" + }, + { + "href": "https://api.w3.org/participations/32764", + "title": "Kevin Poulsen" + }, + { + "href": "https://api.w3.org/participations/32779", + "title": "Ekseli Oy" + }, + { + "href": "https://api.w3.org/participations/32827", + "title": "Michaël Dierick" + }, + { + "href": "https://api.w3.org/participations/32950", + "title": "Graphmetrix, Inc." + }, + { + "href": "https://api.w3.org/participations/32978", + "title": "Epsilon" + }, + { + "href": "https://api.w3.org/participations/32994", + "title": "Michael Pelikan" + }, + { + "href": "https://api.w3.org/participations/33186", + "title": "Jan Schill" + }, + { + "href": "https://api.w3.org/participations/33187", + "title": "Tim Berners-Lee" + }, + { + "href": "https://api.w3.org/participations/33285", + "title": "Brian Kim" + }, + { + "href": "https://api.w3.org/participations/33286", + "title": "Souen Mazouin" + }, + { + "href": "https://api.w3.org/participations/33290", + "title": "JointSpace" + }, + { + "href": "https://api.w3.org/participations/33340", + "title": "Han Su" + }, + { + "href": "https://api.w3.org/participations/33399", + "title": "Ashish S Sharma" + }, + { + "href": "https://api.w3.org/participations/33400", + "title": "Rami Rustom" + }, + { + "href": "https://api.w3.org/participations/33433", + "title": "Kai Chen" + }, + { + "href": "https://api.w3.org/participations/33438", + "title": "Michael Paduch" + }, + { + "href": "https://api.w3.org/participations/33441", + "title": "Michael Herman" + }, + { + "href": "https://api.w3.org/participations/33442", + "title": "Santi Lozano" + }, + { + "href": "https://api.w3.org/participations/33448", + "title": "Syed Ali Raza Zaidi" + }, + { + "href": "https://api.w3.org/participations/33458", + "title": "Christophe R Patraldo" + }, + { + "href": "https://api.w3.org/participations/33466", + "title": "Devaraj Muthuvelmanickam" + }, + { + "href": "https://api.w3.org/participations/33503", + "title": "Datavillage" + }, + { + "href": "https://api.w3.org/participations/33514", + "title": "Jegan Davies-Jones" + }, + { + "href": "https://api.w3.org/participations/33516", + "title": "Pol Alvarez" + }, + { + "href": "https://api.w3.org/participations/33536", + "title": "Findwise" + }, + { + "href": "https://api.w3.org/participations/33543", + "title": "Lauernce Zhang" + }, + { + "href": "https://api.w3.org/participations/33570", + "title": "Pavlos Pseftoyiannis" + }, + { + "href": "https://api.w3.org/participations/33580", + "title": "Andreas Prieß" + }, + { + "href": "https://api.w3.org/participations/33588", + "title": "John Yu" + }, + { + "href": "https://api.w3.org/participations/33594", + "title": "日照鲜购电子商务有限公司" + }, + { + "href": "https://api.w3.org/participations/33610", + "title": "Taekhoon Kim" + }, + { + "href": "https://api.w3.org/participations/33684", + "title": "Gordana Halavanja" + }, + { + "href": "https://api.w3.org/participations/33692", + "title": "Matthew Fowle" + }, + { + "href": "https://api.w3.org/participations/33725", + "title": "Bert Jehoul" + }, + { + "href": "https://api.w3.org/participations/33733", + "title": "Tuitt Philippines, Inc." + }, + { + "href": "https://api.w3.org/participations/33767", + "title": "Carlo Tosoni" + }, + { + "href": "https://api.w3.org/participations/33770", + "title": "Ping Identity" + }, + { + "href": "https://api.w3.org/participations/33818", + "title": "Zongyan Li" + }, + { + "href": "https://api.w3.org/participations/33836", + "title": "Richard Marshall" + }, + { + "href": "https://api.w3.org/participations/33837", + "title": "reconoser ID" + }, + { + "href": "https://api.w3.org/participations/33880", + "title": "Eamonn Costello" + }, + { + "href": "https://api.w3.org/participations/33918", + "title": "James Birmingham" + }, + { + "href": "https://api.w3.org/participations/33919", + "title": "Universidad Politécnica de Madrid" + }, + { + "href": "https://api.w3.org/participations/33948", + "title": "Wouter Kok" + }, + { + "href": "https://api.w3.org/participations/34004", + "title": "Cetis LLP" + }, + { + "href": "https://api.w3.org/participations/34105", + "title": "deb daniel" + }, + { + "href": "https://api.w3.org/participations/34163", + "title": "27th Cross LLC" + }, + { + "href": "https://api.w3.org/participations/34257", + "title": "Gary Murphy" + }, + { + "href": "https://api.w3.org/participations/34270", + "title": "Woods Denny" + }, + { + "href": "https://api.w3.org/participations/34348", + "title": "Onur Yüksel" + }, + { + "href": "https://api.w3.org/participations/34416", + "title": "Maico Oliveira Buss" + }, + { + "href": "https://api.w3.org/participations/34436", + "title": "KONA" + }, + { + "href": "https://api.w3.org/participations/34458", + "title": "Airbnb Inc" + }, + { + "href": "https://api.w3.org/participations/34516", + "title": "Cronos Groep NV" + }, + { + "href": "https://api.w3.org/participations/34614", + "title": "Sheff Engi" + }, + { + "href": "https://api.w3.org/participations/34886", + "title": "soonkuk kang" + }, + { + "href": "https://api.w3.org/participations/35045", + "title": "Alessio Nobile" + }, + { + "href": "https://api.w3.org/participations/35054", + "title": "lin ye" + }, + { + "href": "https://api.w3.org/participations/35064", + "title": "bin ke" + }, + { + "href": "https://api.w3.org/participations/35220", + "title": "Department for Work and Pensions" + }, + { + "href": "https://api.w3.org/participations/35243", + "title": "Sakak" + }, + { + "href": "https://api.w3.org/participations/35367", + "title": "Akshay Kanthi" + }, + { + "href": "https://api.w3.org/participations/35471", + "title": "Zixuan Chen" + }, + { + "href": "https://api.w3.org/participations/35516", + "title": "Yahoo Holdings Inc." + }, + { + "href": "https://api.w3.org/participations/35528", + "title": "Adams Gravitis" + }, + { + "href": "https://api.w3.org/participations/35593", + "title": "University of Southern California" + }, + { + "href": "https://api.w3.org/participations/35594", + "title": "Barath Raghavan" + }, + { + "href": "https://api.w3.org/participations/35603", + "title": "Chunghwa Telecom Company, Ltd." + }, + { + "href": "https://api.w3.org/participations/35674", + "title": "Università della Svizzera italiana" + }, + { + "href": "https://api.w3.org/participations/35730", + "title": "Michiel Bellens" + }, + { + "href": "https://api.w3.org/participations/35762", + "title": "Vivien Kraus" + }, + { + "href": "https://api.w3.org/participations/35774", + "title": "Digita" + }, + { + "href": "https://api.w3.org/participations/36366", + "title": "Leif Johansson" + }, + { + "href": "https://api.w3.org/participations/36392", + "title": "Muze" + }, + { + "href": "https://api.w3.org/participations/36427", + "title": "Kurt Cagle" + }, + { + "href": "https://api.w3.org/participations/36534", + "title": "Pierre-Antoine Champin" + }, + { + "href": "https://api.w3.org/participations/36552", + "title": "Rafael Richards" + }, + { + "href": "https://api.w3.org/participations/36692", + "title": "Guilherme Siquinelli" + }, + { + "href": "https://api.w3.org/participations/36693", + "title": "LG Electronics" + }, + { + "href": "https://api.w3.org/participations/36708", + "title": "Norwegian Agency for Development Cooperation" + }, + { + "href": "https://api.w3.org/participations/36818", + "title": "British Broadcasting Corporation" + }, + { + "href": "https://api.w3.org/participations/36824", + "title": "Khaled Mathlouthi" + }, + { + "href": "https://api.w3.org/participations/36827", + "title": "Kushal Das" + }, + { + "href": "https://api.w3.org/participations/36849", + "title": "damodara _" + }, + { + "href": "https://api.w3.org/participations/36942", + "title": "Kévin Dunglas" + }, + { + "href": "https://api.w3.org/participations/36985", + "title": "BT" + }, + { + "href": "https://api.w3.org/participations/37002", + "title": "Yatharth (Arjun) Mishra" + }, + { + "href": "https://api.w3.org/participations/37061", + "title": "Kevel" + }, + { + "href": "https://api.w3.org/participations/37144", + "title": "Oshani Seneviratne" + }, + { + "href": "https://api.w3.org/participations/37190", + "title": "Peter Smith" + }, + { + "href": "https://api.w3.org/participations/37387", + "title": "Yvo Brevoort" + }, + { + "href": "https://api.w3.org/participations/37773", + "title": "Thorus Technologies Ltd" + }, + { + "href": "https://api.w3.org/participations/37906", + "title": "Brickdoc" + }, + { + "href": "https://api.w3.org/participations/38237", + "title": "Gourab Saha" + }, + { + "href": "https://api.w3.org/participations/38436", + "title": "Defense Information Systems Agency" + }, + { + "href": "https://api.w3.org/participations/38443", + "title": "Institut Mines-Télécom" + }, + { + "href": "https://api.w3.org/participations/38528", + "title": "Ghent University" + }, + { + "href": "https://api.w3.org/participations/38531", + "title": "Sindhu Raju" + }, + { + "href": "https://api.w3.org/participations/38548", + "title": "Amod Malviya" + }, + { + "href": "https://api.w3.org/participations/38580", + "title": "Institut National de Recherche en Informatique et en Automatique (Inria)" + }, + { + "href": "https://api.w3.org/participations/38608", + "title": "Alexandria Consulting" + }, + { + "href": "https://api.w3.org/participations/38609", + "title": "Eric Jahn" + }, + { + "href": "https://api.w3.org/participations/38655", + "title": "Federated Knowledge, LLC" + }, + { + "href": "https://api.w3.org/participations/38696", + "title": "Semantyk" + }, + { + "href": "https://api.w3.org/participations/38699", + "title": "Diaphanous" + }, + { + "href": "https://api.w3.org/participations/38715", + "title": "Lab Objects Corp" + }, + { + "href": "https://api.w3.org/participations/38717", + "title": "Arne Hassel" + }, + { + "href": "https://api.w3.org/participations/38745", + "title": "Hong Sun" + }, + { + "href": "https://api.w3.org/participations/38750", + "title": "Gabriel Rosset" + }, + { + "href": "https://api.w3.org/participations/38867", + "title": "Amber Blue" + }, + { + "href": "https://api.w3.org/participations/38917", + "title": "Harshvardhan J. Pandit" + }, + { + "href": "https://api.w3.org/participations/38940", + "title": "Forschungszentrum Informatik (FZI)" + }, + { + "href": "https://api.w3.org/participations/39059", + "title": "EMILI Canada" + }, + { + "href": "https://api.w3.org/participations/39070", + "title": "Gerald Melles" + }, + { + "href": "https://api.w3.org/participations/39148", + "title": "Eric Prud'hommeaux" + }, + { + "href": "https://api.w3.org/participations/39179", + "title": "Globe Protocol" + }, + { + "href": "https://api.w3.org/participations/39292", + "title": "Alibaba Group" + }, + { + "href": "https://api.w3.org/participations/39350", + "title": "biagio boi" + }, + { + "href": "https://api.w3.org/participations/39351", + "title": "Joachim Van Herwegen" + }, + { + "href": "https://api.w3.org/participations/39353", + "title": "Jeroen Knoops" + }, + { + "href": "https://api.w3.org/participations/39452", + "title": "Paul Daly" + }, + { + "href": "https://api.w3.org/participations/39460", + "title": "Sarven Capadisli" + }, + { + "href": "https://api.w3.org/participations/39511", + "title": "Digitaal Vlaanderen" + }, + { + "href": "https://api.w3.org/participations/39591", + "title": "Alan Davies" + }, + { + "href": "https://api.w3.org/participations/39625", + "title": "Eugene Park" + }, + { + "href": "https://api.w3.org/participations/39819", + "title": "Ponder Source" + }, + { + "href": "https://api.w3.org/participations/39889", + "title": "Ram Kripa" + }, + { + "href": "https://api.w3.org/participations/39916", + "title": "Konstantinos Kotis" + }, + { + "href": "https://api.w3.org/participations/39942", + "title": "Khresterion" + }, + { + "href": "https://api.w3.org/participations/39986", + "title": "Meindert Osinga" + }, + { + "href": "https://api.w3.org/participations/40059", + "title": "Kabul Kurniawan" + }, + { + "href": "https://api.w3.org/participations/40227", + "title": "Han Wammes" + }, + { + "href": "https://api.w3.org/participations/40359", + "title": "Wouter Termont" + }, + { + "href": "https://api.w3.org/participations/40366", + "title": "University of Strathclyde" + }, + { + "href": "https://api.w3.org/participations/40385", + "title": "Friedrich Alexander-University of Erlangen-Nürnberg" + }, + { + "href": "https://api.w3.org/participations/40386", + "title": "O.team" + }, + { + "href": "https://api.w3.org/participations/40425", + "title": "Renoir Boulanger" + }, + { + "href": "https://api.w3.org/participations/40587", + "title": "Sharon Stratsianis" + }, + { + "href": "https://api.w3.org/participations/40648", + "title": "Jonas Smedegaard" + }, + { + "href": "https://api.w3.org/participations/40763", + "title": "Chiali Tsai" + }, + { + "href": "https://api.w3.org/participations/40779", + "title": "Technische Universität Dresden" + }, + { + "href": "https://api.w3.org/participations/40780", + "title": "Ministry of Digital Affairs, Taiwan" + }, + { + "href": "https://api.w3.org/participations/40783", + "title": "Huawei" + }, + { + "href": "https://api.w3.org/participations/40863", + "title": "Aggadom" + }, + { + "href": "https://api.w3.org/participations/40919", + "title": "Miguel Ceriani" + }, + { + "href": "https://api.w3.org/participations/40942", + "title": "Thierry Marianne" + }, + { + "href": "https://api.w3.org/participations/40944", + "title": "Daniel Vangrieken" + }, + { + "href": "https://api.w3.org/participations/40954", + "title": "Matthieu Bosquet" + }, + { + "href": "https://api.w3.org/participations/40960", + "title": "Travis Vachon" + }, + { + "href": "https://api.w3.org/participations/41002", + "title": "John Kirkwood" + }, + { + "href": "https://api.w3.org/participations/41055", + "title": "Digital Bazaar" + }, + { + "href": "https://api.w3.org/participations/41103", + "title": "University of Oxford" + }, + { + "href": "https://api.w3.org/participations/41123", + "title": "thosleaf thos" + } + ], + "self": { + "href": "https://api.w3.org/groups/cg/solid/participations?page=1&items=1000" + }, + "first": { + "href": "https://api.w3.org/groups/cg/solid/participations?page=1&items=1000" + }, + "last": { + "href": "https://api.w3.org/groups/cg/solid/participations?page=1&items=1000" + } + } +} \ No newline at end of file diff --git a/cg.solid.users.json b/cg.solid.users.json new file mode 100644 index 00000000..69d294dd --- /dev/null +++ b/cg.solid.users.json @@ -0,0 +1,1377 @@ +{ + "page": 1, + "limit": 1000, + "pages": 1, + "total": 271, + "_links": { + "up": { + "href": "https://api.w3.org/groups/cg/solid" + }, + "users": [ + { + "href": "https://api.w3.org/users/dfoxubp7p5sg8wo0k0w4ws48s8w444g", + "title": "damodara _", + "former": false + }, + { + "href": "https://api.w3.org/users/4hg2nwvxidus8gogcscgkwwg0sokk8", + "title": "Mike Adams", + "former": false + }, + { + "href": "https://api.w3.org/users/aqh8x84joso448g0ggg88k4o0o008kg", + "title": "Benoit Alessandroni", + "former": false + }, + { + "href": "https://api.w3.org/users/cv2aqq1at68soo4oc8ggok888g4844c", + "title": "Khalid Alnuaim", + "former": false + }, + { + "href": "https://api.w3.org/users/qr8dwote0iog08wwg4w0koo4ogcg00g", + "title": "Pol Alvarez", + "former": false + }, + { + "href": "https://api.w3.org/users/3jofbgow1l44ksocosg8wg4080g48go", + "title": "Fong An", + "former": false + }, + { + "href": "https://api.w3.org/users/pectasibqkg4wkgs4c0o84wgg4wwk48", + "title": "Amin Anjomshoaa", + "former": false + }, + { + "href": "https://api.w3.org/users/24xlu77kh5340ws8wcc80swwgo0kksk", + "title": "Billy Wilson Arante", + "former": false + }, + { + "href": "https://api.w3.org/users/osom446dun4kc8s8gkg8k0ks840wooc", + "title": "Angel Araya", + "former": false + }, + { + "href": "https://api.w3.org/users/jwtjh0djnaoos00c00cw4kg4kgwsw0k", + "title": "Dörthe Arndt", + "former": false + }, + { + "href": "https://api.w3.org/users/74vbvohhtm4o48k8cock8w40o8wkokw", + "title": "Geongyu Bae", + "former": false + }, + { + "href": "https://api.w3.org/users/1j3s1yktqopws08g0kw0kk0s40ogo4c", + "title": "Sina Bahram", + "former": false + }, + { + "href": "https://api.w3.org/users/odhd51st2ogcck484ogkgoc4008g000", + "title": "Daniel Bakas", + "former": false + }, + { + "href": "https://api.w3.org/users/7o82dsw2vns40okkgw80oc804g4ko0k", + "title": "Wendell Baker", + "former": false + }, + { + "href": "https://api.w3.org/users/tw3nw1pbm7kow8wk004o8owcso0kck4", + "title": "Virginia Balseiro", + "former": false + }, + { + "href": "https://api.w3.org/users/167vdus9vam8swg0wkogokwso0s0cw0", + "title": "Arnav Bansal", + "former": false + }, + { + "href": "https://api.w3.org/users/sra7xtxt39wo0sgc8wc8gc0sksw00sw", + "title": "Fabio Barone", + "former": false + }, + { + "href": "https://api.w3.org/users/rj1foj3ih008g8okk8wg4g88kkckk4g", + "title": "Michiel Bellens", + "former": false + }, + { + "href": "https://api.w3.org/users/569ct2hcz748oc8s0kgcsksococo0sg", + "title": "Tim Berners-Lee", + "former": false + }, + { + "href": "https://api.w3.org/users/ksx3at9vlzk8oko488wgskcogkok00", + "title": "Elettra Bietti", + "former": false + }, + { + "href": "https://api.w3.org/users/oc58rv18da8w0cwc8woosgok84sskoc", + "title": "Justin Bingham", + "former": false + }, + { + "href": "https://api.w3.org/users/qlj2vr0kihc8sk48k8skc08oo8kkw8w", + "title": "James Birmingham", + "former": false + }, + { + "href": "https://api.w3.org/users/9rh7ppltec08c4c4w0k4wccwoo8gggo", + "title": "bob bishop", + "former": false + }, + { + "href": "https://api.w3.org/users/sqc2jpv7z1w84k0cocwsgowskg08g0o", + "title": "Amber Blue", + "former": false + }, + { + "href": "https://api.w3.org/users/8g2dg76zcr8c04w4scwo8844k88oo04", + "title": "biagio boi", + "former": false + }, + { + "href": "https://api.w3.org/users/8bwewkojcdgk4ggo008gww0ogos0o4w", + "title": "Matthieu Bosquet", + "former": false + }, + { + "href": "https://api.w3.org/users/htmer29qpmgws40wcgk080cwogskgwo", + "title": "Renoir Boulanger", + "former": false + }, + { + "href": "https://api.w3.org/users/hzy9s776lb4kwcos4g0swk8cwg0ks4o", + "title": "Alain Bourgeois", + "former": false + }, + { + "href": "https://api.w3.org/users/grqxr20vpm0oogko448occ4cgwcsg4k", + "title": "Christoph Braun", + "former": false + }, + { + "href": "https://api.w3.org/users/jcxg7k9k9q0w8wcokw0og44wccgo404", + "title": "Yvo Brevoort", + "former": false + }, + { + "href": "https://api.w3.org/users/4kfyesduxlog4oo8g0cs88800swcogo", + "title": "John Bruce", + "former": false + }, + { + "href": "https://api.w3.org/users/qomkbfn488goso8s8scs0cgock008cg", + "title": "Peter Bruhn Andersen", + "former": false + }, + { + "href": "https://api.w3.org/users/ijow8431u3kgok84gs8o4s0gg0w00g0", + "title": "Christian Buggedei", + "former": false + }, + { + "href": "https://api.w3.org/users/9a26fdb3yqskoks88gkw4gwocscgk4o", + "title": "Kurt Cagle", + "former": false + }, + { + "href": "https://api.w3.org/users/lfjbzotqllw4sgcs4wc044wk8g004wc", + "title": "huanyu cai", + "former": false + }, + { + "href": "https://api.w3.org/users/d3sh0ism2z488wcoo4gs8g0g0s0ws8k", + "title": "Sarven Capadisli", + "former": false + }, + { + "href": "https://api.w3.org/users/srekwclwff48ws0g4g8wow8ow88cwko", + "title": "Melvin Carvalho", + "former": false + }, + { + "href": "https://api.w3.org/users/es8dmeqac1kwckoc40840wcggsg4048", + "title": "Miguel Ceriani", + "former": false + }, + { + "href": "https://api.w3.org/users/t891ludoisggsccsw44o8goccc0s0ks", + "title": "Pierre-Antoine Champin", + "former": false + }, + { + "href": "https://api.w3.org/users/p8uhznaq53kc8osggc884gow0okkowg", + "title": "Kai Chen", + "former": false + }, + { + "href": "https://api.w3.org/users/9jz2l6azd9gk8cgs0oo84osok8wwoo0", + "title": "Tao Chen", + "former": false + }, + { + "href": "https://api.w3.org/users/swwbac51eaog4c88gkk84cw4coko8cw", + "title": "Yehua Chen", + "former": false + }, + { + "href": "https://api.w3.org/users/2h3yv3tol16oc044cg8g8okwcokcogs", + "title": "Zixuan Chen", + "former": false + }, + { + "href": "https://api.w3.org/users/tq081h6gia88s40w00k08ks8ogck4g4", + "title": "Hua-Rong Chu", + "former": false + }, + { + "href": "https://api.w3.org/users/2qp6vzbh7xus0w80cksgs844w0s84cs", + "title": "Andrea Cimmino", + "former": false + }, + { + "href": "https://api.w3.org/users/frz2wf4cjs8o4oowcskwc8w8w0o0c84", + "title": "Andrei Ciortea", + "former": false + }, + { + "href": "https://api.w3.org/users/9ywxhdp4hmgwss84sw00cosw8c4s8w0", + "title": "Aaron Coburn", + "former": false + }, + { + "href": "https://api.w3.org/users/ezvitrntdjww4co80448o80o8008wg", + "title": "Eamonn Costello", + "former": false + }, + { + "href": "https://api.w3.org/users/p403wmwjdlc8008gscg84ko0s8wso4g", + "title": "David Dabbs", + "former": false + }, + { + "href": "https://api.w3.org/users/hr6bbpjqqfsckgs8woosow4ckcco40c", + "title": "April Daly", + "former": false + }, + { + "href": "https://api.w3.org/users/j3qv3jpkfrsc4cos0g0w8c84kc48wc0", + "title": "Paul Daly", + "former": false + }, + { + "href": "https://api.w3.org/users/tg86bczlfeowkwkk44ogg4g0gg8cc08", + "title": "deb daniel", + "former": false + }, + { + "href": "https://api.w3.org/users/6dcd90z011k44880gg4wk4ww4kw84k4", + "title": "Kushal Das", + "former": false + }, + { + "href": "https://api.w3.org/users/ixlji1lgpnw48gsg40840skwgcww84s", + "title": "Alan Davies", + "former": false + }, + { + "href": "https://api.w3.org/users/267qrq1i66kkogosgg8gc88osogo8so", + "title": "Jegan Davies-Jones", + "former": false + }, + { + "href": "https://api.w3.org/users/g4ha5ajke5w80o8cgc4ssgwck8wwgsk", + "title": "Michiel de Jong", + "former": false + }, + { + "href": "https://api.w3.org/users/iaxqurzbgjk0w8osksskwc04cwoogo", + "title": "Esther De Loof", + "former": false + }, + { + "href": "https://api.w3.org/users/r0pj1qio62o48g4ocosokcc480skowo", + "title": "Noel De Martin", + "former": false + }, + { + "href": "https://api.w3.org/users/1z17voq0ro9w88w844cs4k08kkckc44", + "title": "Laurens Debackere", + "former": false + }, + { + "href": "https://api.w3.org/users/e7q9m39829cs0ccs8gwoowk4w4g0wkc", + "title": "Paul deGrandis", + "former": false + }, + { + "href": "https://api.w3.org/users/hvh0950nac084ggo40w0000k4g8cscs", + "title": "Woods Denny", + "former": false + }, + { + "href": "https://api.w3.org/users/qbiv1d8f6tcwk8k4wg8o0wkkswoc4c8", + "title": "Michaël Dierick", + "former": false + }, + { + "href": "https://api.w3.org/users/q6223y79aus8ok0c88k4s0gssosss0k", + "title": "Li Ding", + "former": false + }, + { + "href": "https://api.w3.org/users/djqvhp5i6k0skscc0ccs08ow4g0coo0", + "title": "Huw Diprose", + "former": false + }, + { + "href": "https://api.w3.org/users/t2g716zpx74ckocsskgcg88c4840cgs", + "title": "James Doe", + "former": false + }, + { + "href": "https://api.w3.org/users/q6ng8t0z0iswsk44g4gkogg4gwwg488", + "title": "Sébastien Dubois", + "former": false + }, + { + "href": "https://api.w3.org/users/o0lcrio2jyo8ggwog0wowo4go8s808k", + "title": "Philippe Duchesne", + "former": false + }, + { + "href": "https://api.w3.org/users/bg20qm676p4o80k4wsoocs4sws8wsg4", + "title": "Kévin Dunglas", + "former": false + }, + { + "href": "https://api.w3.org/users/m28irpx6b3ko04w8okkkggwccc4wogg", + "title": "Pete Edwards", + "former": false + }, + { + "href": "https://api.w3.org/users/1e2yqn4gfao04ggwow8c8s440k00owk", + "title": "Pavlik elf", + "former": false + }, + { + "href": "https://api.w3.org/users/he18csvulzsc4oco080wwcs4wkokg40", + "title": "Sheff Engi", + "former": false + }, + { + "href": "https://api.w3.org/users/9xqv2mqdlw084ccgsgsscgc8o88w0ws", + "title": "Albert Esterline", + "former": false + }, + { + "href": "https://api.w3.org/users/n32yqlul2v44g0o0go4sw8ccwggs0cs", + "title": "Beatriz Esteves", + "former": false + }, + { + "href": "https://api.w3.org/users/t5iqyd0baysg84c8k8gwos8cgg0s0s0", + "title": "Matthias Evering", + "former": false + }, + { + "href": "https://api.w3.org/users/3f8jhytue86cos4sg8o0s0gkgwcoo0s", + "title": "Kayode Ezike", + "former": false + }, + { + "href": "https://api.w3.org/users/zcgxhtilecgk84c884s0k8oc8cgc8g", + "title": "david faveris", + "former": false + }, + { + "href": "https://api.w3.org/users/7pwe6sp7aekogo0wscwgc04cskcsw04", + "title": "Matthew Fowle", + "former": false + }, + { + "href": "https://api.w3.org/users/o8gd42e3df4okco0g0c480ogkskwgso", + "title": "Thomas Gallagher", + "former": false + }, + { + "href": "https://api.w3.org/users/26iu2fcd7ukg800k84sckoosgok4gws", + "title": "Caroline Gans Combe", + "former": false + }, + { + "href": "https://api.w3.org/users/desml54m8hwkwgsc480c8c08owwk0ko", + "title": "Jeeth Garageshwara", + "former": false + }, + { + "href": "https://api.w3.org/users/ar9jbsakty8gw0w4gwcgw4s80oswgwg", + "title": "Frederick Gibson", + "former": false + }, + { + "href": "https://api.w3.org/users/gudi61ccgnww88s0oow00s0cwc8kc4o", + "title": "Kai Gilb", + "former": false + }, + { + "href": "https://api.w3.org/users/4r119s0p5hgksw400g48gos4oskscs8", + "title": "Seila Gonzalez Estrecha", + "former": false + }, + { + "href": "https://api.w3.org/users/e2zc6tsuz6oko08088oswcwcswc0swg", + "title": "Simon Grant", + "former": false + }, + { + "href": "https://api.w3.org/users/r7c2t7hmssg4o8goggkwo08wcgs8ko4", + "title": "Adams Gravitis", + "former": false + }, + { + "href": "https://api.w3.org/users/r1dl92634q8oksc84808s004k4gogc0", + "title": "Rahul Gupta", + "former": false + }, + { + "href": "https://api.w3.org/users/cbnciy7ced4w4g8cgogocso88kco0cw", + "title": "Rishabh Gupta", + "former": false + }, + { + "href": "https://api.w3.org/users/rrnxaq3jdo0sokw08o0os80soccsgww", + "title": "Amy Guy", + "former": false + }, + { + "href": "https://api.w3.org/users/tk99kcnutuogog4oso4ckscgwc88ssk", + "title": "Tom Haegemans", + "former": false + }, + { + "href": "https://api.w3.org/users/hivcb94mffso8cwkks4wwg8g84o4k0k", + "title": "Gordana Halavanja", + "former": false + }, + { + "href": "https://api.w3.org/users/kz2z0fh9q7ksccg0swcs0ogwc80g4sg", + "title": "Charlie Halford", + "former": false + }, + { + "href": "https://api.w3.org/users/ckw4u3x9vbk8kk8cgc8kg0s4wkkcw8g", + "title": "Bart Hanssens", + "former": false + }, + { + "href": "https://api.w3.org/users/p4l445fn24g0ckosc8csw884gwo040o", + "title": "Arne Hassel", + "former": false + }, + { + "href": "https://api.w3.org/users/7879eud0e8w0s4s4g0wgccggogs4s4c", + "title": "Michael Herman", + "former": false + }, + { + "href": "https://api.w3.org/users/orefhio3khcsggsogkgko84skw4wksg", + "title": "RJ Herrick", + "former": false + }, + { + "href": "https://api.w3.org/users/1r8xdexxh4xwg84gcw04csks8k8socg", + "title": "Aron Homberg", + "former": false + }, + { + "href": "https://api.w3.org/users/vp3rxil47r4wssco84kcks0c0cwo00", + "title": "Ross Horne", + "former": false + }, + { + "href": "https://api.w3.org/users/izincq0n5jc4gsck4cosocow8wok04g", + "title": "Knut-Olav Hoven", + "former": false + }, + { + "href": "https://api.w3.org/users/p3jwrjm7dog0sk0k8wwks0sc00sgwwg", + "title": "Yen-Lin Huang", + "former": false + }, + { + "href": "https://api.w3.org/users/90uuffxqm1og0wkw8wgwswwgoo0wko8", + "title": "Mark Hughes", + "former": false + }, + { + "href": "https://api.w3.org/users/i5qe4j6zlrksowk0koow40g08c4o84c", + "title": "Eduardo Ibacache Rodriguez", + "former": false + }, + { + "href": "https://api.w3.org/users/e7isfjeac5s84owowgkos48wsow0cs4", + "title": "Kingsley Idehen", + "former": false + }, + { + "href": "https://api.w3.org/users/hbp2gvma85k404g0osggkwswkkk0wos", + "title": "Eric Jahn", + "former": false + }, + { + "href": "https://api.w3.org/users/lx5u09kxfi84skkos0g0swsw0sgswsk", + "title": "Bert Jehoul", + "former": false + }, + { + "href": "https://api.w3.org/users/q6rfb8i0btcc4s08go48kcc8g44c4ws", + "title": "Kerensa Jennings", + "former": false + }, + { + "href": "https://api.w3.org/users/fxulw40dd40g4csswk84wc0ocggw4cw", + "title": "Saiqi Jia", + "former": false + }, + { + "href": "https://api.w3.org/users/nwcvz5oeepcscwo4o0cw884cgc4488w", + "title": "Leif Johansson", + "former": false + }, + { + "href": "https://api.w3.org/users/11sd3pz4suu8gw0ckk04kc00w0s8gcs", + "title": "Brad Jones", + "former": false + }, + { + "href": "https://api.w3.org/users/mv6wjn7embk0wc008so0w8wwo8coocs", + "title": "aligo Kang", + "former": false + }, + { + "href": "https://api.w3.org/users/46w155wuzdickwg448gcwkcssccswcs", + "title": "soonkuk kang", + "former": false + }, + { + "href": "https://api.w3.org/users/gxbopsjdc54wwgcsokwgkssckggkswo", + "title": "Akshay Kanthi", + "former": false + }, + { + "href": "https://api.w3.org/users/ol2za34ywcgwgw0c8kwg0wg0o8wcokk", + "title": "bin ke", + "former": false + }, + { + "href": "https://api.w3.org/users/lqledmhbff4cos4kgockcokwkcokw40", + "title": "Brian Kim", + "former": false + }, + { + "href": "https://api.w3.org/users/e4ya2uav248wkk8c8wocgsowg4og4ks", + "title": "Taekhoon Kim", + "former": false + }, + { + "href": "https://api.w3.org/users/30lml3qphxycg0cooswwgs0cc0oo0so", + "title": "John Kirkwood", + "former": false + }, + { + "href": "https://api.w3.org/users/bynvbi9gv74s4800wg80okkwos48woc", + "title": "Sabrina Kirrane", + "former": false + }, + { + "href": "https://api.w3.org/users/o20ea2dodz4400w8gkwg4w488kkkcsc", + "title": "Kjetil Kjernsmo", + "former": false + }, + { + "href": "https://api.w3.org/users/sg7c9bxes74w8k8k0kk4swkw8ww8k8g", + "title": "Jeroen Knoops", + "former": false + }, + { + "href": "https://api.w3.org/users/kumrbt8b15c8scooc8gkkwk044osk00", + "title": "Wouter Kok", + "former": false + }, + { + "href": "https://api.w3.org/users/8k2xjrhl9nokkgc008s404wk088wkcs", + "title": "Konstantinos Kotis", + "former": false + }, + { + "href": "https://api.w3.org/users/ap5biltt5w084w8owsksgo4sgksgws8", + "title": "Vivien Kraus", + "former": false + }, + { + "href": "https://api.w3.org/users/8b7c6gsg0k0scksk8s8g0skso4k0ook", + "title": "Ram Kripa", + "former": false + }, + { + "href": "https://api.w3.org/users/scntutspqyo4skcgs8k8ccgkw0scgw4", + "title": "Frank Kroon", + "former": false + }, + { + "href": "https://api.w3.org/users/b5e4bv0yac8cwwgc808g0skggw84cok", + "title": "Ganesh Kumble", + "former": false + }, + { + "href": "https://api.w3.org/users/8b14iqxljz0gk8kc08c4kco044wog8k", + "title": "Kabul Kurniawan", + "former": false + }, + { + "href": "https://api.w3.org/users/myrbjsy2z0gwc44c4sg0os0wc0wccww", + "title": "kofi kyei", + "former": false + }, + { + "href": "https://api.w3.org/users/5qssfafaghc8cocsg8g4g4cc8wwc8ww", + "title": "Inge La Riviere", + "former": false + }, + { + "href": "https://api.w3.org/users/qf7jsf8u7cgokg0csk00co40gc0ckgw", + "title": "Jose Emilio Labra Gayo", + "former": false + }, + { + "href": "https://api.w3.org/users/4qkfr6af8xog8gs8wgw00swkc44sk08", + "title": "Fredric Landqvist", + "former": false + }, + { + "href": "https://api.w3.org/users/27ztcufejq808g8wgw8g0co0wg8sokc", + "title": "Samu Lang", + "former": false + }, + { + "href": "https://api.w3.org/users/33hru18jhtog80s0gk4s0gok0c0gk0k", + "title": "Charity Langley", + "former": false + }, + { + "href": "https://api.w3.org/users/eww7umkxvm0440o84sgkcwogogw00sc", + "title": "Philip Laszkowicz", + "former": false + }, + { + "href": "https://api.w3.org/users/il0mhus525w8ok4g080wos4cgocgk48", + "title": "Sylvain Le Bon", + "former": false + }, + { + "href": "https://api.w3.org/users/f2cru1oejg0swsso48koosggw80sc4c", + "title": "Maxime Lecoq", + "former": false + }, + { + "href": "https://api.w3.org/users/kgr6ya2wfr440s44ows884k08o4wkkw", + "title": "Kangchan Lee", + "former": false + }, + { + "href": "https://api.w3.org/users/2j0ltmwg0leswks8skc8cc04cw0ow0o", + "title": "Wonsuk Lee", + "former": false + }, + { + "href": "https://api.w3.org/users/oehp013267kso0kkwoo4sgwwskggcg", + "title": "Roy Leon", + "former": false + }, + { + "href": "https://api.w3.org/users/994bz7h4968s04ko4oos48o0k8gskwo", + "title": "Max Leonard", + "former": false + }, + { + "href": "https://api.w3.org/users/gvu2y2v28eg4k0cc840ooks0wgksscg", + "title": "Zongyan Li", + "former": false + }, + { + "href": "https://api.w3.org/users/mamftppdc2okogkwckoco8sgkkogsss", + "title": "Mark Lizar", + "former": false + }, + { + "href": "https://api.w3.org/users/7enkmdz1290kggw44owsoow00cg84s0", + "title": "Simon Louvet", + "former": false + }, + { + "href": "https://api.w3.org/users/18pxgm8uzetc4g0g804w08k40080w84", + "title": "Santi Lozano", + "former": false + }, + { + "href": "https://api.w3.org/users/58i29xd81kcokk8skgkgw8ogkcwokwc", + "title": "Dan Lussier", + "former": false + }, + { + "href": "https://api.w3.org/users/b2ewte314s0s8gcco80ccgs4o8gkw0w", + "title": "Amod Malviya", + "former": false + }, + { + "href": "https://api.w3.org/users/nvfkd3ftf9ws8s8kkok8gsgkws4880g", + "title": "Pano Maria", + "former": false + }, + { + "href": "https://api.w3.org/users/eukcnzwwnfkkg8004o0c4ocko4swwg", + "title": "Thierry Marianne", + "former": false + }, + { + "href": "https://api.w3.org/users/3ncv9lj9ls6co40wgw4kgk0sswgk8cw", + "title": "Richard Marshall", + "former": false + }, + { + "href": "https://api.w3.org/users/79kg9k7jq58g0ocs4k4wssw00cgscg0", + "title": "James Martin", + "former": false + }, + { + "href": "https://api.w3.org/users/alj2jkms1g8c8cc88s0o0so0kgww8k0", + "title": "david mason", + "former": false + }, + { + "href": "https://api.w3.org/users/dmoeoq3zi6o8ks4g408s80s0wwkso0c", + "title": "Khaled Mathlouthi", + "former": false + }, + { + "href": "https://api.w3.org/users/k6njz72q29s00g84o8wwow4s0gkg80s", + "title": "Augusto Mathurin", + "former": false + }, + { + "href": "https://api.w3.org/users/kytupw60t1s8cgogsccc8g0oo4c4o8c", + "title": "Souen Mazouin", + "former": false + }, + { + "href": "https://api.w3.org/users/eozxx5ftpnsow4wk800ccssg0s44g8o", + "title": "Gerald Melles", + "former": false + }, + { + "href": "https://api.w3.org/users/7s5skkvbak0sgwk80w4w0cokc4socgo", + "title": "Chris Min", + "former": false + }, + { + "href": "https://api.w3.org/users/oxhedt288hcsos4o4cgwkk0skgs8w0s", + "title": "Yatharth (Arjun) Mishra", + "former": false + }, + { + "href": "https://api.w3.org/users/o880jjv47eo0c8ks8sowk84g8sos4cc", + "title": "Hindia Mohammed", + "former": false + }, + { + "href": "https://api.w3.org/users/6wk6al0jx5wkg8gc8w48s84owc4o0k8", + "title": "Jackson Morgan", + "former": false + }, + { + "href": "https://api.w3.org/users/f7g3d19niagc0ko8os8ssk0wg04k4g4", + "title": "Daphne Muller", + "former": false + }, + { + "href": "https://api.w3.org/users/wxzpstxo26ssc8gs88kowg0cc4ggoo", + "title": "Paul Mundt", + "former": false + }, + { + "href": "https://api.w3.org/users/pjkj2cqngvko4gkco0so4gk0g4s40wc", + "title": "Gary Murphy", + "former": false + }, + { + "href": "https://api.w3.org/users/1ca0k6paxkjogcgok0o0o484k0ckgc8", + "title": "Devaraj Muthuvelmanickam", + "former": false + }, + { + "href": "https://api.w3.org/users/cvb1c9xsj1cgcsg8s44cgoocgcsog4o", + "title": "Filippo Nardocci", + "former": false + }, + { + "href": "https://api.w3.org/users/erueoro8gwg804kowkk4w4gg0o4kos8", + "title": "Marco Neumann", + "former": false + }, + { + "href": "https://api.w3.org/users/r312np8pedc080c0wsocoosg84okw00", + "title": "Takeo Nishikata", + "former": false + }, + { + "href": "https://api.w3.org/users/dj5i65t9nago4gc0og0wg48ggkkkkcc", + "title": "Alessio Nobile", + "former": false + }, + { + "href": "https://api.w3.org/users/k4v6p0sy1mo4s48004ocw4w404gcc0w", + "title": "Kelly O'Brien", + "former": false + }, + { + "href": "https://api.w3.org/users/2lz3buddw0sggc004g044w48cwws08o", + "title": "Maico Oliveira Buss", + "former": false + }, + { + "href": "https://api.w3.org/users/7yu82l7kmr0o448c84sso80w0wow8ow", + "title": "Osmar Olivo", + "former": false + }, + { + "href": "https://api.w3.org/users/e0mdss1snsgs0gwg044cksg04s80oow", + "title": "Mike Orchard", + "former": false + }, + { + "href": "https://api.w3.org/users/9nmo6jwjex444kw88ksgkwwoc88sgg8", + "title": "Meindert Osinga", + "former": false + }, + { + "href": "https://api.w3.org/users/bie3wkechds0sssw4gwo0ws8skkc4c0", + "title": "davi ottenheimer", + "former": false + }, + { + "href": "https://api.w3.org/users/qw4cv3ssvhwc800co04gkwcs88ccoks", + "title": "diego pacheco", + "former": false + }, + { + "href": "https://api.w3.org/users/91wfmmbnr2g40ow0gocgkck0888csgo", + "title": "Michael Paduch", + "former": false + }, + { + "href": "https://api.w3.org/users/2lzzhliq4lyc0ok0ogckookwk8gog44", + "title": "Harshvardhan J. Pandit", + "former": false + }, + { + "href": "https://api.w3.org/users/qs3t0euor0gwosg00k4gk4kkw4ogsw4", + "title": "Eugene Park", + "former": false + }, + { + "href": "https://api.w3.org/users/hpifh5j57n4s4wwkcks84kc8s80csck", + "title": "Christophe R Patraldo", + "former": false + }, + { + "href": "https://api.w3.org/users/prdzx0dcclcwc8o0k8oc80coskks80g", + "title": "Jon Pederson", + "former": false + }, + { + "href": "https://api.w3.org/users/1ftbk57y3z0kk8ccgcgo8gsg4008ckw", + "title": "Michael Pelikan", + "former": false + }, + { + "href": "https://api.w3.org/users/bnhurro14vks48kck0wocs8o0kg08w0", + "title": "Christine Perey", + "former": false + }, + { + "href": "https://api.w3.org/users/d9frt4i4c5s8sc84kkcw8kswogwg8oo", + "title": "Roger Perry", + "former": false + }, + { + "href": "https://api.w3.org/users/rxxjvvyvrb40kos0s04w88o8wcog8ks", + "title": "Teodora Petkova", + "former": false + }, + { + "href": "https://api.w3.org/users/j4xp2duegc8wkskc404kkswo8ow04co", + "title": "Denis Pierre", + "former": false + }, + { + "href": "https://api.w3.org/users/5dn8rdavv08ww44cs804w4ow48ocwgg", + "title": "Michael Pigott", + "former": false + }, + { + "href": "https://api.w3.org/users/8kvnbvxguxgckgo0ok0go4og404ckcc", + "title": "Alice Poggioli", + "former": false + }, + { + "href": "https://api.w3.org/users/of6ibrvfbb40g04o84wogwscs8swckk", + "title": "Leon Porter", + "former": false + }, + { + "href": "https://api.w3.org/users/8m3z7p7zmhc80k4cwcgos0ok4048w4k", + "title": "Kevin Poulsen", + "former": false + }, + { + "href": "https://api.w3.org/users/6fbu1j8k3xgk0g0ocgo00cwss4ks0cw", + "title": "Andreas Prieß", + "former": false + }, + { + "href": "https://api.w3.org/users/7k2z3gmayqo0csg8s4k4oog48gg4go4", + "title": "Christopher Prince", + "former": false + }, + { + "href": "https://api.w3.org/users/osp579102f44w4gw8sgc8s0skokkcwg", + "title": "Eric Prud'hommeaux", + "former": false + }, + { + "href": "https://api.w3.org/users/tjwdq64nwe84ksg40gkg44080wwg0s8", + "title": "Pavlos Pseftoyiannis", + "former": false + }, + { + "href": "https://api.w3.org/users/d56wuiax6zccks0o00s4csg0o0wo0wc", + "title": "Brendan Quinn", + "former": false + }, + { + "href": "https://api.w3.org/users/myiroeqi8ggc0ww4wg8ggo40w0skoks", + "title": "Raúl R. Pearson", + "former": false + }, + { + "href": "https://api.w3.org/users/2uxt7jdofo4k4gok04kc8gk4osww08o", + "title": "Barath Raghavan", + "former": false + }, + { + "href": "https://api.w3.org/users/jsif8udltpcgw0g4wgcksc48wkkggw8", + "title": "Sindhu Raju", + "former": false + }, + { + "href": "https://api.w3.org/users/hcpqb5bdo7ww4k4kk08w08g4o0ss0c0", + "title": "Armando Ramos", + "former": false + }, + { + "href": "https://api.w3.org/users/papdd5w7fc0k4gg4sck404w4gg0c48w", + "title": "James Randall", + "former": false + }, + { + "href": "https://api.w3.org/users/mxzqnwq6fr44ckk00o8w8084k8s0k0c", + "title": "Alon Rapaport", + "former": false + }, + { + "href": "https://api.w3.org/users/ewjlj3v9mv40s4s4ks4osksogog40gk", + "title": "Ellen Rapaport", + "former": false + }, + { + "href": "https://api.w3.org/users/takjr8c4pkgsgwk4o4gw0ow4s0w8w0k", + "title": "Rafael Richards", + "former": false + }, + { + "href": "https://api.w3.org/users/s9wqx2uu50gkg8s8k00888s04wgcg8w", + "title": "Peter Rivett", + "former": false + }, + { + "href": "https://api.w3.org/users/8gujns04y6g4kwck48k0k8cwwsco8gc", + "title": "Víctor Rodríguez-Doncel", + "former": false + }, + { + "href": "https://api.w3.org/users/n5guzlp1mn4k8gg48o8w0c8swo4c000", + "title": "Dirk Roeleveld", + "former": false + }, + { + "href": "https://api.w3.org/users/ivna1wtqy00g4g04gkwcswksw80c0sw", + "title": "Leonard Rosenthol", + "former": false + }, + { + "href": "https://api.w3.org/users/ixazmdad69wkgk84w84kk444go8cgsk", + "title": "Soheil Roshankish", + "former": false + }, + { + "href": "https://api.w3.org/users/g6emdivwzgo4og44w0w8os0gssw04ks", + "title": "Gabriel Rosset", + "former": false + }, + { + "href": "https://api.w3.org/users/2t4rh0vu4l0kc8sg0c8wkkg4kwo84k4", + "title": "Rami Rustom", + "former": false + }, + { + "href": "https://api.w3.org/users/rhxy2mn1d8gwkgow8040gsw4o8ksgwc", + "title": "Owen Sacco", + "former": false + }, + { + "href": "https://api.w3.org/users/q8ofi7x8s1wk0kw4gc0skggk48csssc", + "title": "Gourab Saha", + "former": false + }, + { + "href": "https://api.w3.org/users/e994hk5fgzk0ok88gsowckoos0wcwok", + "title": "Sylvain Saint-André", + "former": false + }, + { + "href": "https://api.w3.org/users/hb9oqefqy08osg8o0ockswwog44wc8g", + "title": "Joaquin Salvachua", + "former": false + }, + { + "href": "https://api.w3.org/users/qirx2einw2s00ogs0cs0ccok0k4o8sk", + "title": "Jan Schill", + "former": false + }, + { + "href": "https://api.w3.org/users/bdo9sw0mda80owowsw8gsg40c80ww80", + "title": "Thomas Schouten", + "former": false + }, + { + "href": "https://api.w3.org/users/1mbfu5msv30g0cw8cwkk0wcc4g0wkcg", + "title": "Daniel Schraudner", + "former": false + }, + { + "href": "https://api.w3.org/users/lvlzxcxrsb48cgg8gso04oook0w0k4g", + "title": "Dana Scott", + "former": false + }, + { + "href": "https://api.w3.org/users/ln1cjvh5gyogsoos0sgwwksws800o8g", + "title": "Mark Senefsky", + "former": false + }, + { + "href": "https://api.w3.org/users/bc1i0bfbz8ggsgw8gsk4wk04oossgss", + "title": "Oshani Seneviratne", + "former": false + }, + { + "href": "https://api.w3.org/users/731orb53w0gsc4oo4w4kooscwg4co8s", + "title": "Nicolas Seydoux", + "former": false + }, + { + "href": "https://api.w3.org/users/mwwxsrxnm1wwgo0k0s8woww8owkkg8k", + "title": "Ashish S Sharma", + "former": false + }, + { + "href": "https://api.w3.org/users/rfuhsw6os2s0koc8wcskg8cgsc08wk8", + "title": "Yuhang Shi", + "former": false + }, + { + "href": "https://api.w3.org/users/7kou6ny0ako4g8kogccogkk40o4kocc", + "title": "Hannah Short", + "former": false + }, + { + "href": "https://api.w3.org/users/h14rk9cwkq8s4os0kokckko4wg4ss4w", + "title": "Guilherme Siquinelli", + "former": false + }, + { + "href": "https://api.w3.org/users/tehrz3rf8qo08088gs0880okcwgokw4", + "title": "Ali Siragedien", + "former": false + }, + { + "href": "https://api.w3.org/users/nnnff1mlyv440g0skkc8kkw4ok4swws", + "title": "Jonas Smedegaard", + "former": false + }, + { + "href": "https://api.w3.org/users/fstpqs1cgi880owkc48g8c04wgc8w48", + "title": "Peter Smith", + "former": false + }, + { + "href": "https://api.w3.org/users/367x78ld1m4gcgc4o8w4800ww00gcow", + "title": "Adam Sobieski", + "former": false + }, + { + "href": "https://api.w3.org/users/d75ckhpx13k8cso440kw0o0s0s0wo8o", + "title": "A Soroka", + "former": false + }, + { + "href": "https://api.w3.org/users/5rkaz0ypu48wwwcsgss40ksgc8c4kg4", + "title": "Edwin Steiner", + "former": false + }, + { + "href": "https://api.w3.org/users/hc3608eu5egcw4oss0wkso4808wskk0", + "title": "Sharon Stratsianis", + "former": false + }, + { + "href": "https://api.w3.org/users/6tcr9rucxds0080gwwwww4kw80ccgc4", + "title": "Han Su", + "former": false + }, + { + "href": "https://api.w3.org/users/o3llh637av4ww4gg40kok48048so8g8", + "title": "Hong Sun", + "former": false + }, + { + "href": "https://api.w3.org/users/ro3lhg1xna8gk0gsswkgk0oow0g8g8w", + "title": "Wouter Termont", + "former": false + }, + { + "href": "https://api.w3.org/users/ox8xc2908xcowo8wwkog0cgokcw0o8o", + "title": "Ted Thibodeau", + "former": false + }, + { + "href": "https://api.w3.org/users/dq5nasjuyggs4ws8k4wwsokwcwoosk0", + "title": "Mark Thompson", + "former": false + }, + { + "href": "https://api.w3.org/users/gorphzk7atk4ooosgk0440cs4o44kg4", + "title": "Michael Thornburgh", + "former": false + }, + { + "href": "https://api.w3.org/users/1pci2opqkntwssoos8w0gs0ccwo4kgc", + "title": "thosleaf thos", + "former": false + }, + { + "href": "https://api.w3.org/users/f9rp71joji0wwo0wokooo8ogs0w8gco", + "title": "Wim Tobback", + "former": false + }, + { + "href": "https://api.w3.org/users/d0hdo737kg00kc8sk0kgs4k4wgw0w0g", + "title": "Carlo Tosoni", + "former": false + }, + { + "href": "https://api.w3.org/users/41kth31b5wo48kwsws0oc80w8w8o4kc", + "title": "Emmet Townsend", + "former": false + }, + { + "href": "https://api.w3.org/users/lx5eaxmscy88swcc44c88gwckwwkso8", + "title": "Chiali Tsai", + "former": false + }, + { + "href": "https://api.w3.org/users/6lcd1wp6c1s0wggw4ggs00080880w4k", + "title": "Mischa Tuffield", + "former": false + }, + { + "href": "https://api.w3.org/users/43pw9upb95ycc0wos00wswskc4goo4o", + "title": "Timea Turdean", + "former": false + }, + { + "href": "https://api.w3.org/users/r5erjpp3kys4044c8g4w0wc8ko4c8s4", + "title": "Travis Vachon", + "former": false + }, + { + "href": "https://api.w3.org/users/qoy2whvp6i8ocggw4wcog4sookso048", + "title": "Abel Van den Briel", + "former": false + }, + { + "href": "https://api.w3.org/users/9e4wqshzdbkso8skww8o40gc8cccoc4", + "title": "Pieter van Everdingen", + "former": false + }, + { + "href": "https://api.w3.org/users/afzyk9qqt8g04gk40w8o4g0cwg848g4", + "title": "Joachim Van Herwegen", + "former": false + }, + { + "href": "https://api.w3.org/users/2ejxxj6rphhc4ccoogk0cowcggkggwg", + "title": "Auke van Slooten", + "former": false + }, + { + "href": "https://api.w3.org/users/yrk23dp5vwgwwwscc40088c0kksssw", + "title": "Daniel Vangrieken", + "former": false + }, + { + "href": "https://api.w3.org/users/4hd7lptym54wcc8g8scowcc80040o0g", + "title": "Angelo Veltens", + "former": false + }, + { + "href": "https://api.w3.org/users/q2n9aldvam80488o0cc4c4wgsw48gck", + "title": "Aad Versteden", + "former": false + }, + { + "href": "https://api.w3.org/users/i2rlxrk5fkg8ocskcc4w48wwgckkkwk", + "title": "Samy Vincent", + "former": false + }, + { + "href": "https://api.w3.org/users/13dmwn86pupcoo08wo88gcw8gsc04gg", + "title": "Jacqui Vo", + "former": false + }, + { + "href": "https://api.w3.org/users/bbjdf3du0wg8w84w44cww80ko000kss", + "title": "Bruno Volckaert", + "former": false + }, + { + "href": "https://api.w3.org/users/r270bxdlr5wgo0gk408c880okg8o4g8", + "title": "David Waite", + "former": false + }, + { + "href": "https://api.w3.org/users/8luye1ijxvwoo0s08skw4g0go8c8oc4", + "title": "Matt Wallis", + "former": false + }, + { + "href": "https://api.w3.org/users/kaxk3jn3alsss0g4s4o0kcw4sswksww", + "title": "Han Wammes", + "former": false + }, + { + "href": "https://api.w3.org/users/5jr6wjhxz80ssos00w4csck4sscsw0w", + "title": "Jeff Waters", + "former": false + }, + { + "href": "https://api.w3.org/users/hlyk39uj7q8kswkko0gk40sg8gw0c4w", + "title": "Kevin Weber", + "former": false + }, + { + "href": "https://api.w3.org/users/jkqd2unx7vsooc0w4sokgs88kkck0s0", + "title": "Mark Weiler", + "former": false + }, + { + "href": "https://api.w3.org/users/4dfxa9b4b8g084swwcskskok4ogswg8", + "title": "Eric Woodward", + "former": false + }, + { + "href": "https://api.w3.org/users/r3spj7c7ozk444888o8gsco4sgkcckk", + "title": "Paul Worrall", + "former": false + }, + { + "href": "https://api.w3.org/users/b39dpa6cki88csg4ko0scgc0w8oc884", + "title": "Jesse Wright", + "former": false + }, + { + "href": "https://api.w3.org/users/nir42nbed2s88o40koc040swk8o0wgk", + "title": "lin ye", + "former": false + }, + { + "href": "https://api.w3.org/users/se2eyozl5xc4ooowgcgsoskww004o8s", + "title": "John Yu", + "former": false + }, + { + "href": "https://api.w3.org/users/gtduiz4lfv4808csw8ockwwg4ksssgg", + "title": "Onur Yüksel", + "former": false + }, + { + "href": "https://api.w3.org/users/i5y21d0k17kg00ck8c80o0c48cg8okk", + "title": "Dmitri Zagidulin", + "former": false + }, + { + "href": "https://api.w3.org/users/pvlcztjjd8gwogo480csgw8owo0c4sg", + "title": "Syed Ali Raza Zaidi", + "former": false + }, + { + "href": "https://api.w3.org/users/mum0w0bwgnkcg8gg0cko0scwogsw4co", + "title": "Hadrian Zbarcea", + "former": false + }, + { + "href": "https://api.w3.org/users/om212thq2f4wcgk80w4wo4o0ggs8skg", + "title": "Lauernce Zhang", + "former": false + }, + { + "href": "https://api.w3.org/users/m1r1atazz8gg0cwsggc0wk8o4wc0oks", + "title": "Antoine Zimmermann", + "former": false + }, + { + "href": "https://api.w3.org/users/n2bbanhjvm8co4ccg488k0swwwosg80", + "title": "Jeff Zucker", + "former": false + }, + { + "href": "https://api.w3.org/users/s2mtbm76reow808c884k04og88cggwk", + "title": "Daniel Zuckerman", + "former": false + } + ], + "self": { + "href": "https://api.w3.org/groups/cg/solid/users?page=1&items=1000" + }, + "first": { + "href": "https://api.w3.org/groups/cg/solid/users?page=1&items=1000" + }, + "last": { + "href": "https://api.w3.org/groups/cg/solid/users?page=1&items=1000" + } + } +} \ No newline at end of file diff --git a/coverage.html b/coverage.html new file mode 100644 index 00000000..8faf9e74 --- /dev/null +++ b/coverage.html @@ -0,0 +1,3284 @@ + + + + + Solid Specification - Conformance Test Suite Coverage Report + + + + + + + +
+
+

Solid Specification - Conformance Test Suite Coverage Report

+ +
+
Identifier
+
64044167-9aa0-4755-8530-fbf187f05625
+
+ +
+
+

Specifications under test

+ +
+
+

Test suite

+
+
Name
Specification Tests
+
Description
Solid Specification Conformance Tests
+
Created
+
Developer
https://solidproject.org
+
Homepage
https://github.com/solid-contrib/specification-tests/
+
Programming Language
KarateDSL
+
+
Version
+
+ 0.0.16 + +
+
+
+
+ +
+

Test coverage by specification requirement

+ + + +
+
    +
  • +
    + Specification: https://solidproject.org/TR/protocol + 87 + +
      +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-http-11 + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      Servers MUST conform to HTTP/1.1 Message Syntax and Routing [RFC7230] and HTTP/1.1 Semantics and Content [RFC7231].
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-http-2 + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      SHOULD
      +
      +
      Statement
      Servers SHOULD conform to HTTP/2 [RFC7540].
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-tls-https + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      SHOULD
      +
      +
      Statement
      Servers SHOULD use TLS connections through the https URI scheme in order to secure the communication with clients.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-tls-https-redirect + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      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.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-conditional-requests + 1 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      Servers MUST conform to HTTP/1.1 Conditional Requests [RFC7232].
      + + + + + + + + + + + + + + + + +
      Test cases
      TitleDetailsImplemented
      + Create: PUT Turtle resources to container with If-None-Match: * headers. + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Unreviewed +
      +
      + +       		✔
      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-caching + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      SHOULD
      +
      +
      Statement
      Servers SHOULD conform to HTTP/1.1 Caching [RFC7234].
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-range-requests + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MAY
      +
      +
      Statement
      Servers MAY conform to HTTP/1.1 Range Requests [RFC7233].
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-authentication + 1 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      Servers MUST conform to HTTP/1.1 Authentication [RFC7235].
      + + + + + + + + + + + + + + + + +
      Test cases
      TitleDetailsImplemented
      + Test that unauthenticated users get the correct response + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Approved +
      +
      + +       		✔
      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-unauthenticated + 1 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      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).
      + + + + + + + + + + + + + + + + +
      Test cases
      TitleDetailsImplemented
      + Test that unauthenticated users get the correct response + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Approved +
      +
      + +       		✔
      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-content-type + 1 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      Server MUST reject PUT, POST and PATCH requests without the Content-Type header with a status code of 400.
      + + + + + + + + + + + + + + + + +
      Test cases
      TitleDetailsImplemented
      + Server MUST reject write requests without Content-Type + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Unreviewed +
      +
      + +       		✔
      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#client-http-11 + 0 + +
      +
      Requirement subject
      +
      Client
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      Clients MUST conform to HTTP/1.1 Message Syntax and Routing [RFC7230] and HTTP/1.1 Semantics and Content [RFC7231].
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#client-http-2 + 0 + +
      +
      Requirement subject
      +
      Client
      +
      +
      +
      Requirement level
      +
      MAY
      +
      +
      Statement
      Clients MAY conform to HTTP/2 [RFC7540].
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#client-conditional-requests + 0 + +
      +
      Requirement subject
      +
      Client
      +
      +
      +
      Requirement level
      +
      MAY
      +
      +
      Statement
      Clients MAY conform to HTTP/1.1 Conditional Requests [RFC7232].
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#client-caching + 0 + +
      +
      Requirement subject
      +
      Client
      +
      +
      +
      Requirement level
      +
      MAY
      +
      +
      Statement
      Clients MAY conform to HTTP/1.1 Caching [RFC7234].
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#client-range-requests + 0 + +
      +
      Requirement subject
      +
      Client
      +
      +
      +
      Requirement level
      +
      MAY
      +
      +
      Statement
      Clients MAY conform to HTTP/1.1 Range Requests [RFC7233].
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#client-authentication + 0 + +
      +
      Requirement subject
      +
      Client
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      Clients MUST conform to HTTP/1.1 Authentication [RFC7235] if it needs to access resources requiring authentication (see WebID).
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#client-authentication-different-credentials + 0 + +
      +
      Requirement subject
      +
      Client
      +
      +
      +
      Requirement level
      +
      MAY
      +
      +
      Statement
      When a client receives a response with a 403 or 404 status code, the client MAY repeat the request with different credentials.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#client-content-type + 0 + +
      +
      Requirement subject
      +
      Client
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      Clients MUST use the Content-Type HTTP header in PUT, POST and PATCH requests [RFC7231].
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-uri-trailing-slash-distinct + 1 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST NOT
      +
      +
      Statement
      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.
      + + + + + + + + + + + + + + + + +
      Test cases
      TitleDetailsImplemented
      + With and without trailing slash cannot co-exist + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Unreviewed +
      +
      + +       		✔
      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-uri-redirect-differing + 1 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MAY
      +
      +
      Statement
      Instead, the server MAY respond to requests for the latter URI with a 301 redirect to the former.
      + + + + + + + + + + + + + + + + +
      Test cases
      TitleDetailsImplemented
      + With and without trailing slash cannot co-exist + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Unreviewed +
      +
      + +       		✔
      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-authorization-redirect + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      Servers MUST authorize prior to this optional redirect.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-storage + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      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).
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-storage-nonoverlapping + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      When a server supports multiple storages, the URIs MUST be allocated to non-overlapping space.
      +

      No test cases found.

      +
      + +
      • +
    • + + +
      • +
    • + + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#client-storage-discovery + 0 + +
      +
      Requirement subject
      +
      +
      +
      Requirement level
      +
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#client-rdf-storage + 0 + +
      +
      Requirement subject
      +
      +
      +
      Requirement level
      +
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-storage-description + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      Servers MUST include the Link header 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.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-storage-description-resource + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      Servers MUST include statements about the storage as part of the storage description resource.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-storage-track-owner + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      Servers MUST keep track of at least one owner of a storage in an implementation defined way.
      +

      No test cases found.

      +
      + +
      • +
    • + + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-basic-container + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      The representation and behaviour of containers in Solid corresponds to LDP Basic Container and MUST be supported by server.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-contained-resource-metadata + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      SHOULD
      +
      +
      Statement
      Servers SHOULD include resource metadata about contained resources as part of the container description, unless that information is inapplicable to the server.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-auxiliary-resources-management + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      Servers MUST support auxiliary resources defined by this specification and manage the association between a subject resource and auxiliary resources.
      +

      No test cases found.

      +
      + +
      • +
    • + + +
      • +
    • + + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-description-resource-max + 1 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST NOT
      +
      +
      Statement
      Servers MUST NOT directly associate more than one description resource to a subject resource.
      + + + + + + + + + + + + + + + + +
      Test cases
      TitleDetailsImplemented
      + Server may link to one description resource + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Unreviewed +
      +
      + +       		✔
      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-description-resource-authorization + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      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.
      +

      No test cases found.

      +
      + +
      • +
    • + + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-method-not-allowed + 1 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      Servers MUST respond with the 405 status code to requests using HTTP methods that are not supported by the target resource.
      + + + + + + + + + + + + + + + + +
      Test cases
      TitleDetailsImplemented
      + Error for unsupported method + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Unreviewed +
      +
      + +       		✔
      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-put-patch-uri-assignment + 1 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      When a successful PUT or PATCH request creates a resource, the server MUST use the effective request URI to assign the URI to that resource.
      + + + + + + + + + + + + + + + + +
      Test cases
      TitleDetailsImplemented
      + Server assigns URI based on effective request URI + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Unreviewed +
      +
      + +       		✔
      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-post-uri-assignment + 1 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      When a successful POST request creates a resource, the server MUST assign a URI to that resource.
      + + + + + + + + + + + + + + + + +
      Test cases
      TitleDetailsImplemented
      + Assignment of URIs for POST requests + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Unreviewed +
      +
      + +       		✔
      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-slug-uri-assignment + 1 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MAY
      +
      +
      Statement
      Servers MAY allow clients to suggest the URI of a resource created through POST, using the HTTP Slug header as defined in [RFC5023].
      + + + + + + + + + + + + + + + + +
      Test cases
      TitleDetailsImplemented
      + Assignment of URIs for POST requests with Slug + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Unreviewed +
      +
      + +       		✔
      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-safe-methods + 1 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      Servers MUST support the HTTP GET, HEAD and OPTIONS methods [RFC7231] for clients to read resources or to determine communication options.
      + + + + + + + + + + + + + + + + +
      Test cases
      TitleDetailsImplemented
      + Servers MUST support GET, HEAD and OPTIONS + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Unreviewed +
      +
      + +       		✔
      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-allow-methods + 1 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      Servers MUST indicate the HTTP methods supported by the target resource by generating an Allow header field in successful responses.
      + + + + + + + + + + + + + + + + +
      Test cases
      TitleDetailsImplemented
      + Servers MUST return Allow for GET and HEAD + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Unreviewed +
      +
      + +       		✔
      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-accept-headers + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      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 headers that correspond to acceptable HTTP methods listed in Allow header value in response to HTTP GET, HEAD and OPTIONS requests.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-put-patch-intermediate-containers + 1 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      Servers MUST create intermediate containers and include corresponding containment triples in container representations derived from the URI path component of PUT and PATCH requests.
      + + + + + + + + + + + + + + + + +
      Test cases
      TitleDetailsImplemented
      + Creating a resource using PUT and PATCH must create intermediate containers + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Approved +
      +
      + +       		✔
      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-post-container + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      Servers MUST allow creating new resources with a POST request to URI path ending /.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-post-container-create-resource + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      Servers MUST create a resource with URI path ending /{id} in container /.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-post-container-create-container + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      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.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-post-target-not-found + 1 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      When a POST method request targets a resource without an existing representation, the server MUST respond with the 404 status code.
      + + + + + + + + + + + + + + + + +
      Test cases
      TitleDetailsImplemented
      + POST to non-existing resource must result in 404 + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Unreviewed +
      +
      + +       		✔
      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-put-patch-auxiliary-resource + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      When a PUT or PATCH method request targets an auxiliary resource, the server MUST create or update it.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-post-slug-auxiliary-resource + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      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.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-protect-containment + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST NOT
      +
      +
      Statement
      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.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-protect-contained-resource-metadata + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST NOT
      +
      +
      Statement
      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.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-etag + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MAY
      +
      +
      Statement
      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.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-patch-n3-accept + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      Servers MUST accept a PATCH request with an N3 Patch body when the target of the request is an RDF document [RDF11-CONCEPTS].
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-patch-n3-advertise + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      Servers MUST indicate support of N3 Patch by listing text/n3 as a value of the Accept-Patch header [RFC5789] of relevant responses.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-patch-n3-invalid + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      Servers MUST respond with a 422 status code [RFC4918] if a patch document does not satisfy all of the above constraints.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-n3-patch-where + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      When ?conditions is non-empty, servers MUST treat the request as a Read operation.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-n3-patch-insert + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      When ?insertions is non-empty, servers MUST (also) treat the request as an Append operation.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-n3-patch-delete + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      When ?deletions is non-empty, servers MUST treat the request as a Read and Write operation.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-patch-n3-semantics + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      Servers MUST process a patch resource against the target document as follows:
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-delete-protect-root-container + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      When a DELETE request targets storage’s root container or its associated ACL resource, the server MUST respond with the 405 status code.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-disallow-delete + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      Server MUST exclude the DELETE method in the HTTP response header Allow in response to requests to these resources [RFC7231].
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-delete-remove-containment + 1 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      When a contained resource is deleted, the server MUST also remove the corresponding containment triple.
      + + + + + + + + + + + + + + + + +
      Test cases
      TitleDetailsImplemented
      + Delete containment triple when resource is deleted + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Unreviewed +
      +
      + +       		✔
      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-delete-remove-auxiliary-resource + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      When a contained resource is deleted, the server MUST also delete the associated auxiliary resources (see the Auxiliary Resources section).
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-delete-remove-empty-container + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      When a DELETE request targets a container, the server MUST delete the container if it contains no resources.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-delete-protect-nonempty-container + 1 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      If the container contains resources, the server MUST respond with the 409 status code and response body describing the error.
      + + + + + + + + + + + + + + + + +
      Test cases
      TitleDetailsImplemented
      + Server protects non-empty container + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Unreviewed +
      +
      + +       		✔
      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-representation-turtle-jsonld + 3 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      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].
      +
      +
      Additional comments
      +
      +
        +
      • Note that there is no requirement to support RDFa in a similar way, though some implementations may choose to.
        • +
      +
      +
      + + + + + + + + + + + + + + + + + + + + + + + + + + +
      Test cases
      TitleDetailsImplemented
      + RDF documents containing named graphs can be stored and retrieved + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Unreviewed +
      +
      + +       		✔
      + Requests support content negotiation for JSON-LD resource + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Approved +
      +
      + +       		✔
      + Requests support content negotiation for Turtle resource + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Approved +
      +
      + +       		✔
      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-representation-write-redirect + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      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.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-ldn + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      A Solid server MUST conform to the LDN specification by implementing the Receiver parts to receive notifications and make Inbox contents available [LDN].
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#client-ldn + 0 + +
      +
      Requirement subject
      +
      Client
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      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].
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-notifications-protocol-resource-server + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      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.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-notifications-protocol-subscription-server + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      Servers MUST conform to the Solid Notifications Protocol [SOLID-NOTIFICATIONS-PROTOCOL] by implementing the Subscription Server to process and produce instructions for subscription requests.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-notifications-protocol-notification-sender + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      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.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-notifications-protocol-notification-receiver + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      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.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-cors + 2 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      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 [RFC7231].
      + + + + + + + + + + + + + + + + + + + + + +
      Test cases
      TitleDetailsImplemented
      + Server must implement the CORS protocol for simple requests + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Unreviewed +
      +
      + +       		✔
      + Server must implement the CORS protocol for preflight requests + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Unreviewed +
      +
      + +       		✔
      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-cors-access-control-headers + 1 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      whenever a server 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].
      + + + + + + + + + + + + + + + + +
      Test cases
      TitleDetailsImplemented
      + Server must respond to requests sending Origin with the appropriate Access-Control-* headers + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Unreviewed +
      +
      + +       		✔
      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-cors-acao-vary + 1 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      the server MUST set the Access-Control-Allow-Origin header to the valid Origin value from the request and list Origin in the Vary header value.
      + + + + + + + + + + + + + + + + +
      Test cases
      TitleDetailsImplemented
      + Server returns correct Access-Control-Allow-Origin and Vary headers + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Unreviewed +
      +
      + +       		✔
      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-cors-aceh + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      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-* headers themselves).
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-cors-options + 1 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      A server MUST also support the HTTP OPTIONS method [RFC7231] such that it can respond appropriately to CORS preflight requests.
      + + + + + + + + + + + + + + + + +
      Test cases
      TitleDetailsImplemented
      + Server must support HTTP OPTIONS for CORS preflight requests + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Unreviewed +
      +
      + +       		✔
      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-cors-enumerate + 1 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      SHOULD
      +
      +
      Statement
      servers 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).
      + + + + + + + + + + + + + + + + +
      Test cases
      TitleDetailsImplemented
      + Server should enumerate headers in Access-Control-Expose-Headers + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Unreviewed +
      +
      + +       		✔
      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-cors-accept-acah + 1 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      SHOULD
      +
      +
      Statement
      Servers SHOULD also explicitly list Accept under Access-Control-Allow-Headers
      + + + + + + + + + + + + + + + + +
      Test cases
      TitleDetailsImplemented
      + Server should explicitly list Accept under Access-Control-Allow-Headers + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Unreviewed +
      +
      + +       		✔
      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#server-wac-acp + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      Servers MUST conform to either or both Web Access Control [WAC] and Access Control Policy [ACP] specifications.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#client-wac + 0 + +
      +
      Requirement subject
      +
      Client
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      Clients MUST conform to the Web Access Control specification [WAC].
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/protocol#client-acp + 0 + +
      +
      Requirement subject
      +
      Client
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      Clients MUST conform to the Access Control Policy specification [ACP].
      +

      No test cases found.

      +
      + +
      • +
    +
    +
    • +
  • +
    + Specification: https://solidproject.org/TR/wac + 22 + +
      +
    • + + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/wac#server-resource-acl-max + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST NOT
      +
      +
      Statement
      Servers MUST NOT directly associate more than one ACL resource to a resource.
      +

      No test cases found.

      +
      + +
      • +
    • + + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/wac#client-acl-uri + 0 + +
      +
      Requirement subject
      +
      Client
      +
      +
      +
      Requirement level
      +
      MUST NOT
      +
      +
      Statement
      Clients MUST NOT derive the URI of the ACL resource through string operations on the URI of the resource.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/wac#server-get-acl-turtle + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      Servers MUST accept an HTTP GET and HEAD request targeting an ACL resource when the value of the Accept header requests a representation in text/turtle [TURTLE].
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/wac#server-acl-without-representation + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST NOT
      +
      +
      Statement
      Servers who want a resource to inherit Authorizations (Effective ACL Resource) from a container resource MUST NOT have a representation for the ACL resource that is associated with the resource.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/wac#server-get-acl-without-representation + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      When an authorized HTTP GET or HEAD request targets an ACL resource without an existing representation, the server MUST respond with the 404 status code as per [RFC7231].
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/wac#server-root-container-acl + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      When an authorized HTTP GET or HEAD request targets root container’s ACL resource, the server MUST respond with a representation.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/wac#server-root-container-acl-authorization-control + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      The ACL resource of the root container MUST include an Authorization allowing the acl:Control access privilege ( access mode).
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/wac#server-read-operation + 6 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      When an operation requests to read a resource, the server MUST match an Authorization allowing the acl:Read access privilege on the resource.
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      Test cases
      TitleDetailsImplemented
      + Public agents can read (and only that) a resource when granted read access + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Unreviewed +
      +
      + +       		✔
      + Only authenticated agents can read (and only that) a resource when granted read access + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Unreviewed +
      +
      + +       		✔
      + Only Bob can read (and only that) a resource when granted read access + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Unreviewed +
      +
      + +       		✔
      + Only Bob can write (and only that) a resource when granted write access + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Unreviewed +
      +
      + +       		✔
      + Only authenticated agents can write (and only that) a resource when granted write access + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Unreviewed +
      +
      + +       		✔
      + Only authenticated agents can write (and only that) a resource when granted write access + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Unreviewed +
      +
      + +       		✔
      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/wac#server-create-operation + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      When an operation requests to create a resource as a member of a container resource, the server MUST match an Authorization allowing the acl:Append or acl:Write access privilege (as needed by the operation) on the resource to be created.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/wac#server-update-operation + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      When an operation requests to update a resource, the server MUST match an Authorization allowing the acl:Append or acl:Write access privilege on the resource.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/wac#server-delete-operation + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      When an operation requests to delete a resource, the server MUST match Authorizations allowing the acl:Write access privilege on the resource and the containing container.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/wac#server-control-operation + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      When an operation requests to read and write an ACL resource, the server MUST match an Authorization allowing the acl:Control access privilege on the resource.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/wac#server-cors-acao-acah + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      When a server participates in the CORS protocol [FETCH] and authorization is granted to an HTTP request including the Origin header, the server MUST include the HTTP Access-Control-Allow-Origin and Access-Control-Allow-Headers headers in the response of the HTTP request.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/wac#server-wac-allow + 5 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      Servers MUST advertise client’s access privileges on a resource by including the WAC-Allow HTTP header (WAC-Allow) in the response of HTTP GET and HEAD requests.
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      Test cases
      TitleDetailsImplemented
      + The WAC-Allow header shows user access modes for Bob when given indirect access via a container + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Approved +
      +
      + +       		✔
      + The WAC-Allow header shows public access modes for a public agent when given direct access + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Approved +
      +
      + +       		✔
      + The WAC-Allow header shows public access modes for a public agent when given indirect access via a container + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Approved +
      +
      + +       		✔
      + The WAC-Allow header shows user access modes for Bob when given direct access + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Approved +
      +
      + +       		✔
      + The WAC-Allow header is advertised + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Approved +
      +
      + +       		✔
      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/wac#client-wac-allow + 0 + +
      +
      Requirement subject
      +
      Client
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      Clients MUST discover access privileges on a resource by making an HTTP GET or HEAD request on the target resource, and checking the WAC-Allow header value for access parameters listing the allowed access modes per permission group (WAC-Allow).
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/wac#server-cors-aceh-wac-allow + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      When a server participates in the CORS protocol [FETCH], the server MUST include WAC-Allow in the Access-Control-Expose-Headers field-value in the HTTP response.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/wac#client-wac-allow-parsing + 0 + +
      +
      Requirement subject
      +
      Client
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +
      Statement
      Client parsing algorithms for WAC-Allow header field-values MUST incorporate error handling. When the received message fails to match an allowed pattern, clients MUST ignore the received WAC-Allow header-field. When unrecognised access parameters (such as permission groups or access modes) are found, clients MUST continue processing the access parameters as if those properties were not present.
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/wac#access-modes + 0 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      +

      No test cases found.

      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/wac#access-objects + 4 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      Test cases
      TitleDetailsImplemented
      + Bob can read a container and its children if he is granted both direct and inheritable read access + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Approved +
      +
      + +       		✔
      + Bob cannot read a container or children if he is not given any access + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Approved +
      +
      + +       		✔
      + Bob cannot read a container or children if he is not given any access + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Approved +
      +
      + +       		✔
      + Bob can only read child containers/resources of a container to which he is granted inheritable read access + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Unreviewed +
      +
      + +       		✔
      +
      + +
      • +
    • +
      + Requirement: https://solidproject.org/TR/wac#authorization-evaluation-context + 1 + +
      +
      Requirement subject
      +
      Server
      +
      +
      +
      Requirement level
      +
      MUST
      +
      + + + + + + + + + + + + + + + + +
      Test cases
      TitleDetailsImplemented
      + Inheritable ACL controls child resources + [manifest] + [source] + [requirement] + +
      +
      Status
      +
      +Approved +
      +
      + +       		✔
      +
      + +
      • +
    +
    +
    • +
+
+
+ +
+
+
+ + diff --git a/footprints/index.html b/footprints/index.html new file mode 100644 index 00000000..0fe7d0ec --- /dev/null +++ b/footprints/index.html @@ -0,0 +1,1584 @@ + + + + Data Footprints + + + + + + + + + + +
+

+

Data Footprints

+

Editor’s Draft,

+ +
+

CC0 To the extent possible under law, the editors have waived all copyright +and related or neighboring rights to this work. +In addition, as of 12 May 2020, +the editors have made this specification available under the Open Web Foundation Agreement Version 1.0, +which is available at http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0. +Parts of this work may be from another specification document. If so, those parts are instead covered by the license of that specification document.

+
+
+
+

Abstract

+

This document introduces a description model + + to decide where new resources are stored + and how they are wired up.

+
+
+ +
+

Status of This Document

+ This document is an incomplete 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.

+

1. Introduction

+

Write Introduction section.

+
+
+

Conformance

+

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. + The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” + in the normative parts of this document + are to be interpreted as described in RFC 2119. + However, for readability, + these words do not appear in all uppercase letters in this specification.

+

All of the text of this specification is normative + except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

+

Examples in this specification are introduced with the words “for example” + or are set apart from the normative text with class="example", like this:

+
This is an example of an informative example.
+

Informative notes begin with the word “Note” + and are set apart from the normative text with class="note", like this:

+

Note, this is an informative note.

+
+ +

References

+

Normative References

+
+
[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 +
+

Issues Index

+
+
Write Introduction section. ↵
+
\ No newline at end of file diff --git a/forms/index.html b/forms/index.html new file mode 100644 index 00000000..0fe7d0ec --- /dev/null +++ b/forms/index.html @@ -0,0 +1,1584 @@ + + + + Data Footprints + + + + + + + + + + +
+

+

Data Footprints

+

Editor’s Draft,

+ +
+

CC0 To the extent possible under law, the editors have waived all copyright +and related or neighboring rights to this work. +In addition, as of 12 May 2020, +the editors have made this specification available under the Open Web Foundation Agreement Version 1.0, +which is available at http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0. +Parts of this work may be from another specification document. If so, those parts are instead covered by the license of that specification document.

+
+
+
+

Abstract

+

This document introduces a description model + + to decide where new resources are stored + and how they are wired up.

+
+
+ +
+

Status of This Document

+ This document is an incomplete 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.

+

1. Introduction

+

Write Introduction section.

+
+
+

Conformance

+

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. + The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” + in the normative parts of this document + are to be interpreted as described in RFC 2119. + However, for readability, + these words do not appear in all uppercase letters in this specification.

+

All of the text of this specification is normative + except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

+

Examples in this specification are introduced with the words “for example” + or are set apart from the normative text with class="example", like this:

+
This is an example of an informative example.
+

Informative notes begin with the word “Note” + and are set apart from the normative text with class="note", like this:

+

Note, this is an informative note.

+
+ +

References

+

Normative References

+
+
[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 +
+

Issues Index

+
+
Write Introduction section. ↵
+
\ No newline at end of file diff --git a/introduction.html b/introduction.html new file mode 100644 index 00000000..f34a52af --- /dev/null +++ b/introduction.html @@ -0,0 +1,1732 @@ + + + + [TITLE] + + + + + + + + + + +
+

+

[TITLE]

+

,

+
+
+
Issue Tracking: +
GitHub +
Inline In Spec +
+
+
+

CC0 To the extent possible under law, the editors have waived all copyright +and related or neighboring rights to this work. +In addition, as of 2 October 2019, +the editors have made this specification available under the Open Web Foundation Agreement Version 1.0, +which is available at http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0. +Parts of this work may be from another specification document. If so, those parts are instead covered by the license of that specification document.

+
+
+
+

Abstract

+ [ABSTRACT] +
+
+ +
+

1. Introduction

+

Write Introduction section.

+

Explain the principle of orthogonality, + by which this spec is split into multiple documents.

+

Explain that this specification is not documentation; + it is the easiest way to understand how Solid works, + not the easiest way for building a Solid app.

+

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

+

Introduce the structure of this document. + [Cross-server interoperability](#resource-access) + [Cross-app interoperability](#clients)

+

1.2. Namespaces

+ + + + + + + + +
Prefix + Namespace + Description +
rdf + http://www.w3.org/1999/02/22-rdf-syntax-ns# + [rdf-schema] +
rdfs + http://www.w3.org/2000/01/rdf-schema# + [rdf-schema] +
xsd + http://www.w3.org/2001/XMLSchema# + [xmlschema-2] +
xsd + http://www.w3.org/ns/ldp# + [LDP] +
xsd + http://www.w3.org/2001/XMLSchema# + Solid Terms +
+
+
+

Conformance

+

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. + The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” + in the normative parts of this document + are to be interpreted as described in RFC 2119. + However, for readability, + these words do not appear in all uppercase letters in this specification.

+

All of the text of this specification is normative + except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

+

Examples in this specification are introduced with the words “for example” + or are set apart from the normative text with class="example", like this:

+
This is an example of an informative example.
+

Informative notes begin with the word “Note” + and are set apart from the normative text with class="note", like this:

+

Note, this is an informative note.

+
+ +

Index

+

Terms defined by this specification

+ +

References

+

Normative References

+
+
[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/ +
[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 +
[XMLSCHEMA-2] +
Paul V. Biron; Ashok Malhotra. XML Schema Part 2: Datatypes Second Edition. 28 October 2004. REC. URL: https://www.w3.org/TR/xmlschema-2/ +
+

Issues Index

+
+
Write Introduction section. ↵
+
Explain the principle of orthogonality, + by which this spec is split into multiple documents. ↵
+
Explain that this specification is not documentation; + it is the easiest way to understand how Solid works, + not the easiest way for building a Solid app. ↵
+
Introduce the structure of this document. + [Cross-server interoperability](#resource-access) + [Cross-app interoperability](#clients) ↵
+
+ + \ No newline at end of file diff --git a/main/http-definitions.bs.0 b/main/http-definitions.bs.0 new file mode 100644 index 00000000..05ed5fde --- /dev/null +++ b/main/http-definitions.bs.0 @@ -0,0 +1,58 @@ +HTTP Definitions {#http-definitions} +=================================== + +## HTTP Headers ## {#http-headers} + +### The Accept-Put Response Header ### {#accept-put} + +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 + + +## Link Relations ## {#link-relations} + +The intent is that these link relations will be registered with IANA per [[!RFC8288]]. + +### acl ### {#acl} + +The contents of this section were originally taken from [Web Access Control](https://www.w3.org/wiki/WebAccessControl). + +The following Link Relationship will be submitted to IANA for review, approval, and inclusion in the IANA Link Relations registry. + +: Relation Name +:: `acl` +: Description +:: The relationship `A acl B` asserts that resource B provides access control description of resource A. There are no constraints on the format or representation of A. B MUST be a Access Control List document using a Resource Description Framework syntax. +: Reference +:: This specification. +: Notes +:: Consumers of ACL resources should be aware of the source and chain of custody of the data. + +[[Source](https://github.com/solid/specification/issues/54)] +[[Source](https://github.com/solid/web-access-control-spec/issues/21)] + +Issue: +Shape of ACL: https://github.com/solid/specification/issues/169 \ No newline at end of file diff --git a/main/index.html b/main/index.html new file mode 100644 index 00000000..33cebb73 --- /dev/null +++ b/main/index.html @@ -0,0 +1,2399 @@ + + + + The Solid Ecosystem + + + + + + + + + + + +
+

+

The Solid Ecosystem

+

Editor’s Draft,

+ +
+

MIT License. Copyright 2019–2020 W3C Solid Community Group.

+
+
+
+

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

+

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.

+
+

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

+

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

+

1.2. 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 +
+

2. Protocol

+

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

+

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

+

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

+

2.2. Uniform Resource Identifier

+

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

+

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

+

2.3. Linked Data

+

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

+

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

+

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

+

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

+

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

+

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

+

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

+

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

+

2.5. 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. +
+

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

+

2.5.2. Required Client-Side Implementation

+
2.5.2.1. 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"
+
+
+
2.5.2.2. 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"
+
+
+

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

+
2.5.3.1. 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.

+
2.5.3.2. 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.

+
2.5.3.3. 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.

+

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

+

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

+

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

+

2.8. HTTP Definitions

+

2.8.1. HTTP Headers

+
2.8.1.1. The Accept-Put Response Header
+

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

+

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

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

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

+

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

+

IANA Registration Template:

+

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

+
+
Header field name +
+

Accept-Put

+
Applicable Protocol +
+

HTTP

+
Author/Change controller +
+

W3C Solid Community Group

+
Specification document +
+

This specification

+
+ +

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

+
2.8.2.1. acl
+

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

+

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

+
+
Relation Name +
+

acl

+
Description +
+

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

+
Reference +
+

This specification.

+
Notes +
+

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

+
+

[Source] [Source]

+

Shape of ACL: https://github.com/solid/specification/issues/169

+

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

+

2.9.1. Privacy Considerations

+
2.9.1.1. Identifiable Information
+

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

+

2.9.2. Security and Privacy Review

+

3. Identity

+

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

+

4. Authentication

+

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

+

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

+

5. Authorization

+

5.1. 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 WAC-Allow, using the ABNF syntax is:

+
WAC-Allow           = "WAC-Allow" ":" OWS permissions OWS
+permissions         = user-permissions OWS "," OWS public-permissions
+user-permissions    = "user=" quoted-access-modes
+public-permissions  = "public=" quoted-access-modes
+quoted-access-modes = DQUOTE *( access-modes / SP ) DQUOTE
+access-modes        = "read" / "write" / "append" / "control"
+OWS                 = *( SP / HTAB )
+
+

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

+

Clients can discover their access privileges on a resource by making an HTTP HEAD or GET request on the target URL, and checking the WAC-Allow HTTP +header value for user and public paramaters listing the allowed access +modes.

+

[Source] [Source] [Source]

+
+
+

Conformance

+

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. + The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” + in the normative parts of this document + are to be interpreted as described in RFC 2119. + However, for readability, + these words do not appear in all uppercase letters in this specification.

+

All of the text of this specification is normative + except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

+

Examples in this specification are introduced with the words “for example” + or are set apart from the normative text with class="example", like this:

+
This is an example of an informative example.
+

Informative notes begin with the word “Note” + and are set apart from the normative text with class="note", like this:

+

Note, this is an informative note.

+
+ +

Index

+

Terms defined by this specification

+ +

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 +
[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/specification/wac/ +
[WEBARCH] +
Ian Jacobs; Norman Walsh. Architecture of the World Wide Web, Volume One. 15 December 2004. REC. URL: https://www.w3.org/TR/webarch/ +
[WEBID] +
WebID 1.0 Editors Draft. URL: https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html +
+

Informative References

+
+
[WEBID-TLS] +
WebID-TLS. URL: https://solid.github.io/specification/webid-tls/ +
+ + + \ No newline at end of file diff --git a/main/introduction.html b/main/introduction.html new file mode 100644 index 00000000..f34a52af --- /dev/null +++ b/main/introduction.html @@ -0,0 +1,1732 @@ + + + + [TITLE] + + + + + + + + + + +
+

+

[TITLE]

+

,

+
+
+
Issue Tracking: +
GitHub +
Inline In Spec +
+
+
+

CC0 To the extent possible under law, the editors have waived all copyright +and related or neighboring rights to this work. +In addition, as of 2 October 2019, +the editors have made this specification available under the Open Web Foundation Agreement Version 1.0, +which is available at http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0. +Parts of this work may be from another specification document. If so, those parts are instead covered by the license of that specification document.

+
+
+
+

Abstract

+ [ABSTRACT] +
+
+ +
+

1. Introduction

+

Write Introduction section.

+

Explain the principle of orthogonality, + by which this spec is split into multiple documents.

+

Explain that this specification is not documentation; + it is the easiest way to understand how Solid works, + not the easiest way for building a Solid app.

+

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

+

Introduce the structure of this document. + [Cross-server interoperability](#resource-access) + [Cross-app interoperability](#clients)

+

1.2. Namespaces

+ + + + + + + + +
Prefix + Namespace + Description +
rdf + http://www.w3.org/1999/02/22-rdf-syntax-ns# + [rdf-schema] +
rdfs + http://www.w3.org/2000/01/rdf-schema# + [rdf-schema] +
xsd + http://www.w3.org/2001/XMLSchema# + [xmlschema-2] +
xsd + http://www.w3.org/ns/ldp# + [LDP] +
xsd + http://www.w3.org/2001/XMLSchema# + Solid Terms +
+
+
+

Conformance

+

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. + The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” + in the normative parts of this document + are to be interpreted as described in RFC 2119. + However, for readability, + these words do not appear in all uppercase letters in this specification.

+

All of the text of this specification is normative + except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

+

Examples in this specification are introduced with the words “for example” + or are set apart from the normative text with class="example", like this:

+
This is an example of an informative example.
+

Informative notes begin with the word “Note” + and are set apart from the normative text with class="note", like this:

+

Note, this is an informative note.

+
+ +

Index

+

Terms defined by this specification

+ +

References

+

Normative References

+
+
[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/ +
[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 +
[XMLSCHEMA-2] +
Paul V. Biron; Ashok Malhotra. XML Schema Part 2: Datatypes Second Edition. 28 October 2004. REC. URL: https://www.w3.org/TR/xmlschema-2/ +
+

Issues Index

+
+
Write Introduction section. ↵
+
Explain the principle of orthogonality, + by which this spec is split into multiple documents. ↵
+
Explain that this specification is not documentation; + it is the easiest way to understand how Solid works, + not the easiest way for building a Solid app. ↵
+
Introduce the structure of this document. + [Cross-server interoperability](#resource-access) + [Cross-app interoperability](#clients) ↵
+
+ + \ No newline at end of file diff --git a/main/resource-access.bs.0 b/main/resource-access.bs.0 new file mode 100644 index 00000000..545a811c --- /dev/null +++ b/main/resource-access.bs.0 @@ -0,0 +1,713 @@ +Authenticated Resource Access {#resource-access} +================================================ + +Issue: Write introduction to the Authenticated Resource Access section. + +## Hypertext Transfer Protocol ## {#http} + +### Background and Need ### {#http-need} +This section is non-normative. + +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 ### {#http-server} + +A [=data pod=] MUST be an HTTP/1.1 server [[!RFC7230]][[!RFC7231]]. +It SHOULD additionally be an HTTP/2 server [[!RFC7540]] +to improve performance, +especially in cases where individual clients +are expected to send high numbers of successive requests. + +A data pod SHOULD use TLS connections +through the `https` URI scheme +in order to secure the communication between clients and servers. +When both `http` and `https` are supported, +all `http` URIs MUST redirect to their `https` counterparts +using a response with a `301` status code and a `Location` header. + +A data pod MUST implement the server part +of HTTP/1.1 Conditional Requests [[!RFC7232]] +to ensure that updates requested by clients +will only be applied if given preconditions are met. +It SHOULD additionally implement the server part +of HTTP/1.1 Caching [[!RFC7234]] +to improve performance. +A data pod MAY implement the server part +of HTTP/1.1 Range Requests [[!RFC7233]] +to further improve performance for large representations. + +A data pod MUST implement the server part +of HTTP/1.1 Authentication [[!RFC7235]]. +When a client does not provide valid credentials +when requesting a resource that requires it (see [[#webid]]), +the data pod MUST send a response with a `401` status code +(unless `404` is preferred for security reasons). + +A Solid server MUST reject `PUT`, `POST` and `PATCH` requests without the +`Content-Type` header with a status code of `400`. +[[Source](https://github.com/solid/specification/issues/70#issuecomment-535499628)] + +### Required client-side implementation ### {#http-client} + +A Solid client MUST be an HTTP/1.1 client [[!RFC7230]][[!RFC7231]]. +It MAY additionally be an HTTP/2 client [[!RFC7540]] +to improve performance. + +A Solid client MAY implement the client parts of +HTTP/1.1 Conditional Requests [[!RFC7232]] +to only trigger updates when certain preconditions are met. +It MAY implement +HTTP/1.1 Caching [[!RFC7234]] +and +HTTP/1.1 Range Requests [[!RFC7233]] +to improve performance. + +A Solid client MUST implement the client part +of HTTP/1.1 Authentication [[!RFC7235]] +if it needs to access resources requiring authentication (see [[#webid]]). +When it receives a response with a `403` or `404` status code, +it MAY repeat the request with different credentials. + +A Solid client MUST use the `Content-Type` HTTP header in `PUT`, `POST` and +`PATCH` requests [[!RFC7231]]. +[[Source](https://github.com/solid/specification/issues/70#issuecomment-547924171)] + +## Uniform Resource Identifier ## {#uri} + +### Shared slash semantics ### {#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](https://github.com/solid/specification/issues/35#issuecomment-547949014)] + +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](https://github.com/solid/specification/issues/107#issuecomment-567482817)]. +Behaviour pertaining to authorization MUST proceed this optional redirect +[[Source](https://github.com/solid/specification/issues/107#issuecomment-567454889)] + +## Linked Data ## {#linked-data} + +### Containment ### {#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](https://github.com/solid/specification/issues/98#issuecomment-547506617)]. +It follows that all resources are discoverable from a container and that it is +not possible to create orphan resources. +[[Source](https://github.com/solid/specification/issues/97#issuecomment-547459396)] + +The representation and behaviour of containers in Solid corresponds to LDP +Basic Container and MUST be supported. +[[Source](https://github.com/solid/specification/issues/47#issuecomment-561675764)] + +### Persistence ### {#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](https://github.com/solid/specification/issues/46#issuecomment-589619372)] + +Note: +Servers that wish to disable URI re-use may want to use the `410` status +code. + +## Reading and Writing Resources ## {#read-write} + +Servers MUST respond with the `405` status code to requests using HTTP methods +that are not supported by the target resource. +[[Source](https://github.com/solid/specification/issues/117)] + +### Resource type heuristics ### {#resource-type-heuristics} + +When creating new resources, servers can determine an effective request URI's +type by examining the URI path ending ([[#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](https://github.com/solid/specification/pull/160#issuecomment-636822687)]. + +### Reading resources ### {#read} + +Servers MUST support the HTTP `GET`, `HEAD` and `OPTIONS` methods [[!RFC7231]] +for clients to read resources or to determine communication options. +[[Source](https://github.com/solid/specification/issues/39#issuecomment-538017667)] + +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]] and the `Accept-Post` [[!LDP]] 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` and `Accept-Post` headers in the +response of a `OPTIONS *` request. + +[[Source](https://github.com/solid/specification/issues/85#issuecomment-575386251)] +[[Source](https://github.com/solid/specification/issues/43)] + +### Writing resources ### {#write} + +When a server supports the HTTP `PUT`, `POST` and `PATCH` methods [[!RFC7231]] +this specification imposes the following requirements: +[[Source](https://github.com/solid/specification/issues/39#issuecomment-538017667)] + +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](https://github.com/solid/specification/issues/68#issuecomment-561690124)] + +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](https://github.com/solid/specification/pull/160#issuecomment-636822687)] + +When a `POST` method request targets a resource without an existing +representation, the server `MUST` respond with the `404` status code. +[[Source](https://github.com/solid/specification/issues/108#issuecomment-549448159)] + +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](https://github.com/solid/specification/issues/42#issuecomment-616688848)] + +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](https://github.com/solid/specification/issues/40#issuecomment-573358652)] + +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](https://github.com/solid/specification/issues/108#issuecomment-567272797)] +[[Source](https://github.com/solid/specification/issues/40#issuecomment-566995240)] + +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 ([[#wac]]): + +To create or update an ACL resource (see [[#ar-wac]]), an `acl:agent` MUST +have `acl:Control` privileges per the ACL inheritance algorithm on the +resource directly associated with it. +[[Source](https://github.com/solid/specification/issues/42#issuecomment-616688848)] + +### Deleting Resources ### {#delete} + +When a server supports the HTTP `DELETE` method [[!RFC7231]] this +specification imposes the following requirements: +[[Source](https://github.com/solid/specification/issues/39#issuecomment-538017667)] + +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](https://github.com/solid/specification/issues/37#issuecomment-627281466)] + +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](https://www.w3.org/TR/ldp#ldpc-del-contremovesconttriple)] + +When a contained resource is deleted, the server MUST also delete the +associated resources (see the [[#rm]] 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](https://github.com/solid/specification/pull/187/files/b7426e95a1613e08195a853a4d0a403b7030f494#r447130915)] + +When using Web Access Control ([[#wac]]): + +To delete a resource, an `acl:agent` MUST have `acl:Write` privilege per the +ACL inheritance algorithm on the resource. +[[Source](https://github.com/solid/specification/issues/197#issuecomment-690523999)] + +To delete an ACL resource (see [[#ar-wac]]), an `acl:agent` MUST have +`acl:Control` privileges per the ACL inheritance algorithm on the resource +directly associated with it. +[[Source](https://github.com/solid/specification/issues/145)] + +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](https://github.com/solid/specification/issues/72)] +[[Source](https://github.com/solid/specification/issues/46)] + +As deleted resources can be reinstated with the same URI, access controls on +the reinstated resource can change per the ACL inheritance algorithm. +[[Source](https://github.com/solid/specification/issues/145#issuecomment-618918284)] + +Issue: +Pertaining to events and loss of control mitigation: +https://github.com/solid/specification/issues/41#issuecomment-534679278 + +### Representations ### {#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](https://github.com/solid/specification/issues/45)] +[[Source](https://github.com/solid/specification/issues/69)] +[[Source](https://github.com/solid/specification/issues/109)] +[[Source](https://github.com/solid/specification/issues/195)] + +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](https://github.com/solid/specification/issues/109)] + + +## Auxiliary Resources ## {#rm} + +### Background and Need ### {#ar-need} +This section is non-normative. + +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 ### {#ar-server} + + +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. + +Issue: Is MUST NOT too strong? +[Related Issue](https://github.com/solid/specification/issues/176) + +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 ### {#ar-client} + +#### Discovery of Auxiliary Resources #### {#ar-discovery} + +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 [[#ar-wac]] and + [[#ar-shape]] through a HEAD request on + `:` +

+ 
+    HEAD https://server.example/resource.ttl
+    `Link: ; rel="http://www.w3.org/ns/solid/terms#acl"`
+    `Link: ; rel="http://www.w3.org/ns/solid/terms#shape"`
+
+

+ A client discovers the [[#ar-wac]] and [[#ar-description]] auxiliary + resources through a `GET` request on ``: +

+ 
+    GET https://server.example/image.png
+    `Link: ; rel="http://www.w3.org/ns/solid/terms#acl"`
+    `Link: ; rel="https://www.w3.org/ns/iana/link-relations/relation#describedby"`
+
+
+ +#### Discovery of Annotated Solid Resources #### {#ar-annotated} + +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. + +Issue: Is MUST too strong, as opposed to encouraging via SHOULD instead? +[Related Issue](https://github.com/solid/data-interoperability-panel/issues/37) + +
+

+ A [[#ar-description]] auxiliary resource + `` is directly associated with and + describes ``. A client that performs a GET + request on `` would discover the + following relation in the `Link` headers returned in the response. +

+ 
+    GET https://server.example/desc/08744
+    `Link: ; rel="https://www.w3.org/ns/iana/link-relations/relation#describes"`
+
+
+ +### Reserved Auxiliary Resource Types ### {#ar-reserved} + +The following table lists [[#ar-reserved]] 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 TypeLink Relation
[[#ar-wac]]```"acl"``` or ```http://www.w3.org/ns/solid/terms#acl```
[[#ar-description]]```"describedby"``` or +```https://www.w3.org/ns/iana/link-relations/relation#describedby```
[[#ar-shape]]```http://www.w3.org/ns/solid/terms#shape```
+ +Issue: Agree on specific link relation URIs to use for auxiliary types +[Related Issue](https://github.com/solid/specification/issues/172) + +#### Web Access Control #### {#ar-wac} + +ACL resources as defined by [[#wac]] 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 [[#wac]] + +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](https://github.com/solid/web-access-control-spec#describing-agents) +MUST have +[acl:Control](https://github.com/solid/web-access-control-spec#aclcontrol) +privileges per the +[ACL inheritance algorithm](https://github.com/solid/web-access-control-spec#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 #### {#ar-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. + +Issue: Consider whether a given Solid resource should be allowed to have +multiple resource description auxiliary resources. +[Related Issue](https://github.com/solid/specification/issues/173) + +A given Solid resource MUST NOT be directly associated with more than one +Descriptive auxiliary resource. + +Issue: Determine what the default permissions should be on resource description +auxiliary resources, or whether we should have them at all. +[Related Issue](https://github.com/solid/specification/issues/174) + +To create or modify a Descriptive auxiliary resource, a given +[acl:agent](https://github.com/solid/web-access-control-spec#describing-agents) +MUST have +[acl:Write](https://github.com/solid/web-access-control-spec#aclcontrol) +privileges per the +[ACL inheritance algorithm](https://github.com/solid/web-access-control-spec#acl-inheritance-algorithm) +on the resource directly associated with it. + +To discover or read a Descriptive auxiliary resource, an +[acl:agent](https://github.com/solid/web-access-control-spec#describing-agents) +MUST have +[acl:Read](https://github.com/solid/web-access-control-spec#aclcontrol) +privileges per the +[ACL inheritance algorithm](https://github.com/solid/web-access-control-spec#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 #### {#ar-shape} + +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. + +Issue: Determine what the default permissions should be on shape validation +auxiliary resources, or whether we should have them at all. +[Related Issue](https://github.com/solid/specification/issues/174) + +To create or modify a Shape validation auxiliary resource, an +[acl:agent](https://github.com/solid/web-access-control-spec#describing-agents) +MUST have +[acl:Write](https://github.com/solid/web-access-control-spec#aclcontrol) +privileges per the +[ACL inheritance algorithm](https://github.com/solid/web-access-control-spec#acl-inheritance-algorithm) +on the resource directly associated with it. + +To discover or read a Shape validation auxiliary resource, an +[acl:agent](https://github.com/solid/web-access-control-spec#describing-agents) +MUST have +[acl:Read](https://github.com/solid/web-access-control-spec#aclcontrol) +privileges per the +[ACL inheritance algorithm](https://github.com/solid/web-access-control-spec#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. + +Issue: 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. + +## WebID ## {#webid} + +Issue: Explain inline that agents accessing non-public Solid resources + need to authenticate with a WebID, which is a URL + pointing to a document with an RDF representation. + + +### WebID-OIDC ### {#webid-oidc} + +Issue: Write WebID-OIDC section. + +Draft: +A Solid data pod MUST conform to the WebID-OIDC specification [[!WEBID-OIDC]]. + + +### WebID-TLS ### {#webid-tls} + +Issue: Write WebID-TLS section. + +Draft: +A Solid data pod MAY conform to the WebID-TLS specification [[!WEBID-TLS]]. + + +## Web Access Control ## {#wac} + +Issue: Write Web Access Control section. + +Draft: +A Solid data pod 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`. +[[Source](https://github.com/solid/specification/issues/31#issuecomment-548360553)] + +In the event that a server can't apply an ACL to a resource, it MUST deny +access. +[[Source](https://github.com/solid/specification/issues/130#issue-532777017)] + +## Cross-Origin Resource Sharing ## {#cors} + +### Background and Need ### {#cors-need} +This section is non-normative. + +[=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](#wac)— +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](#wac) +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 ### {#cors-server} + +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](https://github.com/whatwg/fetch/issues/878) 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. diff --git a/meetings/2022-03-02.md b/meetings/2022-03-02.md new file mode 100644 index 00000000..e3b158c0 --- /dev/null +++ b/meetings/2022-03-02.md @@ -0,0 +1,64 @@ +# W3C Solid Community Group: Solid Editors + +* Date: 2022-03-02T11:00:00Z +* Call: https://meet.jit.si/solid-specification +* Chat: https://gitter.im/solid/specification +* Repository: https://github.com/solid/specification + + +## Present +* [Sarven Capadisli](https://csarven.ca/#i) +* Justin Bingham +* Kjetil Kjernsmo +* Tim Berners-Lee + +--- + +## Announcements + +### Meeting Recordings and Transcripts +* No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur. +* Join queue to talk. + + +### Participation and Code of Conduct +* [Join the W3C Solid Community Group](https://www.w3.org/community/solid/join), [W3C Account Request](http://www.w3.org/accounts/request), [W3C Community Contributor License Agreement](https://www.w3.org/community/about/agreements/cla/) +* [Solid Code of Conduct](https://github.com/solid/process/blob/main/code-of-conduct.md), [Positive Work Environment at W3C: Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/) +* Operating principle for effective participation is to allow access across disabilities, across country borders, and across time. Feedback on tooling and meeting timing is welcome. +* If this is your first time, welcome! please introduce yourself. + + +### Scribes +* Sarven Capadisli + + +### Introductions +* name: text + +--- + +## Topics + +Scratchpad (from prior meeting): + +### List for milestoning + +1. Secure WebSockets (with dependencies) +1. Address unspoken assumptions +1. Finish consideration sections +1. client_id in WAC +1. Auxiliary resources +1. Verifiable Credentials +1. Consent (whether server or client side) +1. Validation +1. Approach for ACP +1. More access modes: https://github.com/solid/web-access-control-spec/issues/85 https://github.com/solid/authorization-panel/issues/253 +1. Policy reuse in access control + +### Server options specd in pod metadata + + * Query + * Server-side validation + * W3C Consent request API + * ACP or WAC? version? Pod wide or server-wide? pod-wide -> pod portability + * \ No newline at end of file diff --git a/meetings/2022-09-07.md b/meetings/2022-09-07.md new file mode 100644 index 00000000..d2b4286b --- /dev/null +++ b/meetings/2022-09-07.md @@ -0,0 +1,93 @@ +# W3C Solid Community Group: Solid Editors + +* Date: 2022-09-07T13:00:00Z +* Call: https://meet.jit.si/solid-specification +* Chat: https://gitter.im/solid/specification +* Repository: https://github.com/solid/specification + +## Present +* [Sarven Capadisli](https://csarven.ca/#i) + +--- + +## Announcements + +### Meeting Recordings and Transcripts +* No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur. +* Join queue to talk. + + +### Participation and Code of Conduct +* [Join the W3C Solid Community Group](https://www.w3.org/community/solid/join), [W3C Account Request](http://www.w3.org/accounts/request), [W3C Community Contributor License Agreement](https://www.w3.org/community/about/agreements/cla/) +* [Solid Code of Conduct](https://github.com/solid/process/blob/main/code-of-conduct.md), [Positive Work Environment at W3C: Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/) +* Operating principle for effective participation is to allow access across disabilities, across country borders, and across time. Feedback on tooling and meeting timing is welcome. +* If this is your first time, welcome! please introduce yourself. + + +### Scribes +* Sarven Capadisli + + +### Introductions +* name: text + +--- + + +## Topics + +### Discovery of storage description and notification channel resource + +* SC: https://solid.github.io/notifications/protocol (ED) describes Link headers using `http://www.w3.org/ns/solid/term#storageDescription` (storage level) and `desribedby` (resource-specific) relations. + + + + +### Add requirement for Solid Notification Protocol +URL: https://github.com/solid/specification/pull/409 + +* SC: PR merged. Pending https://github.com/solid/specification/pull/409#issuecomment-1214977145 + + + +### Actions from last Agenda Overview +URL: https://github.com/solid/specification/blob/main/meetings/2022-06-15.md#actions-from-last-agenda-overview + +>ACTION: After resolving storage description, update ED to say MUST new/MAY old, SC. + +* SC: TODO. Same as above re https://github.com/solid/specification/pull/409#issuecomment-1214977145 + +>ACTION: Publish 0.9.1 with that ED, SC. + +* SC: TODO. +* SC: Double check storageDescription and perhaps any other editorial that hsould go out. +* +ACTION: SC to add line about change/update re Websocket and Notification Protocol. + +>ACTION: Reach out to solid-ui maintainers + +* SC: TODO. This wasn't assigned to anyone. + +>ACTION: Ask in Solid/chat whether there are more WebSocket implementations. + +* SC: TODO. This wasn't assigned to anyone. + + + +### Add TR/2022/wac-20220705 +URL: https://github.com/solid/specification/pull/417 + +>ACTION: KK, SC to follow with the suggestion. + +Done. + +>ACTION: TBL to review. + +* SC: + + + +### Add license +URL: https://github.com/solid/specification/pull/412 + +* SC: What's next? diff --git a/meetings/2022-09-28.md b/meetings/2022-09-28.md new file mode 100644 index 00000000..4d883aea --- /dev/null +++ b/meetings/2022-09-28.md @@ -0,0 +1,88 @@ +# W3C Solid Community Group: Solid Editors + +* Date: 2022-09-28T13:00:00Z +* Call: https://meet.jit.si/solid-specification +* Chat: https://gitter.im/solid/specification +* Repository: https://github.com/solid/specification + +## Present +* [Sarven Capadisli](https://csarven.ca/#i) + +--- + +## Announcements + +### Meeting Recordings and Transcripts +* No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur. +* Join queue to talk. + + +### Participation and Code of Conduct +* [Join the W3C Solid Community Group](https://www.w3.org/community/solid/join), [W3C Account Request](http://www.w3.org/accounts/request), [W3C Community Contributor License Agreement](https://www.w3.org/community/about/agreements/cla/) +* [Solid Code of Conduct](https://github.com/solid/process/blob/main/code-of-conduct.md), [Positive Work Environment at W3C: Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/) +* Operating principle for effective participation is to allow access across disabilities, across country borders, and across time. Feedback on tooling and meeting timing is welcome. +* If this is your first time, welcome! please introduce yourself. + + +### Scribes +* Sarven Capadisli + + +### Introductions +* name: text + +--- + + +## Topics + +### Discovery of storage description and notification channel resource +URL: + +* SC: https://solid.github.io/notifications/protocol (ED) describes Link headers using `http://www.w3.org/ns/solid/term#storageDescription` (storage level) and `describedby` (resource-specific) relations. +* SC: There is the question of whether to keep both. + + +### Too Slow: Please provide Updates-Via shortcut to secure web socket address +URL: https://github.com/solid/notifications/issues/110 + + + + + +### Add requirement for Solid Notification Protocol +URL: https://github.com/solid/specification/pull/409 + +* SC: PR merged. Pending https://github.com/solid/specification/pull/409#issuecomment-1214977145 + + + +### Actions from last Agenda Overview +URL: https://github.com/solid/specification/blob/main/meetings/2022-06-15.md#actions-from-last-agenda-overview + +>ACTION: After resolving storage description, update ED to say MUST new/MAY old, SC. + +* SC: TODO. Same as above re https://github.com/solid/specification/pull/409#issuecomment-1214977145 + +>ACTION: Publish 0.9.1 with that ED, SC. + +* SC: TODO. +* SC: Double check storageDescription and perhaps any other editorial that should go out. + +ACTION: SC to add line about change/update re Websocket and Notification Protocol. + +>ACTION: Reach out to solid-ui maintainers + +* SC: TODO. This wasn't assigned to anyone. + +>ACTION: Ask in Solid/chat whether there are more WebSocket implementations. + +* SC: TODO. This wasn't assigned to anyone. + + + + +### Add license +URL: https://github.com/solid/specification/pull/412 + +* SC: What's next? diff --git a/meetings/20240117.md b/meetings/20240117.md new file mode 100644 index 00000000..36863d5f --- /dev/null +++ b/meetings/20240117.md @@ -0,0 +1,161 @@ +# W3C Solid Community Group: Weekly + +* Date: 2024-01-17T14:00:00Z +* Call: https://meet.jit.si/solid-cg +* Chat: https://matrix.to/#/#solid_specification:gitter.im +* Repository: https://github.com/solid/specification + + +## Present +* [Michiel de Jong](https://michielbdejong.com) (chair) +* [Rahul Gupta](https://cxres.pages.dev/profile#i) +* Maxime Lecoq +* Hadrian Zbarcea +* [Sarven Capadisli](https://csarven.ca/#i) +* [elf Pavlik](https://elf-pavlik.hackers4peace.net) +* [Virginia Balseiro](https://virginiabalseiro.com/#me) +* Reza Soltani +* [April Daly](https://aprildaly.me) +* [Pierre-Antoine Champin](https://solid.champin.net/pa/profile/card#me) +* michal/mrkvon +* Fred Gibson + +--- + +## Announcements + +### Meeting Guidelines +* [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar). +* [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md). +* No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur. +* Join queue to talk. +* Topics can be proposed at the bottom of the agenda to be discussed as time allows. Make it known if a topic is urgent or cannot be postponed. + +### Participation and Code of Conduct +* [Join the W3C Solid Community Group](https://www.w3.org/community/solid/join), [W3C Account Request](http://www.w3.org/accounts/request), [W3C Community Contributor License Agreement](https://www.w3.org/community/about/agreements/cla/) +* [Solid Code of Conduct](https://github.com/solid/process/blob/main/code-of-conduct.md), [Positive Work Environment at W3C: Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/) +* Operating principle for effective participation is to allow access across disabilities, across country borders, and across time. Feedback on tooling and meeting timing is welcome. +* If this is your first time, welcome! please introduce yourself. + + +### Scribes +* Sarven Capadisli +* Virginia Balseiro + +--- + +## Topics + +### Open spec PRs + +#### Add security consideration for serving user-created files +URL: https://github.com/solid/specification/pull/598 + +* VB: Please review. +* SC: Tied to an issue, some discussion in the PR. Wrote a comment earlier. Thought this through for a while. I think the consideration is good and we should have more stuff along those lines. Depending on whether the protocol expresses a need like that says something else about the architecture. There are some assumptions baked into this. It has some tradeoffs/conflicts with other things. We should weigh it a bit more and discuss further before assuming it is as intended. Does this belong in that general pattern? Is it consistent with the rest of the design? Just my considerations. +* MdJ: Makes sense. +* eP: We should add it as soon as possible in whatever form we reach rough consensus. Still at least list the possible issues. We can't expect everyone to be aware of all the issues. It could be an inline issue to help make people aware it exists. And perhaps people give valuable feedback. +* RG: Do we have like kanban board +* SC: We have a project board: https://github.com/orgs/solid/projects/15/views/3 +* MdJ: We don't have a team of people working on it. +* MdJ: Please comment on the issue. + + +### Access to Chairs on the Repo +* eP: Do all chairs have access to solid/specification? +* VB: I can take care of it. + +ACTION: VB to give access to co-chairs to solid/specification + +### Project board +* RG: Should the project board be linked from ??? +* SC: Stuff that has been mostly active until last release; been updating in some ways more towards milestoning for next release. Doesn't have categorization of more recent issues. That can be improved. Process those last issues into this board. They're not there. +* MdJ: If Sarven is not regularly grooming, then it's not good to link. Unless, RG, you want to pick it up yourself? +* SC: Virginia will take care of access to chairs and can say more on project board, e.g., STM. +* VB: How are they related? Right for STM, not for issues. If that can be useful, we can add more recent issues or talk about them in these meetings. +* MdJ: We shouldn't link to it until someone works on it. +* HZ: I can help if we agree there is value. +* VB: I can look into using the board as mentioned. +* HZ: If we agree it has value, I can groom it. +* MdJ: I don't see particular value in it. There's more value if people want to do more work on the spec to do more PR reviewing, higher priority. +* HZ: Agree but quite a few open issues. +* VB: Agree with MDJ. Focus on PR review, and if time/resources are available. +* MdJ: Can use these meetings as "our board". +* eP: I'd support it. I can join HZ on this for next week discussion. +* HZ: Sounds good. +* RG: This is so that anybody who comes to this can have a centralised view which might make it easier. +* MdJ: I'd be careful to not pick up work that we might not need. I'd say we try to work on the PRs and feel that not enough clarity and other issues to work, we can dig them up. + + +#### Clarify requests with N3 document in server-representation-turtle-jsonld +URL: https://github.com/solid/specification/pull/608 + +* MdJ: This clarifies that when there is an N3 document, it should be the same as RDF document. I suggested for the purposes of N3 patch +* eP: I want to clarify the intent of this. In LDP, we talk about (Non)RDF-Sources. Here we try to avoid that distinction, but here we do ??? . With N3, it happens to use an N3 document. The way to formulate may be to consider whether SPARQL Update may be used in the future. Take some time and see if we can formulate it in a way that's special for N3 but can also work with SPARQL. Also consideration on what's mature that can go to spec. +* MdJ: Want to make a suggestion into the spec of that wording? +* eP: What do we think about ??? instead of going through content types, like RDF and non-RDF sources. Then we don't have to list all patches. +* SC: I asked for clarification in the chat. Some of that still applies. The requirement is more of a category of formats. The way it's written is not tied to a particular patch format. The only thing the spec says is _patch is done this way_, completely orthogonal to the formats that a server may be accepting, and if it does it needs to make available in ??? Right now the spec implies a server should be able to take an N3 document when you make a patch. Right now we're only saying RDF document, but that is not entirely true. IF we want to say SPARQL is needed, that can be captured along those lines. There is nothing more generic to capture... right now we capture those two. +* MdJ: What about ??? not say anything about the body but the target. +* SC: Creating. +* eP: in the context of creating. If you use SPARQL Update patch to create an RDF resource, ??? +* MdJ: Continue in PR? +* eP: It should covers +* SC: What notion do you know that would cover RDF, N3, SPARQL.. +* MdJ: Don;'t refer to body but target. +* SC: You're saying if I give you an image you can give that back in turtle. +* MdJ: Let's continue on PR. + +#### Add document status to guides, templates +URL: https://github.com/solid/specification/pull/613 + +Proposed by: SC + +* MdJ: You're marking some documents as no longer in effect? +* SC: We're using W3C Solid CG repo, and that's the source of truth. Minor. +* VB: Approved. + +#### Should Solid (storage) servers support "RDF documents" containing multiple subjects (or quads)? +URL: https://github.com/solid/specification/issues/610 + +Proposed by: Maxime + +* MdJ: This is more a question than a PR maybe? +* ML: Some server implementations are not allowing multiple subjects in the payload when creating or updating resources. So, in some apps, can't apply the TypeIndex or any self-describing document. Was wondering if it should not be part of the spec, if/when we are accepting RDF document/graph, we must accept a graph containing multiple subjects. +* MdJ: The spec allows the server. So can never be sure. If a server only accepts triples about the document, I'd say that server is broken. +* eP: Besides self-describing docs, certain predicates are used in a certain direction, like JSON-LD reverse. This is common in RDF. Since it is a graph, often things can be subject or object. I think it'd be interesting to add a test case. What level would this requirement be? +* MdJ: Even if you do WAC for instance, you'd have different Authorization rules. A test would fail in that case. That server wouldn't be compliant. +* PAC: Not sure I agree with you, re: any server should accept any type of content. I don't have a strong opinion. But I can understand that some people might want to develop servers — maybe not generalist servers — but still using some of the Solid server specification. Maybe it is not a good idea to rule out those people. I can share some things from the LDP work. I realised that some terms used in the group didn't make it to the spec. Used to talk about vanilla and chocolate servers — generalist servers and passive servers vs. the ones to put arbitrary resources. +* eP: Should get back to this topic when doing server validation. If a server advertises a shape, and not just arbitrary. I agree not every server can, but can advertise the added payload. +* MdJ: That'd be perhaps in future spec? +* SC: Current spec says... category of constraints, one imposed by the server, expectation that container should behave... Anything beyond is open; spec allows the case PAC was mentioning. There's also the possibility to advertise those contraints. Existing servers, if they want to continue doing what they're doing, might want to get into that habit. +* SC: There's a similar consideration raised in Solid Protocol, whether a read-only Solid server should be conforming. Normally we think read-write. Whether a conforming server not implementing those methods... Some servers might want to do the minimal thing. That's fine. +* MdJ: "Advertising its chocolateness" (TM). +* ML: So this constraint would be known at run-time, and not when they're choosing their pod. So then I get a pod but might not be as expected. +* eP: Separate topic perhaps; how people can choose. Who is setting the constraints. It shouldn't be arbitrary constraints. How we can educate users picking a storage? +* SC: Server could pass the test suite. When it's deployed, it could completely reject requests including multiple subjects. I don't think the test suite will catch that. Comes down to whether URI owner allows that. + + +### Demo +#### Solid Data Modules Intro +URL: https://github.com/solid-contrib/data-modules + +Proposed & presented by: Michiel + +* MdJ: Slides: https://github.com/michielbdejong/presentations/blob/main/sdm-cg-17-jan.pdf +* MdJ: Solid Data Modules uses the platform for data interoperability. I'd call "'small' Solid = RWW". As a power user, there can be data browsers. `mashlib` is one. Also from modula, `ontolo`. Kind of like SolidOS, where any data has a particular shape, can have a view. I also see a bigger vision "'big' Solid = data pivot". It is a datastore. The GUI running on top of it. We need a much stricter spec for pod as a data pivot. App A writes to Solid Pod, read by App B. For one power user, usefulness comes if App A's data can be reused by App B. For that to be open, apps need to know what to expect from the pod, when it will fail, or have discoverable capabilities for minimal reliable working thing. Data application rights need to be available in an understandable way, but then the choice of ontology and data shape matters. The business logic around that needs to be understood. need server behaviour to be strict — can't have chocolate servers — have data conventions, which ontologies to use — even if we share a WebID Profile, it might have `x:name`, but the app is using `y:name`. No good data conventions and also access control and they go hand in hand. The activities in Data Modules, we document and write translations between formats, reusable code in JavaScript, which handles the translation for you. This is one of the sites where we document data conventions. For example, bookmarking is in different vocabs. It'd be nice to make that compatible. Some apps use `x` and other `y` without knowing the other exists. SDM also abstracts them. +* MdJ: There is a chat room, NLnet funding for this project. +* eP: Looks interesting, and with demos would be good in action. For different apps or templates from servers, they don't have a strong reason to use this or some kind of a best practice. Devs go to NPM and tend to pick things wiht most downloads. Most of us take our extensions to use what they'll use. Most devs would be happy to choose the simpler. +* eP: As soon as we have something like recommended shape. Similar like schema.org — tightly curated schema — and there is [LOV](https://lov.linkeddata.es/dataset/lov/) to pick from. +* MdJ: We don't have the issue tracker to ??? +* eP: You mentioned data types for access control. For SAI, we have access needs to reference a project as an IRI. +* MdJ: I'd want to import difference ones from my pod and use code that can read both formats. + +--- end of meeting --- +--- not discussed: --- + +### General Discussion +#### Work Item Proposal: Solid Application Requirements +URL: https://github.com/solid/specification/issues/615 + +#### CG Call Frequency +* MdJ: We could consider having fewer and lighter plenary CG calls, in favour of more in-depth work meetings on specific work items, and moving spec PR reviews into either async for small ones or STMs for bigger ones (then also requiring the STM to write its conclusions into the issue it was about). diff --git a/mit-license.ttl b/mit-license.ttl new file mode 100644 index 00000000..589f881d --- /dev/null +++ b/mit-license.ttl @@ -0,0 +1,30 @@ +@prefix dcterms: . +@prefix rdfs: . +@prefix xsd: . + +<> + a dcterms:LicenseDocument ; + dcterms:created "2022-07-07"^^xsd:dateTime ; + dcterms:modified "2022-07-07"^^xsd:dateTime ; + rdfs:label "MIT License"@en ; + dcterms:rightsHolder ; + dcterms:rights """Copyright (c) 2018 W3C Solid Community Group + +Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the \"Software\"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE."""@en . + +# dcterms:hasVersion "1.0" ; +# dcterms:language ; +# dcterms:source ; +# prov#wasDerivedFrom ; + +# a odrl:Policy ; +# odrl:permission [ +# odrl:action cc:DerivativeWorks, cc:Distribution, cc:Reproduction, odrl:modify, odrl:sell ; +# odrl:duty [ +# odrl:action cc:Notice +# ] +# ] . diff --git a/notification-channel-types.html b/notification-channel-types.html new file mode 100644 index 00000000..3c650ee7 --- /dev/null +++ b/notification-channel-types.html @@ -0,0 +1,395 @@ + + + + + Notification Channel Types + + + + + + +
+
+ +
+
+ +
+
+

Notification Channel Types

+

Living Document, 2022-05-05

+ +
+ More details about this document + +
+
This version
+
https://solidproject.org/TR/notification-channel-types
+
+ +
+
+
Editors
+
Sarven Capadisli
+
+
+ +
+
Created
+
+
+ +
+
Published
+
+
+ +
+
Modified
+
+
+ +
+
Repository
+
GitHub
+
Issues
+
+ +
+
Language
+
English
+
+ +
+
License
+
MIT License
+
+ +
+
Document Status
+
Published
+
+ +
+
In Reply To
+
Solid Origin
+
+ +
+
Policy
+
+
+
Rule
+
Offer
+
Unique Identifier
+
https://solidproject.org/TR/notification-channel-types#document-policy-offer
+
Target
+
https://solidproject.org/TR/notification-channel-types
+
Permission
+
+
+
Assigner
+
W3C Solid Community Group
+
Action
+
+ +
+
+
+
+
+
+
+ +

MIT License. Copyright © 2022 W3C Solid Community Group.

+ +
+
+

Abstract

+
+

This document serves as an index for Channel Types that can be used with the Solid Notifications Protocol.

+
+
+ +
+

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 Living Document. 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 Living Document does not imply endorsement by the W3C Membership. 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.

+ +

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

+
+
+ + + +
+

Introduction

+
+

This section is non-normative.

+ +

The purpose of this document is to help with the discovery of Channel Types published as a Solid Technical Report that can be used with the Solid Notifications Protocol [SOLID-NOTIFICATIONS-PROTOCOL].

+ +

This document also describes the indexing procedure to add new Channel Types to the index.

+ +

This document is for:

+ + + +
+

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

+
+
+
+
+ +
+

Indexing Procedure

+
+

In order to update this index, an implementer MUST submit a modification request for this index, as a pull request on the repository where this index is hosted, where the modification request includes the following information:

+ +
+
Name
+
The name of the subscription type
+
Description
+
A short English description of the type's semantics.
+
Reference
+
Reference to the document that specifies the subscription type, preferably including a URI that can be used to retrieve a copy of the document.
+
+
+
+ +
+

Index

+
+

The information in these documents may be subject to change, therefore please see each document’s publication status and versions for further details.

+ + + + + + + + + + + + + + + + + +
Channel Types
NameDescriptionReference
WebSocketChannel2023Subscription type that uses the WebSocket API.WebSocketChannel2023
+
+
+ +
+

References

+
+
+

Normative References

+
+
+
[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
+
[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
+
+
+
+ +
+

Informative References

+
+
+
[SOLID-NOTIFICATIONS-PROTOCOL]
+
Solid Notifications Protocol. Aaron Coburn; Sarven Capadisli. W3C Solid Community Group. 1 April 2022. Version 0.1.0. URL: https://solidproject.org/TR/notifications-protocol
+
+
+
+
+
+
+
+
+ + diff --git a/notifications-flow-source.svg b/notifications-flow-source.svg new file mode 100644 index 00000000..55563903 --- /dev/null +++ b/notifications-flow-source.svg @@ -0,0 +1 @@ +SubscriberStorage Metadata ResourceSubscriptions ContainerAuthorization ServerNotifications SourceDiscovery1Storage Metadata Resource2Request subscription (with access token)3Verify authorization4capabilities5Subscription response (with notifications source)6Establish connection7Stream notifications8SubscriberStorage Metadata ResourceSubscriptions ContainerAuthorization ServerNotifications Source \ No newline at end of file diff --git a/notifications-flow-target.svg b/notifications-flow-target.svg new file mode 100644 index 00000000..a31a5806 --- /dev/null +++ b/notifications-flow-target.svg @@ -0,0 +1 @@ +SubscriberNotifications TargetStorage Metadata ResourceSubscriptions ContainerAuthorization ServerNotifications SourceDiscovery1Storage Metadata Resource2Request subscription (with access token)3Verify authorization4capabilities5Subscription response (with webid & unsubsribe)6Deliver notification7loop[for each notification]Unsubscribe (delete subscription)8204 No Content9SubscriberNotifications TargetStorage Metadata ResourceSubscriptions ContainerAuthorization ServerNotifications Source \ No newline at end of file diff --git a/p.html b/p.html new file mode 100644 index 00000000..130af8ca --- /dev/null +++ b/p.html @@ -0,0 +1,1216 @@ + + + + + Solid Protocol + + + + + + +
+
+ +
+
+ +
+
+

Solid Protocol

+

Editor’s Draft, 2021-11-05

+ +
+
This version
+
https://solidproject.org/TR/protocol
+
+ + + +
+
Published
+
+
+ +
+
Modified
+
+
+ +
+
Repository
+
GitHub
+
Issues
+
+ +

MIT License. Copyright © 2019–2021 W3C Solid Community Group.

+ +
+
+

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.

+ +

This specification is for:

+ + + +
+

Terminology

+
+

This section is non-normative.

+ +

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

+ + + +
+
data pod
+
A data pod is a place for storing documents, with mechanisms for controlling who can access what.
+ +
Solid app
+
A Solid app is an application that reads or writes data from one or more data pods.
+ +
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 [RFC7231].
+ +
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.
+ +
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 data storage. An owner is identified by a URI, and implicitly has control over all data in a storage. An owner is first set at storage provisioning time and can be changed.
+ +
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
PrefixNamespaceDescription
rdfhttp://www.w3.org/1999/02/22-rdf-syntax-ns#[rdf-schema]
ldphttp://www.w3.org/ns/ldp#[LDP]
solidhttp://www.w3.org/ns/solid/terms#Solid Terms
pimhttp://www.w3.org/ns/pim/space#Workspace Ontology
aclhttp://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.

+ +
+

HTTP Server

+
+

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 server. When both http and https 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.

+ +

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

+ +

A data pod MUST implement the server part of HTTP/1.1 Authentication [RFC7235]. When a client does not provide valid credentials when requesting a resource that requires it (see WebID), the server 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]

+
+
+ +
+

HTTP Client

+
+

A Solid client MUST be an HTTP/1.1 client [RFC7230][RFC7231]. Clients MAY 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. Clients MAY implement HTTP/1.1 Caching [RFC7234]. Clients MAY implement HTTP/1.1 Range Requests [RFC7233] to improve performance.

+ +

A Solid client MUST implement the client part of HTTP/1.1 Authentication [RFC7235] if it needs to access resources requiring authentication (see WebID). When a client receives a response with a 403 or 404 status code, the client 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

+
+
+

Note: Storage Owner and URI Ownership

+
+

This specification does not describe the relationship between a Solid 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 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 Resource Containment).

+ +

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

+ +

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

+ +

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

+ +

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

+ +

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

+ +

[Source] [Source]

+ +

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

+ +

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

+ +
+

Note: Trust Between Owners

+
+

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

+
+
+ +

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

+
+
+ +
+

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.

+ +

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

+ +

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

+ +
+

Note: 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.

+
+
+ +

This specification defines the following types of auxiliary resources:

+ + + +

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

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
Auxiliary TypeLink RelationDefinitions
Web Access Controlacl[Solid Protocol]
Description Resourcedescribedby[LDP]
+
+

The possibility of using URIs as relation types interchangeably or as alternate to the tokens above are under consideration:

+ +
    +
  • http://www.w3.org/ns/auth/acl#accessControl
    • +
  • https://www.w3.org/ns/iana/link-relations/relation#acl
    • +
  • https://www.w3.org/ns/iana/link-relations/relation#describedby
    • +
  • https://www.w3.org/ns/iana/link-relations/relation#describes
    • +
+ +

Issue

+
+
+ +
+

Web Access Control

+
+

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

+
+
+ +
+

Description Resource

+
+

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

+ +

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

+ +

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

+ +

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

+
+
+
+
+
+
+ +
+

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 (URI Slash Semantics).

+ +

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

+ +

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

+ +
+

Note: 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 [RFC7231] for clients to read resources or to determine communication options. [Source]

+ +

When responding to authorized requests:

+ +

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

+ +

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

+ +

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

+ +

[Source] [Source]

+
+
+ +
+

Writing Resources

+
+

Servers MUST support the HTTP PUT, POST and PATCH methods [RFC7231]. [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 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. [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 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]

+ +
+

Note: Conditional Update

+
+

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

+
+ +
+

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]. They MUST indicate such support by listing text/n3 as a value of the Accept-Patch header [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.
    • +
  • The patch resource MAY contain one triple of the form ?patch solid:matchingStrategy solid:SingleMatch.
    • +
  • 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.
    • +
  • The patch document MUST NOT contain any other triples.
    • +
+ +

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:

+ +
    +
  1. Start from the RDF dataset in the target document, or an empty RDF dataset if the target resource does not exist yet.
    2. +
  2. If ?conditions is non-empty, find all (possibly empty) variable mappings such that all of the resulting triples occur in the dataset.
    3. +
  3. If no such mapping exists, or if multiple mappings exist, the server MUST respond with a 409 status code. [Source]
    4. +
  4. The resulting variable mapping is propagated to the ?deletions and ?insertions formulae to obtain two sets of resulting triples.
    5. +
  5. 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]
    6. +
  6. The triples resulting from ?deletions are to be removed from the RDF dataset.
    7. +
  7. 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.
    8. +
  8. 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.
    9. +
+
+ +
+

Example: Applying an N3 patch.

+ 
@prefix solid: <http://www.w3.org/ns/solid/terms#>.
+@prefix ex: <http://www.example.org/terms#>.
+
+_:rename a solid:Patch;
+  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 [RFC7231]. [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 HTTP response header Allow in response to requests [RFC7231]. [Source]

+ +

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

+ +

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

+ +

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

+ +

This section is non-normative.

+ +

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

+ +

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

+ +

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

+
+
+ +
+

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

+
+
+ +
+

WebSockets

+
+

For real-time communication between client and server about changes affecting a resource, Solid uses the WebSocket API [W3C-HTML] and the WebSocket Protocol.

+ +
+

WebSockets Pub-Sub

+
+
+
+ +
+

WebSockets Patching

+
+
+
+
+
+ +
+

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, 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 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 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 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: 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 data pod 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-* headers as specified in the CORS protocol [FETCH]. In particular, the server 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 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-* headers themselves). A server 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, server 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). Servers 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 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

+
+
+

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, and applies the authorization conditions on requested operations. Authorizations are described using the ACL ontology to express and determine access privileges of a requested resource. Applications can discover authorization rules associated with a given resource, and to control such rules, as directed by an agent.

+ +

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

+ +

When a server wants to enable applications to discover the authorization rules associated with a given resource, the server MUST advertise the ACL resource that is associated with a resource by responding to an HTTP request including a Link header with the rel value of acl (acl Link Relation) and the ACL resource as link target [RFC8288]. [Source]

+ +

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

+ +

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

+ +

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

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

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

+ +

This specification defines the following permission-groups:

+ +
+
user
+
Permissions granted to the agent requesting the resource.
+
public
+
Permissions granted to the public.
+
+ +

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

+ +

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

+ +

Client parsing algorithms for WAC-Allow header field-values MUST incorporate error handling. When the received message fails to match an allowed pattern, clients MUST ignore the received WAC-Allow header-field. When unrecognised access parameters (such as permission groups or access modes) are found, clients MUST continue processing the access parameters as if those properties were not present.

+ +

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

+ +

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 urged to seek the advice of security professionals when implementing mission critical systems using the technology outlined in this specification.

+ +

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

+ +

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

+ +

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

+ +

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

+ +

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

+
+
+ +
+

Privacy Considerations

+
+

This section is non-normative.

+ +

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

+ +
+

Identifiable Information

+
+

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

+
+
+
+
+ +
+

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.0 [DPUB-ARIA-1.0]. To support structured graphics such as charts, graphs, technical drawings and scientific diagrams, to assistive technologies in order improve accessibility of graphics or diagrams through detailed annotations, it is encouraged to follow the WAI-ARIA Graphics Module [GRAPHICS-ARIA-1.0].

+ +

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

+ +

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

+
+
+ +
+

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

+
+

..

+
+
+
+
+ +
+

References

+
+
+

Normative References

+
+
+
[FETCH]
+
Fetch Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://fetch.spec.whatwg.org/
+
[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. Dörthe Arndt; William Van Woensel;Dominik Tomaszuk; Gregg Kellogg. W3C. 5 September 2021. Draft Community Group Report. URL: https://w3c.github.io/N3/spec/
+
[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
+
[RFC3864]
+
Registration Procedures for Message Header Fields. G. Klyne; M. Nottingham; J. Mogul. IETF. September 2004. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc3864
+
[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
+
[RFC6892]
+
The 'describes' Link Relation Type. E. Wilde. IETF. March 2013. Informational. URL: https://datatracker.ietf.org/doc/html/rfc6892
+
[RFC7230]
+
Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7230.html
+
[RFC7231]
+
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7231.html
+
[RFC7232]
+
Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7232.html
+
[RFC7233]
+
Hypertext Transfer Protocol (HTTP/1.1): Range Requests. R. Fielding, Ed.; Y. Lafon, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7233.html
+
[RFC7234]
+
Hypertext Transfer Protocol (HTTP/1.1): Caching. R. Fielding, Ed.; M. Nottingham, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7234.html
+
[RFC7235]
+
Hypertext Transfer Protocol (HTTP/1.1): Authentication. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7235.html
+
[RFC7540]
+
Hypertext Transfer Protocol Version 2 (HTTP/2). M. Belshe; R. Peon; M. Thomson, Ed.. IETF. 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://datatracker.ietf.org/doc/html/rfc8174
+
[RFC8288]
+
Web Linking. M. Nottingham. IETF. October 2017. Proposed Standard. URL: https://httpwg.org/specs/rfc8288.html
+
[SOLID-OIDC]
+
SOLID-OIDC. Aaron Coburn; elf Pavlik; Dmitri Zagidulin. W3C Solid Community Group. W3C Editor's Draft. URL: https://solid.github.io/solid-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. Draft. 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. Henry Story; Andrei Sambra; Stéphane Corlosquet. 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. 11 December 2020. W3C Working Draft. URL: https://www.w3.org/TR/coga-usable/
+
[DPUB-ARIA-1.0]
+
Digital Publishing WAI-ARIA Module 1.0. Matt Garrish; Tzviya Siegman; Markus Gylling; Shane McCarron. W3C. 14 December 2017. W3C Recommendation. URL: https://www.w3.org/TR/dpub-aria-1.0/
+
[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/
+
[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. W3C. 2 March 2021. W3C Candidate Recommendation. URL: https://www.w3.org/TR/wai-aria-1.2/
+
[WCAG-3.0]
+
W3C Accessibility Guidelines (WCAG) 3.0. Jeanne F Spellman; Rachael Bradley Montgomery; Shawn Lauriat; Michael Cooper. W3C. 21 January 2021. W3C Working Draft. URL: https://www.w3.org/TR/wcag-3.0/
+
[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/
+
+
+
+
+
+
+
+
+ + + + + + diff --git a/pod-management/index.html b/pod-management/index.html new file mode 100644 index 00000000..7d048241 --- /dev/null +++ b/pod-management/index.html @@ -0,0 +1,1586 @@ + + + + Data Pod Management + + + + + + + + + + +
+

+

Data Pod Management

+

Editor’s Draft,

+ +
+

CC0 To the extent possible under law, the editors have waived all copyright +and related or neighboring rights to this work. +In addition, as of 12 May 2020, +the editors have made this specification available under the Open Web Foundation Agreement Version 1.0, +which is available at http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0. +Parts of this work may be from another specification document. If so, those parts are instead covered by the license of that specification document.

+
+
+
+

Abstract

+

This document describes an RDF-driven Web API + + for managing users and data pods of a Solid pod server. + Through this common API, + servers with different implementations + can be managed with the same apps.

+
+
+ +
+

Status of This Document

+ This document is an incomplete 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.

+

1. Introduction

+

Write Introduction section.

+
+
+

Conformance

+

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. + The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” + in the normative parts of this document + are to be interpreted as described in RFC 2119. + However, for readability, + these words do not appear in all uppercase letters in this specification.

+

All of the text of this specification is normative + except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

+

Examples in this specification are introduced with the words “for example” + or are set apart from the normative text with class="example", like this:

+
This is an example of an informative example.
+

Informative notes begin with the word “Note” + and are set apart from the normative text with class="note", like this:

+

Note, this is an informative note.

+
+ +

References

+

Normative References

+
+
[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 +
+

Issues Index

+
+
Write Introduction section. ↵
+
\ No newline at end of file diff --git a/protocol.test.html b/protocol.test.html new file mode 100644 index 00000000..3b728382 --- /dev/null +++ b/protocol.test.html @@ -0,0 +1,1588 @@ + + + + + Solid Protocol + + + + + + + + +
+
+ +
+
+ +
+
+

Solid Protocol

+ +

Version 0.10.0,

+ +
+ More details about this document + +
+
This version
+
https://solidproject.org/TR/2022/protocol-20221231
+
+ +
+
Latest published version
+
https://solidproject.org/TR/protocol
+
+ +
+
Previous version
+
https://solidproject.org/TR/2021/protocol-20211217
+
+ +
+
Editor’s draft
+
https://solidproject.org/ED/protocol
+
+ +
+
TimeMap
+
https://solidproject.org/TR/protocol.timemap
+
+ +
+
Editors
+
Sarven Capadisli
+ +
Tim Berners-Lee
+ +
Ruben Verborgh
+ +
Kjetil Kjernsmo
+
+ +
+
Published
+
+
+ +
+
Modified
+
+
+ +
+
Repository
+
GitHub
+
Issues
+
+ +
+
Test Suite
+
Coverage
+
+ +
+
Language
+
English
+
+ +
+
License
+
MIT License
+
+ +
+
Document Status
+
Published
+
+ +
+
In Reply To
+
Solid Origin
+
+ +
+
Policy
+
+
+
Rule
+
Offer
+
Unique Identifier
+
https://solidproject.org/TR/protocol#document-policy-offer
+
Target
+
https://solidproject.org/TR/protocol
+
Permission
+
+
+
Assigner
+
W3C Solid Community Group
+
Action
+
+ +
+
+
+
+
+
+
+ +

MIT License. Copyright © 2019–2022 W3C Solid Community Group.

+ +
+
+

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 Version 0.10.0. 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 Version 0.10.0 does not imply endorsement by the W3C Membership. This document 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

+
+

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 [RFC7231].
+ +
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
PrefixNamespaceDescription
rdfhttp://www.w3.org/1999/02/22-rdf-syntax-ns#[rdf-schema]
ldphttp://www.w3.org/ns/ldp#[LDP]
solidhttp://www.w3.org/ns/solid/terms#Solid Terms
pimhttp://www.w3.org/ns/pim/space#Workspace Ontology
aclhttp://www.w3.org/ns/auth/acl#ACL Ontology
dctermshttp://purl.org/dc/terms/[DC-TERMS]
stathttp://www.w3.org/ns/posix/statPOSIX 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 [RFC7230] and [RFC7231] 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 [RFC7230], [RFC7231], 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.

+
+
+
+
+
+
+ +
+

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/1.1 Message Syntax and Routing [RFC7230] and HTTP/1.1 Semantics and Content [RFC7231]. Servers SHOULD conform to HTTP/2 [RFC7540].

+ +

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.

+ +

Servers MUST conform to HTTP/1.1 Conditional Requests [RFC7232]. Servers SHOULD conform to HTTP/1.1 Caching [RFC7234]. Servers MAY conform to HTTP/1.1 Range Requests [RFC7233].

+ +

Servers MUST conform to HTTP/1.1 Authentication [RFC7235]. 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 reject PUT, POST and PATCH requests without the Content-Type header with a status code of 400. [Source]

+
+
+ +
+

HTTP Client

+
+

Clients MUST conform to HTTP/1.1 Message Syntax and Routing [RFC7230] and HTTP/1.1 Semantics and Content [RFC7231]. Clients MAY conform to HTTP/2 [RFC7540].

+ +

Clients MAY conform to HTTP/1.1 Conditional Requests [RFC7232]. Clients MAY conform to HTTP/1.1 Caching [RFC7234]. Clients MAY conform to HTTP/1.1 Range Requests [RFC7233].

+ +

Clients MUST conform to HTTP/1.1 Authentication [RFC7235] if it needs to access resources requiring authentication (see WebID). 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 in PUT, POST and PATCH requests [RFC7231]. [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 may 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 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 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 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 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 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. 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 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 would indicate the same date and time.

+ +
+
Note: Contained Resource Metadata Considerations
+
+

The generation of contained resource metadata may 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:

+ + + +

Servers MUST advertise auxiliary resources associated with a subject resource by responding to HEAD and GET requests by including the HTTP Link header 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 with the rel parameter [RFC8288].

+ + + + + + + + + + + + + + + + + + + + + +
Auxiliary TypeLink RelationDefinitions
Web Access Controlacl[WAC]
Description Resourcedescribedby[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 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 an effective request URI’s type by examining the URI path ending (URI Slash Semantics).

+ +

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

+ +

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

+ +
+

Note: 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 [RFC7231] 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 headers that correspond to acceptable HTTP methods listed in Allow header 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 [RFC7231]. [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 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. [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 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 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 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 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.

+
+ +
+

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 value of the Accept-Patch header [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:

+ +
    +
  1. Start from the RDF dataset in the target document, or an empty RDF dataset if the target resource does not exist yet.
    2. +
  2. If ?conditions is non-empty, find all (possibly empty) variable mappings such that all of the resulting triples occur in the dataset.
    3. +
  3. If no such mapping exists, or if multiple mappings exist, the server MUST respond with a 409 status code. [Source]
    4. +
  4. The resulting variable mapping is propagated to the ?deletions and ?insertions formulae to obtain two sets of resulting triples.
    5. +
  5. 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]
    6. +
  6. The triples resulting from ?deletions are to be removed from the RDF dataset.
    7. +
  7. 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.
    8. +
  8. 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.
    9. +
+
+ +
+

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 [RFC7231]. [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 HTTP response header Allow in response to requests to these resources [RFC7231]. [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 [RFC7231]. 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 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]

+
+
+ +
+

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 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 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 headers, 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 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 [RFC7231].

+ +
+

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-* headers as specified in the CORS protocol [FETCH]. In particular, the server 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 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-* headers themselves). A server 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, servers 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). Servers 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 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 ACL 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 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.

+ +

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 urged to seek the advice of security professionals when implementing mission critical systems using the technology outlined in this specification.

+ +

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

+ +

Servers are strongly discouraged from assuming that HTTP request headers’ field-values are valid or non-malicious. Servers are strongly encouraged to sanitize requests before processing them or incorporating them in messages sent to others. Servers are encouraged to reject bad requests that conflict with this specification's normative requirements. Servers are encouraged to 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 discouraged from assuming that the user agent is a regular Web browser, even when requests contain familiar values in headers such as User-Agent or Origin. Such an assumption could lead to incorrect conclusions about the security model of the application making the request, since the request might actually come from a non-browser actor unaffected by browser security constraints.

+ +

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

+ +

Servers are encouraged to use TLS connections to protect the contents of requests and responses from eavesdropping and modification by third parties. Unsecured TCP connections without TLS may be used in testing environments or when the 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.

+ +
+

Identifiable Information

+
+

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

+
+
+
+
+ +
+

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.0 [DPUB-ARIA-1.0]. To support structured graphics such as charts, graphs, technical drawings and scientific diagrams, to assistive technologies in order improve accessibility of graphics or diagrams through detailed annotations, it is encouraged to follow the WAI-ARIA Graphics Module [GRAPHICS-ARIA-1.0].

+ +

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

+ +

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

+
+
+ +
+

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 payloads can contain any data including that which identifies or refers to the user of the application. Meaningful consent to any personal data that applications include is extended by the client to the server.
+ +
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.
+
+
+
+
+
+ +
+

Change Log

+
+

This section is non-normative.

+ +

The summary of editorial and substantive changes in this section are based on W3C Process Document Classes of Changes [W3C-PROCESS].

+ +

protocol-20221231 ← protocol-20211217

+ +
+

Changes from protocol-20211217 to this version

+
+ +
+
+
+
+ +
+

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. Dörthe Arndt; William Van Woensel;Dominik Tomaszuk; Gregg Kellogg. W3C. 5 September 2021. 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
+
[RFC3864]
+
Registration Procedures for Message Header Fields. G. Klyne; M. Nottingham; J. Mogul. IETF. September 2004. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc3864
+
[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
+
[RFC7230]
+
Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7230.html
+
[RFC7231]
+
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7231.html
+
[RFC7232]
+
Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7232.html
+
[RFC7233]
+
Hypertext Transfer Protocol (HTTP/1.1): Range Requests. R. Fielding, Ed.; Y. Lafon, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7233.html
+
[RFC7234]
+
Hypertext Transfer Protocol (HTTP/1.1): Caching. R. Fielding, Ed.; M. Nottingham, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7234.html
+
[RFC7235]
+
Hypertext Transfer Protocol (HTTP/1.1): Authentication. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7235.html
+
[RFC7540]
+
Hypertext Transfer Protocol Version 2 (HTTP/2). M. Belshe; R. Peon; M. Thomson, Ed.. IETF. 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://datatracker.ietf.org/doc/html/rfc8174
+
[RFC8288]
+
Web Linking. M. Nottingham. IETF. October 2017. Proposed Standard. URL: https://httpwg.org/specs/rfc8288.html
+
[SOLID-NOTIFICATIONS-PROTOCOL]
+
Solid Notifications Protocol. Sarven Capadisli. W3C Solid Community Group. 31 December 2022. Version 0.2.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. 5 July 2022. Version 1.0.0-cr-1. 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. 11 December 2020. W3C Working Draft. URL: https://www.w3.org/TR/coga-usable/
+
[DPUB-ARIA-1.0]
+
Digital Publishing WAI-ARIA Module 1.0. Matt Garrish; Tzviya Siegman; Markus Gylling; Shane McCarron. W3C. 14 December 2017. W3C Recommendation. URL: https://www.w3.org/TR/dpub-aria-1.0/
+
[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. 12 May 2022. 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. 23 March 2021. W3C Note. URL: https://www.w3.org/TR/security-privacy-questionnaire/
+
[SOCIETAL-IMPACT-QUESTIONNAIRE]
+
Self-Review Questionnaire: Societal Impact. Amy Guy. W3C. 13 Dec 2021. 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. W3C. 2 March 2021. W3C Candidate Recommendation. URL: https://www.w3.org/TR/wai-aria-1.2/
+
[WCAG-3.0]
+
W3C Accessibility Guidelines (WCAG) 3.0. Jeanne F Spellman; Rachael Bradley Montgomery; Shawn Lauriat; Michael Cooper. W3C. 21 January 2021. 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. 12 May 2022. W3C Group Draft Note. URL: https://www.w3.org/TR/security-privacy-questionnaire/
+
[W3C-PROCESS]
+
W3C Process Document. Elika J. Etemad / fantasai; Florian Rivoal; W3C Process Community Group. 2 November 2021. URL: https://www.w3.org/Consortium/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/
+
+
+
+
+
+
+
+
+ + + + + + diff --git a/protocol.ttl b/protocol.ttl new file mode 100644 index 00000000..e8717e0e --- /dev/null +++ b/protocol.ttl @@ -0,0 +1,1090 @@ + . + . + . + . + . + . + "Solid Protocol"@en . + "0.9.0"@en . + . + . + . + . + . + . + . + "Sarven"@en . + "Capadisli"@en . + "Sarven Capadisli"@en . + . + . + . + . + . + "Tim"@en . + "Berners-Lee"@en . + "Tim Berners-Lee"@en . + . + . + . + . + "Ruben"@en . + "Verborgh"@en . + "Ruben Verborgh"@en . + . + . + . + . + "Kjetil"@en . + "Kjernsmo"@en . + "Kjetil Kjernsmo"@en . + . + . + . + . + "Justin"@en . + "Bingham"@en . + "Justin Bingham"@en . + . + . + . + "Dmitri"@en . + "Zagidulin"@en . + "Dmitri Zagidulin"@en . + . + . + . + "Aaron"@en . + "Coburn"@en . + "Aaron Coburn"@en . + . + "2020-12-16T00:00:00Z"^^ . + "2021-12-17T00:00:00Z"^^ . + . + . + "en" . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + "\n This document connects a set of specifications that, together, provide applications with secure and permissioned access to externally stored data in an interoperable way.\n "^^ . + . + "Status of This Document"@en . + "\n This section describes the status of this document at the time of its publication.\n\n This document was published by the Solid Community Group as Version 0.9.0. 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.\n\n Publication as Version 0.9.0 does not imply endorsement by the W3C Membership. 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.\n\n This document was produced by a group operating under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.\n "^^ . + . + . + "Introduction"@en . + . + . + . + . + "Terminology"@en . + "Terminology"@en . + "The Solid Protocol specification defines the following terms. These terms are referenced throughout this specification."@en . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + "data pod"@en . + "A data pod is a place for storing documents, with mechanisms for controlling who can access what."@en . + . + "Solid app"@en . + "A Solid app is an application that reads or writes data from one or more storages."@en . + . + "URI"@en . + "A Uniform Resource Identifier (URI) provides the means for identifying resources [RFC3986]."@en . + . + "resource"@en . + "A resource is the target of an HTTP request identified by a URI [RFC7231]."@en . + . + "container resource"@en . + "A container resource is a hierarchical collection of resources that contains other resources, including containers."@en . + . + "root container"@en . + "A root container is a container resource that is at the highest level of the collection hierarchy."@en . + . + "resource metadata"@en . + "Resource metadata encompasses data about resources described by means of RDF statements [RDF11-CONCEPTS]."@en . + . + "agent"@en . + "An agent is a person, social entity, or software identified by a URI; e.g., a WebID denotes an agent [WEBID]."@en . + . + "owner"@en . + "An owner is a person or a social entity that is considered to have the rights and responsibilities of a data storage. An owner is identified by a URI, and implicitly has control over all data in a storage. An owner is first set at storage provisioning time and can be changed."@en . + . + "origin"@en . + "An origin indicates where an HTTP request originates from [RFC6454]."@en . + . + "read operation"@en . + . + "A read operation entails that information about a resource\u2019s existence or its description can be known. [Source]"@en . + . + "write operation"@en . + . + "A write operation entails that information about resources can be created or removed. [Source]"@en . + . + "append operation"@en . + . + "An append operation entails that information can be added but not removed. [Source]"@en . + "\n This section is non-normative.\n\n The Solid Protocol specification defines the following terms. These terms are referenced throughout this specification.\n\n \n\n \n data pod\n A data pod is a place for storing documents, with mechanisms for controlling who can access what.\n\n Solid app\n A Solid app is an application that reads or writes data from one or more storages.\n\n URI\n A Uniform Resource Identifier (URI) provides the means for identifying resources [RFC3986].\n\n resource\n A resource is the target of an HTTP request identified by a URI [RFC7231].\n\n container resource\n A container resource is a hierarchical collection of resources that contains other resources, including containers.\n\n root container\n A root container is a container resource that is at the highest level of the collection hierarchy.\n\n resource metadata\n Resource metadata encompasses data about resources described by means of RDF statements [RDF11-CONCEPTS].\n\n agent\n An agent is a person, social entity, or software identified by a URI; e.g., a WebID denotes an agent [WEBID].\n\n owner\n An owner is a person or a social entity that is considered to have the rights and responsibilities of a data storage. An owner is identified by a URI, and implicitly has control over all data in a storage. An owner is first set at storage provisioning time and can be changed.\n\n origin\n An origin indicates where an HTTP request originates from [RFC6454].\n\n read operation\n A read operation entails that information about a resource\u2019s existence or its description can be known. [Source]\n\n write operation\n A write operation entails that information about resources can be created or removed. [Source]\n\n append operation\n An append operation entails that information can be added but not removed. [Source]\n \n "^^ . + . + "Namespaces"@en . + "\n \n Prefixes and Namespaces\n \n \n Prefix\n Namespace\n Description\n \n \n \n \n rdf\n http://www.w3.org/1999/02/22-rdf-syntax-ns#\n [rdf-schema]\n \n \n ldp\n http://www.w3.org/ns/ldp#\n [LDP]\n \n \n solid\n http://www.w3.org/ns/solid/terms#\n Solid Terms\n \n \n pim\n http://www.w3.org/ns/pim/space#\n Workspace Ontology\n \n \n acl\n http://www.w3.org/ns/auth/acl#\n ACL Ontology\n \n \n dcterms\n http://purl.org/dc/terms/\n [DC-TERMS]\n \n \n stat\n http://www.w3.org/ns/posix/stat\n POSIX File Status\n \n \n \n "^^ . + . + "Conformance"@en . + "\n All assertions, diagrams, examples, and notes are non-normative, as are all sections explicitly marked non-normative. Everything else is normative.\n\n The key words \u201CMUST\u201D, \u201CMUST NOT\u201D, \u201CREQUIRED\u201D, \u201CSHALL\u201D, \u201CSHALL NOT\u201D, \u201CSHOULD\u201D, \u201CSHOULD NOT\u201D, \u201CRECOMMENDED\u201D, \u201CMAY\u201D, and \u201COPTIONAL\u201D are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.\n "^^ . + "\n 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.\n\n 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.\n\n 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.\n\n 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 \u2013 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.\n\n 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.\n\n 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.\n\n This specification is for:\n\n \n Resource server developers that want to enable clients to send and retrieve information;\n Application developers that want to implement a client to perform operations on resources.\n \n\n \n Terminology\n \n This section is non-normative.\n\n The Solid Protocol specification defines the following terms. These terms are referenced throughout this specification.\n\n \n\n \n data pod\n A data pod is a place for storing documents, with mechanisms for controlling who can access what.\n\n Solid app\n A Solid app is an application that reads or writes data from one or more storages.\n\n URI\n A Uniform Resource Identifier (URI) provides the means for identifying resources [RFC3986].\n\n resource\n A resource is the target of an HTTP request identified by a URI [RFC7231].\n\n container resource\n A container resource is a hierarchical collection of resources that contains other resources, including containers.\n\n root container\n A root container is a container resource that is at the highest level of the collection hierarchy.\n\n resource metadata\n Resource metadata encompasses data about resources described by means of RDF statements [RDF11-CONCEPTS].\n\n agent\n An agent is a person, social entity, or software identified by a URI; e.g., a WebID denotes an agent [WEBID].\n\n owner\n An owner is a person or a social entity that is considered to have the rights and responsibilities of a data storage. An owner is identified by a URI, and implicitly has control over all data in a storage. An owner is first set at storage provisioning time and can be changed.\n\n origin\n An origin indicates where an HTTP request originates from [RFC6454].\n\n read operation\n A read operation entails that information about a resource\u2019s existence or its description can be known. [Source]\n\n write operation\n A write operation entails that information about resources can be created or removed. [Source]\n\n append operation\n An append operation entails that information can be added but not removed. [Source]\n \n \n \n\n \n Namespaces\n \n \n Prefixes and Namespaces\n \n \n Prefix\n Namespace\n Description\n \n \n \n \n rdf\n http://www.w3.org/1999/02/22-rdf-syntax-ns#\n [rdf-schema]\n \n \n ldp\n http://www.w3.org/ns/ldp#\n [LDP]\n \n \n solid\n http://www.w3.org/ns/solid/terms#\n Solid Terms\n \n \n pim\n http://www.w3.org/ns/pim/space#\n Workspace Ontology\n \n \n acl\n http://www.w3.org/ns/auth/acl#\n ACL Ontology\n \n \n dcterms\n http://purl.org/dc/terms/\n [DC-TERMS]\n \n \n stat\n http://www.w3.org/ns/posix/stat\n POSIX File Status\n \n \n \n \n \n\n \n Conformance\n \n All assertions, diagrams, examples, and notes are non-normative, as are all sections explicitly marked non-normative. Everything else is normative.\n\n The key words \u201CMUST\u201D, \u201CMUST NOT\u201D, \u201CREQUIRED\u201D, \u201CSHALL\u201D, \u201CSHALL NOT\u201D, \u201CSHOULD\u201D, \u201CSHOULD NOT\u201D, \u201CRECOMMENDED\u201D, \u201CMAY\u201D, and \u201COPTIONAL\u201D are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.\n \n \n "^^ . +_:bnode9 . +_:bnode9 _:bnode11 . +_:bnode11 . +_:bnode11 _:bnode12 . +_:bnode12 . +_:bnode12 . + _:bnode9 . + . + "Hypertext Transfer Protocol"@en . + . + "HTTP Server"@en . + . + . + . + "Servers MUST conform to HTTP/1.1 Message Syntax and Routing [RFC7230] and HTTP/1.1 Semantics and Content [RFC7231]."@en . + . + . + . + "Servers SHOULD conform to HTTP/2 [RFC7540]."@en . + . + . + . + "Servers SHOULD use TLS connections through the https URI scheme in order to secure the communication with clients."@en . + . + . + . + "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."@en . + . + . + . + "Servers MUST conform to HTTP/1.1 Conditional Requests [RFC7232]."@en . + . + . + . + "Servers SHOULD conform to HTTP/1.1 Caching [RFC7234]."@en . + . + . + . + "Servers MAY conform to HTTP/1.1 Range Requests [RFC7233]."@en . + . + . + . + "Servers MUST conform to HTTP/1.1 Authentication [RFC7235]."@en . + . + . + . + "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)."@en . + . + . + . + "Server MUST reject PUT, POST and PATCH requests without the Content-Type header with a status code of 400."@en . + . + "\n Servers MUST conform to HTTP/1.1 Message Syntax and Routing [RFC7230] and HTTP/1.1 Semantics and Content [RFC7231]. Servers SHOULD conform to HTTP/2 [RFC7540].\n\n 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.\n\n Servers MUST conform to HTTP/1.1 Conditional Requests [RFC7232]. Servers SHOULD conform to HTTP/1.1 Caching [RFC7234]. Servers MAY conform to HTTP/1.1 Range Requests [RFC7233].\n\n Servers MUST conform to HTTP/1.1 Authentication [RFC7235]. 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).\n\n Server MUST reject PUT, POST and PATCH requests without the Content-Type header with a status code of 400. [Source]\n "^^ . + . + "HTTP Client"@en . + . + . + . + "Clients MUST conform to HTTP/1.1 Message Syntax and Routing [RFC7230] and HTTP/1.1 Semantics and Content [RFC7231]."@en . + . + . + . + "Clients MAY conform to HTTP/2 [RFC7540]."@en . + . + . + . + "Clients MAY conform to HTTP/1.1 Conditional Requests [RFC7232]."@en . + . + . + . + "Clients MAY conform to HTTP/1.1 Caching [RFC7234]."@en . + . + . + . + "Clients MAY conform to HTTP/1.1 Range Requests [RFC7233]."@en . + . + . + . + "Clients MUST conform to HTTP/1.1 Authentication [RFC7235] if it needs to access resources requiring authentication (see WebID)."@en . + . + . + . + "When a client receives a response with a 403 or 404 status code, the client MAY repeat the request with different credentials."@en . + . + . + . + "Clients MUST use the Content-Type HTTP header in PUT, POST and PATCH requests [RFC7231]."@en . + . + "\n Clients MUST conform to HTTP/1.1 Message Syntax and Routing [RFC7230] and HTTP/1.1 Semantics and Content [RFC7231]. Clients MAY conform to HTTP/2 [RFC7540].\n\n Clients MAY conform to HTTP/1.1 Conditional Requests [RFC7232]. Clients MAY conform to HTTP/1.1 Caching [RFC7234]. Clients MAY conform to HTTP/1.1 Range Requests [RFC7233].\n\n Clients MUST conform to HTTP/1.1 Authentication [RFC7235] if it needs to access resources requiring authentication (see WebID). When a client receives a response with a 403 or 404 status code, the client MAY repeat the request with different credentials.\n\n Clients MUST use the Content-Type HTTP header in PUT, POST and PATCH requests [RFC7231]. [Source]\n "^^ . + "\n 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.\n\n \n HTTP Server\n \n Servers MUST conform to HTTP/1.1 Message Syntax and Routing [RFC7230] and HTTP/1.1 Semantics and Content [RFC7231]. Servers SHOULD conform to HTTP/2 [RFC7540].\n\n 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.\n\n Servers MUST conform to HTTP/1.1 Conditional Requests [RFC7232]. Servers SHOULD conform to HTTP/1.1 Caching [RFC7234]. Servers MAY conform to HTTP/1.1 Range Requests [RFC7233].\n\n Servers MUST conform to HTTP/1.1 Authentication [RFC7235]. 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).\n\n Server MUST reject PUT, POST and PATCH requests without the Content-Type header with a status code of 400. [Source]\n \n \n\n \n HTTP Client\n \n Clients MUST conform to HTTP/1.1 Message Syntax and Routing [RFC7230] and HTTP/1.1 Semantics and Content [RFC7231]. Clients MAY conform to HTTP/2 [RFC7540].\n\n Clients MAY conform to HTTP/1.1 Conditional Requests [RFC7232]. Clients MAY conform to HTTP/1.1 Caching [RFC7234]. Clients MAY conform to HTTP/1.1 Range Requests [RFC7233].\n\n Clients MUST conform to HTTP/1.1 Authentication [RFC7235] if it needs to access resources requiring authentication (see WebID). When a client receives a response with a 403 or 404 status code, the client MAY repeat the request with different credentials.\n\n Clients MUST use the Content-Type HTTP header in PUT, POST and PATCH requests [RFC7231]. [Source]\n \n \n "^^ . +_:bnode11 . +_:bnode11 _:bnode12 . +_:bnode12 . +_:bnode12 . + _:bnode11 . + . + "Uniform Resource Identifier"@en . + . + "Note: Storage Owner and URI Ownership"@en . + "\n This specification does not describe the relationship between a Solid storage owner and Web architecture\u2019s URI ownership [WEBARCH].\n "^^ . + . + "URI Slash Semantics"@en . + . + . + . + . + "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."@en . + . + . + . + "Instead, the server MAY respond to requests for the latter URI with a 301 redirect to the former."@en . + . + . + . + . + "Servers MUST authorize prior to this optional redirect."@en . + . + "\n 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]\n\n 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].\n "^^ . + . + "URI Persistence"@en . + . + . + "Note: URI Reuse"@en . + "\n Servers that wish to disable URI re-use may want to use the 410 status code.\n "^^ . + "\n This section is non-normative.\n\n 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\u2019s URI persistence [WEBARCH]. [Source]\n\n \n Note: URI Reuse\n \n Servers that wish to disable URI re-use may want to use the 410 status code.\n \n \n "^^ . +_:bnode13 . +_:bnode13 . + _:bnode13 . + "\n \n Note: Storage Owner and URI Ownership\n \n This specification does not describe the relationship between a Solid storage owner and Web architecture\u2019s URI ownership [WEBARCH].\n \n \n\n \n URI Slash Semantics\n \n 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]\n\n 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].\n \n \n\n \n URI Persistence\n \n This section is non-normative.\n\n 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\u2019s URI persistence [WEBARCH]. [Source]\n\n \n Note: URI Reuse\n \n Servers that wish to disable URI re-use may want to use the 410 status code.\n \n \n \n \n "^^ . +_:bnode12 . +_:bnode12 _:bnode14 . +_:bnode14 . +_:bnode14 _:bnode15 . +_:bnode15 . +_:bnode15 . + _:bnode12 . + . + "Resources"@en . + . + "Storage"@en . + . + . + . + "Servers MUST provide one or more storages (pim:Storage) \u2013 a space of URIs in which data can be accessed. A storage is the root container for all of its contained resources (see Resource Containment)."@en . + . + . + . + "When a server supports multiple storages, the URIs MUST be allocated to non-overlapping space."@en . + . + . + . + "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\u2019s request URI."@en . + . + . + . + . + . + . + . + . + "Servers MUST keep track of at least one owner of a storage in an implementation defined way."@en . + . + . + . + "When a server wants to advertise the owner of a storage, the server MUST include the Link header with rel=\"http://www.w3.org/ns/solid/terms#owner\" targeting the URI of the owner in the response of HTTP HEAD or GET requests targeting the root container."@en . + . + "Note: Trust Between Owners"@en . + "\n When a server supports multiple storages, there must be complete trust between its owners.\n "^^ . + . + . + . + . + "\n Servers MUST provide one or more storages (pim:Storage) \u2013 a space of URIs in which data can be accessed. A storage is the root container for all of its contained resources (see Resource Containment).\n\n When a server supports multiple storages, the URIs MUST be allocated to non-overlapping space.\n\n 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\u2019s request URI.\n\n 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.\n\n 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.\n\n 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).\n\n [Source] [Source]\n\n Servers MUST keep track of at least one owner of a storage in an implementation defined way.\n\n When a server wants to advertise the owner of a storage, the server MUST include the Link header with rel=\"http://www.w3.org/ns/solid/terms#owner\" targeting the URI of the owner in the response of HTTP HEAD or GET requests targeting the root container.\n\n \n Note: Trust Between Owners\n \n When a server supports multiple storages, there must be complete trust between its owners.\n \n \n\n [Source][Source][Source][Source]\n "^^ . +_:bnode15 . +_:bnode15 . + _:bnode15 . + . + "Resource Containment"@en . + . + . + . + . + . + "The representation and behaviour of containers in Solid corresponds to LDP Basic Container and MUST be supported by server."@en . + . + . + "Note: Container Last-Modified Comparison"@en . + "\n 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. In future versions of this specification, this design may be revisited.\n "^^ . + . + "Contained Resource Metadata"@en . + . + . + . + . + "Servers SHOULD include resource metadata about contained resources as part of the container description, unless that information is inapplicable to the server."@en . + . + "Contained resource metadata statements"@en . + "rdf:type"@en . + . + "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]."@en . + . + "stat:size"@en . + . + "A non-negative integer giving the size of the resource in bytes."@en . + . + "dcterms:modified"@en . + . + "The date and time when the resource was last modified."@en . + . + "stat:mtime"@en . + . + "The Unix time when the resource was last modified."@en . + . + . + "Note: Contained Resource Metadata Considerations"@en . + "\n The generation of contained resource metadata may be inapplicable to some servers, for example, when that information does not exist or is expensive to determine.\n "^^ . + . + . + . + . + "\n 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.\n\n Servers SHOULD include resource metadata about contained resources as part of the container description, unless that information is inapplicable to the server.\n\n Contained resource metadata statements include the properties:\n\n \n rdf:type\n 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].\n stat:size\n A non-negative integer giving the size of the resource in bytes.\n dcterms:modified\n The date and time when the resource was last modified.\n stat:mtime\n The Unix time when the resource was last modified.\n \n\n The dcterms:modified value of a contained resource corresponds with the Last-Modified header 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\u2019s generation, then a response with the 200 status code including the Last-Modified header would indicate the same date and time.\n\n \n Note: Contained Resource Metadata Considerations\n \n The generation of contained resource metadata may be inapplicable to some servers, for example, when that information does not exist or is expensive to determine.\n \n \n\n Contained resource metadata is protected by the server.\n\n [Source]\n [Source] [Source]\n "^^ . +_:bnode18 . +_:bnode18 . + _:bnode18 . + "\n Solid has the notion of containers to represent a collection of linked resources to help with resource discovery and lifecycle management.\n\n 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]\n\n The representation and behaviour of containers in Solid corresponds to LDP Basic Container and MUST be supported by server. [Source]\n\n Servers can determine the value of the HTTP Last-Modified header field in response to HEAD and GET requests targeting a container based on changes to containment triples.\n\n \n Note: Container Last-Modified Comparison\n \n 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. In future versions of this specification, this design may be revisited.\n \n \n\n \n Contained Resource Metadata\n \n 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.\n\n Servers SHOULD include resource metadata about contained resources as part of the container description, unless that information is inapplicable to the server.\n\n Contained resource metadata statements include the properties:\n\n \n rdf:type\n 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].\n stat:size\n A non-negative integer giving the size of the resource in bytes.\n dcterms:modified\n The date and time when the resource was last modified.\n stat:mtime\n The Unix time when the resource was last modified.\n \n\n The dcterms:modified value of a contained resource corresponds with the Last-Modified header 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\u2019s generation, then a response with the 200 status code including the Last-Modified header would indicate the same date and time.\n\n \n Note: Contained Resource Metadata Considerations\n \n The generation of contained resource metadata may be inapplicable to some servers, for example, when that information does not exist or is expensive to determine.\n \n \n\n Contained resource metadata is protected by the server.\n\n [Source]\n [Source] [Source]\n \n \n "^^ . +_:bnode16 . +_:bnode16 _:bnode19 . +_:bnode19 . +_:bnode19 . + _:bnode16 . + . + "Auxiliary Resources"@en . + . + "Note: Self-describing Resources"@en . + "\n Where applicable, to promote self-describing resources, implementations and authors are encouraged to use the subject resource instead of the associated auxiliary resource.\n "^^ . + . + . + "Web Access Control"@en . + "\n An auxiliary resource of type Web Access Control provides access control description of a subject resource (Web Access Control).\n "^^ . + . + "Description Resource"@en . + . + . + . + "Servers MUST NOT directly associate more than one description resource to a subject resource."@en . + . + . + . + "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."@en . + . + "\n An auxiliary resource of type Description Resource provides a description of a subject resource ([LDP]).\n\n Servers MUST NOT directly associate more than one description resource to a subject resource.\n\n 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.\n\n Clients can discover resources that are described by description resources by making an HTTP HEAD or GET request on the target URL, and checking the HTTP Link header with a rel value of describes (inverse of the describedby relation) [RFC6892].\n "^^ . + "\n 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.\n\n Server manages the association between a subject resource and auxiliary resources defined by this specification. The lifecycle of auxiliary resources defined by this specification depend on the lifecycle of the subject resource that they are associated with.\n\n 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.\n\n \n Note: Self-describing Resources\n \n Where applicable, to promote self-describing resources, implementations and authors are encouraged to use the subject resource instead of the associated auxiliary resource.\n \n \n\n This specification defines the following types of auxiliary resources:\n\n \n Web Access Control\n Resource Description\n \n\n Clients can discover auxiliary resources associated with a subject resource by making an HTTP HEAD or GET request on the target URL, and checking the HTTP Link header with the rel parameter [RFC8288].\n\n \n \n \n Auxiliary Type\n Link Relation\n Definitions\n \n \n \n \n Web Access Control\n acl\n [WAC]\n \n \n Description Resource\n describedby\n [LDP]\n \n \n \n \n \n \n The possibility of using URIs as relation types interchangeably or as alternate to the tokens above are under consideration:\n\n \n http://www.w3.org/ns/auth/acl#accessControl\n https://www.w3.org/ns/iana/link-relations/relation#acl\n https://www.w3.org/ns/iana/link-relations/relation#describedby\n https://www.w3.org/ns/iana/link-relations/relation#describes\n \n\n Issue\n \n \n \n \n \n\n \n Web Access Control\n \n An auxiliary resource of type Web Access Control provides access control description of a subject resource (Web Access Control).\n \n \n\n \n Description Resource\n \n An auxiliary resource of type Description Resource provides a description of a subject resource ([LDP]).\n\n Servers MUST NOT directly associate more than one description resource to a subject resource.\n\n 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.\n\n Clients can discover resources that are described by description resources by making an HTTP HEAD or GET request on the target URL, and checking the HTTP Link header with a rel value of describes (inverse of the describedby relation) [RFC6892].\n \n \n "^^ . +_:bnode19 . +_:bnode19 _:bnode20 . +_:bnode20 . +_:bnode20 _:bnode21 . +_:bnode21 . +_:bnode21 . + _:bnode19 . + "\n \n Storage\n \n Servers MUST provide one or more storages (pim:Storage) \u2013 a space of URIs in which data can be accessed. A storage is the root container for all of its contained resources (see Resource Containment).\n\n When a server supports multiple storages, the URIs MUST be allocated to non-overlapping space.\n\n 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\u2019s request URI.\n\n 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.\n\n 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.\n\n 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).\n\n [Source] [Source]\n\n Servers MUST keep track of at least one owner of a storage in an implementation defined way.\n\n When a server wants to advertise the owner of a storage, the server MUST include the Link header with rel=\"http://www.w3.org/ns/solid/terms#owner\" targeting the URI of the owner in the response of HTTP HEAD or GET requests targeting the root container.\n\n \n Note: Trust Between Owners\n \n When a server supports multiple storages, there must be complete trust between its owners.\n \n \n\n [Source][Source][Source][Source]\n \n \n\n \n Resource Containment\n \n Solid has the notion of containers to represent a collection of linked resources to help with resource discovery and lifecycle management.\n\n 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]\n\n The representation and behaviour of containers in Solid corresponds to LDP Basic Container and MUST be supported by server. [Source]\n\n Servers can determine the value of the HTTP Last-Modified header field in response to HEAD and GET requests targeting a container based on changes to containment triples.\n\n \n Note: Container Last-Modified Comparison\n \n 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. In future versions of this specification, this design may be revisited.\n \n \n\n \n Contained Resource Metadata\n \n 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.\n\n Servers SHOULD include resource metadata about contained resources as part of the container description, unless that information is inapplicable to the server.\n\n Contained resource metadata statements include the properties:\n\n \n rdf:type\n 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].\n stat:size\n A non-negative integer giving the size of the resource in bytes.\n dcterms:modified\n The date and time when the resource was last modified.\n stat:mtime\n The Unix time when the resource was last modified.\n \n\n The dcterms:modified value of a contained resource corresponds with the Last-Modified header 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\u2019s generation, then a response with the 200 status code including the Last-Modified header would indicate the same date and time.\n\n \n Note: Contained Resource Metadata Considerations\n \n The generation of contained resource metadata may be inapplicable to some servers, for example, when that information does not exist or is expensive to determine.\n \n \n\n Contained resource metadata is protected by the server.\n\n [Source]\n [Source] [Source]\n \n \n \n \n\n \n Auxiliary Resources\n \n 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.\n\n Server manages the association between a subject resource and auxiliary resources defined by this specification. The lifecycle of auxiliary resources defined by this specification depend on the lifecycle of the subject resource that they are associated with.\n\n 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.\n\n \n Note: Self-describing Resources\n \n Where applicable, to promote self-describing resources, implementations and authors are encouraged to use the subject resource instead of the associated auxiliary resource.\n \n \n\n This specification defines the following types of auxiliary resources:\n\n \n Web Access Control\n Resource Description\n \n\n Clients can discover auxiliary resources associated with a subject resource by making an HTTP HEAD or GET request on the target URL, and checking the HTTP Link header with the rel parameter [RFC8288].\n\n \n \n \n Auxiliary Type\n Link Relation\n Definitions\n \n \n \n \n Web Access Control\n acl\n [WAC]\n \n \n Description Resource\n describedby\n [LDP]\n \n \n \n \n \n \n The possibility of using URIs as relation types interchangeably or as alternate to the tokens above are under consideration:\n\n \n http://www.w3.org/ns/auth/acl#accessControl\n https://www.w3.org/ns/iana/link-relations/relation#acl\n https://www.w3.org/ns/iana/link-relations/relation#describedby\n https://www.w3.org/ns/iana/link-relations/relation#describes\n \n\n Issue\n \n \n \n \n \n\n \n Web Access Control\n \n An auxiliary resource of type Web Access Control provides access control description of a subject resource (Web Access Control).\n \n \n\n \n Description Resource\n \n An auxiliary resource of type Description Resource provides a description of a subject resource ([LDP]).\n\n Servers MUST NOT directly associate more than one description resource to a subject resource.\n\n 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.\n\n Clients can discover resources that are described by description resources by making an HTTP HEAD or GET request on the target URL, and checking the HTTP Link header with a rel value of describes (inverse of the describedby relation) [RFC6892].\n \n \n \n \n "^^ . +_:bnode14 . +_:bnode14 _:bnode20 . +_:bnode20 . +_:bnode20 _:bnode21 . +_:bnode21 . +_:bnode21 . + _:bnode14 . + . + "Reading and Writing Resources"@en . + . + . + . + "Servers MUST respond with the 405 status code to requests using HTTP methods that are not supported by the target resource."@en . + . + . + "Resource Type Heuristics"@en . + . + . + . + "When a successful PUT or PATCH request creates a resource, the server MUST use the effective request URI to assign the URI to that resource."@en . + . + . + . + "When a successful POST request creates a resource, the server MUST assign a URI to that resource."@en . + . + . + . + "Servers MAY allow clients to suggest the URI of a resource created through POST, using the HTTP Slug header as defined in [RFC5023]."@en . + . + "Note: URI Allocation"@en . + "\n 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.\n "^^ . + . + . + "\n When creating new resources, servers can determine an effective request URI\u2019s type by examining the URI path ending (URI Slash Semantics).\n\n When a successful PUT or PATCH request creates a resource, the server MUST use the effective request URI to assign the URI to that resource.\n\n When a successful POST request creates a resource, the server MUST assign a URI to that resource. Servers MAY allow clients to suggest the URI of a resource created through POST, using the HTTP Slug header as defined in [RFC5023].\n\n \n Note: URI Allocation\n \n 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.\n \n \n\n [Source][Source].\n "^^ . +_:bnode21 . +_:bnode21 . + _:bnode21 . + . + "Reading Resources"@en . + . + . + . + "Servers MUST support the HTTP GET, HEAD and OPTIONS methods [RFC7231] for clients to read resources or to determine communication options."@en . + . + . + . + . + "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."@en . + . + . + . + "Servers MUST indicate supported media types in the HTTP Accept-Patch [RFC5789], Accept-Post [LDP] and Accept-Put [The Accept-Put Response Header] response headers that correspond to acceptable HTTP methods listed in Allow header value in response to HTTP GET and HEAD requests."@en . + . + . + . + "Servers MAY include the HTTP Accept-Patch, Accept-Post and Accept-Put headers in the response of a OPTIONS * request."@en . + . + . + "\n Servers MUST support the HTTP GET, HEAD and OPTIONS methods [RFC7231] for clients to read resources or to determine communication options. [Source]\n\n When responding to authorized requests:\n\n 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.\n\n Servers MUST indicate supported media types in the HTTP Accept-Patch [RFC5789], Accept-Post [LDP] and Accept-Put [The Accept-Put Response Header] response headers that correspond to acceptable HTTP methods listed in Allow header value in response to HTTP GET and HEAD requests.\n\n Servers MAY include the HTTP Accept-Patch, Accept-Post and Accept-Put headers in the response of a OPTIONS * request.\n\n [Source] [Source]\n "^^ . + . + "Writing Resources"@en . + . + . + . + . + . + "Servers MUST create intermediate containers and include corresponding containment triples in container representations derived from the URI path component of PUT and PATCH requests."@en . + . + . + . + . + "Servers MUST allow creating new resources with a POST request to URI path ending /."@en . + . + . + . + "Servers MUST create a resource with URI path ending /{id} in container /."@en . + . + . + . + "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."@en . + . + . + . + . + . + "When a POST method request targets a resource without an existing representation, the server MUST respond with the 404 status code."@en . + . + . + . + . + "When a PUT or PATCH method request targets an auxiliary resource, the server MUST create or update it."@en . + . + . + . + "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."@en . + . + . + . + . + . + "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."@en . + . + . + . + . + "Servers MUST NOT allow HTTP POST, PUT and PATCH to update a container\u2019s resource metadata statements; if the server receives such a request, it MUST respond with a 409 status code."@en . + . + . + "Note: Conditional Update"@en . + . + . + . + "\n Clients are encouraged to use the HTTP If-None-Match header with a value of \"*\" to prevent an unsafe request method (e.g., PUT, PATCH) from inadvertently modifying an existing representation of the target resource when the client believes that the resource does not have a current representation. [Source] [Source] [Source]\n "^^ . + . + . + . + "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."@en . + "\n Servers MUST support the HTTP PUT, POST and PATCH methods [RFC7231]. [Source] [Source]\n\n 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]\n\n 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. [Source] [Source]\n\n When a POST method request targets a resource without an existing representation, the server MUST respond with the 404 status code. [Source]\n\n 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]\n\n 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]\n\n Servers MUST NOT allow HTTP POST, PUT and PATCH to update a container\u2019s resource metadata statements; if the server receives such a request, it MUST respond with a 409 status code. [Source]\n\n \n Note: Conditional Update\n \n Clients are encouraged to use the HTTP If-None-Match header with a value of \"*\" to prevent an unsafe request method (e.g., PUT, PATCH) from inadvertently modifying an existing representation of the target resource when the client believes that the resource does not have a current representation. [Source] [Source] [Source]\n \n \n\n 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.\n "^^ . +_:bnode22 . +_:bnode22 . + _:bnode22 . + . + "Modifying Resources Using N3 Patches"@en . + . + . + . + "Servers MUST accept a PATCH request with an N3 Patch body when the target of the request is an RDF document [RDF11-CONCEPTS]."@en . + . + . + . + "Servers MUST indicate support of N3 Patch by listing text/n3 as a value of the Accept-Patch header [RFC5789] of relevant responses."@en . + . + . + . + "A patch document MUST contain one or more patch resources."@en . + . + . + "A patch resource MUST be identified by a URI or blank node, which we refer to as ?patch in the remainder of this section."@en . + . + . + "?patch rdf:type solid:Patch"@en . + . + . + "A patch resource MUST contain at most one triple of the form ?patch solid:deletes ?deletions."@en . + . + . + . + . + "A patch resource MUST contain at most one triple of the form ?patch solid:where ?conditions."@en . + . + . + "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 {}."@en . + . + "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:"@en . + . + . + "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."@en . + . + . + "?patch rdf:type solid:InsertDeletePatch"@en . + . + . + "The ?insertions and ?deletions formulae MUST NOT contain variables that do not occur in the ?conditions formula."@en . + . + . + "The ?insertions and ?deletions formulae MUST NOT contain blank nodes."@en . + . + . + . + "Servers MUST respond with a 422 status code [RFC4918] if a patch document does not satisfy all of the above constraints."@en . + . + . + . + "When ?conditions is non-empty, servers MUST treat the request as a Read operation."@en . + . + . + . + "When ?insertions is non-empty, servers MUST (also) treat the request as an Append operation."@en . + . + . + . + "When ?deletions is non-empty, servers MUST treat the request as a Read and Write operation."@en . + . + . + . + "Servers MUST process a patch resource against the target document as follows:"@en . + . + . + . + "server MUST respond with a 409 status code."@en . + . + . + . + . + "server MUST respond with a 409 status code."@en . + . + "\n 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 value of the Accept-Patch header [RFC5789] of relevant responses. [Source]\n\n An N3 Patch is a document in the Notation3 (N3) format [N3], identified by the media type text/n3, conforming to the following constraints:\n\n \n A patch document MUST contain one or more patch resources.\n A patch resource MUST be identified by a URI or blank node, which we refer to as ?patch in the remainder of this section.\n A patch resource MAY contain a triple [RDF11-CONCEPTS] ?patch rdf:type solid:Patch.\n A patch resource MUST contain at most one triple of the form ?patch solid:deletes ?deletions.\n A patch resource MUST contain at most one triple of the form ?patch solid:inserts ?insertions.\n A patch resource MUST contain at most one triple of the form ?patch solid:where ?conditions.\n 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 {}.\n \n\n 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:\n\n \n 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.\n A patch resource MUST contain a triple ?patch rdf:type solid:InsertDeletePatch.\n The ?insertions and ?deletions formulae MUST NOT contain variables that do not occur in the ?conditions formula.\n The ?insertions and ?deletions formulae MUST NOT contain blank nodes.\n \n\n Servers MUST respond with a 422 status code [RFC4918] if a patch document does not satisfy all of the above constraints.\n\n 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.\n\n Servers MUST process a patch resource against the target document as follows:\n\n \n Start from the RDF dataset in the target document, or an empty RDF dataset if the target resource does not exist yet.\n If ?conditions is non-empty, find all (possibly empty) variable mappings such that all of the resulting triples occur in the dataset.\n If no such mapping exists, or if multiple mappings exist, the server MUST respond with a 409 status code. [Source]\n The resulting variable mapping is propagated to the ?deletions and ?insertions formulae to obtain two sets of resulting triples.\n 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]\n The triples resulting from ?deletions are to be removed from the RDF dataset.\n 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.\n 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.\n \n "^^ . + . + . + "@prefix solid: .\n@prefix ex: .\n\n_:rename a solid:InsertDeletePatch;\n solid:where { ?person ex:familyName \"Garcia\". };\n solid:inserts { ?person ex:givenName \"Alex\". };\n solid:deletes { ?person ex:givenName \"Claudia\". }."@en . + "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."@en . +_:bnode23 . +_:bnode23 . + _:bnode23 . + . + "Deleting Resources"@en . + . + . + . + . + . + "When a DELETE request targets storage\u2019s root container or its associated ACL resource, the server MUST respond with the 405 status code."@en . + . + . + . + "Server MUST exclude the DELETE method in the HTTP response header Allow in response to requests to these resources [RFC7231]."@en . + . + . + . + . + "When a contained resource is deleted, the server MUST also remove the corresponding containment triple."@en . + . + . + . + . + "When a contained resource is deleted, the server MUST also delete the associated auxiliary resources (see the Auxiliary Resources section)."@en . + . + . + . + "When a DELETE request targets a container, the server MUST delete the container if it contains no resources."@en . + . + . + . + "If the container contains resources, the server MUST respond with the 409 status code and response body describing the error."@en . + . + . + . + "\n Servers MUST support the HTTP DELETE method [RFC7231]. [Source] [Source]\n\n When a DELETE request targets storage\u2019s root container or its associated ACL resource, the server MUST respond with the 405 status code. Server MUST exclude the DELETE method in the HTTP response header Allow in response to requests to these resources [RFC7231]. [Source]\n\n When a contained resource is deleted, the server MUST also remove the corresponding containment triple. [Source]\n\n When a contained resource is deleted, the server MUST also delete the associated auxiliary resources (see the Auxiliary Resources section).\n\n 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]\n\n This section is non-normative.\n\n 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.\n\n Subsequent GET requests to the deleted resource usually result in a 404 or 410 status code, although HTTP allows others. [Source] [Source]\n\n Pertaining to events and loss of control mitigation: https://github.com/solid/specification/issues/41#issuecomment-534679278\n "^^ . + . + "Resource Representations"@en . + . + . + . + "When a server creates a resource on HTTP PUT, POST or PATCH requests such that the request\u2019s 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]."@en . + . + . + . + . + . + . + . + "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."@en . + . + "\n When a server creates a resource on HTTP PUT, POST or PATCH requests such that the request\u2019s 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]\n\n 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]\n "^^ . + "\n Servers MUST respond with the 405 status code to requests using HTTP methods that are not supported by the target resource. [Source]\n\n \n Resource Type Heuristics\n \n When creating new resources, servers can determine an effective request URI\u2019s type by examining the URI path ending (URI Slash Semantics).\n\n When a successful PUT or PATCH request creates a resource, the server MUST use the effective request URI to assign the URI to that resource.\n\n When a successful POST request creates a resource, the server MUST assign a URI to that resource. Servers MAY allow clients to suggest the URI of a resource created through POST, using the HTTP Slug header as defined in [RFC5023].\n\n \n Note: URI Allocation\n \n 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.\n \n \n\n [Source][Source].\n \n \n\n \n Reading Resources\n \n Servers MUST support the HTTP GET, HEAD and OPTIONS methods [RFC7231] for clients to read resources or to determine communication options. [Source]\n\n When responding to authorized requests:\n\n 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.\n\n Servers MUST indicate supported media types in the HTTP Accept-Patch [RFC5789], Accept-Post [LDP] and Accept-Put [The Accept-Put Response Header] response headers that correspond to acceptable HTTP methods listed in Allow header value in response to HTTP GET and HEAD requests.\n\n Servers MAY include the HTTP Accept-Patch, Accept-Post and Accept-Put headers in the response of a OPTIONS * request.\n\n [Source] [Source]\n \n \n\n \n Writing Resources\n \n Servers MUST support the HTTP PUT, POST and PATCH methods [RFC7231]. [Source] [Source]\n\n 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]\n\n 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. [Source] [Source]\n\n When a POST method request targets a resource without an existing representation, the server MUST respond with the 404 status code. [Source]\n\n 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]\n\n 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]\n\n Servers MUST NOT allow HTTP POST, PUT and PATCH to update a container\u2019s resource metadata statements; if the server receives such a request, it MUST respond with a 409 status code. [Source]\n\n \n Note: Conditional Update\n \n Clients are encouraged to use the HTTP If-None-Match header with a value of \"*\" to prevent an unsafe request method (e.g., PUT, PATCH) from inadvertently modifying an existing representation of the target resource when the client believes that the resource does not have a current representation. [Source] [Source] [Source]\n \n \n\n 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.\n \n\n \n Modifying Resources Using N3 Patches\n \n 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 value of the Accept-Patch header [RFC5789] of relevant responses. [Source]\n\n An N3 Patch is a document in the Notation3 (N3) format [N3], identified by the media type text/n3, conforming to the following constraints:\n\n \n A patch document MUST contain one or more patch resources.\n A patch resource MUST be identified by a URI or blank node, which we refer to as ?patch in the remainder of this section.\n A patch resource MAY contain a triple [RDF11-CONCEPTS] ?patch rdf:type solid:Patch.\n A patch resource MUST contain at most one triple of the form ?patch solid:deletes ?deletions.\n A patch resource MUST contain at most one triple of the form ?patch solid:inserts ?insertions.\n A patch resource MUST contain at most one triple of the form ?patch solid:where ?conditions.\n 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 {}.\n \n\n 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:\n\n \n 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.\n A patch resource MUST contain a triple ?patch rdf:type solid:InsertDeletePatch.\n The ?insertions and ?deletions formulae MUST NOT contain variables that do not occur in the ?conditions formula.\n The ?insertions and ?deletions formulae MUST NOT contain blank nodes.\n \n\n Servers MUST respond with a 422 status code [RFC4918] if a patch document does not satisfy all of the above constraints.\n\n 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.\n\n Servers MUST process a patch resource against the target document as follows:\n\n \n Start from the RDF dataset in the target document, or an empty RDF dataset if the target resource does not exist yet.\n If ?conditions is non-empty, find all (possibly empty) variable mappings such that all of the resulting triples occur in the dataset.\n If no such mapping exists, or if multiple mappings exist, the server MUST respond with a 409 status code. [Source]\n The resulting variable mapping is propagated to the ?deletions and ?insertions formulae to obtain two sets of resulting triples.\n 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]\n The triples resulting from ?deletions are to be removed from the RDF dataset.\n 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.\n 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.\n \n \n\n \n Example: Applying an N3 patch.\n @prefix solid: .\n@prefix ex: .\n\n_:rename a solid:InsertDeletePatch;\n solid:where { ?person ex:familyName \"Garcia\". };\n solid:inserts { ?person ex:givenName \"Alex\". };\n solid:deletes { ?person ex:givenName \"Claudia\". }.\n 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.\n \n \n \n\n \n Deleting Resources\n \n Servers MUST support the HTTP DELETE method [RFC7231]. [Source] [Source]\n\n When a DELETE request targets storage\u2019s root container or its associated ACL resource, the server MUST respond with the 405 status code. Server MUST exclude the DELETE method in the HTTP response header Allow in response to requests to these resources [RFC7231]. [Source]\n\n When a contained resource is deleted, the server MUST also remove the corresponding containment triple. [Source]\n\n When a contained resource is deleted, the server MUST also delete the associated auxiliary resources (see the Auxiliary Resources section).\n\n 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]\n\n This section is non-normative.\n\n 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.\n\n Subsequent GET requests to the deleted resource usually result in a 404 or 410 status code, although HTTP allows others. [Source] [Source]\n\n Pertaining to events and loss of control mitigation: https://github.com/solid/specification/issues/41#issuecomment-534679278\n \n \n\n \n Resource Representations\n \n When a server creates a resource on HTTP PUT, POST or PATCH requests such that the request\u2019s 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]\n\n 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]\n \n \n "^^ . +_:bnode20 . +_:bnode20 _:bnode24 . +_:bnode24 . +_:bnode24 _:bnode25 . +_:bnode25 . +_:bnode25 _:bnode26 . +_:bnode26 . +_:bnode26 _:bnode27 . +_:bnode27 . +_:bnode27 . + _:bnode20 . + . + "Notifications"@en . + . + . + . + "A Solid server MUST conform to the LDN specification by implementing the Receiver parts to receive notifications and make Inbox contents available [LDN]."@en . + . + . + . + "A Solid client MUST conform to the LDN specification by implementing the Sender or Consumer parts to discover the location of a resource\u2019s Inbox, and to send notifications to an Inbox or to retrieve the contents of an Inbox [LDN]."@en . + "\n A Solid server MUST conform to the LDN specification by implementing the Receiver parts to receive notifications and make Inbox contents available [LDN].\n\n A Solid client MUST conform to the LDN specification by implementing the Sender or Consumer parts to discover the location of a resource\u2019s Inbox, and to send notifications to an Inbox or to retrieve the contents of an Inbox [LDN].\n "^^ . + . + "Live Update"@en . + . + "WebSockets"@en . + . + . + . + "Servers SHOULD implement the Solid WebSockets API [SOLID-WEBSOCKETS-API]."@en . + . + . + . + "Clients SHOULD implement the Solid WebSockets API [SOLID-WEBSOCKETS-API]."@en . + . + "\n For real-time collaborative communication between client and server about changes affecting a resource, this Solid Protocol uses the WebSocket API [W3C-HTML] and the WebSocket Protocol.\n\n Servers SHOULD implement the Solid WebSockets API [SOLID-WEBSOCKETS-API].\n\n Clients SHOULD implement the Solid WebSockets API [SOLID-WEBSOCKETS-API].\n\n The following is non-normative.\n\n The Solid WebSockets API (Unofficial Draft) has been the common protocol for many years. That draft does not include an authentication mechanism, and therefore the Protocol will transition to a new design. The new design is currently at Solid Notifications Protocol [SOLID-NOTIFICATIONS-PROTOCOL]. It is planned to include both security through authentication, and also common formats with other forms of real-time notification in the Solid ecosystem.\n\n Both client and server implementations should provide the existing protocol, and should transition to providing both protocols as the new one becomes available..\n\n The future directions of the protocol include moving from a simple one-bit notification that a resource has changed, requiring the client to reload the resource, to adding PATCH information in the notification so the client can calculate the new state immediately.\n "^^ . + "\n \n WebSockets\n \n For real-time collaborative communication between client and server about changes affecting a resource, this Solid Protocol uses the WebSocket API [W3C-HTML] and the WebSocket Protocol.\n\n Servers SHOULD implement the Solid WebSockets API [SOLID-WEBSOCKETS-API].\n\n Clients SHOULD implement the Solid WebSockets API [SOLID-WEBSOCKETS-API].\n\n The following is non-normative.\n\n The Solid WebSockets API (Unofficial Draft) has been the common protocol for many years. That draft does not include an authentication mechanism, and therefore the Protocol will transition to a new design. The new design is currently at Solid Notifications Protocol [SOLID-NOTIFICATIONS-PROTOCOL]. It is planned to include both security through authentication, and also common formats with other forms of real-time notification in the Solid ecosystem.\n\n Both client and server implementations should provide the existing protocol, and should transition to providing both protocols as the new one becomes available..\n\n The future directions of the protocol include moving from a simple one-bit notification that a resource has changed, requiring the client to reload the resource, to adding PATCH information in the notification so the client can calculate the new state immediately.\n \n \n "^^ . +_:bnode24 . +_:bnode24 . + _:bnode24 . + . + "Cross-Origin Resource Sharing"@en . + . + "CORS Server"@en . + . + . + . + "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 [RFC7231]."@en . + . + "Note: CORS Protocol Blocking"@en . + "\n 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.\n "^^ . + . + . + . + "whenever a server 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]."@en . + . + . + . + "the server MUST set the Access-Control-Allow-Origin header to the valid Origin value from the request and list Origin in the Vary header value."@en . + . + . + . + "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-* headers themselves)."@en . + . + . + . + "A server MUST also support the HTTP OPTIONS method [RFC7231] such that it can respond appropriately to CORS preflight requests."@en . + . + . + . + "server 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)."@en . + . + . + . + "Servers SHOULD also explicitly list Accept under Access-Control-Allow-Headers"@en . + "\n 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 [RFC7231].\n\n \n Note: CORS Protocol Blocking\n \n 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.\n \n \n\n Concretely, whenever a server 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 server 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 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-* headers themselves). A server MUST also support the HTTP OPTIONS method [RFC7231] such that it can respond appropriately to CORS preflight requests.\n\n Careful attention is warranted, especially because of the many edge cases. For instance, server 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). Servers 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.\n "^^ . +_:bnode26 . +_:bnode26 . + _:bnode26 . + "\n 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.\n\n For cases where the other origins have their own access protection mechanism \u2014 like within Solid \u2014 the browser\u2019s 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.\n\n 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 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\u2019s allowed permissions. The next section describes how to achieve this through the right HTTP header configuration.\n\n \n CORS Server\n \n 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 [RFC7231].\n\n \n Note: CORS Protocol Blocking\n \n 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.\n \n \n\n Concretely, whenever a server 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 server 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 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-* headers themselves). A server MUST also support the HTTP OPTIONS method [RFC7231] such that it can respond appropriately to CORS preflight requests.\n\n Careful attention is warranted, especially because of the many edge cases. For instance, server 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). Servers 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.\n \n \n "^^ . +_:bnode25 . +_:bnode25 . + _:bnode25 . + . + "Identity"@en . + . + "WebID"@en . + "\n 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.\n "^^ . + "\n \n WebID\n \n 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.\n \n \n "^^ . +_:bnode27 . +_:bnode27 . + _:bnode27 . + . + "Authentication"@en . + . + "Solid-OIDC"@en . + "\n 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].\n "^^ . + . + "WebID-TLS"@en . + "\n This section is non-normative.\n\n 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.\n "^^ . + "\n \n Solid-OIDC\n \n 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].\n \n \n\n \n WebID-TLS\n \n This section is non-normative.\n\n 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.\n \n \n "^^ . +_:bnode28 . +_:bnode28 _:bnode29 . +_:bnode29 . +_:bnode29 . + _:bnode28 . + . + "Authorization"@en . + . + "Web Access Control"@en . + . + . + . + . + "Servers MUST conform to the Web Access Control specification [WAC]."@en . + . + . + . + "Clients MUST conform to the Web Access Control specification [WAC]."@en . + . + . + . + . + "\n Web Access Control (WAC) is a decentralized cross-domain access control system providing a way for Linked Data systems to set authorization conditions on HTTP resources using the Access Control List (ACL) model. Server manages the association between a resource and an ACL resource, and applies the authorization conditions on requested operations. Authorizations are described using the ACL ontology to express and determine access privileges of a requested resource. Applications can discover authorization rules associated with a given resource, and to control such rules, as directed by an agent.\n\n Servers MUST conform to the Web Access Control specification [WAC].\n\n Clients MUST conform to the Web Access Control specification [WAC].\n\n [Source] [Source] Source] Source]\n "^^ . + "\n \n Web Access Control\n \n Web Access Control (WAC) is a decentralized cross-domain access control system providing a way for Linked Data systems to set authorization conditions on HTTP resources using the Access Control List (ACL) model. Server manages the association between a resource and an ACL resource, and applies the authorization conditions on requested operations. Authorizations are described using the ACL ontology to express and determine access privileges of a requested resource. Applications can discover authorization rules associated with a given resource, and to control such rules, as directed by an agent.\n\n Servers MUST conform to the Web Access Control specification [WAC].\n\n Clients MUST conform to the Web Access Control specification [WAC].\n\n [Source] [Source] Source] Source]\n \n \n "^^ . +_:bnode29 . +_:bnode29 . + _:bnode29 . + . + "HTTP Definitions"@en . + . + "HTTP Headers"@en . + . + "The Accept-Put Response Header"@en . + "\n 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].\n\n The syntax for Accept-Put, using the ABNF syntax defined in Section 1.2 of [RFC7231], is:\n\n Accept-Put = \"Accept-Put\" \":\" # media-range\n\n 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.\n\n 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.\n\n IANA Registration Template:\n\n The Accept-Put response header must be added to the permanent registry (see [RFC3864]).\n\n \n Header field name\n Accept-Put\n Applicable Protocol\n HTTP\n Author/Change controller\n W3C Solid Community Group\n Specification document\n This specification\n \n "^^ . + "\n \n The Accept-Put Response Header\n \n 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].\n\n The syntax for Accept-Put, using the ABNF syntax defined in Section 1.2 of [RFC7231], is:\n\n Accept-Put = \"Accept-Put\" \":\" # media-range\n\n 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.\n\n 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.\n\n IANA Registration Template:\n\n The Accept-Put response header must be added to the permanent registry (see [RFC3864]).\n\n \n Header field name\n Accept-Put\n Applicable Protocol\n HTTP\n Author/Change controller\n W3C Solid Community Group\n Specification document\n This specification\n \n \n \n "^^ . +_:bnode31 . +_:bnode31 . + _:bnode31 . + "\n \n HTTP Headers\n \n \n The Accept-Put Response Header\n \n 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].\n\n The syntax for Accept-Put, using the ABNF syntax defined in Section 1.2 of [RFC7231], is:\n\n Accept-Put = \"Accept-Put\" \":\" # media-range\n\n 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.\n\n 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.\n\n IANA Registration Template:\n\n The Accept-Put response header must be added to the permanent registry (see [RFC3864]).\n\n \n Header field name\n Accept-Put\n Applicable Protocol\n HTTP\n Author/Change controller\n W3C Solid Community Group\n Specification document\n This specification\n \n \n \n \n \n "^^ . +_:bnode30 . +_:bnode30 . + _:bnode30 . + . + "Considerations"@en . + . + "Security Considerations"@en . + "\n This section is non-normative.\n\n While this section attempts to highlight a set of security considerations, it is not a complete list. Implementers are urged to seek the advice of security professionals when implementing mission critical systems using the technology outlined in this specification.\n\n Implementations are subject to the same security considerations that are found in HTTP/1.1 [RFC7230] and [RFC7231].\n\n Servers are strongly discouraged from assuming that HTTP request headers\u2019 field-values are valid or non-malicious. Servers are strongly encouraged to sanitize requests before processing them or incorporating them in messages sent to others. Servers are encouraged to reject bad requests that conflict with this specification's normative requirements. Servers are encouraged to apply normalization and canonicalization algorithms where applicable. Servers are encouraged to take measures to mitigate potential timing attacks attempting to discover resource existence even if requesting agent has no access to the resource(s). Servers are strongly discouraged from exposing information beyond the minimum amount necessary to enable a feature.\n\n Servers are strongly discouraged from assuming that the user agent is a regular Web browser, even when requests contain familiar values in headers such as User-Agent or Origin. Such an assumption could lead to incorrect conclusions about the security model of the application making the request, since the request might actually come from a non-browser actor unaffected by browser security constraints.\n\n 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\u2019s 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.\n\n 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.\n "^^ . + . + "Privacy Considerations"@en . + . + "Identifiable Information"@en . + "\n In order to prevent leakage of non-resource data, servers are strongly discouraged from including identifiable information in error responses.\n "^^ . + "\n This section is non-normative.\n\n Servers are encouraged to use authorization techniques to prevent unwanted access to resources, rather than depending on the relative obscurity of their resource names.\n\n \n Identifiable Information\n \n In order to prevent leakage of non-resource data, servers are strongly discouraged from including identifiable information in error responses.\n \n \n "^^ . +_:bnode33 . +_:bnode33 . + _:bnode33 . + . + "Accessibility Considerations"@en . + . + . + . + . + . + . + . + "\n This section is non-normative.\n\n 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.\n\n 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].\n\n Accessible Applications: To help assistive technologies to provide a consistent user interface and understanding of the objects, it is strongly encouraged to follow the Accessible Rich Internet Applications [WAI-ARIA-1.2] recommendations. To enable semantic navigation, styling and interactive features in context of digital publishing, it is encouraged to follow the Digital Publishing WAI-ARIA Module 1.0 [DPUB-ARIA-1.0]. To support structured graphics such as charts, graphs, technical drawings and scientific diagrams, to assistive technologies in order improve accessibility of graphics or diagrams through detailed annotations, it is encouraged to follow the WAI-ARIA Graphics Module [GRAPHICS-ARIA-1.0].\n\n 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.\n\n 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].\n "^^ . + . + "Internationalization Considerations"@en . + . + "\n This section is non-normative.\n\n 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:\n\n \n include links to navigate to different languages of the content;\n declare the base language of a document, indicate multiple languages and their directional flow \u2013 to help with translations;\n use Unicode character encoding, e.g., UTF-8, in data forms and text to ensure correct effects;\n check and minimise inappropriate cultural bias, and improve translatability;\n restrict markup use to structure and semantics.\n \n "^^ . + . + "Security and Privacy Review"@en . + . + . + ".."^^ . + . + . + . + ".."^^ . + . + . + . + ".."^^ . + . + . + . + ".."^^ . + . + . + . + ".."^^ . + . + . + . + ".."^^ . + . + . + . + ".."^^ . + . + . + . + ".."^^ . + . + . + . + ".."^^ . + . + . + . + ".."^^ . + . + . + . + ".."^^ . + . + . + . + ".."^^ . + . + . + . + ".."^^ . + . + . + . + ".."^^ . + . + . + . + ".."^^ . + . + . + . + ".."^^ . + . + . + . + ".."^^ . + . + . + . + ".."^^ . + . + "\n This section is non-normative.\n\n These questions provide an overview of security and privacy considerations for this specification as guided by [SECURITY-PRIVACY-QUESTIONNAIRE].\n\n \n What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?\n ..\n\n Do features in your specification expose the minimum amount of information necessary to enable their intended uses?\n ..\n\n How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?\n ..\n\n How do the features in your specification deal with sensitive information?\n ..\n\n Do the features in your specification introduce new state for an origin that persists across browsing sessions?\n ..\n\n Do the features in your specification expose information about the underlying platform to origins?\n ..\n\n Does this specification allow an origin to send data to the underlying platform?\n ..\n\n Do features in this specification allow an origin access to sensors on a user\u2019s device?\n ..\n\n 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.\n ..\n\n Do features in this specification enable new script execution/loading mechanisms?\n ..\n\n Do features in this specification allow an origin to access other devices?\n ..\n\n Do features in this specification allow an origin some measure of control over a user agent\u2019s native UI?\n ..\n\n What temporary identifiers do the features in this specification create or expose to the web?\n ..\n\n How does this specification distinguish between behaviour in first-party and third-party contexts?\n ..\n\n How do the features in this specification work in the context of a browser\u2019s Private Browsing or Incognito mode?\n ..\n\n Does this specification have both \"Security Considerations\" and \"Privacy Considerations\" sections?\n ..\n\n Do features in your specification enable origins to downgrade default security protections?\n ..\n\n How does your feature handle non-\"fully active\" documents?\n ..\n \n "^^ . + . + "Societal Impact Review"@en . + . + . + ".."^^ . + . + . + . + ".."^^ . + . + . + . + ".."^^ . + . + . + . + ".."^^ . + . + . + . + ".."^^ . + . + . + . + ".."^^ . + . + . + . + ".."^^ . + . + . + . + ".."^^ . + . + . + . + ".."^^ . + . + . + . + . + . + "Yes, in Security Considerations and Privacy Considerations."^^ . + . + "\n This section is non-normative.\n\n These questions provide an overview of ethical considerations and societal impact as guided by [SOCIETAL-IMPACT-QUESTIONNAIRE].\n\n \n What kinds of activities could your specification become a part of that you are not designing for?\n ..\n\n What risks do you see in features of your specification being misused, or used differently from how you intended?\n ..\n\n Can users of the Web Platform choose not to use features of your specification?\n ..\n\n What groups of people are excluded from using features of your specification?\n ..\n\n What effect may features of your specification have on minority groups?\n ..\n\n What are the power dynamics at play in implementations of your specification?\n ..\n\n What points of centralization does your feature bring to the web platform?\n ..\n\n To what extent do the features in your specification result in increased power consumption or emissions?\n ..\n\n What is the expected lifetime of your specification feature(s)?\n ..\n\n Have you completed the Security & Privacy Self-review Questionnaire?\n Yes, in Security Considerations and Privacy Considerations.\n \n "^^ . + "\n This section details security, privacy, accessibility and internationalization considerations.\n\n 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.\n\n \n Security Considerations\n \n This section is non-normative.\n\n While this section attempts to highlight a set of security considerations, it is not a complete list. Implementers are urged to seek the advice of security professionals when implementing mission critical systems using the technology outlined in this specification.\n\n Implementations are subject to the same security considerations that are found in HTTP/1.1 [RFC7230] and [RFC7231].\n\n Servers are strongly discouraged from assuming that HTTP request headers\u2019 field-values are valid or non-malicious. Servers are strongly encouraged to sanitize requests before processing them or incorporating them in messages sent to others. Servers are encouraged to reject bad requests that conflict with this specification's normative requirements. Servers are encouraged to apply normalization and canonicalization algorithms where applicable. Servers are encouraged to take measures to mitigate potential timing attacks attempting to discover resource existence even if requesting agent has no access to the resource(s). Servers are strongly discouraged from exposing information beyond the minimum amount necessary to enable a feature.\n\n Servers are strongly discouraged from assuming that the user agent is a regular Web browser, even when requests contain familiar values in headers such as User-Agent or Origin. Such an assumption could lead to incorrect conclusions about the security model of the application making the request, since the request might actually come from a non-browser actor unaffected by browser security constraints.\n\n 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\u2019s 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.\n\n 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.\n \n \n\n \n Privacy Considerations\n \n This section is non-normative.\n\n Servers are encouraged to use authorization techniques to prevent unwanted access to resources, rather than depending on the relative obscurity of their resource names.\n\n \n Identifiable Information\n \n In order to prevent leakage of non-resource data, servers are strongly discouraged from including identifiable information in error responses.\n \n \n \n \n\n \n Accessibility Considerations\n \n This section is non-normative.\n\n 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.\n\n 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].\n\n Accessible Applications: To help assistive technologies to provide a consistent user interface and understanding of the objects, it is strongly encouraged to follow the Accessible Rich Internet Applications [WAI-ARIA-1.2] recommendations. To enable semantic navigation, styling and interactive features in context of digital publishing, it is encouraged to follow the Digital Publishing WAI-ARIA Module 1.0 [DPUB-ARIA-1.0]. To support structured graphics such as charts, graphs, technical drawings and scientific diagrams, to assistive technologies in order improve accessibility of graphics or diagrams through detailed annotations, it is encouraged to follow the WAI-ARIA Graphics Module [GRAPHICS-ARIA-1.0].\n\n 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.\n\n 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].\n \n \n\n \n Internationalization Considerations\n \n This section is non-normative.\n\n 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:\n\n \n include links to navigate to different languages of the content;\n declare the base language of a document, indicate multiple languages and their directional flow \u2013 to help with translations;\n use Unicode character encoding, e.g., UTF-8, in data forms and text to ensure correct effects;\n check and minimise inappropriate cultural bias, and improve translatability;\n restrict markup use to structure and semantics.\n \n \n \n\n \n Security and Privacy Review\n \n This section is non-normative.\n\n These questions provide an overview of security and privacy considerations for this specification as guided by [SECURITY-PRIVACY-QUESTIONNAIRE].\n\n \n What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?\n ..\n\n Do features in your specification expose the minimum amount of information necessary to enable their intended uses?\n ..\n\n How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?\n ..\n\n How do the features in your specification deal with sensitive information?\n ..\n\n Do the features in your specification introduce new state for an origin that persists across browsing sessions?\n ..\n\n Do the features in your specification expose information about the underlying platform to origins?\n ..\n\n Does this specification allow an origin to send data to the underlying platform?\n ..\n\n Do features in this specification allow an origin access to sensors on a user\u2019s device?\n ..\n\n 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.\n ..\n\n Do features in this specification enable new script execution/loading mechanisms?\n ..\n\n Do features in this specification allow an origin to access other devices?\n ..\n\n Do features in this specification allow an origin some measure of control over a user agent\u2019s native UI?\n ..\n\n What temporary identifiers do the features in this specification create or expose to the web?\n ..\n\n How does this specification distinguish between behaviour in first-party and third-party contexts?\n ..\n\n How do the features in this specification work in the context of a browser\u2019s Private Browsing or Incognito mode?\n ..\n\n Does this specification have both \"Security Considerations\" and \"Privacy Considerations\" sections?\n ..\n\n Do features in your specification enable origins to downgrade default security protections?\n ..\n\n How does your feature handle non-\"fully active\" documents?\n ..\n \n \n \n\n \n Societal Impact Review\n \n This section is non-normative.\n\n These questions provide an overview of ethical considerations and societal impact as guided by [SOCIETAL-IMPACT-QUESTIONNAIRE].\n\n \n What kinds of activities could your specification become a part of that you are not designing for?\n ..\n\n What risks do you see in features of your specification being misused, or used differently from how you intended?\n ..\n\n Can users of the Web Platform choose not to use features of your specification?\n ..\n\n What groups of people are excluded from using features of your specification?\n ..\n\n What effect may features of your specification have on minority groups?\n ..\n\n What are the power dynamics at play in implementations of your specification?\n ..\n\n What points of centralization does your feature bring to the web platform?\n ..\n\n To what extent do the features in your specification result in increased power consumption or emissions?\n ..\n\n What is the expected lifetime of your specification feature(s)?\n ..\n\n Have you completed the Security & Privacy Self-review Questionnaire?\n Yes, in Security Considerations and Privacy Considerations.\n \n \n \n "^^ . +_:bnode32 . +_:bnode32 _:bnode36 . +_:bnode36 . +_:bnode36 _:bnode37 . +_:bnode37 . +_:bnode37 _:bnode38 . +_:bnode38 . +_:bnode38 _:bnode39 . +_:bnode39 . +_:bnode39 _:bnode40 . +_:bnode40 . +_:bnode40 . + _:bnode32 . + . + "References"@en . + . + "Normative References"@en . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + . + "\n \n [DC-TERMS]\n 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/\n [FETCH]\n Fetch Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://fetch.spec.whatwg.org/\n [IANA-MEDIA-TYPES]\n Media Types. IANA. URL: https://www.iana.org/assignments/media-types/\n [JSON-LD11]\n 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/\n [LDN]\n Linked Data Notifications. Sarven Capadisli; Amy Guy. W3C. 2 May 2017. W3C Recommendation. URL: https://www.w3.org/TR/ldn/\n [LDP]\n Linked Data Platform 1.0. Steve Speicher; John Arwe; Ashok Malhotra. W3C. 26 February 2015. W3C Recommendation. URL: https://www.w3.org/TR/ldp/\n [N3]\n Notation3. D\u00F6rthe Arndt; William Van Woensel;Dominik Tomaszuk; Gregg Kellogg. W3C. 5 September 2021. Draft Community Group Report. URL: https://w3c.github.io/N3/spec/\n [RDF-SCHEMA]\n RDF Schema 1.1. Dan Brickley; Ramanathan Guha. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf-schema/\n [RDF11-CONCEPTS]\n 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/\n [RFC2119]\n 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\n [RFC3864]\n Registration Procedures for Message Header Fields. G. Klyne; M. Nottingham; J. Mogul. IETF. September 2004. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc3864\n [RFC3986]\n 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\n [RFC4918]\n 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\n [RFC5023]\n The Atom Publishing Protocol. J. Gregorio, Ed.; B. de hOra, Ed.. IETF. October 2007. Proposed Standard. URL: https://datatracker.ietf.org/doc/html/rfc5023\n [RFC5789]\n PATCH Method for HTTP. L. Dusseault; J. Snell. IETF. March 2010. Proposed Standard. URL: https://httpwg.org/specs/rfc5789.html\n [RFC6454]\n The Web Origin Concept. A. Barth. IETF. December 2011. Proposed Standard. URL: https://datatracker.ietf.org/doc/html/rfc6454\n [RFC6455]\n The WebSocket Protocol. I. Fette; A. Melnikov. IETF. December 2011. Proposed Standard. URL: https://datatracker.ietf.org/doc/html/rfc6455\n [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\n [RFC6892]\n The 'describes' Link Relation Type. E. Wilde. IETF. March 2013. Informational. URL: https://datatracker.ietf.org/doc/html/rfc6892\n [RFC7230]\n Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7230.html\n [RFC7231]\n Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7231.html\n [RFC7232]\n Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7232.html\n [RFC7233]\n Hypertext Transfer Protocol (HTTP/1.1): Range Requests. R. Fielding, Ed.; Y. Lafon, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7233.html\n [RFC7234]\n Hypertext Transfer Protocol (HTTP/1.1): Caching. R. Fielding, Ed.; M. Nottingham, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7234.html\n [RFC7235]\n Hypertext Transfer Protocol (HTTP/1.1): Authentication. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7235.html\n [RFC7540]\n Hypertext Transfer Protocol Version 2 (HTTP/2). M. Belshe; R. Peon; M. Thomson, Ed.. IETF. May 2015. Proposed Standard. URL: https://httpwg.org/specs/rfc7540.html\n [RFC8174]\n 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\n [RFC8288]\n Web Linking. M. Nottingham. IETF. October 2017. Proposed Standard. URL: https://httpwg.org/specs/rfc8288.html\n [SOLID-WEBSOCKETS-API]\n 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\n [SOLID-OIDC]\n SOLID-OIDC. Aaron Coburn; elf Pavlik; Dmitri Zagidulin. W3C Solid Community Group. 13 December 2021. W3C Editor's Draft. URL: https://solid.github.io/solid-oidc/\n [SPARQL11-QUERY]\n 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/\n [Turtle]\n RDF 1.1 Turtle. Eric Prud'hommeaux; Gavin Carothers. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/turtle/\n [W3C-HTML]\n HTML. W3C. 28 January 2021. W3C Recommendation. URL: https://www.w3.org/TR/html/\n [WAC]\n Web Access Control. Sarven Capadisli. W3C Solid Community Group. 11 July 2021. Draft. URL: https://solidproject.org/TR/wac\n [WEBARCH]\n 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/\n [WEBID]\n WebID 1.0. Andrei Sambra; St\u00E9phane Corlosquet. W3C WebID Community Group. 5 March 2014. W3C Editor\u2019s Draft. URL: https://www.w3.org/2005/Incubator/webid/spec/identity/\n \n "^^ . + . + "Informative References"@en . + . + . + . + . + . + . + . + . + . + . + . + "\n \n [ATAG20]\n 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/\n [COGA-USABLE]\n Making content usable for people with cognitive and learning disabilities. Lisa Seeman-Horwitz; Rachael Bradley Montgomery; Steve Lee; Ruoxi Ran. W3C. 11 December 2020. W3C Working Draft. URL: https://www.w3.org/TR/coga-usable/\n [DPUB-ARIA-1.0]\n Digital Publishing WAI-ARIA Module 1.0. Matt Garrish; Tzviya Siegman; Markus Gylling; Shane McCarron. W3C. 14 December 2017. W3C Recommendation. URL: https://www.w3.org/TR/dpub-aria-1.0/\n [GRAPHICS-ARIA-1.0]\n 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/\n [SECURITY-PRIVACY-QUESTIONNAIRE]\n Self-Review Questionnaire: Security and Privacy. Theresa O'Connor; Peter Snyder. W3C. 23 March 2021. W3C Note. URL: https://www.w3.org/TR/security-privacy-questionnaire/\n [SOCIETAL-IMPACT-QUESTIONNAIRE]\n Self-Review Questionnaire: Societal Impact. Amy Guy. W3C. 13 Dec 2021. W3C Draft TAG Finding. URL: https://w3ctag.github.io/societal-impact-questionnaire/\n [SOLID-NOTIFICATIONS-PROTOCOL]\n Solid Notifications Protocol. Aaron Coburn; Sarven Capadisli. W3C Solid Community Group. 16 December 2021. W3C Editor\u2019s Draft. URL: https://solid.github.io/notifications/protocol\n [UAAG20]\n 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/\n [WAI-ARIA-1.2]\n Accessible Rich Internet Applications (WAI-ARIA) 1.2. Joanmarie Diggs; James Nurthen; Michael Cooper. W3C. 2 March 2021. W3C Candidate Recommendation. URL: https://www.w3.org/TR/wai-aria-1.2/\n [WCAG-3.0]\n W3C Accessibility Guidelines (WCAG) 3.0. Jeanne F Spellman; Rachael Bradley Montgomery; Shawn Lauriat; Michael Cooper. W3C. 21 January 2021. W3C Working Draft. URL: https://www.w3.org/TR/wcag-3.0/\n [WEBID-TLS]\n WebID Authentication over TLS. Henry Story; St\u00E9phane Corlosquet; Andrei Sambra. W3C WebID Community Group. W3C Editor's Draft. URL: https://www.w3.org/2005/Incubator/webid/spec/tls/\n \n "^^ . + "\n \n Normative References\n \n \n [DC-TERMS]\n 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/\n [FETCH]\n Fetch Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://fetch.spec.whatwg.org/\n [IANA-MEDIA-TYPES]\n Media Types. IANA. URL: https://www.iana.org/assignments/media-types/\n [JSON-LD11]\n 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/\n [LDN]\n Linked Data Notifications. Sarven Capadisli; Amy Guy. W3C. 2 May 2017. W3C Recommendation. URL: https://www.w3.org/TR/ldn/\n [LDP]\n Linked Data Platform 1.0. Steve Speicher; John Arwe; Ashok Malhotra. W3C. 26 February 2015. W3C Recommendation. URL: https://www.w3.org/TR/ldp/\n [N3]\n Notation3. D\u00F6rthe Arndt; William Van Woensel;Dominik Tomaszuk; Gregg Kellogg. W3C. 5 September 2021. Draft Community Group Report. URL: https://w3c.github.io/N3/spec/\n [RDF-SCHEMA]\n RDF Schema 1.1. Dan Brickley; Ramanathan Guha. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf-schema/\n [RDF11-CONCEPTS]\n 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/\n [RFC2119]\n 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\n [RFC3864]\n Registration Procedures for Message Header Fields. G. Klyne; M. Nottingham; J. Mogul. IETF. September 2004. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc3864\n [RFC3986]\n 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\n [RFC4918]\n 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\n [RFC5023]\n The Atom Publishing Protocol. J. Gregorio, Ed.; B. de hOra, Ed.. IETF. October 2007. Proposed Standard. URL: https://datatracker.ietf.org/doc/html/rfc5023\n [RFC5789]\n PATCH Method for HTTP. L. Dusseault; J. Snell. IETF. March 2010. Proposed Standard. URL: https://httpwg.org/specs/rfc5789.html\n [RFC6454]\n The Web Origin Concept. A. Barth. IETF. December 2011. Proposed Standard. URL: https://datatracker.ietf.org/doc/html/rfc6454\n [RFC6455]\n The WebSocket Protocol. I. Fette; A. Melnikov. IETF. December 2011. Proposed Standard. URL: https://datatracker.ietf.org/doc/html/rfc6455\n [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\n [RFC6892]\n The 'describes' Link Relation Type. E. Wilde. IETF. March 2013. Informational. URL: https://datatracker.ietf.org/doc/html/rfc6892\n [RFC7230]\n Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7230.html\n [RFC7231]\n Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7231.html\n [RFC7232]\n Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7232.html\n [RFC7233]\n Hypertext Transfer Protocol (HTTP/1.1): Range Requests. R. Fielding, Ed.; Y. Lafon, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7233.html\n [RFC7234]\n Hypertext Transfer Protocol (HTTP/1.1): Caching. R. Fielding, Ed.; M. Nottingham, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7234.html\n [RFC7235]\n Hypertext Transfer Protocol (HTTP/1.1): Authentication. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7235.html\n [RFC7540]\n Hypertext Transfer Protocol Version 2 (HTTP/2). M. Belshe; R. Peon; M. Thomson, Ed.. IETF. May 2015. Proposed Standard. URL: https://httpwg.org/specs/rfc7540.html\n [RFC8174]\n 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\n [RFC8288]\n Web Linking. M. Nottingham. IETF. October 2017. Proposed Standard. URL: https://httpwg.org/specs/rfc8288.html\n [SOLID-WEBSOCKETS-API]\n 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\n [SOLID-OIDC]\n SOLID-OIDC. Aaron Coburn; elf Pavlik; Dmitri Zagidulin. W3C Solid Community Group. 13 December 2021. W3C Editor's Draft. URL: https://solid.github.io/solid-oidc/\n [SPARQL11-QUERY]\n 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/\n [Turtle]\n RDF 1.1 Turtle. Eric Prud'hommeaux; Gavin Carothers. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/turtle/\n [W3C-HTML]\n HTML. W3C. 28 January 2021. W3C Recommendation. URL: https://www.w3.org/TR/html/\n [WAC]\n Web Access Control. Sarven Capadisli. W3C Solid Community Group. 11 July 2021. Draft. URL: https://solidproject.org/TR/wac\n [WEBARCH]\n 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/\n [WEBID]\n WebID 1.0. Andrei Sambra; St\u00E9phane Corlosquet. W3C WebID Community Group. 5 March 2014. W3C Editor\u2019s Draft. URL: https://www.w3.org/2005/Incubator/webid/spec/identity/\n \n \n \n\n \n Informative References\n \n \n [ATAG20]\n 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/\n [COGA-USABLE]\n Making content usable for people with cognitive and learning disabilities. Lisa Seeman-Horwitz; Rachael Bradley Montgomery; Steve Lee; Ruoxi Ran. W3C. 11 December 2020. W3C Working Draft. URL: https://www.w3.org/TR/coga-usable/\n [DPUB-ARIA-1.0]\n Digital Publishing WAI-ARIA Module 1.0. Matt Garrish; Tzviya Siegman; Markus Gylling; Shane McCarron. W3C. 14 December 2017. W3C Recommendation. URL: https://www.w3.org/TR/dpub-aria-1.0/\n [GRAPHICS-ARIA-1.0]\n 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/\n [SECURITY-PRIVACY-QUESTIONNAIRE]\n Self-Review Questionnaire: Security and Privacy. Theresa O'Connor; Peter Snyder. W3C. 23 March 2021. W3C Note. URL: https://www.w3.org/TR/security-privacy-questionnaire/\n [SOCIETAL-IMPACT-QUESTIONNAIRE]\n Self-Review Questionnaire: Societal Impact. Amy Guy. W3C. 13 Dec 2021. W3C Draft TAG Finding. URL: https://w3ctag.github.io/societal-impact-questionnaire/\n [SOLID-NOTIFICATIONS-PROTOCOL]\n Solid Notifications Protocol. Aaron Coburn; Sarven Capadisli. W3C Solid Community Group. 16 December 2021. W3C Editor\u2019s Draft. URL: https://solid.github.io/notifications/protocol\n [UAAG20]\n 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/\n [WAI-ARIA-1.2]\n Accessible Rich Internet Applications (WAI-ARIA) 1.2. Joanmarie Diggs; James Nurthen; Michael Cooper. W3C. 2 March 2021. W3C Candidate Recommendation. URL: https://www.w3.org/TR/wai-aria-1.2/\n [WCAG-3.0]\n W3C Accessibility Guidelines (WCAG) 3.0. Jeanne F Spellman; Rachael Bradley Montgomery; Shawn Lauriat; Michael Cooper. W3C. 21 January 2021. W3C Working Draft. URL: https://www.w3.org/TR/wcag-3.0/\n [WEBID-TLS]\n WebID Authentication over TLS. Henry Story; St\u00E9phane Corlosquet; Andrei Sambra. W3C WebID Community Group. W3C Editor's Draft. URL: https://www.w3.org/2005/Incubator/webid/spec/tls/\n \n \n \n "^^ . +_:bnode36 . +_:bnode36 _:bnode37 . +_:bnode37 . +_:bnode37 . + _:bnode36 . + "\n \n Abstract\n \n This document connects a set of specifications that, together, provide applications with secure and permissioned access to externally stored data in an interoperable way.\n \n \n\n \n Status of This Document\n \n This section describes the status of this document at the time of its publication.\n\n This document was published by the Solid Community Group as Version 0.9.0. 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.\n\n Publication as Version 0.9.0 does not imply endorsement by the W3C Membership. 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.\n\n This document was produced by a group operating under the W3C Community Contributor License Agreement (CLA). A human-readable summary is available.\n \n \n\n \n Table of Contents\n \n \n \n Abstract\n \n \n Status of This Document\n \n \n 1 Introduction\n \n 1.1 Terminology\n 1.2 Namespaces\n 1.3 Conformance\n \n \n \n 2 Hypertext Transfer Protocol\n \n \n 3 Uniform Resource Identifier\n \n \n 4 Resources\n \n 4.1 Storage\n 4.2 Resource Containment\n 4.3 Auxiliary Resources\n \n \n \n 5 Reading and Writing Resources\n \n 5.1 Resource Type Heuristics\n 5.2 Reading Resources\n 5.3 Writing Resources\n 5.4 Deleting Resources\n 5.5 Resource Representations\n \n \n \n 6 Notifications\n \n \n 7 Live Update\n \n \n 8 Cross-Origin Resource Sharing\n \n \n 9 Identity\n \n 9.1 WebID\n \n \n \n 10 Authentication\n \n 10.1 Solid-OIDC\n 10.2 WebID-TLS\n \n \n \n 11 Authorization\n \n 11.1 Web Access Control\n \n \n \n 12 HTTP Definitions\n \n 12.1 HTTP Headers\n \n \n \n 13 Considerations\n \n 13.1 Security Considerations\n 13.2 Privacy Considerations\n 13.3 Accessibility Considerations\n 13.4 Internationalization Considerations\n 13.5 Security and Privacy Review\n 13.6 Societal Impact Review\n \n \n \n References\n \n Normative References\n Informative References\n \n \n \n \n \n\n \n Introduction\n \n 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.\n\n 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.\n\n 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.\n\n 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 \u2013 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.\n\n 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.\n\n 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.\n\n This specification is for:\n\n \n Resource server developers that want to enable clients to send and retrieve information;\n Application developers that want to implement a client to perform operations on resources.\n \n\n \n Terminology\n \n This section is non-normative.\n\n The Solid Protocol specification defines the following terms. These terms are referenced throughout this specification.\n\n \n\n \n data pod\n A data pod is a place for storing documents, with mechanisms for controlling who can access what.\n\n Solid app\n A Solid app is an application that reads or writes data from one or more storages.\n\n URI\n A Uniform Resource Identifier (URI) provides the means for identifying resources [RFC3986].\n\n resource\n A resource is the target of an HTTP request identified by a URI [RFC7231].\n\n container resource\n A container resource is a hierarchical collection of resources that contains other resources, including containers.\n\n root container\n A root container is a container resource that is at the highest level of the collection hierarchy.\n\n resource metadata\n Resource metadata encompasses data about resources described by means of RDF statements [RDF11-CONCEPTS].\n\n agent\n An agent is a person, social entity, or software identified by a URI; e.g., a WebID denotes an agent [WEBID].\n\n owner\n An owner is a person or a social entity that is considered to have the rights and responsibilities of a data storage. An owner is identified by a URI, and implicitly has control over all data in a storage. An owner is first set at storage provisioning time and can be changed.\n\n origin\n An origin indicates where an HTTP request originates from [RFC6454].\n\n read operation\n A read operation entails that information about a resource\u2019s existence or its description can be known. [Source]\n\n write operation\n A write operation entails that information about resources can be created or removed. [Source]\n\n append operation\n An append operation entails that information can be added but not removed. [Source]\n \n \n \n\n \n Namespaces\n \n \n Prefixes and Namespaces\n \n \n Prefix\n Namespace\n Description\n \n \n \n \n rdf\n http://www.w3.org/1999/02/22-rdf-syntax-ns#\n [rdf-schema]\n \n \n ldp\n http://www.w3.org/ns/ldp#\n [LDP]\n \n \n solid\n http://www.w3.org/ns/solid/terms#\n Solid Terms\n \n \n pim\n http://www.w3.org/ns/pim/space#\n Workspace Ontology\n \n \n acl\n http://www.w3.org/ns/auth/acl#\n ACL Ontology\n \n \n dcterms\n http://purl.org/dc/terms/\n [DC-TERMS]\n \n \n stat\n http://www.w3.org/ns/posix/stat\n POSIX File Status\n \n \n \n \n \n\n \n Conformance\n \n All assertions, diagrams, examples, and notes are non-normative, as are all sections explicitly marked non-normative. Everything else is normative.\n\n The key words \u201CMUST\u201D, \u201CMUST NOT\u201D, \u201CREQUIRED\u201D, \u201CSHALL\u201D, \u201CSHALL NOT\u201D, \u201CSHOULD\u201D, \u201CSHOULD NOT\u201D, \u201CRECOMMENDED\u201D, \u201CMAY\u201D, and \u201COPTIONAL\u201D are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.\n \n \n \n \n\n \n Hypertext Transfer Protocol\n \n 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.\n\n \n HTTP Server\n \n Servers MUST conform to HTTP/1.1 Message Syntax and Routing [RFC7230] and HTTP/1.1 Semantics and Content [RFC7231]. Servers SHOULD conform to HTTP/2 [RFC7540].\n\n 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.\n\n Servers MUST conform to HTTP/1.1 Conditional Requests [RFC7232]. Servers SHOULD conform to HTTP/1.1 Caching [RFC7234]. Servers MAY conform to HTTP/1.1 Range Requests [RFC7233].\n\n Servers MUST conform to HTTP/1.1 Authentication [RFC7235]. 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).\n\n Server MUST reject PUT, POST and PATCH requests without the Content-Type header with a status code of 400. [Source]\n \n \n\n \n HTTP Client\n \n Clients MUST conform to HTTP/1.1 Message Syntax and Routing [RFC7230] and HTTP/1.1 Semantics and Content [RFC7231]. Clients MAY conform to HTTP/2 [RFC7540].\n\n Clients MAY conform to HTTP/1.1 Conditional Requests [RFC7232]. Clients MAY conform to HTTP/1.1 Caching [RFC7234]. Clients MAY conform to HTTP/1.1 Range Requests [RFC7233].\n\n Clients MUST conform to HTTP/1.1 Authentication [RFC7235] if it needs to access resources requiring authentication (see WebID). When a client receives a response with a 403 or 404 status code, the client MAY repeat the request with different credentials.\n\n Clients MUST use the Content-Type HTTP header in PUT, POST and PATCH requests [RFC7231]. [Source]\n \n \n \n \n\n \n Uniform Resource Identifier\n \n \n Note: Storage Owner and URI Ownership\n \n This specification does not describe the relationship between a Solid storage owner and Web architecture\u2019s URI ownership [WEBARCH].\n \n \n\n \n URI Slash Semantics\n \n 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]\n\n 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].\n \n \n\n \n URI Persistence\n \n This section is non-normative.\n\n 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\u2019s URI persistence [WEBARCH]. [Source]\n\n \n Note: URI Reuse\n \n Servers that wish to disable URI re-use may want to use the 410 status code.\n \n \n \n \n \n \n\n \n Resources\n \n \n Storage\n \n Servers MUST provide one or more storages (pim:Storage) \u2013 a space of URIs in which data can be accessed. A storage is the root container for all of its contained resources (see Resource Containment).\n\n When a server supports multiple storages, the URIs MUST be allocated to non-overlapping space.\n\n 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\u2019s request URI.\n\n 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.\n\n 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.\n\n 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).\n\n [Source] [Source]\n\n Servers MUST keep track of at least one owner of a storage in an implementation defined way.\n\n When a server wants to advertise the owner of a storage, the server MUST include the Link header with rel=\"http://www.w3.org/ns/solid/terms#owner\" targeting the URI of the owner in the response of HTTP HEAD or GET requests targeting the root container.\n\n \n Note: Trust Between Owners\n \n When a server supports multiple storages, there must be complete trust between its owners.\n \n \n\n [Source][Source][Source][Source]\n \n \n\n \n Resource Containment\n \n Solid has the notion of containers to represent a collection of linked resources to help with resource discovery and lifecycle management.\n\n 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]\n\n The representation and behaviour of containers in Solid corresponds to LDP Basic Container and MUST be supported by server. [Source]\n\n Servers can determine the value of the HTTP Last-Modified header field in response to HEAD and GET requests targeting a container based on changes to containment triples.\n\n \n Note: Container Last-Modified Comparison\n \n 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. In future versions of this specification, this design may be revisited.\n \n \n\n \n Contained Resource Metadata\n \n 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.\n\n Servers SHOULD include resource metadata about contained resources as part of the container description, unless that information is inapplicable to the server.\n\n Contained resource metadata statements include the properties:\n\n \n rdf:type\n 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].\n stat:size\n A non-negative integer giving the size of the resource in bytes.\n dcterms:modified\n The date and time when the resource was last modified.\n stat:mtime\n The Unix time when the resource was last modified.\n \n\n The dcterms:modified value of a contained resource corresponds with the Last-Modified header 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\u2019s generation, then a response with the 200 status code including the Last-Modified header would indicate the same date and time.\n\n \n Note: Contained Resource Metadata Considerations\n \n The generation of contained resource metadata may be inapplicable to some servers, for example, when that information does not exist or is expensive to determine.\n \n \n\n Contained resource metadata is protected by the server.\n\n [Source]\n [Source] [Source]\n \n \n \n \n\n \n Auxiliary Resources\n \n 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.\n\n Server manages the association between a subject resource and auxiliary resources defined by this specification. The lifecycle of auxiliary resources defined by this specification depend on the lifecycle of the subject resource that they are associated with.\n\n 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.\n\n \n Note: Self-describing Resources\n \n Where applicable, to promote self-describing resources, implementations and authors are encouraged to use the subject resource instead of the associated auxiliary resource.\n \n \n\n This specification defines the following types of auxiliary resources:\n\n \n Web Access Control\n Resource Description\n \n\n Clients can discover auxiliary resources associated with a subject resource by making an HTTP HEAD or GET request on the target URL, and checking the HTTP Link header with the rel parameter [RFC8288].\n\n \n \n \n Auxiliary Type\n Link Relation\n Definitions\n \n \n \n \n Web Access Control\n acl\n [WAC]\n \n \n Description Resource\n describedby\n [LDP]\n \n \n \n \n \n \n The possibility of using URIs as relation types interchangeably or as alternate to the tokens above are under consideration:\n\n \n http://www.w3.org/ns/auth/acl#accessControl\n https://www.w3.org/ns/iana/link-relations/relation#acl\n https://www.w3.org/ns/iana/link-relations/relation#describedby\n https://www.w3.org/ns/iana/link-relations/relation#describes\n \n\n Issue\n \n \n \n \n \n\n \n Web Access Control\n \n An auxiliary resource of type Web Access Control provides access control description of a subject resource (Web Access Control).\n \n \n\n \n Description Resource\n \n An auxiliary resource of type Description Resource provides a description of a subject resource ([LDP]).\n\n Servers MUST NOT directly associate more than one description resource to a subject resource.\n\n 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.\n\n Clients can discover resources that are described by description resources by making an HTTP HEAD or GET request on the target URL, and checking the HTTP Link header with a rel value of describes (inverse of the describedby relation) [RFC6892].\n \n \n \n \n \n \n\n \n Reading and Writing Resources\n \n Servers MUST respond with the 405 status code to requests using HTTP methods that are not supported by the target resource. [Source]\n\n \n Resource Type Heuristics\n \n When creating new resources, servers can determine an effective request URI\u2019s type by examining the URI path ending (URI Slash Semantics).\n\n When a successful PUT or PATCH request creates a resource, the server MUST use the effective request URI to assign the URI to that resource.\n\n When a successful POST request creates a resource, the server MUST assign a URI to that resource. Servers MAY allow clients to suggest the URI of a resource created through POST, using the HTTP Slug header as defined in [RFC5023].\n\n \n Note: URI Allocation\n \n 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.\n \n \n\n [Source][Source].\n \n \n\n \n Reading Resources\n \n Servers MUST support the HTTP GET, HEAD and OPTIONS methods [RFC7231] for clients to read resources or to determine communication options. [Source]\n\n When responding to authorized requests:\n\n 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.\n\n Servers MUST indicate supported media types in the HTTP Accept-Patch [RFC5789], Accept-Post [LDP] and Accept-Put [The Accept-Put Response Header] response headers that correspond to acceptable HTTP methods listed in Allow header value in response to HTTP GET and HEAD requests.\n\n Servers MAY include the HTTP Accept-Patch, Accept-Post and Accept-Put headers in the response of a OPTIONS * request.\n\n [Source] [Source]\n \n \n\n \n Writing Resources\n \n Servers MUST support the HTTP PUT, POST and PATCH methods [RFC7231]. [Source] [Source]\n\n 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]\n\n 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. [Source] [Source]\n\n When a POST method request targets a resource without an existing representation, the server MUST respond with the 404 status code. [Source]\n\n 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]\n\n 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]\n\n Servers MUST NOT allow HTTP POST, PUT and PATCH to update a container\u2019s resource metadata statements; if the server receives such a request, it MUST respond with a 409 status code. [Source]\n\n \n Note: Conditional Update\n \n Clients are encouraged to use the HTTP If-None-Match header with a value of \"*\" to prevent an unsafe request method (e.g., PUT, PATCH) from inadvertently modifying an existing representation of the target resource when the client believes that the resource does not have a current representation. [Source] [Source] [Source]\n \n \n\n 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.\n \n\n \n Modifying Resources Using N3 Patches\n \n 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 value of the Accept-Patch header [RFC5789] of relevant responses. [Source]\n\n An N3 Patch is a document in the Notation3 (N3) format [N3], identified by the media type text/n3, conforming to the following constraints:\n\n \n A patch document MUST contain one or more patch resources.\n A patch resource MUST be identified by a URI or blank node, which we refer to as ?patch in the remainder of this section.\n A patch resource MAY contain a triple [RDF11-CONCEPTS] ?patch rdf:type solid:Patch.\n A patch resource MUST contain at most one triple of the form ?patch solid:deletes ?deletions.\n A patch resource MUST contain at most one triple of the form ?patch solid:inserts ?insertions.\n A patch resource MUST contain at most one triple of the form ?patch solid:where ?conditions.\n 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 {}.\n \n\n 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:\n\n \n 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.\n A patch resource MUST contain a triple ?patch rdf:type solid:InsertDeletePatch.\n The ?insertions and ?deletions formulae MUST NOT contain variables that do not occur in the ?conditions formula.\n The ?insertions and ?deletions formulae MUST NOT contain blank nodes.\n \n\n Servers MUST respond with a 422 status code [RFC4918] if a patch document does not satisfy all of the above constraints.\n\n 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.\n\n Servers MUST process a patch resource against the target document as follows:\n\n \n Start from the RDF dataset in the target document, or an empty RDF dataset if the target resource does not exist yet.\n If ?conditions is non-empty, find all (possibly empty) variable mappings such that all of the resulting triples occur in the dataset.\n If no such mapping exists, or if multiple mappings exist, the server MUST respond with a 409 status code. [Source]\n The resulting variable mapping is propagated to the ?deletions and ?insertions formulae to obtain two sets of resulting triples.\n 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]\n The triples resulting from ?deletions are to be removed from the RDF dataset.\n 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.\n 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.\n \n \n\n \n Example: Applying an N3 patch.\n @prefix solid: .\n@prefix ex: .\n\n_:rename a solid:InsertDeletePatch;\n solid:where { ?person ex:familyName \"Garcia\". };\n solid:inserts { ?person ex:givenName \"Alex\". };\n solid:deletes { ?person ex:givenName \"Claudia\". }.\n 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.\n \n \n \n\n \n Deleting Resources\n \n Servers MUST support the HTTP DELETE method [RFC7231]. [Source] [Source]\n\n When a DELETE request targets storage\u2019s root container or its associated ACL resource, the server MUST respond with the 405 status code. Server MUST exclude the DELETE method in the HTTP response header Allow in response to requests to these resources [RFC7231]. [Source]\n\n When a contained resource is deleted, the server MUST also remove the corresponding containment triple. [Source]\n\n When a contained resource is deleted, the server MUST also delete the associated auxiliary resources (see the Auxiliary Resources section).\n\n 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]\n\n This section is non-normative.\n\n 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.\n\n Subsequent GET requests to the deleted resource usually result in a 404 or 410 status code, although HTTP allows others. [Source] [Source]\n\n Pertaining to events and loss of control mitigation: https://github.com/solid/specification/issues/41#issuecomment-534679278\n \n \n\n \n Resource Representations\n \n When a server creates a resource on HTTP PUT, POST or PATCH requests such that the request\u2019s 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]\n\n 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]\n \n \n \n \n\n \n Notifications\n \n A Solid server MUST conform to the LDN specification by implementing the Receiver parts to receive notifications and make Inbox contents available [LDN].\n\n A Solid client MUST conform to the LDN specification by implementing the Sender or Consumer parts to discover the location of a resource\u2019s Inbox, and to send notifications to an Inbox or to retrieve the contents of an Inbox [LDN].\n \n \n\n \n Live Update\n \n \n WebSockets\n \n For real-time collaborative communication between client and server about changes affecting a resource, this Solid Protocol uses the WebSocket API [W3C-HTML] and the WebSocket Protocol.\n\n Servers SHOULD implement the Solid WebSockets API [SOLID-WEBSOCKETS-API].\n\n Clients SHOULD implement the Solid WebSockets API [SOLID-WEBSOCKETS-API].\n\n The following is non-normative.\n\n The Solid WebSockets API (Unofficial Draft) has been the common protocol for many years. That draft does not include an authentication mechanism, and therefore the Protocol will transition to a new design. The new design is currently at Solid Notifications Protocol [SOLID-NOTIFICATIONS-PROTOCOL]. It is planned to include both security through authentication, and also common formats with other forms of real-time notification in the Solid ecosystem.\n\n Both client and server implementations should provide the existing protocol, and should transition to providing both protocols as the new one becomes available..\n\n The future directions of the protocol include moving from a simple one-bit notification that a resource has changed, requiring the client to reload the resource, to adding PATCH information in the notification so the client can calculate the new state immediately.\n \n \n \n \n\n \n Cross-Origin Resource Sharing\n \n 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.\n\n For cases where the other origins have their own access protection mechanism \u2014 like within Solid \u2014 the browser\u2019s 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.\n\n 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 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\u2019s allowed permissions. The next section describes how to achieve this through the right HTTP header configuration.\n\n \n CORS Server\n \n 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 [RFC7231].\n\n \n Note: CORS Protocol Blocking\n \n 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.\n \n \n\n Concretely, whenever a server 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 server 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 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-* headers themselves). A server MUST also support the HTTP OPTIONS method [RFC7231] such that it can respond appropriately to CORS preflight requests.\n\n Careful attention is warranted, especially because of the many edge cases. For instance, server 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). Servers 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.\n \n \n \n \n\n \n Identity\n \n \n WebID\n \n 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.\n \n \n \n \n\n \n Authentication\n \n \n Solid-OIDC\n \n 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].\n \n \n\n \n WebID-TLS\n \n This section is non-normative.\n\n 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.\n \n \n \n \n\n\n \n Authorization\n \n \n Web Access Control\n \n Web Access Control (WAC) is a decentralized cross-domain access control system providing a way for Linked Data systems to set authorization conditions on HTTP resources using the Access Control List (ACL) model. Server manages the association between a resource and an ACL resource, and applies the authorization conditions on requested operations. Authorizations are described using the ACL ontology to express and determine access privileges of a requested resource. Applications can discover authorization rules associated with a given resource, and to control such rules, as directed by an agent.\n\n Servers MUST conform to the Web Access Control specification [WAC].\n\n Clients MUST conform to the Web Access Control specification [WAC].\n\n [Source] [Source] Source] Source]\n \n \n \n \n\n \n HTTP Definitions\n \n \n HTTP Headers\n \n \n The Accept-Put Response Header\n \n 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].\n\n The syntax for Accept-Put, using the ABNF syntax defined in Section 1.2 of [RFC7231], is:\n\n Accept-Put = \"Accept-Put\" \":\" # media-range\n\n 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.\n\n 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.\n\n IANA Registration Template:\n\n The Accept-Put response header must be added to the permanent registry (see [RFC3864]).\n\n \n Header field name\n Accept-Put\n Applicable Protocol\n HTTP\n Author/Change controller\n W3C Solid Community Group\n Specification document\n This specification\n \n \n \n \n \n \n \n\n \n Considerations\n \n This section details security, privacy, accessibility and internationalization considerations.\n\n 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.\n\n \n Security Considerations\n \n This section is non-normative.\n\n While this section attempts to highlight a set of security considerations, it is not a complete list. Implementers are urged to seek the advice of security professionals when implementing mission critical systems using the technology outlined in this specification.\n\n Implementations are subject to the same security considerations that are found in HTTP/1.1 [RFC7230] and [RFC7231].\n\n Servers are strongly discouraged from assuming that HTTP request headers\u2019 field-values are valid or non-malicious. Servers are strongly encouraged to sanitize requests before processing them or incorporating them in messages sent to others. Servers are encouraged to reject bad requests that conflict with this specification's normative requirements. Servers are encouraged to apply normalization and canonicalization algorithms where applicable. Servers are encouraged to take measures to mitigate potential timing attacks attempting to discover resource existence even if requesting agent has no access to the resource(s). Servers are strongly discouraged from exposing information beyond the minimum amount necessary to enable a feature.\n\n Servers are strongly discouraged from assuming that the user agent is a regular Web browser, even when requests contain familiar values in headers such as User-Agent or Origin. Such an assumption could lead to incorrect conclusions about the security model of the application making the request, since the request might actually come from a non-browser actor unaffected by browser security constraints.\n\n 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\u2019s 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.\n\n 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.\n \n \n\n \n Privacy Considerations\n \n This section is non-normative.\n\n Servers are encouraged to use authorization techniques to prevent unwanted access to resources, rather than depending on the relative obscurity of their resource names.\n\n \n Identifiable Information\n \n In order to prevent leakage of non-resource data, servers are strongly discouraged from including identifiable information in error responses.\n \n \n \n \n\n \n Accessibility Considerations\n \n This section is non-normative.\n\n 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.\n\n 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].\n\n Accessible Applications: To help assistive technologies to provide a consistent user interface and understanding of the objects, it is strongly encouraged to follow the Accessible Rich Internet Applications [WAI-ARIA-1.2] recommendations. To enable semantic navigation, styling and interactive features in context of digital publishing, it is encouraged to follow the Digital Publishing WAI-ARIA Module 1.0 [DPUB-ARIA-1.0]. To support structured graphics such as charts, graphs, technical drawings and scientific diagrams, to assistive technologies in order improve accessibility of graphics or diagrams through detailed annotations, it is encouraged to follow the WAI-ARIA Graphics Module [GRAPHICS-ARIA-1.0].\n\n 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.\n\n 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].\n \n \n\n \n Internationalization Considerations\n \n This section is non-normative.\n\n 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:\n\n \n include links to navigate to different languages of the content;\n declare the base language of a document, indicate multiple languages and their directional flow \u2013 to help with translations;\n use Unicode character encoding, e.g., UTF-8, in data forms and text to ensure correct effects;\n check and minimise inappropriate cultural bias, and improve translatability;\n restrict markup use to structure and semantics.\n \n \n \n\n \n Security and Privacy Review\n \n This section is non-normative.\n\n These questions provide an overview of security and privacy considerations for this specification as guided by [SECURITY-PRIVACY-QUESTIONNAIRE].\n\n \n What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?\n ..\n\n Do features in your specification expose the minimum amount of information necessary to enable their intended uses?\n ..\n\n How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?\n ..\n\n How do the features in your specification deal with sensitive information?\n ..\n\n Do the features in your specification introduce new state for an origin that persists across browsing sessions?\n ..\n\n Do the features in your specification expose information about the underlying platform to origins?\n ..\n\n Does this specification allow an origin to send data to the underlying platform?\n ..\n\n Do features in this specification allow an origin access to sensors on a user\u2019s device?\n ..\n\n 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.\n ..\n\n Do features in this specification enable new script execution/loading mechanisms?\n ..\n\n Do features in this specification allow an origin to access other devices?\n ..\n\n Do features in this specification allow an origin some measure of control over a user agent\u2019s native UI?\n ..\n\n What temporary identifiers do the features in this specification create or expose to the web?\n ..\n\n How does this specification distinguish between behaviour in first-party and third-party contexts?\n ..\n\n How do the features in this specification work in the context of a browser\u2019s Private Browsing or Incognito mode?\n ..\n\n Does this specification have both \"Security Considerations\" and \"Privacy Considerations\" sections?\n ..\n\n Do features in your specification enable origins to downgrade default security protections?\n ..\n\n How does your feature handle non-\"fully active\" documents?\n ..\n \n \n \n\n \n Societal Impact Review\n \n This section is non-normative.\n\n These questions provide an overview of ethical considerations and societal impact as guided by [SOCIETAL-IMPACT-QUESTIONNAIRE].\n\n \n What kinds of activities could your specification become a part of that you are not designing for?\n ..\n\n What risks do you see in features of your specification being misused, or used differently from how you intended?\n ..\n\n Can users of the Web Platform choose not to use features of your specification?\n ..\n\n What groups of people are excluded from using features of your specification?\n ..\n\n What effect may features of your specification have on minority groups?\n ..\n\n What are the power dynamics at play in implementations of your specification?\n ..\n\n What points of centralization does your feature bring to the web platform?\n ..\n\n To what extent do the features in your specification result in increased power consumption or emissions?\n ..\n\n What is the expected lifetime of your specification feature(s)?\n ..\n\n Have you completed the Security & Privacy Self-review Questionnaire?\n Yes, in Security Considerations and Privacy Considerations.\n \n \n \n \n \n\n \n References\n \n \n Normative References\n \n \n [DC-TERMS]\n 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/\n [FETCH]\n Fetch Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://fetch.spec.whatwg.org/\n [IANA-MEDIA-TYPES]\n Media Types. IANA. URL: https://www.iana.org/assignments/media-types/\n [JSON-LD11]\n 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/\n [LDN]\n Linked Data Notifications. Sarven Capadisli; Amy Guy. W3C. 2 May 2017. W3C Recommendation. URL: https://www.w3.org/TR/ldn/\n [LDP]\n Linked Data Platform 1.0. Steve Speicher; John Arwe; Ashok Malhotra. W3C. 26 February 2015. W3C Recommendation. URL: https://www.w3.org/TR/ldp/\n [N3]\n Notation3. D\u00F6rthe Arndt; William Van Woensel;Dominik Tomaszuk; Gregg Kellogg. W3C. 5 September 2021. Draft Community Group Report. URL: https://w3c.github.io/N3/spec/\n [RDF-SCHEMA]\n RDF Schema 1.1. Dan Brickley; Ramanathan Guha. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/rdf-schema/\n [RDF11-CONCEPTS]\n 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/\n [RFC2119]\n 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\n [RFC3864]\n Registration Procedures for Message Header Fields. G. Klyne; M. Nottingham; J. Mogul. IETF. September 2004. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc3864\n [RFC3986]\n 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\n [RFC4918]\n 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\n [RFC5023]\n The Atom Publishing Protocol. J. Gregorio, Ed.; B. de hOra, Ed.. IETF. October 2007. Proposed Standard. URL: https://datatracker.ietf.org/doc/html/rfc5023\n [RFC5789]\n PATCH Method for HTTP. L. Dusseault; J. Snell. IETF. March 2010. Proposed Standard. URL: https://httpwg.org/specs/rfc5789.html\n [RFC6454]\n The Web Origin Concept. A. Barth. IETF. December 2011. Proposed Standard. URL: https://datatracker.ietf.org/doc/html/rfc6454\n [RFC6455]\n The WebSocket Protocol. I. Fette; A. Melnikov. IETF. December 2011. Proposed Standard. URL: https://datatracker.ietf.org/doc/html/rfc6455\n [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\n [RFC6892]\n The 'describes' Link Relation Type. E. Wilde. IETF. March 2013. Informational. URL: https://datatracker.ietf.org/doc/html/rfc6892\n [RFC7230]\n Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7230.html\n [RFC7231]\n Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7231.html\n [RFC7232]\n Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7232.html\n [RFC7233]\n Hypertext Transfer Protocol (HTTP/1.1): Range Requests. R. Fielding, Ed.; Y. Lafon, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7233.html\n [RFC7234]\n Hypertext Transfer Protocol (HTTP/1.1): Caching. R. Fielding, Ed.; M. Nottingham, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7234.html\n [RFC7235]\n Hypertext Transfer Protocol (HTTP/1.1): Authentication. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7235.html\n [RFC7540]\n Hypertext Transfer Protocol Version 2 (HTTP/2). M. Belshe; R. Peon; M. Thomson, Ed.. IETF. May 2015. Proposed Standard. URL: https://httpwg.org/specs/rfc7540.html\n [RFC8174]\n 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\n [RFC8288]\n Web Linking. M. Nottingham. IETF. October 2017. Proposed Standard. URL: https://httpwg.org/specs/rfc8288.html\n [SOLID-WEBSOCKETS-API]\n 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\n [SOLID-OIDC]\n SOLID-OIDC. Aaron Coburn; elf Pavlik; Dmitri Zagidulin. W3C Solid Community Group. 13 December 2021. W3C Editor's Draft. URL: https://solid.github.io/solid-oidc/\n [SPARQL11-QUERY]\n 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/\n [Turtle]\n RDF 1.1 Turtle. Eric Prud'hommeaux; Gavin Carothers. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/turtle/\n [W3C-HTML]\n HTML. W3C. 28 January 2021. W3C Recommendation. URL: https://www.w3.org/TR/html/\n [WAC]\n Web Access Control. Sarven Capadisli. W3C Solid Community Group. 11 July 2021. Draft. URL: https://solidproject.org/TR/wac\n [WEBARCH]\n 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/\n [WEBID]\n WebID 1.0. Andrei Sambra; St\u00E9phane Corlosquet. W3C WebID Community Group. 5 March 2014. W3C Editor\u2019s Draft. URL: https://www.w3.org/2005/Incubator/webid/spec/identity/\n \n \n \n\n \n Informative References\n \n \n [ATAG20]\n 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/\n [COGA-USABLE]\n Making content usable for people with cognitive and learning disabilities. Lisa Seeman-Horwitz; Rachael Bradley Montgomery; Steve Lee; Ruoxi Ran. W3C. 11 December 2020. W3C Working Draft. URL: https://www.w3.org/TR/coga-usable/\n [DPUB-ARIA-1.0]\n Digital Publishing WAI-ARIA Module 1.0. Matt Garrish; Tzviya Siegman; Markus Gylling; Shane McCarron. W3C. 14 December 2017. W3C Recommendation. URL: https://www.w3.org/TR/dpub-aria-1.0/\n [GRAPHICS-ARIA-1.0]\n 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/\n [SECURITY-PRIVACY-QUESTIONNAIRE]\n Self-Review Questionnaire: Security and Privacy. Theresa O'Connor; Peter Snyder. W3C. 23 March 2021. W3C Note. URL: https://www.w3.org/TR/security-privacy-questionnaire/\n [SOCIETAL-IMPACT-QUESTIONNAIRE]\n Self-Review Questionnaire: Societal Impact. Amy Guy. W3C. 13 Dec 2021. W3C Draft TAG Finding. URL: https://w3ctag.github.io/societal-impact-questionnaire/\n [SOLID-NOTIFICATIONS-PROTOCOL]\n Solid Notifications Protocol. Aaron Coburn; Sarven Capadisli. W3C Solid Community Group. 16 December 2021. W3C Editor\u2019s Draft. URL: https://solid.github.io/notifications/protocol\n [UAAG20]\n 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/\n [WAI-ARIA-1.2]\n Accessible Rich Internet Applications (WAI-ARIA) 1.2. Joanmarie Diggs; James Nurthen; Michael Cooper. W3C. 2 March 2021. W3C Candidate Recommendation. URL: https://www.w3.org/TR/wai-aria-1.2/\n [WCAG-3.0]\n W3C Accessibility Guidelines (WCAG) 3.0. Jeanne F Spellman; Rachael Bradley Montgomery; Shawn Lauriat; Michael Cooper. W3C. 21 January 2021. W3C Working Draft. URL: https://www.w3.org/TR/wcag-3.0/\n [WEBID-TLS]\n WebID Authentication over TLS. Henry Story; St\u00E9phane Corlosquet; Andrei Sambra. W3C WebID Community Group. W3C Editor's Draft. URL: https://www.w3.org/2005/Incubator/webid/spec/tls/\n \n \n \n \n \n "^^ . +_:bnode8 . +_:bnode8 _:bnode37 . +_:bnode37 . +_:bnode37 _:bnode38 . +_:bnode38 . +_:bnode38 _:bnode39 . +_:bnode39 . +_:bnode39 _:bnode40 . +_:bnode40 . +_:bnode40 _:bnode41 . +_:bnode41 . +_:bnode41 _:bnode42 . +_:bnode42 . +_:bnode42 _:bnode43 . +_:bnode43 . +_:bnode43 _:bnode44 . +_:bnode44 . +_:bnode44 _:bnode45 . +_:bnode45 . +_:bnode45 _:bnode46 . +_:bnode46 . +_:bnode46 _:bnode47 . +_:bnode47 . +_:bnode47 _:bnode48 . +_:bnode48 . +_:bnode48 _:bnode49 . +_:bnode49 . +_:bnode49 _:bnode50 . +_:bnode50 . +_:bnode50 . + _:bnode8 . diff --git a/respec.html b/respec.html new file mode 100644 index 00000000..26471d92 --- /dev/null +++ b/respec.html @@ -0,0 +1,119 @@ + + + + + Replace me with a real title + + + + +
+
+

Stuff

+

+[[ACTIVITYPUB]] +[[ACTIVITYSTREAMS-CORE]] +[[ACTIVITYSTREAMS-VOCABULARY]] +[[ATAG20]] +[[COGA-USABLE]] +[[DC-TERMS]] +[[DPUB-ARIA-1.0]] +[[EARL10-Guide]] +[[EARL10-Schema]] +[[ETHICAL-WEB-PRINCIPLES]] +[[FETCH]] +[[FOAF]] +[[GRAPHICS-ARIA-1.0]] +[[IANA-MEDIA-TYPES]] +[[INFRA]] +[[JSON-LD11]] +[[JSON-LD]] +[[LDN]] +[[LDP]] +[[OAUTH-POP-KEY-DISTRIBUTION]] +[[ODRL-MODEL]] +[[POWDER-DR]] +[[prov-o]] +[[qa-handbook]] +[[qaframe-spec]] +[[RDF-SCHEMA]] +[[RDF11-CONCEPTS]] +[[RFC2119]] +[[RFC3864]] +[[RFC3986]] +[[RFC5023]] +[[RFC5789]] +[[RFC6454]] +[[RFC6455]] +[[RFC6570]] +[[RFC6749]] +[[RFC6892]] +[[RFC7230]] +[[RFC7231]] +[[RFC7232]] +[[RFC7233]] +[[RFC7234]] +[[RFC7235]] +[[RFC7540]] +[[RFC8174]] +[[RFC8288]] +[[RFC8446]] +[[RFC9110]] +[[SECURITY-PRIVACY-QUESTIONNAIRE]] +[[skos-reference]] +[[SOCIETAL-IMPACT-QUESTIONNAIRE]] +[[SOLID-OIDC]] +[[SPARQL11-QUERY]] +[[SPARQL11-UPDATE]] +[[spec-variability]] +[[test-metadata]] +[[TURTLE]] +[[UAAG20]] +[[VCARD-RDF]] +[[W3C-HTML]] +[[W3C-PROCESS]] +[[w3c-process]] +[[WAC]] +[[WAI-ARIA-1.2]] +[[WCAG-3.0]] +[[WEBARCH]] +[[WEBID-TLS]] +[[WEBID]] +[[WEBSOCKETS]] +[[WEBSUB]] +[[XMLSCHEMA11-2]] +

+ +
+ + diff --git a/test.html b/test.html new file mode 100644 index 00000000..f3f0cae1 --- /dev/null +++ b/test.html @@ -0,0 +1,364 @@ + + + + + Solid Technical Reports + + + + + + + + +
+
+ +
+
+ +
+
+

Solid Technical Reports

+ +

Living Document,

+ +
+
This version
+
https://solidproject.org/TR/
+
+ +
+
Editors
+
Sarven Capadisli
+
+ +
+
Created
+
+
+ +
+
Published
+
+
+ +
+
Modified
+
+
+ +
+
Repository
+
GitHub
+
Issues
+
+ +

MIT License. Copyright © 2019–2023 W3C Solid Community Group.

+ +
+
+

Abstract

+
+

Hi! We’re the Solid Community Group (CG) of the W3C. The purpose of this document is to help readers orient themselves with the activities of the Solid CG.

+ +

The CG has a charter.

+ +

The Solid CG’s technical reports (TR) include specifications, use cases and requirements, best practices and guidelines, primers and notes about the Solid ecosystem.

+
+
+ +
+

Work Items

+
+

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 information in these documents may be subject to change, therefore please see each document’s publication status and versions for further details. You are invited to contribute any feedback, comments, or questions you might have.

+ +
+

Linked Data aware applications can view the Solid Technical Reports Knowledge Graph.

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Technical Reports
Work ItemRepositoryCurrent Stage
Solid Protocolhttps://github.com/solid/specificationVersion 0.10.0
Solid WebID Profilehttps://github.com/solid/webid-profileVersion 1.0.0, Editor's Draft
Solid OIDChttps://github.com/solid/solid-oidcVersion 0.1.0
HTTPSig Authentication for Solidhttps://github.com/solid/httpsigCG-DRAFT Unofficial
Web Access Controlhttps://github.com/solid/web-access-control-spec/Version 1.0.0-cr.1
Access Control Policyhttps://github.com/solid/authorization-panelVersion 0.9.0
Solid Application Interoperabilityhttps://github.com/solid/data-interoperability-panelEditor’s Draft
Shape Treeshttps://github.com/shapetrees/specificationEditor’s Draft
Solid DID Methodhttps://github.com/solid/did-method-solidUnofficial Draft
Solid Notifications Protocolhttps://github.com/solid/notificationsVersion 0.2.0
EventSourceChannel2023https://github.com/solid/notificationsVersion 1.0.0
LDNChannel2023https://github.com/solid/notificationsVersion 1.0.0, Editor’s Draft
StreamingHTTPChannel2023https://github.com/solid/notificationsVersion 0.1, Editor’s Draft
WebSocketChannel2023https://github.com/solid/notificationsEditor’s Draft
WebhookChannel2023https://github.com/solid/notificationsVersion 0.1, Editor’s Draft
Solid Chathttps://github.com/solid/chatVersion 1.0.0, Editor's Draft
Solid QAhttps://github.com/solid/specificationVersion 0.2.0
Solid OIDC Primerhttps://github.com/solid/solid-oidcVersion 0.1.0
Authorization Use Cases and Requirementshttps://github.com/solid/authorization-panelUnofficial Draft
Authorization Use Cases Surveyhttps://github.com/solid/authorization-panelUnofficial Draft
Solid Application Interoperability: Application Primerhttps://github.com/solid/data-interoperability-panelUnofficial Draft
Solid Application Interoperability: Authorization Agent Primerhttps://github.com/solid/data-interoperability-panelUnofficial Draft
+ +

The Test Suites support the Technical Reports:

+ + + + + + + + + + + + + + + + + + + + + + +
Test Suites
Work ItemRepositoryCurrent Stage
Test Suitehttps://github.com/solid-contrib/test-suiteTBD
Specification Testshttps://github.com/solid-contrib/specification-testsTBD
+ +
+

Notification Channel Type Registry

+
+

In order to help with the discovery of notification channel types that can be used with the Solid Notifications Protocol, it is encouraged to register them for maximum global interoperability.

+ +

To update the registry table an implementer MUST submit a modification request for this index as a pull request at the https://github.com/solid/specification repository, which includes the following information:

+ +
+
Specification
+
The URL of the document that specifies the notification channel type.
+
Name
+
The name of the notification channel type.
+
IRI
+
The IRI of the notification channel type.
+
Description
+
A short English description of the notification channel type.
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Notification Channel Types
SpecificationIRIDescription
EventSourceChannel2023http://www.w3.org/ns/solid/notifications#EventSourceChannel2023A notification channel type that uses the EventSource Web API.
LDNChannel2023http://www.w3.org/ns/solid/notifications#LDNChannel2023A notification channel type that uses the Linked Data Notifications protocol.
StreamingHTTPChannel2023http://www.w3.org/ns/solid/notifications#StreamingHTTPChannel2023A notification channel type that uses the Fetch API.
WebhookChannel2023http://www.w3.org/ns/solid/notifications#WebhookChannel2023A notification channel type that uses Webhooks.
WebSocketChannel2023http://www.w3.org/ns/solid/notifications#WebSocketChannel2023A notification channel type that uses the WebSocket API.
+
+
+
+
+ +
+

Participate

+
+

It’s easy to join the CG if you’d like to contribute to the Solid project. Please note that in order to join, you’ll need to request a W3C account if you don’t already have one.

+ +

We publish a list of current participants on our W3C page.

+ +

The Solid CG conducts all technical work in public, mainly in various repositories of the Solid organisation but also in text chat, periodic teleconferences and face-to-face meetings.

+
+
+ +
+

Code of Conduct

+
+

Please note that all work and communication within the Solid CG is covered by the Solid Code of Conduct as well as the Positive Work Environment at W3C: Code of Ethics and Professional Conduct.

+
+
+
+
+
+ + diff --git a/wac/index.html b/wac/index.html new file mode 100644 index 00000000..69ce7a71 --- /dev/null +++ b/wac/index.html @@ -0,0 +1,1583 @@ + + + + Web Access Control + + + + + + + + + + +
+

+

Web Access Control

+

Editor’s Draft,

+ +
+

CC0 To the extent possible under law, the editors have waived all copyright +and related or neighboring rights to this work. +In addition, as of 12 May 2020, +the editors have made this specification available under the Open Web Foundation Agreement Version 1.0, +which is available at http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0. +Parts of this work may be from another specification document. If so, those parts are instead covered by the license of that specification document.

+
+
+
+

Abstract

+

This document introduces a mechanism + + for fine-grained access control to resources on the Web.

+
+
+ +
+

Status of This Document

+ This document is an incomplete 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.

+

1. Introduction

+

Write Introduction section.

+
+
+

Conformance

+

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. + The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” + in the normative parts of this document + are to be interpreted as described in RFC 2119. + However, for readability, + these words do not appear in all uppercase letters in this specification.

+

All of the text of this specification is normative + except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

+

Examples in this specification are introduced with the words “for example” + or are set apart from the normative text with class="example", like this:

+
This is an example of an informative example.
+

Informative notes begin with the word “Note” + and are set apart from the normative text with class="note", like this:

+

Note, this is an informative note.

+
+ +

References

+

Normative References

+
+
[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 +
+

Issues Index

+
+
Write Introduction section. ↵
+
\ No newline at end of file diff --git a/webid-oidc/index.html b/webid-oidc/index.html new file mode 100644 index 00000000..9df9dd04 --- /dev/null +++ b/webid-oidc/index.html @@ -0,0 +1,1578 @@ + + + + WebID-OIDC + + + + + + + + + + +
+

+

WebID-OIDC

+

Editor’s Draft,

+
+
+
This version: +
https://solid.github.io/specification/webid-oidc/ +
Issue Tracking: +
GitHub +
Editors: +
Dmitri Zagidulin +
Justin Bingham +
+
+
+

CC0 To the extent possible under law, the editors have waived all copyright +and related or neighboring rights to this work. +In addition, as of 12 May 2020, +the editors have made this specification available under the Open Web Foundation Agreement Version 1.0, +which is available at http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0. +Parts of this work may be from another specification document. If so, those parts are instead covered by the license of that specification document.

+
+
+
+

Abstract

+

This document introduces an authentication mechanism based on the OpenID + + Connect protocol.

+
+
+ +
+

Status of This Document

+ This document is an incomplete 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.

+

1. Introduction

+

Write Introduction section.

+
+
+

Conformance

+

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. + The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” + in the normative parts of this document + are to be interpreted as described in RFC 2119. + However, for readability, + these words do not appear in all uppercase letters in this specification.

+

All of the text of this specification is normative + except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

+

Examples in this specification are introduced with the words “for example” + or are set apart from the normative text with class="example", like this:

+
This is an example of an informative example.
+

Informative notes begin with the word “Note” + and are set apart from the normative text with class="note", like this:

+

Note, this is an informative note.

+
+ +

References

+

Normative References

+
+
[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 +
\ No newline at end of file diff --git a/webid-tls/index.html b/webid-tls/index.html new file mode 100644 index 00000000..20942533 --- /dev/null +++ b/webid-tls/index.html @@ -0,0 +1,1583 @@ + + + + WebID-TLS + + + + + + + + + + +
+

+

WebID-TLS

+

Editor’s Draft,

+ +
+

CC0 To the extent possible under law, the editors have waived all copyright +and related or neighboring rights to this work. +In addition, as of 12 May 2020, +the editors have made this specification available under the Open Web Foundation Agreement Version 1.0, +which is available at http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0. +Parts of this work may be from another specification document. If so, those parts are instead covered by the license of that specification document.

+
+
+
+

Abstract

+

This document introduces a mechanism for authenticating agents with a WebID + + through the OpenID Connect protocol.

+
+
+ +
+

Status of This Document

+ This document is an incomplete 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.

+

1. Introduction

+

Write Introduction section.

+
+
+

Conformance

+

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. + The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” + in the normative parts of this document + are to be interpreted as described in RFC 2119. + However, for readability, + these words do not appear in all uppercase letters in this specification.

+

All of the text of this specification is normative + except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

+

Examples in this specification are introduced with the words “for example” + or are set apart from the normative text with class="example", like this:

+
This is an example of an informative example.
+

Informative notes begin with the word “Note” + and are set apart from the normative text with class="note", like this:

+

Note, this is an informative note.

+
+ +

References

+

Normative References

+
+
[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 +
+

Issues Index

+
+
Write Introduction section. ↵
+
\ No newline at end of file