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

[Erik Rissanen <erik@axiomatics.com>]

Hi Rich,

See inline.

On 2011-04-19 20:55, rich levinson wrote:
> 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.

Yes, but the question is which type of Indeterminate? {P}, {D} or {DP}? 
This was the issue which was posted on the comments list.

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

This is what Paul is proposing, but I think what I wrote is safer. See 
my other response to Paul.

Best regards,
Erik


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