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-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]