You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

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:  Unable to locate Jira server for this macro. It may be due to Application Link configuration.


  • If we are preserving ACLs as part of a version rather than using the original resource's, then for resources without an assigned or inherited ACLs Fedora would need to record the Default ACL at the time of the snapshot somehow. 5.3 Inheritance and Default ACLs
    • Similarly, an inherited ACL would also need to be recorded for the snapshot.

Memento and Security

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


Design thoughts

Here are a few ways that ACLS and versions of resources might interact.   Ideas and use cases are welcome, especially if you have a certain way in which you might expect ACLs and Versioning to behave.

LDPRv - "Original Resource" -  the original resource that has versions

LDPCv -  A LDP container that contains the versions of a resource;  otherwise known as the TimeMap in memento

  1. Ignore any ACL on a versioned resource; instead honor the ACL that the Original Resource (LDPRv) has.  Essentially the versioned resource 'inherit' the ACL from the version container (LDPCv). 
    1. If the LDPCv has no ACL - default back to the LDPRv??  Or perhaps the LDPCv points to some sort of default ACL?
    2. This scenario allows for the LDPRv to potentially have a separate ACL from the versions of itself. 
  2. Any versioned resource always has the same ACL as the Original Resource (LDPRv).  In other words, the ACL on the LDPCv always applies to all versions of the resource. If the ACL is changed or updated on the LDPCv, all the versions then have that same change/update.  The ACL would be stored and referenced from the LDPRv (not stored in the versions). 
  3. When a LDPR is versioned, honor the ACL that's on the versioned resource that was there at the time the version was created.
    1.  If the URL of the ACL pointed to never changes, then all the versions will have the same ACL restrictions as the LDPRv. 
    2.  If the URL of the ACL pointed to changes over time, then the versions may have different ACL restrictions, from both each other and the Original Resource.
    3. This scenario gets complicated quickly, especially when an ACL that's on a version, but no longer on the LDPRv, gets removed from the system.  
  4. Version the ACL along with the LDPRv.  
    1. This would be a tricky scenario to work with as an admin would potentially be unable to manage access appropriately. Given that mementos are immutable, the versioned ACLs wouldn't be able to change and an admin would be unable to change authorizations for versions of resources. 

URIs in LDPRm, and the "multiple parent" problem

It seems to be difficult to determine the identity of the "parent" of a resource via ldp:contains with versioning.  

  1. LDPR contains LDPR (without versioning).  This one is simple.  A ldp:contains A/B.  A/B has exactly one parent:  A.
  2. LDPRv contains LDPRv.  This one is also pretty simple.  A ldp:contains A/B, A/B has exactly one parent: A.
  3. LDPRm contains LDPRv.  This one is a little less straightforward.  There could be multiple resources that assert they contain B:  What does a client need to know the identity of the resource that contains B?
    1. A_m1 (an LDPRm for A):  <A_m1> <ldp:contains> <B> 
    2. A_m2 (a different LDPRm for A): <A_m2> <ldp:contaiins> <B>
    3. A (an LDPRv): <A> <ldp:contains> <B>
  4. LDPRm contains LDPRm. This one causes problems due to the fact that an LDPRm MUST be contained by an LDPCv as well.  For memento B_m1 of resource B What does a client need to know in order to determine which one is B_m1's parent via containment?:
    1. A_m1 (an LDPRm for A):  <A_m1> <ldp:contains> <B_m1> 
    2. A_m2 (a different LDPRm for A): <A_m2> <ldp:contaiins> <B_m1>
    3. B_cv (The LDPCv for B):  <B_cv> <ldp:contains> <B_m1>

Snapshot Versioning (problem ?)

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:

  1. <A/fcr:versions/v1/B> is a new LDPR, bit its relationship to versioning is not defined in any spec.  It is not an LDPRv, nor an LDPRm.  It does not the have equivalent of an LDPCv associated with it.
  2. There is no explicit or implicit relationship between <A/fcr:versions/v1/B> and <B>

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" 

  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.