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]

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]

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

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]

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.

[uvdsl]

See my suggestions below.

[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

[uvdsl]

Just noting that this functionality the server-internal recording of resource creators underlying this functionality could be useful for authorization as well, see e.g. solid/web-access-control-spec#139

[elf-pavlik]

Just noting that this functionality could be useful for authorization as well, see e.g. solid/web-access-control-spec#139

Wouldn't it make sense to design it in a way that recording it and having it for available for access control is independent from if/how it is disclosed to clients? Related to this thread #807 (comment)

I would be more comfortable if by default at least control mode was required to obtain creator information.

This PR doesn't inform who makes the decision if creator is recorded in the first place - implementer, deployment manager, server admin, storage owner, user. Having it recorded internally first and later adding standard process for the storage owner to manage disclosure would be my preference.

[uvdsl]

@elf-pavlik, to my understanding of this PR (@csarven, please do correct me), your comment is orthogonal to what both this PR and solid/web-access-control-spec#139 are about.

How exactly the creator of resources is recorded or where that information is stored in a Server is independent of the above issues. Today's Servers could/can already record the creator of a resource (which we did e.g. for MANDAT).

To my understanding, this PR aims to specify how a Server would indicate the creator of a resource -- if and when the Server records and (wants to <- not testable) indicates resource creators.
The issue of solid/web-access-control-spec#139 aims to specify how an authorization rule would specify that the creator of a resource is authorized to access that resource.

It is true that both of the above mechanisms use the underlying recording of resource creators by the Server.
And therefore, I shall correct my above comment to reflect that. Thank you for pointing this out.

Still, related to your other creator-recording question, I believe that this PR is just one way to indicate the resource creator based on an server-internal recording of resource creators. At the same time, there is no obligation to record creators at all -- or to store creators somewhere other than the description resource (if the Server so chooses). The PR and the WAC issue simply make no statement about that.

[elf-pavlik]

Thanks for clarification! Having full human readable diff available would make this review easier #807 (comment)

I understand that this PR only intends to define the potential disclosure part by

• registering dct:creator statements in Description Resource as exclusive server-only assertions
• instructing cilents that server can assert creator in the Description Resource
• leaving who and how controls disclosure of the creator out of scope

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]

I think the above would need to be adjusted, to don't assume if server tracks it or not but only if it wants to disclose it.

The next step IMO would be to look at possibly having a separate PR to specify requirement for server to track it, or not and maybe advertise this capability.
As well as looking at alternative proposals for when creator is tracked, how it could be disclosed and how this disclosure could be controlled - at least by the storage owner or agent with control over resource's access.

[elf-pavlik]

I see need to define in loosely coupled manner

1. recording creator of the resource
2. disclosing creator in a controlled way and a mechanism to control that disclosure

Besides above, adding 'protected' statement to the Description Resource can lead to various issues. Based on known implementation challanges related to current precedent of having protected statement in a container description.

• https://communitysolidserver.github.io/CommunitySolidServer/latest/usage/metadata/#protected-metadata
• and 0 implementations of protected statements proposed by WebID-Profile draft long time ago

[elf-pavlik]

Thinking about possible ways to have this proposal available for experimenting without the lack of consensus blocking it. In lines of https://github.com/w3c-cg/solid/blob/main/framework-for-proposals.md

This could be a separate proposal listed on https://solidproject.org/TR which could provide a better reference to potential implementers than an open PR.

[uvdsl]

Hm. I don't see these requirements here:

[...] need to define [...] recording creator of the resource

Whether a Server records the creators of resources is not a question of interoperability but rather an implementation choice. With that, I don't think there is a requirement that this specification must/should/would require a Server to record resource creators. (That is an internal thing after all.)

disclosing creator in a controlled way and a mechanism to control that disclosure

How a Server is configured to indicate a resource's creator seems to be -- to my understanding of this PR and the discussion so far -- out of scope for this PR. That said, nothing here forbids defining such a mechanism in a separate PR. You are welcome to propose something that builds on this!

Besides above, adding 'protected' statement to the Description Resource can lead to various issues.

I politely request you to enumerate the "various issues".

Based on known implementation challenges

I don't see how the two bullet points support the claim that protecting particular statements on the server-side are challenging. LDP (the W3C REC) specifies such behavior as well for ldp:contains (which the Solid Protocol does too). This is already part of the Solid Protocol.

Besides, your link is just documenting CSS behavior. Nothing challenging to see there.
And on

0 implementations of protected statements proposed by WebID-Profile draft

