Skip to content

Add creator definition and requirements to record and protect creator #807

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
csarven wants to merge 7 commits into
base: main
Choose a base branch
from
+28 −4
Open

Add creator definition and requirements to record and protect creator #807

Changes from 1 commit
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
d5300c9
Add creator definition and requirements to record and protect creator
csarven Jul 19, 2026
126b196
Minor. Link to creator
csarven Jul 20, 2026
08cf553
Clarify creator-privacy
csarven Jul 20, 2026
9452d01
Use "records" consistently for trigger as observable behaviour
csarven Jul 21, 2026
2068d82
Move server-protect-creator to writing-resources and drop POST
csarven Jul 24, 2026
45ac3d2
Replace records with discloses
csarven Jul 24, 2026
28804ab
Replace discloses with indicates
csarven Jul 24, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 28 additions & 4 deletions ED/protocol.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -225,7 +225,7 @@
<article about="" typeof="schema:Article">
<div class="head">
<h1 property="schema:name">Solid Protocol</h1>
<p id="w3c-state">Editor’s Draft, <time datetime="2025-04-12T00:00:00Z">2025-04-12</time></p>
<p id="w3c-state">Editor’s Draft, <time datetime="2026-07-19T00:00:00Z">2026-07-19</time></p>
<details open="">
<summary>More details about this document</summary>
<dl id="document-identifier">
Expand Down Expand Up @@ -260,7 +260,7 @@ <h1 property="schema:name">Solid Protocol</h1>
</dl>
<dl id="document-modified">
<dt>Modified</dt>
<dd><time content="2025-04-12T00:00:00Z" datatype="xsd:dateTime" datetime="2025-04-12T00:00:00Z" property="schema:dateModified">2025-04-12</time></dd>
<dd><time content="2026-07-19T00:00:00Z" datatype="xsd:dateTime" datetime="2026-07-19T00:00:00Z" property="schema:dateModified">2026-07-19</time></dd>
</dl>
<dl id="document-feedback">
<dt>Feedback</dt>
Expand Down Expand Up @@ -511,8 +511,7 @@ <h3 property="schema:name skos:prefLabel">Terminology</h3>
<div datatype="rdf:HTML" property="schema:description">
<p><em>This section is non-normative.</em></p>
<p property="skos:definition">The Solid Protocol specification defines the following terms. These terms are referenced throughout this specification.</p>
<p><span rel="skos:hasTopConcept"><span resource="#storage"></span><span resource="#solid-app"></span><span resource="#uniform-resource-identifier"></span><span resource="#resource"></span><span resource="#container-resource"></span><span resource="#root-container"></span><span resource="#resource-metadata"></span><span resource="#agent"></span><span resource="#owner"></span><span resource="#origin"></span><span resource="#read-operation"></span><span resource="#write-operation"></span><span resource="#append-operation"></span></span></p>
<dl>
<dl rel="skos:hasTopConcept">
<dt about="#storage" property="skos:prefLabel" typeof="skos:Concept"><dfn id="storage">storage</dfn></dt>
<dd about="#storage" property="skos:definition">A storage is a space of URIs that affords agents controlled access to resources.</dd>
<dt about="#solid-app" property="skos:prefLabel" typeof="skos:Concept"><dfn id="solid-app">Solid app</dfn></dt>
Expand All @@ -529,6 +528,8 @@ <h3 property="schema:name skos:prefLabel">Terminology</h3>
<dd about="#resource-metadata" property="skos:definition">Resource metadata encompasses data about resources described by means of RDF statements [<cite><a class="bibref" href="#bib-rdf11-concepts">RDF11-CONCEPTS</a></cite>].</dd>
<dt about="#agent" property="skos:prefLabel" typeof="skos:Concept"><dfn id="agent">agent</dfn></dt>
<dd about="#agent" property="skos:definition">An agent is a person, social entity, or software identified by a URI; e.g., a WebID denotes an agent [<cite><a class="bibref" href="#bib-webid">WEBID</a></cite>].</dd>
<dt about="#creator" property="skos:prefLabel" typeof="skos:Concept"><dfn id="creator">creator</dfn></dt>
<dd about="#creator" property="skos:definition">A creator is an <a href="#agent">agent</a> that is attributed with the creation of a resource. A creator is first set at resource creation time and does not change.</dd>
<dt about="#owner" property="skos:prefLabel" typeof="skos:Concept"><dfn id="owner">owner</dfn></dt>
<dd about="#owner" property="skos:definition">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.</dd>
<dt about="#origin" property="skos:prefLabel" typeof="skos:Concept"><dfn id="origin">origin</dfn></dt>
Expand Down Expand Up @@ -835,6 +836,8 @@ <h4 property="schema:name">Description Resource</h4>
<p>An auxiliary resource of type <em>Description Resource</em> provides a description of a subject resource.</p>
<p about="" id="server-description-resource-max" rel="spec:requirement" resource="#server-description-resource-max"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUSTNOT">MUST NOT</span> directly associate more than one description resource to a subject resource.</span></p>
<p about="" id="server-description-resource-authorization" rel="spec:requirement" resource="#server-description-resource-authorization"><span property="spec:statement">When an HTTP request targets a description resource, the <span rel="spec:requirementSubject" resource="#Server">server</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> apply the authorization rule that is used for the subject resource with which the description resource is associated.</span></p>
<p about="" id="server-description-resource-creator" rel="spec:requirement" resource="#server-description-resource-creator"><span property="spec:statement">When a <span rel="spec:requirementSubject" resource="#Server">server</span> wants to track the <a href="#creator">creator</a> of a resource created by a successful request from an authenticated <a href="#agent">agent</a>, the server <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> include a statement with the <code>dcterms:creator</code> property, whose subject is the created resource and whose object is the authenticated agent, in the associated description resource.</span> [<a href="https://github.com/solid/specification/issues/315" rel="cito:citesAsSourceDocument">Source</a>][<a href="https://github.com/solid/specification/issues/66" rel="cito:citesAsSourceDocument">Source</a>]</p>
Comment thread
uvdsl marked this conversation as resolved.
Outdated
<p about="" id="server-protect-creator" rel="spec:requirement" resource="#server-protect-creator"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUSTNOT">MUST NOT</span> allow HTTP <code>POST</code>, <code>PUT</code> and <code>PATCH</code> to update creator statements in a description resource; if the server receives such a request, it <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> respond with a <code>409</code> status code.</span> [<a href="https://github.com/solid/specification/issues/315" rel="cito:citesAsSourceDocument">Source</a>]</p>
Comment thread
csarven marked this conversation as resolved.
Outdated
<p about="" id="client-link-describes" rel="spec:requirement" resource="#client-link-describes">Clients can discover resources that are described by description resources by making an HTTP <code>HEAD</code> or <code>GET</code> request on the target URL, and checking the HTTP <code>Link</code> header field with a <code>rel</code> value of <code>describes</code> (inverse of the <code>describedby</code> relation) [<cite><a class="bibref" href="#bib-rfc6892">RFC6892</a></cite>].</p>
</div>
</section>
Expand Down Expand Up @@ -1143,6 +1146,7 @@ <h3 property="schema:name">Privacy Considerations</h3>
<p about="" id="authorization-resources" rel="spec:advisement" resource="#authorization-resources"><span property="spec:statement">Servers are <span rel="spec:advisementLevel" resource="spec:Encouraged">encouraged</span> to use authorization techniques to prevent unwanted access to resources, rather than depending on the relative obscurity of their resource names.</span></p>
<p about="" id="identifiable-information-error-responses" rel="spec:advisement" resource="#identifiable-information-error-responses"><span property="spec:statement">To prevent leakage of non-resource data, servers are <span rel="spec:advisementLevel" resource="spec:StronglyDiscouraged">strongly discouraged</span> from including identifiable information in error responses.</span></p>
<p about="" id="webid-profile-privacy" rel="spec:advisement" resource="#webid-profile-privacy"><span property="spec:statement">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 <span rel="spec:advisementLevel" resource="spec:Encouraged">encouraged</span> 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 <a href="#storage-owner-uri-ownership">Storage Owner and URI Ownership</a> and <a href="#self-describing-resources">Self-describing Resources</a>.)</span></p>
<p about="" id="creator-privacy" rel="spec:advisement" resource="#creator-privacy"><span property="spec:statement">The <a href="#creator">creator</a> 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 <span rel="spec:advisementLevel" resource="spec:Encouraged">encouraged</span> to minimise disclosure beyond what is necessary. Servers <span rel="spec:advisementLevel" resource="spec:Can">can</span> honour an agent’s request not to be attributed, or to have an existing attribution removed, for example, to meet data protection obligations.</span></p>

