Subject: Some observations
1. For RBAC there is a need to define policySet that are only accesible through a policySetIdReference, it would be useful if a policySet could be defined as either public or private. public policySets would always be evaluated, private policySets would only be evaluated if included as a reference. The next two comments arise from our experience in trying to graphically represent an XACML policy. 2. As any thought been given to defining function classes. For re-use it would be useful to be able to define a function class as a set of logic and a number of parameters. e.g. calculateAge would take a date of birth as a parameter and return the age in years. This condition could then be used to calculate Bart's DOB, or the Doctor's DOB for example. This is both good from a re-use point of view, but it is very benefical when graphically trying to represent XACML as a condition can then be modeled as a decision tree. With the decision tree consisting of the function classes. e.g. Is Under 18 ------- CalculateAge ------- dob | |------------- current Date dob and current Date are attributes. Is Under 18 and Calculate Age are functions. 3. The other addition that would be welcome is that of attribute aliasing. What we are finding is that the person who defines the model is not necessary the same person that will connect the policy to the real world. So a modeller would want to deal with abstract attributes, but the deployer would want to deal with real world attributes. e.g. LoanValue may be a XPath into the input document, Role may come from an external attribute server, but the modeller doesn't need to know this information and it would be good from a graphical representation of XACML if this could be hidden. Yes, we could keep a seperate meta-data file for a policy, but we feel there is a benefit for having all the information in the policy. John.