Re: [xacml] <Advice> for NotApplicable

[Bill Parducci <bill@parducci.net>]

>>> <Eric>
>>> One question which was posed on the call last week was whether the  
>>> <Advice> is returned if the target of a policy does not match. I  
>>> suppose that this should be clarified since this is an issue which  
>>> does not occuer with obligations since the FullfilOn (Permit or  
>>> Deny) cannot match the policy value if the policy target does not  
>>> match. I then said that I hadn't thought about it. I propose that  
>>> it will be returned if the target does not match, since evaluating  
>>> the target meanst that the policy has been evaluated.
>> <Bill>
>> Doesn't this then mean that the PDP will have to perform a unique  
>> evaluation for Advice? E.g. should the "traditional" evaluation  
>> result in NA a second pass would need to be made to discover all  
>> Advice of type NA throughout the Policy corpora where the Target  
>> didn't match, etc.
> <Eric>
> I can't speak for other implementations, but in the Axiomatics  
> implementation it would not be an overhead since obligations/advice  
> are already referenced, since we don't evaluate XACML in XML form.  
> And note that it's only the <Advice> at the same level where the  
> target is located which are included in the result. Not advice  
> nested more deeply in the policy tree, so it's not necessary to scan  
> the tree deeper than what would be evaluated anyway.

Sorry, I still do not understand this. I assume that you are  
performing a Target match then proceeding. With Obligations and/or  
Advice bound to Permit|Deny there is no need to consider non-Target  
match Polices (and their children) further. In the case of adding Not  
Applicable as a valid trigger, alternative processing would have to  
occur from that needed for Permit|Deny to collect this information,  
right? In other words,  regardless of the internal syntactical  
structure the process by which the "traditional" decision is made has  
to be different/distinct from how NA based information is gathered,  
right?


> <Eric>
>>> The <Advice> for NotApplicable is useful inside nested policies,  
>>> in cases where higher level targets have constrained the matching  
>>> requests already.
>> <Bill>
>> But is this true? My understanding of Not Applicable is that it is  
>> the set of all conditional logic that doesn't apply to a decision.  
>> I don't understand how nesting alleviates that.
> <Eric>
> No, the point is that if a target does not match, then advice nested  
> below that target MUST NOT be included (because we define the spec  
> so it's like that).
I would offer that is because the model is built around a binary  
decision system. Trying to make Indeterminate, Not Applicable, etc.  
actionable introduces subtleties that don't exist in this framework. I  
suggest that the working definition of what is not applicable to a  
decision is one of those. :)

>>> <Eric>
>>> One issue with obligations in general in the current spec is that  
>>> the combining algorithms are ambigious about evaluation order.  
>>> Now, I am not talking about that the basic combining algorithm may  
>>> evaluate their child policies in any order. If that is a problem,  
>>> then the user can use an ordered combining algorithm. What I mean  
>>> is that none of the combining algorithms say anything about  
>>> whether the PDP may continue evaluating policies even after it has  
>>> reached a decision. Consider this example:
>>>
>>> <PolicySet CombiningAlg="ordered-permit-overrides">
>>> <Policy> evalutates to permit, with Obligation 1 </Policy>
>>> <Policy> evalutates to permit, with Obligation 2 </Policy>
>>> </PolicySet>
>>>
>>> In this case a typical implementation would stop after the first  
>>> policy and only return obligation 1. But I don't see anything in  
>>> the spec disallowing the combining algorithm to continue evaluate  
>>> the remaining policies and also including obligation 2 into the  
>>> result.
>> <Bill>
>> This is an excellent point. I believe that the common assumption is  
>> that the PDP will only return those Obligations that were  
>> associated directly with the Policy that lead to results generated  
>> by the local processing model. Obligations have been a form of  
>> baggage that tags along.
> <Eric>
> Yes, we may want to clarify this, even if we don't do advice for  
> notapplicable.

Agreed.


>>> <Eric>
>>> A related issue is that the order in which policies are evaluted  
>>> with respect to child<->parent is not defined either. This is not  
>>> a real problem for obligations, but for <Advice> with  
>>> NotApplicable it is since it is conceivable that the PDP continues  
>>> evaluating nested policies even if a policy set target does not  
>>> match. Look at the medical example again:
>> <Bill>
>> Actually, using the same logic wouldn't it impact Obligations as  
>> well for a similar reason to what you outline above? Combining  
>> Policies with a simple [Permit|Deny]-Overrides is not ordered so in  
>> theory the decision can be arrived upon without fully considering  
>> all of the Target matches, yes? If so, then you have the same  
>> problem: a Policy that was Applicable--but not "necessary" for a  
>> decision--might have its Obligations ignored, but might not :)
> <Eric>
> No, because if the target is notapplicable, then no obligations  
> would not be returned anyway, so it wouldn't make any difference  
> even if the PDP would evaluate all the nested policies and collect  
> obligations from them, just to throw them out because it's a  
> nonApplicable on the whole.

Actually I was referring to the case where the Target is applicable.  
Consider a PolicySet that has 3 Policies combined with Permit- 
Override. Assume that the Target matches on all 3 Policies. Assume  
that all 3 Policies result in Permit IF evaluated.

Now, consider a system that reads the PolicySet, grabs one of the  
Policies, matches the Target and computes a Permit. The highly  
optimized PDP realizes that the results of the other Policies is  
unimportant because it has a Permit in a Permit-Overrides scenario. It  
therefore gathers the Obligation(s) from that Policy and sends them up  
with a Permit.

In this scenario isn't the fate of the other two Policies +  
Obligations the same that you describe in the ordered case?

thanks

b