Some observations

[John Howard <john.howard9@btinternet.com>]

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.