> * [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
