second proposal for hierarchical resources

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

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