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] interior node <Result> elements for a hierarchy



Okay, so now I'm confused.
Why is what we agreed to not the same as this?

Maybe I had one two many tooters the night before, but I thought we had
agreed that you get results for *all* nodes with in the scope in the
request. You get one Result for each node found in the hierarchy. Each
Result applies only to the node itself, and says nothing about its
decendants (or ancestors).

Is that the agreed upon interpretation?

Cheers,
-Polar

On Tue, 11 May 2004, Anne Anderson wrote:

> On 11 May, Polar Humenn writes: Re: [xacml] interior node <Result> elements for a hierarchy
>  > On Tue, 11 May 2004, Anne Anderson wrote:
>  >
>  > > 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.
>  >
>  > How do you indicate the difference?
>  >
>  > What if I want a node that only gets Deny, only if all its children are
>  > Deny, and it gets Permit otherwise?
>
> You are right, I was wrong: I can't do that.  I can specify
> Permit or Deny for the specific interior node and I can
> separately specify Permit or Deny for each child.
>
> This is how XACML 1.0/1.1 worked.  As Seth put it, it is a matter
> of what semantics we assign to Permit or Deny on interior nodes.
> We currently have semantics that say, unless PEP processes the
> results otherwise, Permit or Deny on an interior node merely says
> one has Permit or Deny to that node and says nothing about access
> to any of its children.  The meaning of "Permit" or "Deny" to a
> single interior node will depend on the resource and how it is
> interpreted by the PEP.
>
> 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
>


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