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.

[uvdsl]

@elf-pavlik, from your comment

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)

Can you substantiate what exactly in this proposal is breaking existing implementations or what is already in the protocol?
I do not understand how the Link-Header approach would be breaking anything either.

Note: This is the same style of claim as "various issues" from earlier. Please provide sufficient explanations to your statements so people can follow your train of thought.

---

On the Link-Header approach:
Sarven enumerated different possible approaches in this comment which is under the second (now resolved) conversation of my review. The Link-Header was one of them.

• Personally, I am not a fan of putting too much custom metadata into Link-Header relations because that might bloat the headers (which have a size limitation of a few kB). Depending on how much protected metadata there is to add, this might become problematic (also considering that implementations might appreciate some headroom for other standard or custom (link) headers as well).
• We already have the description resource (which is based on [POWDER-DR] (W3C REC) ) linked in the Link-Headers in the Solid Protocol. We also already have the concept of server-managed triples in the Solid Protocol. Including a link header for dcterms:creator might just be redundant?

I acknowledge your preference for the Link-Header approach.
What is your objection to using the description resource?

[elf-pavlik]

Can you substantiate what exactly in this proposal is breaking existing implementations or what is already in the protocol?

• Currently Solid Protocol doesn't define any 'protected statements' in the Description Resource.
• There may be existing resource with dct:creator statements set by the client
• This PR intends to ensure that those statements are only set by the server
• Client relying on that assurance, which fetches data from a server implementing 0.11 protocol, may receive a statement that was set by the client

What is your objection to using the description resource?

The whole 'protected statement' adventure leads to a lot of complexity in server implementations. I already pointed out various tricks that CSS does to handle

• https://solidproject.org/TR/protocol#server-protect-containment
• https://solidproject.org/TR/protocol#server-protect-contained-resource-metadata

Which implementation experience/feedback do you base your view of complexity related to use of 'protected statements'?

[elf-pavlik]

It may be helpful to already add tests to https://github.com/solid-contrib/specification-tests
And see if existing implementations are passing those specific tests.

[uvdsl]

Thank you for spelling that out. This is helpful.

• This PR intends to ensure that those statements are only set by the server
• Client relying on that assurance,

I am not sure what kind of assurance you think a triple being server-managed provides? To me, this just means that the server provides the statement. The only "guarantee" I could see is that the statement is not altered after it is first set (by either Server or Client for the first time) - which indeed would not hold on older implementations. Do you see additional guarantees? (or maybe I misunderstand your concept of assurance?)

What is your objection to using the description resource?

The whole 'protected statement' adventure leads to a lot of complexity in server implementations. I already pointed out various tricks that CSS does to handle

To be honest, the "various tricks" (again, unsubstantiated!) as you call them are just implementation of the functionality in my view. Disallowing PUT on representations that might contain protected statements is an absolutely valid implementation choice and not at all a "trick" in my opinion. I don't see how pointing to the developer documentation of an implementation of the exact mechanism that you try to discredit is emphasizing your point. On the contrary in my opinion, the implementations of the Solid Protocol right now, be it NSS/CSS/ESS/PSS that implement server-managed triples are a proof that server-managed triples are implementable without too much of an issue.

Therefore, I acknowledge your objection but question the technical foundation you claim to base it on as I see that foundation to rather prove the opposite.

And, I can't help myself:

The whole 'protected statement' adventure

is dismissive of prior art, namely LDP (W3C REC), and dismissive of how the Solid Protocol currently is specified. I can acknowledge that you are not particularly fond of this approach. However, I honestly don't appreciate how you express your opinion under this issue.

[elf-pavlik]

The only "guarantee" I could see is that the statement is not altered after it is first set (by either Server or Client for the first time) - which indeed would not hold on older implementations.

I think I may still be missing the exact intent motivating this PR. I was assuming that client is not allowed to set the creator - period.

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.

How does it get set by "either Server of Client for the first time"?

[csarven]

Your assumption is correct. Under this PR the client is not allowed to set or update the creator. It is server-managed, #server-description-resource-creator sets it and #server-protect-creator stops clients writing it via 409 (as #server-protect-containment does for containment triples).

I read Christoph's "first set (by either Server or Client for the first time)" as existing deployments that already allowed a client to add a creator statement before this feature, that is legacy data, not something the proposed text permits. So there's no contradiction since this PR is server-only. The client-set case exists only on older or non-conforming deployments. Deployments with existing creator statements are left as they're, and whether to keep or remove them is an admin decision, not a spec concern. In any case, the protocol constrains what clients may write, not what the URI owner's server may represent, so trust in the statement ultimately rests on the URI owner.

[elf-pavlik]

The client-set case exists only on older or non-conforming deployments.

If those deployments are currently fully conformant with how the Description Resource feature is specified. And after this change they become non-conforming with new handing of Description Resource. Shouldn't that be considered as class 3 / breaking change?

[csarven]

A deployment that currently allows a client to write dcterms:creator to a description resource becomes non-conforming under this change. But that doesn't make it class 3.

The class 3 vs 4 distinction isn't "affects conformance", because both can. It's whether a new feature is added. This PR adds a new feature, there was no creator concept in the spec before, so it is class 4 by definition and cannot be class 3, which explicitly excludes new features. A new feature's requirements making prior implementations non-conforming is inherent to adding features, and is exactly what class 4 accounts for.

[elf-pavlik]

This PR adds a new feature, there was no creator concept in the spec before, so it is class 4 by definition and cannot be class 3, which explicitly excludes new features.

It sounds like you are considering every normative statement as a new feature. I see it as conformance breaking change to the existing Description Resource feature. If you add the creator feature without making breaking change to the Description Resource feature I would agree that it would only be class 4 change.

[csarven]

