Decide on a method of recording the creator of a resource

[dmitrizagidulin]

(Specifically, this means creator in the sense of 'What is the WebID of the user who issued the PUT/POST/PATCH request that resulted in this resource?', not in the "author of a paper" sense.)

At the moment, the Solid platform does not have a mechanism to record or discover which user created a resource, even though the server has that information at the time of resource creation (that is, by the time a PUT/POST/PATCH succeeds, the user has been authenticated, and their WebID is known to the server).

This causes various security implications, including not being able to verify the sender of Notifications for LDN inboxes.

Decisions:

• Decide where this information gets recorded. The current consensus is - in the Server-protected metadata resource
• What vocab term should be used to record the WebID of the agent who created the resource? dc:creator?
• What vocab term should be used to record the ID of the application that the agent used to create the resource, if applicable?

[pmcb55]

Yep, great issue @dmitrizagidulin. For me, this just reflects yet another need for generic resource meta-data - in this particular case, server-specific meta-data associated with the resource at the time of it's creation (i.e. not only should we be able to record the WebID of the resource 'author', but also lots of other potential meta-data, like the time it was created, the IP address of the server host(s) that processed the creation request, the version of the backend database used to persist the data, etc. (speaking hypothetically here in relation to the security concerns around exposing this kind of internal server-implementation-specific data as dereference-able resource meta-data, but you know what I mean :) !)).

So to reiterate my point from the ACL issue - how should the Solid spec define access to this kind of resource metadata...?

[acoburn]

This sort of data could be considered as part of an audit history of a resource, and an example of how this could be implemented is described in #65 (comment)

[elf-pavlik]

This causes various security implications, including not being able to verify the sender of Notifications for LDN inboxes.

I think this fits under scope of Data Interoperability panel - Validation. I think we can see it as distinct from some kind of audit trial of the resource.

What is the WebID of the user who issued the PUT/POST/PATCH request that resulted in this resource?',

For POST and PUT it sounds simple, for PATCH we can have different statements created by different users. If it stays internal to the server I don't know if spec needs to provide any guidance. Also server may want to record the whole history (versioning) and who created which change.

Where do you see it coming into play besides server internal implementation?

[kjetilk]

I can easily see that there are requirements along these lines arising from the "Records of processing activities" in GDPR, in cases where other parties are granted access to personal data, i.e. Solid takes the burden of maintaining access records so that the user can verify that the processor has records that are consistent with the access records.

[pmcb55]

So yeah, absolutely @acoburn, this data most certainly would be part of the audit history of a resource (assuming the server implements accessible resource auditing!), but I agree with @elf-pavlik that's it's also distinct meta-data in it's own right (that I'd see as part of 'server-managed meta-data').
So I see huge value in being able to access this data (as either audit data, or as server-managed-resource-meta-data) via the same consistent mechanism, which at the moment I think is via Named Graphs associated (i.e. linked) directly to the resource itself (and accessable via link headers on resource GET or HEAD requests).

[dmitrizagidulin]

(Added the list of decisions required for this item, to the issue description.)