A place to record thoughts on the interaction of resource versions and WAC authorization in the context of the Fedora API alignment sprint.
JIRA issue:
Memento has very little to say about security, mainly just that it is up to the server in terms of how access to previous versions work (most likely we want it to behave the same way it behaved at the point of the snapshot, but that is something that needs to be decided), and what memento headers to expose during authentication:
https://tools.ietf.org/html/rfc7089#section-7
For versioning: Versioning Delta/Specification Notes
For authorization: TBD
There are three separate entities at play in this scenario.
To find the ACL that relates to a LDPRm, follow this algorithm:
Given this, the following is then true:
@prefix acl: <http://www.w3.org/ns/auth/acl#> . @prefix iana: <http://www.iana.org/assignments/relation/> . @prefix ldp: <http://www.w3.org/ns/ldp#> . @prefix memento: <http://example.com/memento#> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . </path/to/resource/xyz/timemap> a memento:TimeMap, ldp:Container ; acl:hasAccessControl </path/to/acls> ; # this is for the LDPCv itself memento:hasOriginalResource </path/to/orig/resource/xyz> ; memento:hasTimeGate </path/to/orig/resource/xyz> ; memento:hasAccessControl </path/to/acls> ; iana:first </path/to/resource/xyz/timemap/12344> ; iana:last </path/to/resource/xyz/timemap/12347> ; ldp:contains </path/to/resource/xyz/timemap/12344>, </path/to/resource/xyz/timemap/12345>, </path/to/resource/xyz/timemap/12347>, </path/to/resource/xyz/timemap/12346> . |
The use of IANA may or may not work here - esp if the original object's snapshot is in this LDPRm directly - we need to make sure that triples don't overlap. If we stick with all memento triples, then we can strip them out and have the version of the resource the user is after.
@prefix acl: <http://www.w3.org/ns/auth/acl#> . @prefix iana: <http://www.iana.org/assignments/relation/> . @prefix ldp: <http://www.w3.org/ns/ldp#> . @prefix memento: <http://example.com/memento#> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . </path/to/resource/xyz/timemap/12345> a memento:Memento , ldp:RDFSource ; memento:datetime "20010320133610" ; memento:hasTimegate </path/to/orig/resource/xyz> ; #original resource == timegate memento:hasOriginalResource </path/to/orig/resource/xyz> ; # timegate and orig resource could come from LDPCv instead iana:next </path/to/xyz/timemap/datetimestamp12346> ; iana:prev </path/to/xyz/timemap/datetimestamp12344> ; ... triples from original resource at the time of the versioning are here as well. |
Versioning/Authorization Use-Cases
It seems to be difficult to determine the identity of the "parent" of a resource via ldp:contains with versioning.
The current fedora implementation creates (and links to) new LDPRs when a non-empty LDPRv is versioned. These resources are neither an LDPRv, nor LDPRm
For example, consider a container A and A/B where A ldp:contains B.
Creating a version v1 of <A> creates a resource <A/fcr:versions/v1>. This is essentially an LDPRm, and contains triple <A/fcr:versions/v1> ldp:contains <A/fcr:versions/v1/B>.
Issues are:
All of this may be fine, but it lies outside of any specification. Essentially, "when you create a new version of a resource, that resource versions now points new and different things that it didn't previously point to, and have nothing to do with versioning"