Re: [xacml] Boolean Policy resolution - a slight modification

[bill parducci <bill@parducci.net>]

it seems that we are actually trying to solve two problems with the 
'<and>' issue:

1. determining applicability of [sub]policies
2. determining evaluation result of resulting policy

as i have stated in prior notes, i am not in favor of a policy resolving 
to true where any of the predicates evaluate to anything other than true 
and are combined with an '<and>' (true = true + n/a). on the other hand 
i support the idea of policy inclusion logic using this mechanism as hal 
has proposed below.

in thinking more about this it seems that these functions should be 
handled separately (syntactically). what came to mind is the concept of 
a 'join'. it seems to me that behavior we are looking for with respect 
to aggregate policies ('use if it applies, ignore otherwise') is more in 
line with a 'join' than 'and'.

<join>
      <applicablePolicyReference>
          xprp://policy.sample.com/$TargetValues
      </applicablePolicyReference>
</join>

this leaves the term '<and>' with the forcefulness that i believe is 
appropriate.

does this make sense?

b

-------- Original Message --------
Subject: RE: [xacml] Boolean Policy resolution - a slight modification
Date: Thu, 31 Jan 2002 11:02:57 -0500
From: Hal Lockhart <hal.lockhart@entegrity.com>
To: "'Anne Anderson'" <Anne.Anderson@Sun.com>, XACML TC 
<xacml@lists.oasis-open.org>

[...]

> Since this can return multiple applicable policies, I further propose 
> that the surrounding combinator treat each returned applicable policy as 
> if it were a distinct predicate. In other words (Polar should like this) 
> this:
> 
> <and>
>     <applicablePolicyReference>
>         xprp://policy.sample.com/$TargetValues
>     </applicablePolicyReference>
> </and>
> 
> means that value of each applicable policy returned is anded with the 
> others (and any other retrevial points with in the combinator), as usual 
> dropping the ones that turn out to be inapplicable.