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
Before reading through this, it would be good to review the Fedora Specification Versioning Section as well as understand the Memento Terminology.
This design relates specifically to how versioning could be done in the Modeshape Implementation of Fedora 4
A PUT or POST request to create an object will make a resource versionable if it includes header Link: rel="type" with type of http://fedora.info/definitions/fcrepo#VersionedResource
A LDPR will be created as a LDPRv with the versioning type.
A LDPCv will be created, from which a TimeMap can be generated.
A LDPRm will be generated, contained by the LDPCv.
Any subsequent responses from the LDPRv will include the appropriate memento links in the header: Timegate, Timemap
A PUT request to an Existing LDPR will make a resource versionable if it includes header Link: rel="type" with type of http://fedora.info/definitions/fcrepo#VersionedResource
The versioning type will be added to the LDPR, making it a LDPRv.
A LDPCv will be created, from which a TimeMap can be generated.
A LDPRm will be generated, contained by the LDPCv.
Any subsequent responses from the LDPRv will include the appropriate memento links in the header: timegate, timemap
A HEAD request on the LDPRv will return response with Link rel="type" http://fedora.info/definitions/fcrepo#VersionedResource which indicates versioning support and a 'Link rel="timemap"' points to the URL of the LDPCv/TimeMap.
An OPTIONS request on LDPCv/TimeMap that contains an "Allow: POST" header
indicates that versions can be created by a client.
Note: when creating a new version of the LDPRv, only the single resource itself will be versioned. There is no concept of "tree" snapshots anymore.
A POST request to the LDPCv with an empty body and no "Memento-Datetime" header will cause a new memento of the LDPRv to be created with current date/time.
A POST request to the LDPCv with header "Memento-Datetime" and no body will create a historic verision with current state of the LDPRv with the specificed date/time.
A POST request to the LDPCv with header "Memento-Datetime" and a body will create a historic version with the specified body and date/time.
A POST request to the LDPCv with a body and no "Memento-Datetime" header to create a version with the specified body and the current datetime.
A GET request to the LDPCv with the "Accept: application/link-format" header will cause the TimeMap to be returned.
A GET request to the LDPCv with no "Accept:" header, or one specificying an RDF format will result in the LDPCv being returned in rdf format.
The response from the GET will include a "Vary-Post: Memento-Datetime" to indicate that a client can request a specific time be associated with a memento when it's created via a POST.
A GET request to the TimeGate Resource (the LDPRv itself) with "Accept-Datetime" header specified will return the LDPRm associated with that datetime, or the closest one if there is not an exact match.
example header usage: "Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT"
a Link header will be in the response to show the TimeGate URI
A GET request to LDPRm/Memento (if the LDPRm/Memento has its own URI), will result in the memento being returned if it exists.
See: Datetime negotiation algorithm example for Accept-Datetime negotiation details.
Any response from the LDPRv will include link relation headers of type "timegate" (referring to the LDPRv), "original" (also referring to this LDPRv), and "timemap" (referencing the URI of the LDPCv).
A DELETE request to LDPRm/Memento will result in that memento being deleted.
Note: This interaction still needs to be ironed out as this is currently under discussion in Spec Issue 217
A PUT request to LDPRv/TimeGate with header (can't be Content-Location
, but something like it) pointing to the LDPRm/Memento URI to indicate the version to restore
- OR - A PATCH request to LDPRv/TimeGate with no body and a "Memento-Datetime" header indicating the version to restore, will result in the memento that relates to that date/time being restored.
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:
This section describes the algorithm used in figuring out which memento will be returned on a GET request to the TimeGate with an Accept-Datetime header.
Here's an example of a LDPRv - what signifies that it is a LDPRv is that it has a `fedora:hasVersions` triple. This is the current behavior of the Modeshape Fedora and doesn't seem to need any change, other then maybe how the `fcr:versions` triple is created.
@prefix premis: <http://www.loc.gov/premis/rdf/v1#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix fedora: <http://fedora.info/definitions/v4/repository#> . @prefix ldp: <http://www.w3.org/ns/ldp#> . </path/to/resource/xyz> rdf:type fedora:Container ; rdf:type fedora:Resource ; rdf:type ldp:RDFSource ; rdf:type ldp:Container ; fedora:lastModifiedBy "bypassAdmin"^^<http://www.w3.org/2001/XMLSchema#string> ; fedora:createdBy "bypassAdmin"^^<http://www.w3.org/2001/XMLSchema#string> ; fedora:lastModified "2017-09-18T20:01:33.501Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> ; fedora:created "2017-09-15T21:19:49.731Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> ; fedora:writable "true"^^<http://www.w3.org/2001/XMLSchema#boolean> ; fedora:hasParent </path/to/resource> ; ldp:contains </path/to/resource/xyz/abc> ; fedora:hasVersions </path/to/resource/xyz/fcr:versions> . # pointer to the LDPCv (TimeMap) |
@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#> . @prefix time: <http://www.w3.org/2006/time#> . </path/to/resource/xyz/fcr:versions> a ldp:Container ; acl:hasAccessControl </path/to/acls> ; # this is for the LDPCv itself, for the TimeMap retrieval prov:startedAtTime "2017-09-08T21:35:19Z"^^xsd:dateTime ; # first memento prov:endedAtTime "2017-09-11T15:41:04Z"^^xsd:dateTime ; # last memento memento:hasAccessControl </path/to/acls> ; memento:hasOriginalResource </path/to/orig/resource/xyz> ; # how else can we represent this? is this a given based on url? memento:hasTimeGate </path/to/orig/resource/xyz> ; # how else can we represent this? is this a given based on url? iana:first </path/to/resource/xyz/fcr:versions/12344> ; iana:last </path/to/resource/xyz/fcr:versions/12347> ; ldp:contains </path/to/resource/xyz/fcr:versions/12344>, </path/to/resource/xyz/fcr:versions/12345>, </path/to/resource/xyz/fcr:versions/12347>, </path/to/resource/xyz/fcr:versions/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#> . @prefix time: <http://www.w3.org/2006/time#> . </path/to/resource/xyz/fcr:versions/12345> a ldp:RDFSource , prov:InstantaneousEvent; prov:atTime "2012-04-30T20:40:40"^^xsd:dateTime; memento:hasTimegate </path/to/orig/resource/xyz> ; # how else can we represent this? is this this a given based on url? memento:hasOriginalResource </path/to/orig/resource/xyz> ; # how else can we represent this? Is this a given based on url? iana:next </path/to/xyz/fcr:versions/12346> ; # to memento iana:prev </path/to/xyz/fcr:versions/12344> ; # to memento ... triples from original resource at the time of versioning... or, if we keep them separate, it might look like this: (I'm not clear on how a binary and it's metadata would be represented) ldp:contains </path/to/xyz/fcr:versions/12345/version> , </path/to/xyz/fcr:versions/12345/version/fcr:metadata> ; |
One way to fix this is to update the system so that links to other resources are URIs and not node references
The initial version of this change will not allow snapshot(tree) versioning. The first pass at spec compliance will only include versioning one resource at a time.
The discussion was to have the ldp:containment triples reference the cannonical URL of the resources.
When versioning a tree of resources, what happens if one of the resources in the tree does not have the version interaction model attached to it?
Given that we will not be doing snapshot (tree) versioning at this point, this should not be an issue to consider at the present time.
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"