RE: [xacml] XACML Profile for Hierarchical Resources, WD 8

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

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:Anne.Anderson@Sun.COM] 
 > 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:Anne.Anderson@Sun.COM] 
 >  > 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: 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