OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [xacml] <Advice> for NotApplicable

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,

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

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

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

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

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]