The Process says "affects conformance" which is broader than "breaking". Only the first case of class 3 (conforming becoming non-conforming) is a break. Adding a new required rule produces that same break, because anything that doesn't implement the rule becomes non-conforming. So affecting conformance is common to both class 3 and class 4, and distinguishes neither.

What distinguishes them is fix versus add. Class 3 fixes an existing rule, and its "makes conforming .. become non-conforming" case arises because the old rule's text changed. Class 4 adds: "new functionality, such as new elements, new APIs, new rules, etc."

This PR edits no existing rule. It adds new rules for a concept the spec didn't have. It does constrain PUT/PATCH for creator statements, but constraining existing behaviour by adding a rule is what a new feature does, not a fix. Otherwise every new restriction would be class 3.

Any creator mechanism adds rather than fixes, so it is a class 4 change.

The PR is even titled "Add creator definition and requirements to record and protect creator".

[elf-pavlik]

This PR edits no existing rule. It adds new rules for a concept the spec didn't have. It does constrain PUT/PATCH for creator statements, but constraining existing behaviour by adding a rule is what a new feature does, not a fix.

I don't want to dive into this topic to deep in this PR, later this week I'm going to create a dedicated discussion for it. At this moment I don't agree that constraining existing behaviour (the Description Resource feature) results in a pure addition of a new feature. Creating a new auxiliary resource type rel=yetanotherone, instead of shoehorning 'protected statement' on already existing Description Resource, would be a pure addition of a new feature IMO.

[uvdsl]

My two cents on class 3 vs class 4: I do see where you are coming from, @elf-pavlik, in that there might be a change in conformance of existing implementations, but note -- just like in other discussions we had e.g. on Matrix -- that there was simply no statement made about whether or not a Server manages a creator statement in the description resource. Now adding such a statement about a server-managed creator statement in the description resource adds this functionality into the specification. (That is the same as for the Link header in my opinion.) So, I see it as a Class 4 with the same effect that could also result from a Class 3. In the end, this discussion is informative with regards to this PR, and therefore I would not put to much weight into that distinction here. 🙂

With that, I would like to take stock of what we have

• the current proposal by Sarven for a server-managed dcterms:creator statement in the description resource when the Server indicates the agent who is attributed with the creation of the primary resource.
• Sharon voiced support for this feature
• Melvin provided feedback
• Jesse suggested to consider adding even more (provenance) metadata
• I myself helped refine the wording to address some concern of mine and others, and would support this PR
• Pavlik would prefer a Link header over a server-managed statement in the description resource
• Ted did not voice a particular opinion, but provided useful input on wording (appreciated as usual!)

I also note that this PR targets the ED of the Solid Protocol, so follow-up PRs can still amend the functionality when needed.
Additional follow-up PRs on functionality extension or mechanism clarification are well welcome.

[elf-pavlik]

Pavlik would prefer a Link header over a server-managed statement in the description resource

I object to removing fully client managed description resources.

Link header option satisfies the same use case and doesn't bring known implementation challenges, possibly leading to independent updates with PUT being removed by implementations.

[uvdsl]

@elf-pavlik, your earlier objection and preference have already been acknowledged.

I object to removing fully client managed description resources.

I don't remember the current Solid Protocol to specify that description resources are / should / must be fully client-managed.

The current Solid Protocol does not specify servers to unconditionally honor what a client submits via PUT or PATCH.
The current Solid Protocol does not forbid a server to accept a PUT or PATCH on a description resource and to later update the resource based on some internal record or procedure.
The current Solid Protocol does not forbid implementations to have server-managed statements in description resources.
The current Solid Protocol does not forbid partial updates (like them or not) on description resources, which could be advertised via constrainedBy.

I don't think that this particular objection has valid grounds given the current state of the Solid Protocol.

Link header option satisfies the same use case

Yes, and your preference has been noted.
Your preference and the existence of an alternative approach does not invalidate the proposal at hand.

and doesn't bring known implementation challenges,

Has already been addressed above.

possibly leading to independent updates with PUT being removed by implementations.

which is one potential approach to implementation, agreed. Another approach would be to only execute a partial update (which might be less RESTful in the eyes of some). But these two are just some options for implementation, not necessarily arguments against the proposal at hand.

[elf-pavlik]

and doesn't bring known implementation challenges,

Has already been addressed above.

While you responded in a comment and stated your opinion, I don't see it as the issue being addressed in any way.
We can perform survey and gather feedback from imlementers if we want to go beyond our opinions on that issue.

There are more opinions in

• Specify container description #227

[uvdsl]

and doesn't bring known implementation challenges,

Has already been addressed above.

While you responded in a comment and stated your opinion, I don't see it as the issue being addressed in any way.

If you don't see the issue being addressed by my response, it might have been the case that the issue's explanation was not sufficient for me to understand where you see the issue?

Don't get me wrong, I understand that server-managed statements require corresponding server logic to be implemented. I do not dispute that. The above explanation however, even after re-reading it, did not convince me that there is an issue in that for this particular PR. I genuinely do not see the issue you are pointing at. Apologies.

I acknowledge that you argue that the mechansim of server-managed statements, which is already in the Solid Protocol, e.g. for the much debated case of container metadata (the issue you linked), should not be re-used for general (provenance?) resource metadata such as the proposed dcterms:creator.

Typically, re-using an established mechanism within a specification is considered best practice. You seem to prefer a different mechanism, which is fine. But you also base your objection on the notion that the existing mechanism somehow poses as a blocking issue?

I am left confused by our conversation

• (a) because I don't understand the technical issue of server-managed statements you seem to see.
• (b) because I don't understand how a mechanism that already exists in the protocol can be cited as a blocking issue for a new PR.

I'll leave it at that.