[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xacml] Re: Minutes of Feb 18 Policy model subcommittee concall
> * [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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC