Re: [xacml] Indeterminate Policy Targets [WAS: [xacml] Posted WD-19of core and WD-14 of SAML profile]

[rich levinson <rich.levinson@oracle.com>]

Hi Paul,

A quick response is that it is basically the same as the rule combining 
algorithms.
For example, in a deny-overrides policy, you have to continue evaluating 
policies
until you either:
      - find a deny,
      - or a permit with no deny (basically all permits),
      - or a permit and an indeterminate, which results in indeterminate.
The only way to avoid evaluating all policies is if you encounter a 
deny, then
you know the answer regardless of what the other policies might return.

If the Target of the current PolicySet is Indeterminate, then I expect one
would immediately return Indeterminate w/o evaluating the children, since
they are all predicated on successful evaluation of the Target.

This is distinct from the case where say there is a parent PolicySet 
that has
n child PolicySets, then if one of the child PolicySets is 
Indeterminate, then
you still need to evaluate the other child PolicySets using the 
algorithm above,
where the breakout point depends on what the combining algorithm and the
current set of child results imply at that point.

Finally, I don't think finding Indeterminate in the parent PolicySet 
Target is
ambiguous, because you would then look at the possible responses from
its children and if they were only Permits it would be Ind(P), if they were
only Denys then it would be Ind(D), and a mix would be Ind(DP).

I don't think there is much point in this last case of actually 
evaluating the
child Policies after the parent Target is Indeterminate, but there is a 
purpose
in "scanning" them to determine what their possible returns would have
been.

     Thanks,
     Rich


On 4/19/2011 11:00 AM, Tyson, Paul H wrote:
> Erik, good job on the spec.
>
> I have some misgivings about the "extended indeterminate" solution for
> policy[set] targets.
>
> When a policy or policy-set target evaluates to Indeterminate, are we
> saying that the PDP must still evaluate the children and apply the
> combining-algorithm?  I think that will result in a lot of extra
> evaluation for marginal benefits.
>
> At the root of the "extended indeterminate" problem for policy targets
> is the question: are we returning the possible indeterminate values that
> could result from evaluating the policy in *this* request context, or in
> *any possible* request context.  The 1st answer requires much more
> sophisticated processing (and might be undecidable in some cases); the
> 2nd answer can be determined simply by getting the unique values of the
> descendant Rule/@Effect attributes (including those reachable by policy
> references).
>
> Perhaps the "extended indeterminate" range of values should include an
> "Indeterminate{U}" value, interpreted as "it is unknown whether either a
> Deny or a Permit could be returned".  The default "Indeterminate{DP}"
> value says "it is certain that either a Permit or a Deny decision could
> be returned".  If this value bubbles up from rule evaluations, it is
> legitimate and perhaps helpful.  But if it comes from a policy target,
> it is ambiguous.
>
> We should reconsider whether to require full evaluation of policies or
> policy sets when the target is Indeterminate.  As a possible evaluation
> shortcut, we could specify returning an extended indeterminate value
> based on the descendant Rule/@Effect values, without requiring full
> evaluation.
>
> If the new sections 7.11, 7.12, and 7.13 stand as is, there are some
> additional editorial changes to make, but I will save those pending
> result of discussion.
>
> Regards,
> --Paul
>
>
>
> -----Original Message-----
> From: Erik Rissanen [mailto:erik@axiomatics.com]
> Sent: Thursday, April 14, 2011 12:17
> To: xacml
> Subject: [xacml] Posted WD-19 of core and WD-14 of SAML profile
>
> All,
>
> I have just uploaded XACML 3.0 core WD 19 and SAML profile WD 14. The
> fixes are for the recently found issues in CS-01:
>
> 1. CORE: Missing functions for the new dayTimeDuration and
> yearMonthDuration datatypes
>
> See
> http://lists.oasis-open.org/archives/xacml-comment/201012/msg00000.html
>
> The missing functions have been added and the old ones moved to planned
> for deprecation.
>
> 2. SAML: Inappropriate use of xsi:type in SAML profile protocol schemas
>
> See
> http://lists.oasis-open.org/archives/xacml-comment/201012/msg00001.html
>
> The schema has been corrected. Note that there is also a new spec
> document since the namespaces were changed. I also changed the assertion
>
> schemas although there were no errors in them, but just to make the
> "wd-14" in the namespaces the same. I figured that unless I do that,
> somebody is going to ask about it...
>
> 3. CORE: The x500Name-match function is not clearly defined
>
> http://lists.oasis-open.org/archives/xacml-comment/201101/msg00005.html
>
> I added an example.
>
> 4. CORE: Inconsistent definition for the any-of-all function
>
> See
> http://lists.oasis-open.org/archives/xacml-comment/201101/msg00006.html
>
> I removed the Haskell stuff.
>
> 5. This issue intentionally left blank.
>
> 6. CORE: Specification of extended indeterminate in combining algorithms
>
> is incomplete
>
> See
> http://lists.oasis-open.org/archives/xacml-comment/201103/msg00000.html
>
> I added the missing specifications as discussed on last week's meeting.
>
> 7. CORE: Erratum concerning the 'Expression Substitution Group'
>
> See http://lists.oasis-open.org/archives/xacml/201103/msg00036.html
>
> I removed the<Condition>  element from this list.
>
> 8. CORE: Obligations problem
>
> See http://lists.oasis-open.org/archives/xacml/201103/msg00037.html
>
> I changed the wording as suggested by Greg.
>
> 9. CORE: Incomplete definition of the ipAddress-is-in and dnsName-is-in
> functions
>
> See
> http://lists.oasis-open.org/archives/xacml-comment/201103/msg00006.html
>
> I removed these functions. Note that the other higher order functions
> were not defined for these data types anyway. They would have had the
> same issue.
>
> 10. CORE: Which argument is subtracted from the other by the
> integer-subtract function?
>
> See:
> http://lists.oasis-open.org/archives/xacml-comment/201103/msg00008.html
>
> I specified the order which is used in the 2.0 conformance tests.
>
> 11. CORE: Non-deterministic output of the string-from-type functions
>
> See
> http://lists.oasis-open.org/archives/xacml-comment/201103/msg00007.html
>
> I used the XSD canonical form where available, otherwise specified the
> form from the original XML encoding. Note, I also updated many other
> functions which also depended on datatype to string conversion. BTW, one
>
> of the functions was uri equals, and I checked the spec for XML
> namespaces, which depends heavily on uri equality testing, and they do
> the same as we, namely just compare the string representation straight,
> without any kind of interpretation or canonicalization of the URIs.
>
> Best regards,
> Erik
>
>
> ---------------------------------------------------------------------
> 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
>
>
> ---------------------------------------------------------------------
> 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
>