[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] wd-20 policy evaluation description
See inline. > -----Original Message----- > From: Erik Rissanen [mailto:erik@axiomatics.com] > Sent: Monday, May 30, 2011 09:58 > To: xacml@lists.oasis-open.org > Subject: Re: [xacml] wd-20 policy evaluation description > > Hi Paul, > > Thanks for the effort. See inline. > > On 2011-05-26 18:47, Paul Tyson wrote: > > Hi Erik& all > > > > I appreciate and admire the work Erik has done to put these late > changes > > on a complicated topic into the 3.0 spec. But there are a couple of > > things that I would like to discuss. > > > > The reworded first paragraphs under 7.12 and 7.13 are not clear > enough. > > Some of the wording from the previous version should be preserved, to > > make it clear that the Target determines applicability of the policy, > > while the combining algorithm applied to the Rule or Policy[Set] > > children determine the result. The wd-20 wording leaves open the > > interpretation that the Target participates in the combining > algorithm. > > Are you sure this is the case? I figured that the way the tables are > written, it is clear that if the target says NoMatch, then the result > is > NoMatch. If the target matches, then the combining algorithm decides > the > result, etc. > > The reason I dropped the text was that I wanted the tables to speak for > themselves. If we put text in there as well, the we are specifying the > same thing twice, and it's really cumbersome to capture the full, exact > meaning of the table in plain English. If the text is not exactly like > the table, then there is an ambiguity. I think my proposed wording is exactly like the table. The new wd-20 wording introduces confusion, because the 2nd sentence in 7.12 says: "A policy's value SHALL be determined by evaluation of the policy's target and rules, according to the specified rule-combining algorithm." This is a subtle but significant change from the previous wording, which did not allow the possibility of the Target participating in the rule-combining algorithm. Similarly for the 1st paragraph in 7.13. I guess we could strike the 2nd sentence in each paragraph, and just refer to the truth table. I find the tables to be a helpful summary but I would like the natural language explanation to be complete and precise--or at least not misleading. > > > For 7.12 opening paragraphs I propose: > > > > "The value of a policy SHALL be determined by its contents, > considered > > in relation to the contents of the request context. > > > > "The policy's target SHALL be evaluated to determine the > applicability > > of the policy. If the target evaluates to "Match" then the value of > the > > policy SHALL be determined by evaluating the policy's rules according > to > > the specified rule combining algorithm. If the target evaluates to > "No > > match" then the value of the policy shall be "Not Applicable". If > the > > target evaluates to "Indeterminate", then the value of the policy > shall > > be determined as if the policy's rules were evaluated according to > the > > specified rule combining algorithm, and then transforming the result > > according to Table 7 (Section 7.14)." > > > > For 7.13: > > > > "The value of a policy set SHALL be determined by its contents, > > considered in relation to the contents of the request context. > > > > "The policy set's target SHALL be evaluated to determine the > > applicability of the policy set. If the target evaluates to "Match" > > then the value of the policy set SHALL be determined by evaluating > the > > child policies and policy sets according to the specified policy > > combining algorithm. If the target evaluates to "No match" then the > > value of the policy set shall be "Not Applicable". If the target > > evaluates to "Indeterminate", then the value of the policy set shall > be > > determined as if the child policies and policy sets were evaluated > > according to the specified policy combining algorithm, and then > > transforming the result according to Table 7 (Section 7.14)." > > > > On another point: > > The clarification that extended indeterminate values shall not be > > returned from the top-level evaluation leaves me confused, if all it > > does is return plain Indeterminate. I probably still don't fully > > understand the extended intermediate indeterminate values, because I > > don't see where an "Indeterminate{P}" is ever construed as "Permit" > or > > an "Indeterminate{D}" as "Deny". The various indeterminate flavors > > simply bubble up through the policy evaluation process without > > influencing the results (except that {P} or {D} might become {DP}). > I > > thought the purpose was to reduce the incidence of indeterminacy when > a > > missing attribute, if supplied, would not change the decision. I > won't > > belabor this point, but if someone has a simple explanation I would > > appreciate it. Otherwise I will study it further. > > This was simply intended to make it clear that all of Indeterminate{*} > become just plain Indeterminate in the <Result> in the response from > the > PDP. If it is not clear, could you propose a better wording? No, the spec is clear about the ultimate return value. The whole Ind{P|D} business doesn't make sense when I try to analyze what difference these values make to policy evaluation, because the different flavors of Ind never appear to change a decision--they just bubble up to the top, perhaps becoming more indeterminate (e.g., Ind{P} -> Ind{DP}). Regards, --Paul
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]