MHonArc v2.5.0b2 -->
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]