MHonArc v2.5.0b2 -->
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
From: Anne Anderson <>
To: Polar Humenn <>
Date: Tue, 11 May 2004 16:01:56 -0400
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 <>
> To: XACML TC <>
> 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:
> > 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:
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311 Tel: 781/442-0928
Burlington, MA 01803-0902 USA Fax: 781/442-1692
