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

[Daniel Engovatov <daniel@streamdynamics.com>]

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.

URI approach is not generic enough.  It is not a viable substitute for a generic 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.

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.

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.     

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.

Daniel;