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] | [List Home]

Subject: RE: [xacml] wd-19 indeterminate policy target handling


From: rich levinson [mailto:rich.levinson@oracle.com] 
Sent: Thursday, May 19, 2011 11:38 PM
To: xacml@lists.oasis-open.org
Subject: Re: [xacml] wd-19 indeterminate policy target handling

>> Just to answer your question (see mtg minutes for overall issue disposition), I will try again
to make the point:
Assume the current processing location is that the PolicySet has just been
called for evaluation, and it "knows" it needs to obtain a decision by sending
an array of Decisions from its children to the combining algorithm. <<

The current WD presents a conceptual explanation of how the algorithm should work, not an actual implementation. Therefore, the "array" of Decisions is not an actual array in the programming language sense. Instead, the algorithm could be implemented in a programming language to receive an iterator of Decisions, and the iterator could be lazy, meaning it will only evaluate the next Decision when that Decision is requested by the combining algorithm.

This is an implementation detail, one that we should leave to vendors implementing the spec. All we should care about is that we have a description that allows vendors to implement the algorithms in a consistent manner, and that there is at least one efficient implementation imaginable. Since I've given one above, I think our work here is done. Do you agree?

>> So, the code that knows it needs to send the array of Decisions to the combining
algorithm now needs to "evaluate" each Policy that it wants a Decision from and
add that Decision to the array it is going to pass. <<

This is not true, see my comment about lazy iterators above.

>> * If it wants to send Decisions from all its children, then there are no issues because
it doesn't have to "know" very much to take this approach.
 * However, if it wants to send the minimum Decisions that it can get away with
evaluating then it must decide which Policies to evaluate, and it will have to have
some basis for selecting a subset of the full set of 10 Policies in the example. <<

No, the combining algorithm should drive which subset to evaluate.

>> o One way to achieve this is for the code to know it is calling a deny-overrides
combining algorithm, and it can then only evaluate Policies until it finds a
Deny, and then only submit that one Decision or whatever set of Decisions
it has accumulated up to that point.
o However, I claim that by requiring the caller to know about the algorithm
that it is calling and to prune its policy selection accordingly has a multitude
of undesirable effects, such as:
* It now becomes very unclear to anyone analyzing the PolicySet, what
criteria are going to be used to select the Decisions to send to the
algorithm, and as a result makes the PolicySet nearly impossible to
analyze by simply looking at the Policy and not knowing details of
the implementation. <<

Not at all. The current WD specifies the conceptual workings of the algorithm, and that should be enough to analyze the PolicySet.

>> * Things get even more obscure when one considers changing the algorithm for
the PolicySet. If I change to permit-overrides, then which Policies will then be
selected to send to the algorithm?
o Clearly I can't use the same criteria as above where I stopped when I found
the first Deny.
* The overall point is that this structure of passing in the processed nodes as opposed
to the unprocessed nodes puts the burden on the implementer to decide which nodes
to send in <<

No, see my comment about lazy iterators above.

>> , and, even worse, in my opinion, makes it nearly impossible for an
administrator to clearly say what the behavior is going to be based only on the
XACML language of the PolicySet and its descendants. <<

I don't understand that claim at all. The current description is clear to me as to what effect the combining algorithm should have. What do you think an administrator will not understand?

>> On the other hand, I believe the proposal I sent earlier, which requires some modest
changes, with some defined benefits, makes all these potential issues go away. <<

I agree with that statement, but I still prefer a conceptual description over one that is implementation-centric. We should not steer vendors in a certain direction, but give them as much freedom as possible to come up with innovative solutions.


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