RE: [xacml] wd-20 policy evaluation description

["Tyson, Paul H" <PTyson@bellhelicopter.textron.com>]

Regarding the wording of 7.12 and 7.13: I don't want to see "target", "rule" (or "policy"), and "combining algorithm" mentioned in the same sentence unless it is clear that the combining algorithm only applies to the child rules (or policies), and not to the target.

Thanks for the example of extended indeterminate values.  I see now how an indeterminate value can be swallowed by the algorithm.

Regards,
--Paul

> -----Original Message-----
> From: Erik Rissanen [mailto:erik@axiomatics.com]
> Sent: Tuesday, May 31, 2011 09:58
> To: Tyson, Paul H
> Cc: xacml@lists.oasis-open.org
> Subject: Re: [xacml] wd-20 policy evaluation description
> 
> Hi Paul,
> 
> See inline.
> 
> On 2011-05-31 15:08, Tyson, Paul H wrote:
> > 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.
> 
> Sure, it should not be misleading. We could fix that sentence. If we
> put
> a full description, then at the least we must make it non-normative.
> 
> >>> 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}).
> 
> Here is an example. Without extended values:
> 
> deny-overrides:
>    Indeterminate
>    Permit
> ->>> Result should be Indeterminate because first child could have been
> deny if there would not have been an error
> 
> With extended values:
> 
> deny-overrides:
>    Indeterminate{P}
>    Permit
> ->>> Result should be Permit since second child says explicitly Permit
> and the first child could not have changed that even if there would
> have
> not been any error.
> 
> Best regards,
> Erik
>