interior node <Result> elements for a hierarchy

[Anne Anderson <Anne.Anderson@Sun.COM>]

We decided at the Face-to-Face that we could return <Result>
elements only for leaf nodes in a hierarchy.  The reason was that
we thought the <Result> values for interior nodes could be
ambiguous otherwise.

Seth has convince me that this is not the case.  I think our
decision was made when we were still exploring the possibility of
having a single evaluation cover multiple nodes in a Request,
where I think there is a possibility for ambiguity.  Our current
proposal, which does not include this, does not have a problem
with interior nodes.

We have decided to retain the XACML 1.1 semantics that a Request
for multiple nodes SHALL be equivalent to the <Result> elements
produced by evaluating each requested node individually: i.e. the
fact.  This means an unambiguous <Result> can be returned for
each node.  For some types of hierarchy, an interior node will
get Permit only if all its children get Permit, or will get Deny
unless all its children get Permit, but this is up to the policy.

Unless someone gives me a good reason otherwise, I plan to
specify that a <Result> SHALL be returned for each requested node
in a hierarchy.  This retains backwards compatibility with the
XACML 1.0/1.1 "scope" description.

Anne
-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692