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

Compare with Current View Page History

« Previous Version 8 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 - the 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. 
  • No labels