Following is an alternative to "first proposal for hierarchical
resources"
(http://lists.oasis-open.org/archives/xacml/200304/msg00057.html).
This second proposal explicitly deals with all the following
aspects of the "hierarchical resource" problem:
<Policy> EXPRESSION ASPECTS OF THE PROBLEM:
a) How, where xpath-node-match is insufficient, to express
matches between a resource description contained in a
<Request> with a resource description contained in a <Policy>,
where the resource is hierarchical.
b) How to express permitted <Actions> for a resource, where
certain <Action> identifiers imply other <Action>
identifiers.
c) How to express permitted <Actions> for a resource, where
certain <Action> identifiers require being permitted to
perform the <Action> on every node above or below the
immediate node being accessed.
<Policy> EVALUATION ASPECTS OF THE PROBLEM:
d) Define how an "xpath-node-match" in a <Policy> interacts with
a <Resource> in a Request that has a "resource:scope"
Attribute.
e) How to deal with a <Resource> having a "resource:scope"
Attribute where the <Resource> can not be described using
"xpath-node-match".
SECOND PROPOSAL
For each Resource Model, a new DataType identifier SHALL be
created.
For each new Resource Model DataType identifier, a new FunctionId
identifier of the form "<DataType>-match" SHALL be created.
A textual or functional description SHALL be provided in
association with each new Resource Model DataType and
"<DataType>-match" FunctionId. This description SHALL include:
1) The syntax to be used for describing a requested resource of
this DataType (that is, the format for literal values
associated with a particular node in this resource hierarchy).
2) The syntax to be used for describing template or collective
descriptions of resources of this DataType (that is, the
format for "regular expressions" of this DataType).
3) The rules for matching literal values with templates of this
DataType.
4) Optionally (if allowed), rules for matching templates of this
DataType with other templates of this DataType (that is, where
Requester wants access to the collection of nodes described by
a template).
5) The set of or namespace for "action:action-id" identifiers
associated with this new Resource Model DataType.
6) The propagation rules for each "action:action-id" identifier
associated with this new Resource Model DataType.
7) The implication rules for each "action:action-id" identifier
associated with this new Resource Model DataType.
8) The rules for how the PDP shall evaluate a <Request>
having a Resource with both a "resource:resource-id" Attribute
using this new "DataType" AND having a "resource:scope"
Attribute. The rules may simply specify "not supported".
Any XACML PDP that claims to support the new Resource Model
DataType SHALL implement support for all functionality in the
description.
Anne Anderson
--
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