Re: [xacml] wd-20 policy evaluation description

[Erik Rissanen <erik@axiomatics.com>]

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.

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

Best regards,
Erik


> Regards,
> --Paul
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>