xacml — archive

[Polar Humenn]

Hi Bill, You still have the problem for including your proposed "<join>" components with other combinations of "<and>" and "<or>". So, I think it doesn't really buy you much more. I may have a good sound evaluation strategy by later today. Performing the work on the lattice had actually got me to think of the problem a litte harder. Cheers, -Polar On Thu, 7 Feb 2002, bill parducci wrote: > 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 > >