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] 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
 > 
 > 
 > 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_workgro
 > up.php.
 > 
 > 
 > 
 > 
 > 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]