Re: [xacml] Issue: Hierarchical profile appears ambiguous and inconsistent

["Rich.Levinson" <rich.levinson@oracle.com>]

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;