Re: [xacml] Example of dag and forest used to manage collection ofresources for comparison

Hi Daniel and TC,

I am disappointed that this response does not directly address the
example. I consider it to be a very reasonable example. One such use
case would be a "farm" of sharable computers, and two applications,
each organized as a hierarchy of modules, that the appl deployer
configures on different machines, possibly because those machines have
resources needed by specific application modules.

Also, it is not an "overly complicated example". It is as simple as 2
sheets of paper with numbered boxes that are each filled in by a
different person with a different purpose for using the shared
resources. 

Each person may want to make the contents of those boxes (physical or
logical) available only to certain members of that person's
organization and allocates access to the boxes within organization's
own hierarchical framework (which is all contained in the two columns
allocated to the customer by the parent attribute associated with each
customer-specified node name).

This is typical enterprise use case with many large distributed
applications over world-wide corporate resources. Each application
needs to be managed independently of other applications, yet at the
same time must share the common corporate resources on which it is run.

Finally, I want to emphasize one more time: I have not advocated
removing any of the DAG functionality that already exists in the spec.
If you carefully read the proposed modified spec, I think you will see
it is functionally unchanged. The changes are only to distinguish the
DAG from the forest and to fill in the missing information to show how
the forest can be used, if one chooses to do so.

Both the forest and URI capabilities (URI is concrete representation of
more general forest) have been in the spec since the beginning, long
before I had any working involvement with the XACML specifications.
There are many obvious use cases for forest and URI, such as the ones I
have mentioned and, at a minimum, cases where an investment has already
been made and URIs already exist and the customer has no interest in
changing them.

The example I have given demonstrates the distinction of information
content between the forest and the DAG, namely that the forest, as a
set of disjoint trees, one way or another contains the hierarchical
relationship of the collection of resources within each disjoint tree,
as well as the relationships to the other trees when the trees are
mapped on the common resources to be organized.

The DAG specifically does not need to keep whatever structures are used
to keep the original trees disjoint, and similarly has no capabilities
for recovering any information about the original disjoint properties
of its current members unless it happens to have kept this information
around. That is why the DAG leads one to dismantle URIs, because there
is no need to maintain the order of the components. That is analogous
to the row compression in the example I gave.

For application use cases where the URI structure or the example row
structure is not needed, then DAG is a perfectly good solution. 

However, the use cases in enterprise security quite often are geared
around independent hierarchical lines of authority for which it is very
important to maintain knowledge of precisely where this authority is
coming from.

The change to the spec leaves the DAG capabilities unchanged and
available for use. The change also explicitly distinguishes DAG and
forest and fills in section 3.2, which currently only contains DAG
information and is missing the comparable forest information.

The main difference between DAG and forest is that DAG can be used  to
"merge" hierarchies into a single uniform structure which has no memory
of the original hierarchies. The forest "aggregates" hierarchies into a
single uniform structure that does have memory of the original
hierarchies and the capability of maintaining that info thru adds moves
and changes. 

The example shows a concrete instance of this forest
implementation and the changes that can be made to transform it into a
DAG, which is essentially the same structure minus the original
hierarchy mechanism, which was to maintain a customer as two columns.

The "forest", applied to resources, is in common use today under the
term "polyarchy". Since the XACML Hierarchical Resource Profile already
has this capability, I see no reason to suppress or remove it, but
consider it a strength of XACML that it currently does support it and
that it can be used if properly explained in the specification, which
is the purpose of these proposed changes.

    Thanks,

    Rich

Daniel Engovatov wrote:

  

    

Bottom line: again as I see it, this is the problem with the person who
was the xacml-commenter referenced in earlier emails who was seeking
advice, presumbably guided by the spec in its current form to dismantle
their URIs. To me, this appears as if they are basically destroying
information that they had already established as a sunk cost, and
constraining themselves to work within the more limited framework that
the lesser information provides.
    

    

  
  

This assumption is incorrect.  There is no need to construct any URI in
the first place.
  

  

This whole overly complicated example demonstrates that XACML should
not be involved in any form of resource ontology management.  It is
based on wrong and completely unjustified assumption about what
hierarchy means for the purpose of policy evaluation.     From the
point of view of PDP, there is only one hierarchy.  There is only one
"customer" at a time.  All we need to do is to specify is a protocol to
transmit this information to PDP.    That is completely sufficient.  
DAG accomplishes that.   Everything else is completely extraneous, not
needed, and none of our business.    We should clarify the existing
specification about the use of opaque unique identifiers, remove any
references to URI's for the non-XML case, and leave it at that.  It
works, and works correctly.
  

  

Daniel;