@elf-pavlik elf-pavlik Jul 20, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it mean that the use case of recording the creator without disclosing it to everyone who can read the subject resource remains unsolved?

@csarven csarven Jul 20, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. I've clarified creator-privacy to be more concrete on what is intended, removed parts that were intentionally left open for features in the future, and added a bit on transparency.

Correct, that use case is not addressed. That's deliberate. Attribution is either recorded in the description resource and disclosed under the subject resource's authorization rule, or not recorded at all. Consistent with the Protocol.

This feature is for readers. Auditing or moderation by URI owners or server operators doesn't (particularly) require interop, since servers can keep internal records outside the protocol any way. Client-asserted authorship is forgeable, the server-asserted creator statement is not, and so the latter is trustable, and it's only useful if readers can see it. Disclosure to the resource's readership is the feature, not a side effect. This is a common practice e.g., commit log or wiki history.

@elf-pavlik elf-pavlik Jul 21, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://solidproject.org/TR/acp#matcher has acp:CreatorAgent

I recall commonly requested feature that access policies may have special case if agent is the creator of a resource. Would the intent be to have two separate mechanism for recording and disclosing the creator for the use case that this PR intends to satsify and for the use case of setting such access policies?

@uvdsl uvdsl Jul 21, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@elf-pavlik, as I am interested in that functionality as well - I have to admit that I cannot follow your question.
How do you come to the conclusion that the would be two separate mechanisms for recording?

