OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [xacml] xacml model subcommittee - minutes of Jan.7 concall


MINUTES OF THE 7 JAN. 2002 CONCALL
==================================

Anne noted that a suggestion previously made by Tim on post-conditions
was not reflected in the issues list. The suggestion was that only the
post-conditions associated with the rules that were evaluated to get
to an access decisions should be executed (this in response to the
comment that post-conditions have the drawback of requesting the
evaluation of *all* rules). Pierangela notes that a possible drawback
of this approach is that deterministic behavior may be lost. For
instance, there may be N rules applying to an access request. If the
evaluation of 1 of them brings to a ``permit'' decision (so there is
no need to evaluate the others); then, you would ignore the
postconditions possibly associated with the other N-1. Different
executions of the same request on the same state could then have a
different behavior (because a different rule is considered as
authorizing the request). Pierangela to update the issue list
to include Tim's suggestion and related comment.

There was a discussion about triplet vs. pre-condition option. Simon
mentions that attributes with the same name for principals and resources
could be a problem. As an example, you have an attribute named
``color'' for resources and principals, how do you know which one you
are referring to? Anne and Carlisle note that the attribute will be
referred to with the complete path expression so you woud know if you
are referring to the principal or the resource. Simon agrees on it but
fears that mixing predicates on all attributes in a single expression
could bring confusion for simple cases when - in the triplet solution
- the element in which the predicate appears could solve the
ambiguity.

Ernesto draws the attention on policy composition (which is a recent
issue) to see if everybody agrees on how the problems associated with
it are listed. In particular he asks Tim whether an applicable policy
can refer to several policies (the schema assumes one single policy).
there are three possible approaches:
1) there may be more policies applicable to each  resource which will
   be stated in different policy documents with overlapping targets [Hal]
2) we have a PRP, that takes the fragments and unifies them in a single
   policy (applicable policy) [Tim]. PRP returns a self-contained 
   applicable policy to the PDP. In principle the applicable policy can
   be distributed in different documents (overlapping targets),
   ensuring that retrieval brings you the complete set of rules is done
   at run-time.
3) logical expressions of policies [example in issue list] or policy 
   fragments [Anne].
   There is a single applicable policy for each request but the
   applicable policy can refer to (be a logical expression of)
   different policies (which could be distributed). Each Policy can be
   a path expression that points to a set of rules.

Tim says that the current schema supports the first two approaches,
not the last (as it does not allow logical expressions of policies).
Ernesto recalls Michiharu's proposal of pointing to an external URI
where the way policies should be combined is stated.  Anne says that
at the last concall Michiharu stated that his proposal was a
``radical'' extension, not compatible with the current solution (use
of ``deny'' in solving policies would require you to change the
language and the semantics).  In particular, Anne mentions a problem
with negative authorizations that could have a ``global effect''. For
instance, if you have a policy composition P1 OR P2, even if P1 says
that access should be granted you cannot stop access control, you
should evaluate P2 as well, as it may contain negative rules which, in
a denial-takes-precedence policy should win over P1 decision.
Pierangela agrees on this but notes that in a previous concall it was
agreed that the scope of the negative rule should be confined within a
policy.  Pierangela notes that it might still be possible to allow a
policy to explicitely state a negation allowing policies to return a
3-valued decision. Composition operators should be redefined
accordingly. This matter is to be investigated further. Allowing a
3-valued decision and refining the operators accordingly may increase
expressiveness with limited complications. For instance you can
express a policy that says ``grant access if the department permits
(P1 retuns `permit') and central administration does not have any
objection to it (P2 does not return `deny'). Note that in a case of a
3-valued solution, returning `deny' is different from returning
`null' (instead in a 2-valued scenario null is mapped to the default
decision)..

Anne recalls that in previous concalls it was mentioned that 80\% of
the requirements should be met by the core syntax. If negative
policies are part of the requirements, negative policies should be
part of the core.

Anne starts a discussion regarding whose task it is to state how
policies should be combined.  Is it for the PDP, PEP, PRP? Follows
some discussion (i got lost in it), Tim to supply a diagram via email
to clarify the matter.

Ernesto draws attention to the problem of composition
w.r.t. distribution of policies. Assuming composition is because of
distribution of policies, we should decide whether we want to support
composition explicitly.
Pierangela mentions that distribution may mean conceptual
distribution (not necessarily geographical). I may want to be able to
express logic expressions combining policies which are maintained by
separate authorities, regardless of their physical location. Tim says
that the current schema should be able to accomodate this last case
(details w.r.t. how to be provided).

ACTIONS:
- Pierangela to update the issue list according to tonight discussion 
- Ken to organize the issue list and number issues (wait for tomorrow 
  version)
- Tim to update the document on changes people already agreed on
- Tim to update the glossary to reflect changes agreed
- Everybody who has input for the glossary to send a msg to Tim.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC