Add creator definition and requirements to record and protect creator

[csarven]

This PR introduces the feature to record and protect the creator of a resource along with some privacy considerations.

This PR includes class 2 and 4 changes (Processing PRs):

• #creator (class 4)
• #server-description-resource-creator (class 4)
• #server-protect-creator (class 4)
• #creator-privacy (class 2)

Resolves #315 , #66

---

Preview

[SharonStrats]

This is great!

[csarven]

Implemented in dokieli (source code, code change)

[melvincarvalho]

Some technical issues with the proposed requirements, in rough order of severity.

1. #server-protect-creator conflicts with #server-put-patch-auxiliary-resource.
The existing requirement states: "When a PUT or PATCH request targets an auxiliary resource, the server MUST create or update it." The new requirement states the server MUST NOT allow PUT/PATCH to update creator statements in a description resource and MUST respond 409. A server receiving a PATCH to a description resource that touches a creator statement cannot satisfy both MUSTs. The PR needs to amend the existing requirement to carve out the exception, or scope the new one so they compose.

2. "When a server wants to track…" is not a testable conformance condition.
A MUST predicated on server intent cannot be evaluated by a test suite — there is no observable distinction between "does not want to" and "wants to but fails to." Suggest either: (a) make it a MAY/SHOULD, or (b) condition it on an observable, discoverable server capability (e.g. advertised in the storage description).

3. The immutability guarantee is void under the deletion lifecycle.
Per #server-delete-remove-auxiliary-resource, deleting a resource deletes its auxiliary resources. Any agent with write access can therefore DELETE and re-PUT a resource, becoming its recorded creator. Meanwhile the original creator cannot correct or remove their own attribution (409). The mechanism is bypassable by exactly the parties it should constrain, and binding on exactly the party it should serve. If creator is intended as provenance, it needs to survive — or explicitly not survive — delete/recreate, and the spec should say which.

4. The privacy advisement has no conforming mechanism.
#creator-privacy says servers "can honour an agent's request … to have an existing attribution removed, for example, to meet data protection obligations." But #server-protect-creator forbids every HTTP write method from touching creator statements, and #creator defines the creator as unchanging. As written, honouring an erasure request (e.g. GDPR Art. 17) requires the server to violate a MUST NOT. The erasure path needs to be a defined, conforming operation, not an advisement that contradicts a requirement.

5. dcterms:creator is not a reserved predicate.
Description resources are the designated location for client-managed resource metadata, and dcterms:creator is in wide use meaning author — which routinely differs from the authenticated agent (apps writing on a user's behalf, uploads of third-party works, imported data). The requirement (a) overloads the predicate to mean "authenticated creating agent," and (b) as written, 409s any client statement using it, including pre-existing legitimate authorship metadata. Is the protection intended to cover all triples with predicate dcterms:creator, or only the server-asserted one? Either answer causes problems; a server-managed predicate (or a dedicated one, e.g. in the solid vocab) would avoid the collision.

6. For RDF sources the assertion is forgeable in the subject resource itself.
The protection covers only the description resource. A client can assert <> dcterms:creator ?x in the RDF source's own representation, which the server cannot reject on these grounds. A consumer merging the resource with its description resource (the normal use of describedby) obtains conflicting creator triples with no way to distinguish the server-asserted one. The guarantee doesn't survive the data model it's embedded in.

7. Minor points.

• 409 (Conflict) implies a resolvable state conflict; refusing a categorically forbidden modification is 403 territory. (Noting the 409 appears to be carried over from #server-protect-containment, where containment triples live in a server-managed representation — a materially different situation from a client-writable description resource.)
• Resources created via unauthenticated writes (public write access) record no creator, so consumers cannot rely on presence of the statement.
• A storage migrated or restored to another server cannot reproduce existing creator statements without the target server violating #server-protect-creator.
• The cited implementation (dokieli) is a client; both new requirements bind servers. Is there server implementation experience for the record-and-protect behaviour, per the class 4 designation?

[elf-pavlik]

Can you please add HTML diff? I don't find raw RDFa diff to be something human readable 😵‍💫

[elf-pavlik]

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]

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]

How would that work on description resources of containers? Some implementations don't allow to write statements on containers and only to description resources. This would lead to situation where on non containers client could set dcterms:creator but on containers only server managed creator would be possible.

[csarven]

dcterms:creator in description resources is server-managed, and client-asserted authorship can go in the subject resource's own representation. Clients can't set dcterms:creator on description resources of non-containers.

That said, the situation you describe arises from implementations that further restrict writes on container representations beyond what this spec requires. So, where clients can express metadata about a container is for them to resolve.

[uvdsl]

See my suggestions below.

[uvdsl]

Might I suggest to make the pre-conditions a bit clearer?

1. If Server records Creator of a resource
   AND
2. If that resource is created by an identified and authenticated agent
   THEN
   the Server must do xyz.

Not sure if the following suggestion is the right approach, but I think you'll get the idea:

Suggested change

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

<p about="" id="server-description-resource-creator" rel="spec:requirement" resource="#server-description-resource-creator"><span property="spec:statement">If a <span rel="spec:requirementSubject" resource="#Server">server</span> documents the <a href="#creator">creator</a> of a resource and that resource is 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>

Might I also suggest to add identified to authenticated agent?
While currently in the Solid Protocol all authenticated agents are identified by their WebID, there are use cases where agent attributes (via anonymous credentials) might be used to authenticate an agent without identifying them. At the same time, when an agent is not identified, the object value could simply be a blank node (that a server might describe with additional information). But I acknowledge that this is not forbidden here at all with the current wording.

[uvdsl]

Might I suggest to move this statement to #writing-resources for consistency in constraints on writing (on various types of resources incl. description resources)?

With that, #server-put-patch-auxiliary-resource could be amended to reflect the restriction stated here.

[jeswr]

This is a valuable piece of provenance to be capturing. In addition; I would suggest also providing a way for servers to capture the following:

• The application used to author the document
• Provenance of all (agent, application) pairs that have subsequently modified the document