Daniel, I have responded to your comments in the new Draft 09 as
follows:
On 15 September, Daniel Engovatov writes: RE: [xacml] XACML Profile for Hierarchical Resources, WD 8
> An example would be
> Allow delete any file in directory, but not the directory itself:
> GRANT(delete, "/a/b" = resource-ancestors)
> //remembering that "=" is equivalent to "in-bag" for target matching
> operations
>
> For the case when you are allow to delete directory as well(/a/b in this
> case) that would be:
> GRANT(delete, "/a/b" = resource-ancestors-or-self)
>
> In general, when hierarchy has non-heterogeneous resources, ancestors,
> distinct from ancestors-or-self would be useful to have.
I have added an "resource-ancestor-or-self" AttributeId, and
inserted a description of its use everywhere there is currently a
description of the "resource-ancestor" attribute. I also defined
URIs to represent support for the "resource-ancestor-or-self"
functionality.
> The reason I suggested defining ancestors-or-self using the type-union
> function definition is to avoid duplicating the "self" in cases when the
> ancestors are defined to include the "self".
I made no changes for this, and also did not add any comments
about "don't compute ancestors by recursively computing parents".
The Profile does not say how to compute the "resource-ancestor"
or "resource-ancestor-or-self" attribute. The current semantic
description precludes multiple instances of the same normative
identity of any node in a "resource-ancestor" or
"resource-ancestor-or-self" attribute, so I would rather minimize
the changes at this point, and not start introducing
implementation notes. I think the current semantic description
is sufficient.
> As far as "parent", I think they are not generally needed, as for system
> requiring one level deep inheritance that can be handled with an
> appropriate definition of what "ancestor" is. So I would also think
> that "parent-or-self" is redundant.
I did not define a new "resource-parent-or-self" attribute.
Anne
> Daniel;
>
> -----Original Message-----
> From: Anne Anderson [mailto:]
> Sent: Wednesday, September 15, 2004 8:24 AM
> To: XACML TC
> Subject: RE: [xacml] XACML Profile for Hierarchical Resources, WD 8
>
> Can anyone supply a use case for where a policy will be based on
> the ancestors of a node, but not the node itself? I would rather
> not add a new AttributeId, but if there are no use cases for
> "ancestors not including self", then I would be happy to change
> "resource-ancestor" to "resource-ancestor-or-self".
>
>
> And do we need a "resource-parent-or-self"? I can't think of a
> use case. So is leaving "resource-parent" without including
> "self" OK?
>
> On 14 September, Daniel Engovatov writes: RE: [xacml] XACML Profile for
> Hierarchical Resources, WD 8
>
> > 1.
> > For the non XML hierarchy, we either need to add to the definition of
> > the resource-ancestor, that it does include the resource-id of the
> > resource itself. It is important for the use case of policies
> > applicable to a resource itself and all its children: so you do not
> need
> > to write two rules.
>
> > OR (probably preferably, as it fits along with XQuery/XPath axes
> > definitions): add definition for
> > urn:oasis:names:tc:xacml:2.0:resource:resource-ancestor-or-self
>
> > "For each ancestor of the node specified in the "resource-id"
> attribute
> > or attributes, and for each normative representation of that ancestor
> > node, an <Attribute> element with AttributeId
> > "urn:oasis::names:tc:xacml:2.0:resource:resource-ancestor-or-self".
>
> > The <AttributeValue> of this <Attribute> SHALL be the result of
> applying
> > urn:oasis:names:tc:xacml:1.0:function:type-union function to the
> > contents of
> > "resource-id" and "resource-ancestor" attributes, where the "type" is
> > selected according to the used datatype of those attributes."
>
> > 2.
> > We need to mention in the definition of "resource-ancestor", that it
> can
> > not be guaranteed to be computed by recursively combining
> > "resource-parent" values. Parent of a parent is not necessarily
> defined
> > as an ancestor in our case (this is to avoid circular reference and
> > other problems). That may seem odd, but we should not impose
> > unnecessary requirements on the structure.
>
> I'll have to admit I don't understand this. Exactly why can't
> you define "resource-ancestor" by recursively combining
> "resource-parent"? Why does that introduce circular references?
> Can you give a concrete example?
>
> Anne
>
> > Daniel;
>
> > -----Original Message-----
> > From: Anne Anderson [mailto:]
> > Sent: Tuesday, September 14, 2004 10:29 AM
> > To: XACML TC
> > Subject: [xacml] XACML Profile for Hierarchical Resources, WD 8
>
> > Colleagues,
>
> > I have entered a new draft of the Profile for Hierarchical
> > Resources into the repository. The link on our TC web page now
> > points to it.
>
> > The changes since the previous draft are:
>
> > In response to Michiharu's comment in
> > http://lists.oasis-open.org/archives/xacml/200409/msg00002.html
>
> > - Add clarifying paragraph to the introduction explaining that a
> > hierarchical resource may be "represented" as an XML document
> > even if it physically is not an XML document; likewise, an XML
> > document resource may be "represented" as a non-XML hierarchy.
> >
> > - Change all instances of "XML document resource" to "a resource
> > represented as an XML document" (the exact wording varies
> > depending on the context)
> >
> > I also re-inserted the definition of xpath-expression DataType,
> > since it is no longer in the XACML core spec.
> >
> > 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
