To: XACML TC:
This issue is intended to officially replace an existing issue, as will
be described below. In addition to pointing to the background emails
(item 1, below), a fresh explanation of the user visible
characteristics of the issue that is being raised will be described
below (item 2 below).
(Note: to people who have followed this issue, there should
be nothing new in this issue except to present it in terms that should
make determining its disposition should be easier for all to
understand.)
Finally, the slightly modified recommendation referenced below is
included as item 3 below:
Item 1. Background reference points for this issue (one does not now
have to follow these links and may skip to #2 below, but they are here
for anyone who wants or needs additional context):
the issue that initiated two clusters of long email discussions in the
past several weeks, with the first cluster initiated by this email:
http://lists.oasis-open.org/archives/xacml/200901/msg00031.html
the 2nd cluster was initiated by this email:
http://lists.oasis-open.org/archives/xacml/200902/msg00015.html
a commenter was also using the profile and requesting advice, which has
also contributed to demonstrating exactly why the omission in
description is considered to be severe, although, exactly what the
commenter was expecting has not yet been determined precisely:
http://lists.oasis-open.org/archives/xacml-comment/200901/msg00003.html
Finally, an initial proposal was suggested in this email, and is
effectively what will be proposed here, except it will take into
consideration the comments of the reply to that email:
http://lists.oasis-open.org/archives/xacml/200902/msg00052.html
Item 2. "User-friendly" description of the issue:
The launching point for understanding this problem may be seen in
version 2.0 of the hierarchical profile, all of which has been carried
over to version 3. The following paragraph on lines 73-77 of the
Hierarchical Resource Profile is where the problem begins, which is
carried thru the rest of the spec:
http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-hier-profile-spec-os.pdf
- "In this Profile, a resource organized as a hierarchy may be a
“tree” (a hierarchy with a single root) or a “forest” (a hierarchy with
multiple roots), but the hierarchy may not have cycles. Another term
for these two types of hierarchy is “Directed Acyclic Graph” or “DAG”.
All such resources are called hierarchical resources in this Profile.
An XML document is always structured as a “tree”. Other types of
hierarchical resources, such as files in a file system that supports
links, may be structured as “forests”."
The problem with this paragraph is that it equates 2 structures: Forest
and DAG. While it is true that a Forest is a subclass of DAG, the
behavior of these two objects, just as subclass and superclass in
object-oriented programming, is quite different.
Both these objects define an "ancestor" collecting algorithm, such that
when one identifies a node that access is requested to (the requested
node), the algorithm of the Forest and DAG specifies what "ancestors"
of the requested node to collect in order to determine what nodes
contain the requested node within their "scope".
By scope, what is meant, is that in hierarchical resources one often
defines the scope of a policy to be a specific node and all the nodes
in the subtree below that node. It is both the contents of the subtrees
of nodes and the set of ancestor nodes that is different between the
Forest and the DAG, as will now be explained.
This conceptualization is intended to show the distinctions between a
Forest and a DAG. This first set of bullets is intended to describe the
meaning of a DAG in terms of the hierarchies involved and what happens
to them as the concerning their "multi-hierarchical" properties:
- For a single hierarchy, the DAG and Forest are equivalent.
- It is only when you get cross-cutting and overlapping hierarchies
that the differences begin to appear, and the difference is that with
DAG, when you lay down the 2nd hierarchy you sweep up not only the
exact overlapping nodes of the first hierarchy, but the subtrees of all
those nodes as well. So, you get a "hierarchy plus". The "plus" is
still a hierarchical part of the 2nd hierarchy, but it is "additional"
stuff that is not in the original 2nd hierarchy.
- There is also a "plus" on the first hierarchy as well.
Specifically, when you lay the second hierarchy on the first, every
node of the first hierarchy which is a new member of the 2nd hierarchy,
also picks up additional members of the 2nd hierarchy that are in the
subtree of the node from the 2nd hierarchy that is overlapping the node
of the 1st hierarchy.
By contrast, for a Forest, which has a generally accepted
definition as to be a "disjoint set of trees":
- When you lay down the 2nd hierarchy over the first, any node of
the 1st hierarchy becomes also a node of the 2nd hierarchy, any node in
the 1st hierarchy that is not overlapped explicitly by the 2nd
hierarchy is not a member of the 2nd hierarchy.
- Similarly, the 2nd hierarchy only picks up the nodes of the first
hierarchy that actually overlap. i.e. the number of nodes in the 2nd
hierarchy does not change. The only change is that some nodes in the
2nd hierarchy are now members of the first as well. Similarly, the
first hierarchy is also unchanged in members, except that some of its
members are now also members of the 2nd hierarchy as well.
Hopefully, the description above should make it clear that Forest and
DAG are quite different objects, and that it is important to identify
them as such in the Hierarchical Resource Profile. Currently, the only
description of ancestor collection given in the profile is that for the
DAG in section 3.2 of the profile.
Interestingly, the URI naming issue is incidental and not a core factor
in resolution to this issue, because its only significance is that it
is very handy and has great performance advantages when used with the
Forest model, however, it is not particularly useful with the DAG
model, because the hierarchy it represents is only a portion of the
"hierarchy" that is "available" with the DAG.
Item 3: Proposed resolution for this issue:
The recommended solution to address this problem is the following,
which as mentioned above is a slight modification in the ref'd email
above:
- Modify existing document so that nonXML nodes are described with
DAG option and with Forest option. This can be done minimally as
follows:
- Add explanatory text, similar to what is above in section 1,
intro text and glossary to explain distinction of Forest and DAG.
- Optionally add a new identifier in section 2.2 to indicate
that that use of URIs are inherently forest-oriented (keep existing
definition for compatibilty but both mean exact same thing):
- "urn:oasis:names:tc:xacml:2.0:profile:hierarchical:forest:non-xml-node-id"
- Add an identifier in section 3.2 to indicate the forest
algorithms:
- "urn:oasis:names:tc:xacml:2.0:profile:hierarchical:forest:non-xml-node-req"
- Add an alternative set of bulleted algorithms to section 3.2,
which are the same as the existing ancestor algorithms except specify
that only the parent and ancestor nodes of the requested node are
collected which are direct ancestors of one of the normative identities
of the requested node (which is possible, because with a forest the
original parent identifier is always retained for each hierarchy the
requested node still belongs to or has been added to since joining the
forest)
- Other options include any variation, rearrangement, separation,
or enhancement of the existing profile that builds on and includes the
contents identified in #1.
The above is intended to be a minimally intrusive change to the
existing spec that does not alter any existing functionality and simply
explains the distinction between Forest and DAG and provides
information on the manner in which the Forest ancestor collection
algorithms operate, which was already implicit (but not explained in
any way) by simply using URIs with the anyURI-regexp-match function for
scoping.
Thanks,
Rich
|