[xacml] Re: Minutes of Feb 18 Policy model subcommittee concall

[Pierangela Samarati <samarati@pinky.crema.unimi.it>]

MINUTES OF THE POLICY MODEL SUBCOMMITTEE (MONDAY, FEB. 18 2002)
===============================================================

PRESENT
* Anne Anderson (Sun) 
* Carlisle Adams (Entrust)
* Ernesto Damiani (Unimi)
* Simon Godik (Crosslogix)
* Polar Humenn
* Michiharu Kudoh (IBM)
* Fred Moses
* Pierangela Samarati (Unimi)
* Donn Flinn

---------------------------------------------------------------

We went over Tim's document, below is a summary of the points we
touched and corrections requested to the document (points requiring
corrections are anticipated by *). Summary of discussion or
explanation is in the NOTE following each point.

* [line 98, access control] ``with policy'' change to ``with a
  policy''

[line 100, Attribute] Donn notes that it seems a circular
definition. Everybody agrees but it is also noted that this there
seems to be no better way to define it. 

* [line 102, authorization decision] ''of policy'' change to ''of a
  policy''. Also ``BOOLEAN range'' change to
  ``permit/deny/undetermined'' 

* [line 109, meta-policy] ''combining rules'' change to combining
  rules or policies"
  NOTE: A metapolicy can state how you should combine classes of rules
       or of policies. For instance, it could query attributes of
       rules (e.g., sign) or of policies (corporate policies as
       opposed to department policies). Simon notes there are two
       components. one is how to solve conflicts, you do not really
       need this syntax. The other level is when you start combining
       policies, here you need the expressive power of the metapolicy
       language. So for meta-policies associated with elementary
       policies we could have a pre-defined URI expressing the
       conflict resolution policy without need to use the metapolicy
       specification language. It is however noted that at the URI you
       should find a metapolicy expressed.

* [line 110, meta-policy-one] Question: do we want it?
  NOTE: We once said it would be nice if we had at least an example of
        meta-policy in our proposal. Should we have it explicitly
        mentiones ``meta-policy one''?



* [line 111, policy] Change the entry to say ``Applicable policy''
  also add in the definition ``plus a specification of how to combine
  them'' 
  NOTE: The current definition sees policy from the PDP point of
        view. It is noted that there is another point of view with
        which to look at policy: the policy writer point of view. If,
        as a department, I specify certain authorizations, to me that
        set is a policy even if it not complete w.r.t. an access
        decision (since there are corporate authorizations to be
        enforced also, and even if it refers to more than one access.
        It is suggested to capture both view point by distinguishing
        the definition of ``policy'' (point of view of the policy
        writer) and ``applicable policy'' (point of view of the PDP).

* Add definition of ``Policy'' as ``A set of rules or an expression of
  policies with associated a specification of how to combine them
  (metapolicy)''

* [line 112, PAP] ``rules'' change to ``policies''
  Note: the administrative unit is the policy, not the rule

* [line 118, PRP] ``creates policy from rules'' change to ``creates a
  policy from "from component policies or rules"

* [lines 127&128, Role and role mapping] Remove
  NOTE: we do not support roles in a traditional sense of RBAC access
        control. Also it is not clear if the clear separation between
        groups and roles that holds in traditional context (role is
        set of privileges and is dynamic, group is set of people and
        is static) would apply in our open scenario (for instance
        ``Oasis member'' expresses a group or a role concept). Donn
        suggests not to put such concepts in the glossary. It is
        however agreed that roles and groups and important concept in
        access control and we should mention them and how we are able
        to support them. It is agreed to

* add the mention to roles and groups in Section 1.2- related terms
  and say that they are we support them through SAML assertions (that
  can state that a subject enjoys some roles or belong to some groups).

* [line 129, rule] It is agreed that it will need to be redefined, 
  the definition is postponed to after the model discussion (so we
  will have agreement of how a rule looks like)

  NOTE: Michiharu notes there is no rule element in the XML
        examples. Ernesto replies that there need not be, there is a
        rule type, you can call the elements how you want.

* [lines 136&137] To be rephrased as they are not correct. 
  NOTE: It's true that we are not using those terms but they are not
        attributes

* [line 138] We use subject (in line with SAML) not principal.

* [line, 130, subject] change to "the entity that submits access
   requests"
  NOTE: The definition as it is now is not informative. it is noted
  that the new definition proposed may not be comprehesive of all
  possible cases. For instance, there is the multiple subject
  examples: a patient asks the system to send its data to a
  doctor. Our subject will be the patient, how do we capture the
  doctor? Also, there is the case of objecty-oriented or Java based
  policies where you may need to consider which method called which
  method or consider the different parties (e.g., caller and owner) of
  a piece of code. Michiharu asks if we should capture the concept of
  a "initiator" (similar to multiple subjects, e.g. object oriented
  where a method delegate to another for making a request...)  It is
  proposed to keep the simple definition for now (to arrive to version
  1) and work later on possible extensions. Our version 1.0 should be
  able to satisfy functionalities for a number of cases and
  environments.  The ones that are not covered are to be taken as a
  basis for extensions. Ernesto notes that not supporting the cases
  for Java and o-o scenarios may result limiting.

* mention the concept of ``requestor'' and ``initiator'' in Section
  1.2 - related terms

* [line 131, target] Add ``A boolean expression on subject, resource
  and action that defines'' at the beginning.
  NOTE: Is the target really stated as such an expression (cf. F2F)

* [page 17, line 630] target refers to the old definition (should be
  updated). Also, element name applicable policy should be changed to
  policy statement.

Still pending concept we would like to convey but probably later in
the document reported here to remember it is that ``a policy is a
smallest unit that can be solved by the PDP'' (Simon ``a policy is the
smallest exportable unit -- i.e., the one on which you can define
combination (you do not combine rules but policies)

In the concall we went over section 1. Rest of the document for next
concall (Monday Feb. 25, 2002).

best
-p