Solid Protocol
-Editor’s Draft,
+Editor’s Draft,
More details about this document
-
@@ -260,7 +260,7 @@
Solid Protocol
- Modified - +
- Feedback @@ -511,8 +511,7 @@
- storage
- A storage is a space of URIs that affords agents controlled access to resources.
- Solid app @@ -529,6 +528,8 @@
- 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]. +
- creator +
- A creator is an agent that is attributed with the creation of a resource. A creator is first set at resource creation time and does not change.
- 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 @@ -835,6 +836,7 @@
Terminology
This section is non-normative.
The Solid Protocol specification defines the following terms. These terms are referenced throughout this specification.
--
-
+
Terminology
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 a server indicates the creator of a resource created by a successful request from an authenticated agent, the server MUST include a statement with the dcterms:creator property, whose subject is the created resource and whose object is the authenticated agent, in the associated description resource. [Source][Source]
Clients can discover resources that are described by description resources by making an HTTP HEAD or GET request on the target URL, and checking the HTTP Link header field with a rel value of describes (inverse of the describedby relation) [RFC6892].
Writing Resources
Servers MUST allow creation of new resources by a POST request to a URI path ending with /. Servers MUST create resources with URI paths ending with /{id} in container /. [Source] [Source]
When a POST method request targets a resource without an existing representation, the server MUST respond with the 404 status code. [Source]
When a PUT or PATCH request targets an auxiliary resource, the server MUST create or update it. [Source]
Servers MUST NOT allow HTTP PUT or PATCH to update creator statements in a description resource; if the server receives such a request, it MUST respond with a 409 status code. [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]
Privacy Considerations
To prevent leakage of non-resource data, servers are strongly discouraged from including identifiable information in error responses.
The decision to include or exclude any information (e.g., storage, inbox) in a WebID Profile served from a Solid storage lies with the Agent controlling the WebID (or the URI owner). A URI allocated to a WebID in a Solid storage does not imply that the WebID is the storage owner. Owners of a WebID hosted from Solid storage are encouraged to consider information related to themselves that could be readable from other resources in the storage, even if that information (e.g., storage, inbox) is not part of the WebID Profile itself (see Storage Owner and URI Ownership and Self-describing Resources.)
+The creator of a resource reveals information about an agent’s identity and activity. Disclosure of the creator through a description resource is subject to the same authorization rule as the subject resource. Servers are encouraged to make their attribution practice known to agents. URI owners can take measures beyond what is defined by this specification to determine what information is retained, for example, removing an existing attribution to meet data protection obligations.
Servers are encouraged to respond with the 451 status code and, where appropriate, identify the entities implementing the blocking to provide transparency in cases where legal or public policy issues affect server operations, as outlined in Report Legal Obstacles, while avoiding the disclosure of sensitive legal or privacy-related details [RFC 7725].