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