Daniel, Seth, Erik, and TC,
As should be seen from my replies in line, it appears to me the
fundamental point of disagreement here is about the definition of the
term "hierarchy". If we stick to the generally accepted definition that
an object in a hierarchy can have at most one parent, then a URI solves
the problem without having to look beyond the URI itself (a rather
remarkable and powerful property). If we define a forest to be a
collection of hierarchies, where, like in a forest, even though the
members are intertwined, they do not lose their identity, then each
node having a set of URIs as its normative identifiers solves the
problem, as all the parents, ancestors, are self-contained in the set
of URIs.
However, if we allow the hierarchies to break down and lose their
inherent hierarchical properties, then more complicated approaches,
such as going outside the initial request context to get more nodes,
although still solvable w URIs as demo'd below, are needed.
Again, I am not trying to add or change any of the existing
functionality, which, as described below is currently designed to
address the "more complicated than hierarchies" problem. I think one of
the main problems with the spec is that it leads you to think you are
addressing a problem related to hierarchies, yet the solution described
is much more general than that, which, imo, is misleading, unless it is
appropriately documented as such. And if the resources under
consideration are not identified by hierarchical names then the
approach currently in the spec, qualified by whether it is strict
hierarchies or hierarchies obscured by non-hierarchical relations that
are incidentally introduced when using multiple hierarchies and not
keeping track of the origin of each hierarchy.
However, I do want to show by example how the strictly defined
hierarchy and forest of hierarchies, that each retain their initial
hierarchy properties, is addressed using URIs along the lines of the
example document that is in the archives and referenced below.
Thanks,
Rich (additional replies inline below)
Daniel Engovatov wrote:
With URIs you do not need the algorithms because the URIs representing
the normative identities of the requested node already contain:
"each normative representation of the requested node"
"each immediate parent of the node specified"
"each ancestor of the node specified"
Nothing else is needed. Note however, that doing the analysis with URIs
points out what might be considered to be a flaw in the bulleted
algorithms. The bulleted algorithms require obtaining all parents of
the requested node's parent on up the line, regardless of whether those
additional parents are connected to the requested node by an explicit
hierarchical relationship or not.
No, much more is needed. There may be more then one immediate
parent. Ancestor nodes may use a different naming convention.
There is no need to force them to be on the same tree.
This may be at the core of this issue. In a hierarchy, an node can have
at most one parent. A node can belong to more than one hierarchy, in
which case it has one parent for each hierarchy it belongs to. As soon
as we start defining structures where the normative identity of a node
can have more than one parent directly related to it, we are no longer
talking about hierarchies, but some other more general structure.
However, this is the "Hierarchical Resource Profile", where the subject
is to
provide access control for a resource that is organized as a
hierarchy.
I agree if we try to develop solutions for more complicated problems
then "much more" will probably be needed. But if we are dealing with
hierarchies, the URI fully defines the necessary capabilities.
URI approach is not generic enough. It is not a viable substitute for
a generic profile.
But this is not a "generic profile" it is the "Hierarchical profile".
i.e. the bulleted scheme implicitly forces
the requested node to collect ancestors that have not been structurally
assigned any direct relationship to the requested node. When
hierarchies are used to represent lines of authority, these additional
relationships are not relevant and obscure the real lines of authority
which are generally what is of interest in enterprise security.
The text in bold is incorrect. This profile has nothing to do with
lines of authority. You are bringing in a completely unrelated
concept.
It is simply a concrete real world realization of the notion of
hierarchy used for illustrative purposes to give people context to help
them understand the nature of the problem that is being addressed.
However, it is my opinion, that the primary
purpose of these specifications is to inform consumers of these
specifications on the capabilities contained within the spec so that
they may then apply those capabilities to meet their needs.
Yes, and does its job without any URI naming schemes.
However, it does the job in a much more difficult to understand manner,
which is probably because it is a mechanism that appears to be intended
more complex problems than hierarchies.
By only including the bulleted ancestor
algorithms in section 3.2, the capabilities of URI, which are clearly
specified in the rest of the spec, and were included in the example
document in the XACML archive (see section 4.2, 4.3 of
http://www.oasis-open.org/committees/download.php/7315/xacml-profile-hierarchical-resources-nonXML-1.0-draft01.pdf),
we are effectively making the URI capability so obscure in the spec as
to be unusable.
That is an assertion that I strongly disagree with. It is not
unusable.
I agree. That is an overstatement. I should have said "so obscure as to
be unusable in the normal manner one would expect to use URIs", which
is shown in the example document that was part of the process of
developing this specification:
http://www.oasis-open.org/committees/download.php/7315/xacml-profile-hierarchical-resources-nonXML-1.0-draft01.pdf
Again, my proposed changes do not change any functionality, they simply
explain the capabilities that are currently there, which because of the
obscure representation of the existing functionality in the current
spec are nearly impossible to understand.
It does change functionality. It introduces an unrelated and
burdensome concept of hierarchical naming scheme, and it reduces the
flexibility of the approach.
Again, I have to repeat that I am not "introducing" the URI scheme. It
is already there in sections 2.2, 4.1, 4.3 with explicit descriptions
of how it can be used. What's missing is an operational description of
how it can be used in section 3.2.
Furthermore, it does not reduce any functionality related to
hierarchies, but I agree that in its most basic form it would not solve
the more general non-hierarchical problem. However, as explained in
previous email, that is easily corrected, by "going out" and getting
the non-hierarchical guests that are collected in its ancestors. In its
basic form, intended to address the pure problem of a forest of
multiple hierarchies, it does not need to "go out" for anything,
because all the required information is contained in the normative
identities of the requested node.
Daniel;
