== FedoraXACML Evaluation Summary ==

 . '''Assumption''': Authentification is done outside DOMS. We are only concerned with authorization.
 . Evaluation: It seems Fedora Authorization with XACML Policy provides what we need.
   . ''What we need'': We have decided to use licenses in DOMS only to restrict who can view what material. See [[DataModel]].
   . We can specify an object-specific policy within the object's policy datastream. This datastream can refer to a policy in a 'license object' (rights object). The XACML policy of this license object can however '''not''' include a policy from a 'parent' license object. Note that this means that we have both a 'hasLicense' relation from object A to it's license object B and a reference from the policy datastream in A to a policy datastream in B. This means that there is a risk the two references get 'out of sync'. We however need the policy reference, and we want the RELS-EXT relation, as the license object also holds a textual description... 
 . We have decides on a DOMS architecture with a journaling style Fedora-Front and Fedora-Back, and we would like to enforce '''only''' repository wide policies for Fedora-Front (for the in-house DOMS manager GUI) {{{
<param name="VALIDATE-OBJECT-POLICIES-FROM-DATASTREAM" value="false"/>
}}} and both object policies and repository wide policies for Fedora-Back (for the read-only oai-harvester).
 . We want full edit rights for all in-house users, i.e. all users of the GUI.
 . Questions:
   . Who edits XACML policies? How? When?
   . Which attributes do we need? 'Access to material with this License'-attributes? Who manages those (i.e. manages which users have which attributes)?
   . Do we want to be able to create new attributes in connection with new collections?