Solid Protocol
-Editor’s Draft, 2021-06-16
+Editor’s Draft, 2021-07-07
- This version @@ -185,7 +185,7 @@
- Modified - +
http://www.w3.org/ns/auth/acl#accessControl
+ https://www.w3.org/ns/iana/link-relations/relation#aclhttps://www.w3.org/ns/iana/link-relations/relation#describedbyhttps://www.w3.org/ns/iana/link-relations/relation#describes- [W3C-HTML]
- HTML. W3C. 28 January 2021. W3C Recommendation. URL: https://www.w3.org/TR/html/
- [WAC] -
- Web Access Control. W3C Solid Community Group. W3C Editor's Draft. URL: https://solid.github.io/web-access-control-spec/ +
- Web Access Control. Sarven Capadisli. W3C Solid Community Group. W3C Editor's Draft. URL: https://solid.github.io/web-access-control-spec/
- [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] -
- Web Identity and Discovery. W3C Editor's Draft. URL: https://www.w3.org/2005/Incubator/webid/spec/identity/ +
- WebID 1.0. Henry Story; Andrei Sambra; Stéphane Corlosquet. W3C Editor’s Draft. URL: https://www.w3.org/2005/Incubator/webid/spec/identity/
Editor’s Draft, 2021-06-16
-
@@ -487,12 +487,6 @@
Storage
Note: When a server supports multiple storages, there must be complete trust between its owners.
[Source][Source][Source][Source]
- -When using Web Access Control (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]
@@ -510,15 +504,13 @@Resource Containment
Auxiliary Resources
Solid has the notion of auxiliary resources to provide supplementary information such as descriptive metadata, authorization policies, 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.
+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.
-Auxiliary resources are represented as RDF documents [RDF11-CONCEPTS].
+Server manages the association between a subject resource and auxiliary resources defined by this specification. The lifecycle of auxiliary resources defined by this specification depend on the lifeycle of the subject resource that they are associated with.
-Note: Where applicable, to promote self-describing resources, implementations and authors are encouraged to use the subject resource instead of the associated auxiliary resource.
+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.
-Servers exposing auxiliary resources that are defined by this specification MUST have the same "origin" for both the resource and the associated auxiliary resource [RFC6454].
- -As per Deleting Resources, the lifecycle of auxiliary resources defined by this specification depend on the lifecycle of the subject resource.
+Note: Where applicable, to promote self-describing resources, implementations and authors are encouraged to use the subject resource instead of the associated auxiliary resource.
This specification defines the following types of auxiliary resources:
@@ -557,6 +549,7 @@Auxiliary Resources
Auxiliary Resources
Web Access Control
An auxiliary resource of type Web Access Control provides access control description of a subject resource (Web Access Control).
- -Servers MUST NOT directly associate more than one ACL auxiliary resource to a subject resource.
Description 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 policy that is used for the subject resource with which the description resource is associated.
+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].
Writing Resources
Clients MAY use the HTTP If-None-Match header with a value of "*" to prevent an unsafe request method (e.g., PUT, PATCH) from inadvertently modifying an existing representation of the target resource when the client believes that the resource does not have a current representation. [Source] [Source]
Servers MAY use the HTTP ETag header with a strong validator for RDF bearing representations in order to encourage clients to opt-in to using the If-Match header in their requests.
When using Web Access Control (Web Access Control):
- -To create or update an ACL resource (see Web Access Control), an acl:agent MUST have acl:Control privileges per the ACL inheritance algorithm on the resource directly associated with it. [Source]
Deleting Resources
When a 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 (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 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
@@ -729,9 +710,9 @@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.
+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.
+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
@@ -755,10 +736,6 @@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.
- -When using Web Access Control (Web Access Control):
- -Agents accessing non-public Solid resources need to authenticate with a WebID.
Authorization
Web Access Control
Web Access Control (WAC) is a decentralized cross-domain access control system. The WAC mechanism is concerned with giving access to agents denoted by a 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 agents with modes of access on target resources.
+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].
@@ -922,7 +899,7 @@Security Considerations
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 Web Access Control. 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 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.