The authorization (for creator access) could simply look at the listed creator, captured via the here described mechanism, no? Am I missing something?

@elf-pavlik elf-pavlik Jul 21, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With this proposal, if creator is recorded it is always disclosed to whoever has read access to the subject resource. So if Max creates a report in TAO's storage, description resource gets tao:report-x dct:creator foo:max ., then when TAO gives read access to SME they also end up disclosing that Max specifically created this report.
I see problem that recording the creator requires such disclosure and there is no flexible way to control how it gets disclosed.

@uvdsl uvdsl Jul 21, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Understood. Just pointing out that this is true also for all the other metadata (creation time etc).

Given the concrete proposal wording, I don't think that it is mandatory to record the creator of a resource and add it to the description resource. Therefore, I think it is also possible to simply record it but not put it in the description resource?

If you desire to decouple the access control lifecycle of the metadata from the primary resource then maybe -- for such use cases -- the description resource is not the best place for (to be private) metadata? Consider linking to another primary resource with that private meta data using rdfs:seeAlso from the description resource of the first primary resource.

I think a Server Implementation geared towards such privacy-critical use cases would be able to accommodate for such use cases even with the currently proposed wording.

<p about="" id="report-legal-obstacles" rel="spec:advisement" resource="#report-legal-obstacles"><span property="spec:statement">Servers are <span rel="spec:advisementLevel" resource="spec:Encouraged">encouraged</span> to respond with the <code>451</code> 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 <cite><a href="https://www.rfc-editor.org/rfc/rfc7725.html" rel="cito:citesAsAuthority">Report Legal Obstacles</a></cite>, while avoiding the disclosure of sensitive legal or privacy-related details [<cite><a class="bibref" href="#bib-rfc7725">RFC 7725</a></cite>].</span></p>
</div>
</section>
Expand Down Expand Up @@ -1311,6 +1315,26 @@ <h2 property="schema:name">Changelog</h2>
<td><a href="#server-patch-n3-blank-nodes-syntax" rel="spec:changeSubject">#server-patch-n3-blank-nodes-syntax</a></td>
<td property="spec:statement">Add requirement for server to constrain <a href="#server-patch-n3-blank-nodes-syntax">blank node usage in N3 Patch syntax</a>.</td>
</tr>
<tr about="#ea3b1abc-7e19-42f1-8e82-b62cae0aca49" typeof="spec:Change">
<td><a href="https://www.w3.org/policies/process/#class-4" rel="spec:changeClass">4</a></td>
<td><a href="#creator" rel="spec:changeSubject">#creator</a></td>
<td property="spec:statement">Add definition of <a href="#creator">creator</a>.</td>
</tr>
<tr about="#d74c7d63-67a0-41fb-ac20-a70e612b2dfe" typeof="spec:Change">
<td><a href="https://www.w3.org/policies/process/#class-4" rel="spec:changeClass">4</a></td>
<td><a href="#server-description-resource-creator" rel="spec:changeSubject">#server-description-resource-creator</a></td>
<td property="spec:statement">Add requirement for server to record the <a href="#server-description-resource-creator">creator in the associated description resource</a>.</td>
</tr>
<tr about="#f46e3ef2-215f-41b0-9098-c4f5049e4dd6" typeof="spec:Change">
<td><a href="https://www.w3.org/policies/process/#class-4" rel="spec:changeClass">4</a></td>
<td><a href="#server-protect-creator" rel="spec:changeSubject">#server-protect-creator</a></td>
<td property="spec:statement">Add requirement for server to protect <a href="#server-protect-creator">creator statements in a description resource</a>.</td>
</tr>
<tr about="#c5e1c7a2-55ed-459b-b0dd-669eda9737df" typeof="spec:Change">
<td><a href="https://www.w3.org/policies/process/#class-2" rel="spec:changeClass">2</a></td>
<td><a href="#creator-privacy" rel="spec:changeSubject">#creator-privacy</a></td>
<td property="spec:statement">Add advisement for <a href="#creator-privacy">creator privacy</a>.</td>
</tr>
</tbody>
<tfoot>
<tr>
Expand Down