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

[Sekhar Vajjhala - Sun Microsystems <sekhar.vajjhala@sun.com>]

> * [line, 130, subject] change to "the entity that submits access
>    requests"

How about "an entity that is the source of an access request" ?

The interpretation of the source is from the point of view PDP.
So it could be the "initiator" or the "intermediary".

Sekhar


Pierangela wrote:
> 
> 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
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

-- 
Sekhar