Hi all, Just a quick remark to Asger's email: in my opinion, policies and licenses are very different things. I even have my doubts if I would like to see policies (which will change over time) as something I want to store in a repository at all. Changing a policy doesn't change the object itself, whereas a license associated with an object is a much tighter and stable relationship (think of an OA license with an embargo - the policy changes after the embargo ends, the license is still valid).
That brings me to a more general remark. I tend to think that I just want to see objects in my repository which I want to keep for a long time (decades rather than months). Policies (just like users) are transient information which I rather store outside of a repository. Storing policies in Fedora probably requires a cache for faster access, which further complicates things. The charming idea of FESL to separate the access control and policy evaluation from the repository proper is somehow contradicted by making policies first class objects in the repository. Cheers, Matthias. > -----Original Message----- > From: Asger Askov Blekinge [mailto:[email protected]] > Sent: Friday, February 12, 2010 1:50 PM > To: Steve Bayliss > Cc: [email protected] > Subject: Re: [Fedora-commons-developers] FeSL: Make XACML policies > first-class Fedora digital objects (FCREPO-577) > > Hi > > I have been following this discussion with great interest. > > Firstly I support the promotion of policies to first class objects. It > brings several advantages to Fedora > 1. An easy way to provide metadata about a policy (as the first class > object can of course have other datastreams) > 2. An easy way to replicate the logical contents of a repository > > Still, the current proposal falls short of my requirements. In our > repository, we have the socalled "License" objects. Data objects can > declare a "hasLicense" relation to such an object, and will then be > subject to the policy in the license object. The license object will > primarily control which user attributes are nessesary to view the > contents of the data object. > > The 1. point above, about the metadata about the policy is expecially > valid here. We want the legal formulation about the policy to be stored > alongside the technical implementation. > > We chose this design because we needed a straightforward way to change > which license a data object was released under, and because we needed a > simple way to query about objects available under a given license (ie. > available to a given user) > > The correct way, I feel, for the fedora policy design would be as > follows. > > Declare a Repository Object, called "fedora-system:Repository" (or > something) > > Create a number of Policy objects, containing a policy. The policies > that should be active for the entire repository should then be > referenced from the Repository Object. The policies that should be > active for a particular object should be referenced from that object. > The policies that should be active for a datastream should be > referenced > from the datastream's relations. > > Finding the relevant policies for an invocation would be easy, as they > will be the ones for the datastream referenced, the object referenced > and the repository. No need for the triple store to find these. > > If we wanted to speed this up, we could easily cache the Repository > wide > policies, and have some listener to update the cache upon changes to > RELS-EXT in Repository. > > If we cache all the Policy objects, the object and datastream lookup > will also be very fast. And since the entire object is parsed whenever > an operation is performed on it, the information about the PIDs of the > policies are readily available. > > > > > Please, at least use the central object to denote global policies. > Having all policy objects be automatically active for the entire > repository, with no way of turning them off is a backwards-compatible > disaster waiting to happen. > > > Regards > > > On Fri, 2010-02-12 at 08:00 +0100, Steve Bayliss wrote: > > > > > Is the policy manager service used for anything > > > > > other than > > > > > bootstrap (and unit tests :)? (or intended to be?) > > > > > > > > used for - no (apart from the tests!). intended to be - it was > in > > > > Muradora, it's an open question as to the form of a policy > > > management > > > > API > > > > > > I see. I think this is not really in scope for this issue, > > > but I'm just trying to see how this policy manager service > > > fits into the big picture in relation to this task. Do we > > > see "policies as fedora objects" as an end or a means? > > > > Potentially both - they could be seen as resources in their own > rights, > > perhaps part of a network of objects that includes scanned copies of > > actual licences, licence expressions (ODRL, ccREL, Onix-PL, MPEG-21 > REL etc) > > and licence policy enforcement expressions (XACML), all related to > > the resources to which they apply. > > > > > Externally, are the policy manager and future API to be the > > > primary focal point of policy management (and representation > > > as fedora objects is merely one implementation), or are > > > policies as fedora objects the primary focal point, with APIs > > > and managers performing a > > > supporting role for manipulating the ultimately-canonical objects? > I > > > think my questions have been motivated by the prospect of the > latter. > > > > I'd see this as something similar to the RELS datastreams - editable > in > > their own > > right as datastreams, but potentially with additional API methods for > > ease-of-use > > such as the relationships methods we currently have. Manipulating > XACML > > directly could be a barrier for some folks, so methods to simplify > adding > > and manipulating permissions could help. > > > > > > > > > I'd suggest they shouldn't be in a "fedora-system" namespace > unless > > > > they are non-editable and somehow essential to make Fedora > "work". > > > > Are the objects that are currently in the fedora-system namespace > > > > editable? > > > > > > Actually, yes, they are editable ... but there is also a fair > > > bit of hard-coded functionality that isn't! To confuse > > > things even more, consider the policies that are in the > > > "hands off" fedora-internal-use directory. I'm not sure > > > which makes most sense, but I just wanted to make note that > > > this could be a potential point of confusion. > > > To me, if policy objects are a means, I see the namespace > > > choice as unimportant. If policy objects are an end, I would > > > tend to favor 'fedora-system'. That's just my (not very > > > strong) opinion right now. > > > > Maybe one for further discussion then, I'll make sure that FCREPO-577 > is > > coded in such a way to allow for either situation for now. > > > > > > > > > > > > I think there's a difference here between deprecating and not yet > > > > implemented within FeSL ;o) > > > > > > Ahh, OK. I did not know object-level policies were not > > > implemented. To be honest, I've never really had to use this > > > functionality myself. > > > > Object level policies are implemented in the sense that FeSL > "understands" > > XACML policies directly identifying individual resources; resources > > that are members of identified collections can also be specified. > > > > What's not implemented is the ability to interpret policies as > applying to > > the > > object in which the policy resides. Currently in FeSL the XACML > needs to > > identify the resource. > > > > > > A question here is whether to (continue to) standardise on a > > > > datastream called POLICY for XACML policies, whether within > > > existing > > > > "data" objects or in stand-alone policy objects, or to make > > > that more > > > > flexible. > > > > > > There may be other options too (format URI, RELS-INT, > > > something in extended content models), but I don't know if > > > anything is any better than the proposed solution. > > > > I'm now tending towards standardising on a datastream name for > simplicity, > > however there is an inconsistency with the current XACML > implementation if > > we > > went for a POLICY datastream: > > > > Current situation > > - POLICY datastreams on Fedora objects automatically apply to the > resource > > containing the datastream > > - other policies are stored in specific filesystem directories > > > > FCREPO-577 current proposal > > - POLICY datastreams need to specify the resource to which they apply > > - POLICY datastreams can specify any resource > > - no policies in filesystem directories (other than for bootstrapping > > initial policy objects) > > > > So there's a case for FeSL using the (reserved) POLICY datastream for > some > > level > > of consistency, there's also a case for using a different datastream > name as > > there is a difference in interpretation of the XACML with respect to > > resource identification. > > > > So people migrating to FeSL where existing POLICY datastreams are in > play > > would > > find a change in behaviour. > > > > I think the subject of resource identification could be one for > discussion > > at > > the London meeting, potentially this could include things like > > - policy applies to object where POLICY datastream applies > > - policy applies to members of a collection (or more generally > specified > > through relationships between objects) > > - policy applies to objects with a specific content model > > - etc ... > > > > > > > > --------------------------------------------------------------------- > --------- > > SOLARIS 10 is the OS for Data Centers - provides features such as > DTrace, > > Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW > > http://p.sf.net/sfu/solaris-dev2dev > > _______________________________________________ > > Fedora-commons-developers mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/fedora-commons- > developers > > > > ----------------------------------------------------------------------- > ------- > SOLARIS 10 is the OS for Data Centers - provides features such as > DTrace, > Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW > http://p.sf.net/sfu/solaris-dev2dev > _______________________________________________ > Fedora-commons-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers ------------------------------------------------------- Fachinformationszentrum Karlsruhe, Gesellschaft für wissenschaftlich-technische Information mbH. Sitz der Gesellschaft: Eggenstein-Leopoldshafen, Amtsgericht Mannheim HRB 101892. Geschäftsführerin: Sabine Brünger-Weilandt. Vorsitzender des Aufsichtsrats: MinR Hermann Riehl. ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev _______________________________________________ Fedora-commons-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