The fact that you don't know of any implementation (where I think to remember that ESS does it - but happy to be proven wrong) does not prove that it is hard or challenging to implement it.

---

Independent of the above, I am wondering what particular changes you are requesting?

[uvdsl]

Dear @elf-pavlik,

I politely request you to refrain from introducing procedural blockers where none are due.
If you have procedural concerns, raise them with sufficient explanations.

There is no need to branch this proposal out into a spec fork or a self-contained proposal/work-item. There is no need to rush anything or to delay anything. If you have feedback, provide comments and/or suggest changes that are actionable. If you want to experiment with the proposed functionality, you are welcome implement it and provide feedback in a meaningful manner, e.g., by suggesting concrete changes.

Cheers
Christoph

[elf-pavlik]

I don't think there is a requirement that this specification must/should/would require a Server to record resource creators. (That is an internal thing after all.)

Since this PR tightly couples recording and disclosure, I see need that such behavior is being advertised. See also #807 (comment)

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

Then

How a Server is configured to indicate a resource's creator seems to be -- to my understanding of this PR and the discussion so far -- out of scope for this PR. That said, nothing here forbids defining such a mechanism in a separate PR. You are welcome to propose something that builds on this!

This PR adds

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.

How do you imagine building alternative mechanism for disclosing the creator on top of this tightly coupled approach?

BTW one can always propose changes that replace something in current draft, not only build on top of it. Of course the bar is higher but there's nothing preventing replacing current functionality in a CG draft.

Besides, your link is just documenting CSS behavior. Nothing challenging to see there.

If you like we can dive deeper into

Impact on creating containers¶

When creating a container the input body is ignored and performing a PUT request on an existing container will result in an error. Container metadata can only be added and modified by performing a PATCH on the description resource, similarly to documents. This is done to clearly differentiate between a container's representation and its metadata.

And why current CSS implementation could extend list of 'protected' predicates, as long as client only uses PATCH.
Based on #807 (comment) I have impression that implementation experience may not always be taken into considerations, or at least very selectively.

The fact that you don't know of any implementation (where I think to remember that ESS does it - but happy to be proven wrong) does not prove that it is hard or challenging to implement it.

As far as I know ESS doesn't create WebID inside of user's storage, which makes it more secure than default CSS config.

Independent of the above, I am wondering what particular changes you are requesting?

#807 (review)

I see need to define in loosely coupled manner

• recording creator of the resource
• disclosing creator in a controlled way and a mechanism to control that disclosure

either further work on addressing it or #807 (comment)

[uvdsl]

Did you review the latest changes to the proposal?

[elf-pavlik]

The preview link was updated 20min ago, I'll take another look.

EDIT there is a power grid maintenence scheduled for today, I may be offline for next couple of hours.

[elf-pavlik]

Given current state of this PR and my understanding of a use case that it tries to address.

1. recording (or not) is out of scope
2. control of disclosure is out of scope

It pretty much only ensures clients that dct:creator in the Description Resource is server managed and matches who created the resource.

Can we accomplish the same by simply having something in lines of

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 with the http://purl.org/dc/terms/creator relation, whose value is the authenticated agent who created the resource.

This way we should have equivalent solution without getting into problems like sub resource access control and protected triples which lead to nuances exemplified by CSS tricks used to implement ones on containers.

[elf-pavlik]

This variant could be even more bulletproof:

When a server sets in a response an HTTP Link header with the http://purl.org/dc/terms/creator relation, its value MUST NOT be different from the resource's creator. If server doesn't know the resource's creator it MUST NOT set it under any circumstances.

So if server sets it to anything other than recorded creator it violates those requirements. This should give clients safety to rely on that link relation if present in the response.

BTW, approach proposed in this PR looks like a breaking change, while link header approach is probably less breaking (technically should also be considered as breaking)

This PR includes class 2 and 4 changes

3. Other changes that do not add new features
   For Recommendation-track documents, these changes may affect conformance to the specification. A change that affects conformance is one that:

• makes conforming data, processors, or other conforming agents become non-conforming according to the new version, or

Wouldn't setting it in a Description Resource to something else to creator fall under that? We could test it with solidcommunity.net today. Link header wouldn't break any known to me implementation / deployment.

It doesn't strictly apply to CG drafts since they are not on REC-track, but if we want to use this classification we probably want to consider it.

[TallTed]

A light tweak --

When a server response includes an HTTP Link header with the http://purl.org/dc/terms/creator relation, its value MUST NOT differ from the resource's creator. If the server doesn't know the resource's creator, it MUST NOT set it under any circumstances.