[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] interior node <Result> elements for a hierarchy
I *think* what we agreed at the F2F (informal agreemennt, not a vote) was that <Result> elements would be returned only for leaf nodes. This was in the context of a bunch of other assumptions, however, so I am just trying to clarify what the group wants to do under our current assumptions. I am proposing now exactly what you state below: > 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). And this is consistent with the semantics specified for XACML 1.0/1.1. Anne On 11 May, Polar Humenn writes: Re: [xacml] interior node <Result> elements for a hierarchy > From: Polar Humenn <polar@syr.edu> > To: XACML TC <xacml@lists.oasis-open.org> > Subject: Re: [xacml] interior node <Result> elements for a hierarchy > Date: Tue, 11 May 2004 15:57:16 -0400 (EDT) > > > 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 > > > > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php. > -- 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]