If you make a new version of a value and give it more restrictive permissions, should the past versions still be available with the same permissions? Or should the new permissions be applied to all past versions?
Use case 1: You create the value, then realise you gave it the wrong permissions.
Use case 2: You add a secret to the value, but you don’t care if people see the past versions, which don’t contain the secret.
Maybe it would make sense that the value permissions behave in line with deleting a resource. If I don’t want anyone to see the value anymore, then it would make sense to not have access to past versions.
Also, if each value version has its own permissions, then when returning the history, you would need to check for each version if the user is allowed to access it. Maybe it can be simplified by keeping only one version string per value.
I agree, I think we should store permissions only for the latest version of each value, and use the same permissions for all past versions.
I could think of another use case:
Valid permissions are a function, allowing or prohibiting the view of a resource.
Earlier permissions, especially if they are more restrictive, are just metadata.
Example is an image that the owner restricts until let’s say 1.1.2020 and then its use is free.
Then the metadata would just say: This image was restricted until 31.12.2019.
Is such a thing feasible?
Is such a thing feasible?
Yes, we could use only the latest permissions for permission-checking, but still return the old ones when you request a previous version of the data.
Thist would be perfect. You agree, Lukas?
It is a little bit off-topic but @erwin.zbinden’s post triggers the idea that at some point, we may need a way to handle embargo period within Knora, allowing the data of a project to become public (= accessible to knora-admin:UnknownUser) at a pre-determined time, instead of having to run a SPARQL query 5 years or 15 years after the beginning of a project to updates all the permissions of a project. I am not sure how it could be done… Any idea about this?
An embargo period should probably be part of the metadata related to a knora-project. And here comes again the (old!) project metadata issue #566 
we may need a way to handle embargo period
@mrivoal If the embargo period was part of the project metadata, and if Knora cached project metadata, this could be implemented efficiently.
Then it would be great to have that
I thought of another scenario: The data contains confidential information, e.g. the names of survey participants. The researcher then anonymises the data, and wants to make the anonymised version public. In this case, the researcher would not want the new permissions to apply to the earlier version of the data.
Regarding the peculiar scenario of anonymisation, I don’t think it applies because the DaSCH currently makes the user responsible for his data anonymisation before his data are transfered to the DaSCH. We do not have an infrastructure compliant with sensitive data requirements and I am not sure that we will ever go this way. But @lrosenth could add his thoughts on the matter.
Survey data would most probably be transmitted to FORS rather than to DaSCH, that’s what they do. And even FORS ask the user to anonymise his data before.
I guess you could find a similar scenario that doesn’t imply anonymised data but I think the consequence of a mistake in attributing the permissions would be far less severe.
Yes, up to now the DaSCH refuses to take over sensitive data comtaining personal data that has to be anonymized. This kind of data will be friendly forwarded to FORS…
@lrosenth OK, so should we say that the permissions on the most recent version of a value apply to all previous versions of the value? And that we keep the previous permissions only as historical metadata (so you can see what the permissions used to be)?
I think that’s a could way. Don’t let us do too complicated things. If someone is allowed to see the last version, the she/he should be able to see all previous versions.
I think we should retract from hosting too sensitive data. Permissions are for copyright issues mainly, eventually also embargo periods for researchers. But hosting delicate data would have many more consequences, e.g. we would have to modify the backups, build up much more security for the servers, intrusion detection etc. We are not able to do this, and it is probably not the goal of the DaSCH 
.
If we implement @mrivoal’s request for an embargo date, do we need to keep the permissions on old versions of values? Or can we delete them? Then we would be able to say, “This was made public on this date,” but we wouldn’t be able to say what the restricted permissions used to be.
If we are to keep it simple, I think we should just delete the permissions on old versions of values.
As I see it, projects willing to keep some permissions will simply not use the embargo date. On the contrary, if there is an embargo date on a project’s data, it should mean that all its data will become publicly available once the embargo comes to an end. We could then get rid of all the old permissions.
I think we should just delete the permissions on old versions of values.
This is implemented in PR 1372.
Great! Have you already added a metadata stating the length of an embargo for a project? Or is it a different step?