From d5300c9078c815bb9743b0eb6c5c3520ae5e7a82 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Sun, 19 Jul 2026 12:06:08 +0200 Subject: [PATCH 1/7] Add creator definition and requirements to record and protect creator Resolves https://github.com/solid/specification/issues/315 , https://github.com/solid/specification/issues/66 --- ED/protocol.html | 32 ++++++++++++++++++++++++++++---- 1 file changed, 28 insertions(+), 4 deletions(-) diff --git a/ED/protocol.html b/ED/protocol.html index eed02d3f..4db94eaa 100644 --- a/ED/protocol.html +++ b/ED/protocol.html @@ -225,7 +225,7 @@

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 @@

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
@@ -529,6 +528,8 @@

Terminology

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,8 @@

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.

+

When a server wants to track 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]

+

Servers MUST NOT allow HTTP POST, PUT and 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]

@@ -1143,6 +1146,7 @@

Privacy Considerations

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

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

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

+

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 minimise disclosure beyond what is necessary. Servers can honour an agent’s request not to be attributed, or to have an existing attribution removed, for example, to meet data protection obligations.

@@ -1311,6 +1315,26 @@

Changelog

#server-patch-n3-blank-nodes-syntax Add requirement for server to constrain blank node usage in N3 Patch syntax. + + 4 + #creator + Add definition of creator. + + + 4 + #server-description-resource-creator + Add requirement for server to record the creator in the associated description resource. + + + 4 + #server-protect-creator + Add requirement for server to protect creator statements in a description resource. + + + 2 + #creator-privacy + Add advisement for creator privacy. + From 126b1960e6a82941c68c5457d570111cbb03ae53 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Mon, 20 Jul 2026 08:05:42 +0200 Subject: [PATCH 2/7] Minor. Link to creator --- ED/protocol.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ED/protocol.html b/ED/protocol.html index 4db94eaa..3c0fe244 100644 --- a/ED/protocol.html +++ b/ED/protocol.html @@ -837,7 +837,7 @@

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 rule that is used for the subject resource with which the description resource is associated.

When a server wants to track 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]

-

Servers MUST NOT allow HTTP POST, PUT and 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 POST, PUT and 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]

From 08cf553e4a4c10b66be70caf6584510aaf00d620 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Mon, 20 Jul 2026 08:27:45 +0200 Subject: [PATCH 3/7] Clarify creator-privacy --- ED/protocol.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ED/protocol.html b/ED/protocol.html index 3c0fe244..fedaae97 100644 --- a/ED/protocol.html +++ b/ED/protocol.html @@ -1146,7 +1146,7 @@

Privacy Considerations

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

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

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

-

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 minimise disclosure beyond what is necessary. Servers can honour an agent’s request not to be attributed, or to have an existing attribution removed, for example, to meet data protection obligations.

+

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.

From 9452d01a146450caabafac361f35eb39e4c7830a Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Tue, 21 Jul 2026 12:15:36 +0200 Subject: [PATCH 4/7] Use "records" consistently for trigger as observable behaviour --- ED/protocol.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ED/protocol.html b/ED/protocol.html index fedaae97..cca3de10 100644 --- a/ED/protocol.html +++ b/ED/protocol.html @@ -836,7 +836,7 @@

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.

-

When a server wants to track 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]

+

When a server records 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]

Servers MUST NOT allow HTTP POST, PUT and 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]

From 2068d82e32fe4298b0b4ab2bb1fb474cf31d200a Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Fri, 24 Jul 2026 10:41:00 +0200 Subject: [PATCH 5/7] Move server-protect-creator to writing-resources and drop POST --- ED/protocol.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ED/protocol.html b/ED/protocol.html index cca3de10..9d0bb88b 100644 --- a/ED/protocol.html +++ b/ED/protocol.html @@ -837,7 +837,6 @@

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 rule that is used for the subject resource with which the description resource is associated.

When a server records 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]

-

Servers MUST NOT allow HTTP POST, PUT and 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]

@@ -881,6 +880,7 @@

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]

From 45ac3d27f9c5e41f092e3b512d8e52cc4ed78569 Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Fri, 24 Jul 2026 11:29:44 +0200 Subject: [PATCH 6/7] Replace records with discloses Co-authored-by: Christoph Braun --- ED/protocol.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ED/protocol.html b/ED/protocol.html index 9d0bb88b..335fd6a7 100644 --- a/ED/protocol.html +++ b/ED/protocol.html @@ -836,7 +836,7 @@

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.

-

When a server records 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]

+

When a server discloses 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]

From 28804abe2f0e40904763d4011693129083e2b4fc Mon Sep 17 00:00:00 2001 From: Sarven Capadisli Date: Fri, 24 Jul 2026 11:55:19 +0200 Subject: [PATCH 7/7] Replace discloses with indicates Co-authored-by: Christoph Braun --- ED/protocol.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ED/protocol.html b/ED/protocol.html index 335fd6a7..ef9b7e0a 100644 --- a/ED/protocol.html +++ b/ED/protocol.html @@ -836,7 +836,7 @@

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.

-

When a server discloses 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]

+

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]