Re: [xacml] <Advice> for NotApplicable

[Erik Rissanen <erik@axiomatics.com>]

Hi Bill,

See responses inline.

bill parducci wrote:
>
> On Jan 14, 2009, at 6:34 AM, Erik Rissanen wrote:
>> 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.
>
> 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.

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.

>> Another question which was asked was what happens if lots of policies 
>> in the PDP contain <Advice> for NotApplicable? Wouldn't that mean 
>> that you get lots of <Advice> each time? Yes, but if you don't want 
>> that, then don't do it. :-)
>
> The problem I see with this (volume aside :) is that it seems that it 
> will require the Policy writer to be aware of the processing 
> ramifications and it makes any sort of multi-tenancy of security 
> domains untenable.

Yes, this is a valid concern. First note that it is already possible for 
policies to push up "bad stuff" into other domains in the form of 
incorrect decisions, for instance. But you are right, this does 
introduce another concern. Currently, if someone manages centrally a set 
of multi domain policies, he can isolate the domains by controlling high 
level targets, under which the "imported" domain specific policies are 
placed. In this manner the central manager can provide a degree of 
isolation between the domains.

However, if Advice are associated with NotApplicable results, the 
advices will always be able to taint the other domains, and there is no 
way to isolate the domains like we can now.

This is a reason for why we maybe shouldn't adopt my proposal. I'll 
think more about it. Thanks for realizing this. :-)

>> The <Advice> for NotApplicable is useful inside nested policies, in 
>> cases where higher level targets have constrained the matching 
>> requests already.
>
> 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.

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

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

Yes, we may want to clarify this, even if we don't do advice for 
notapplicable.

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

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.

>> I don't know, but if you think it is better, we could instead make a 
>> separate section for advice, rather than try to handle advice and 
>> obligations in the same section. The sections would look very 
>> similar, but the text would be a bit simpler to read and understand. 
>> What do you prefer?
>
> IMHO they are different things so a different section makes sense to 
> me (but that idea didn't get much traction in the TC last I broached 
> it :D )
>
> b
>