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 an HTTP Link header field with rel="http://purl.org/dc/terms/#creator" targeting the WebID of the authenticated agent. [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].
Security Considerations
- + 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 is401 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
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 an HTTP Link header field 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].