Re: [xacml] <Advice> for NotApplicable

[Erik Rissanen <erik@axiomatics.com>]

Bill Parducci wrote:
>>>> <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?

Yes, it is true that there is a change in the processing. I thought you 
meant that there would be additional processing of nested policies 
needed to get advice from them as well. This is not necessary. It's only 
a matter of collecting the advice at the current level of evaluation, 
which is a very minor overhead for me.

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

Yes, I also now feel that there are subtleties which we don't 
understand, so I have changed my mind and I think that my proposal is a 
bad idea. I still think the use case is a valid one, but you have 
convinced me that we need to be careful with something like this. In 
particular, I think the point you brought up earlier about a advice 
"infecting" other policy domains is a concern. Thanks for the critical 
feedback. :-)

I'll think about whether there is an alternative way to solve the use case.

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

Yes, I consider that the same case. I saw two distinct cases: a target 
matches, in which case there are ambiguities "on the horizontal" about 
which of the nested policies are evaluated, and thus which obligations 
are returned. The second case is with advice with N/A and a non-matching 
target, in which case there could be ambiguity "on the vertical", about 
how deeply the PDP can go into non-applicable policies to get advice. 
The latter case is not a concern for obligations, since the "vertical" 
ambiguity occurs only in not applicable policies.

Regards,
Erik