Daniel,
These replies contain no explanation as to their basis. You are simply
making opposite assertions and not backing it up with any basis. For
example:
"DAG describes what to apply precisely."
DAG only selects ancestors. It decides which ancestors based only on
the fact a relation exists and does not distinguish one relation from
another. It uses limited information and produces limited results based
on that information. Unfortunately, it throws away useful information
which is why it is more limited, less useful model than forest. It is
fine for applications that do not require the additional info, but
useless for those that do.
Here is a second example:
"What ever is the intended chain of command can be
presented to PDP as a list of ancestors without any problem."
The DAG presents list of ancestors as described in section 3.2. If that
works for some application like source code control or subassemblies,
then I agree there is no problem. If you need accountable lines of
authority then DAG "is the problem".
And this:
"You have created a definition of "hierarchy" that is not
applicable and trying to shoehorn it into the profile."
If you read the text you quoted as the basis of this comment, you would
see that I asserted that "The DAG is inherently is multiple
"overlapping" hierarchies that can be combined into a "single multiroot
hierarchy"" and gave a reference for that assertion.
In addition, the original Hierarchical Profile defines "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”."
This definition clearly combines trees (hierarchies with single roots)
into a forest (a hierarchy with multiple roots) and calls it a DAG.
The reference I gave provides substance around this assertion and also
provides the necessary context to begin to disambiguate what is clearly
a problem with this spec that it incorrectly equates DAG and forest.
It is when we disambiguate that we find that both models are indeed
represented in the spec, however incompletely and in a confusing manner.
I am concerned that none of the DAG proponents seem to be able to give
any kind of explanation of precisely how DAG can avoid finding policies
that it considers "applicable" when no such applicability is intended.
I expect the reason is that DAG simply cannot do this and for some
reason, the DAG proponents choose to assert that "one size fits all".
Again, I repeat, my proposal does not remove any DAG capabilities. It
simply provides clarity as to the choice of DAG and forest and allows
implementers and policy designers to pick what is appropriate for their
applications.
And, again I repeat, I am not adding any functionality to the spec, I
am simply explaining what is already there by disentangling the current
confusing presentation and simply saying these capabilities apply to
DAG, and these other capabilities apply to forest.
Unfortunately, the only rebuttal appears to be that only DAG will be
supported and anything else frowned upon, which requires removing
clearly intended functionality from what is currently in the spec.
Thanks,
Rich
Daniel Engovatov wrote:
On Mar 4, 2009, at 10:52 AM, Rich.Levinson wrote:
The reason I am concerned about this issue is that from a security
perspective, it makes little sense to me to force commonly understood
hierarchies, such as organization charts, geographic breakdowns of
organization operations, whether within a building or around the world,
to suddenly have policies that are intended only to apply to the
resources within these specified domains, suddenly apply to resources
outside of these domains.
It will not happen. DAG describes what to apply precisely. Nothing
will be "suddenly applied".
Similarly, resources within these domains
will find themselves subject to policies applied to resources outside
of these domains.
For example, if I am a manager in the United States, and there is a
policy that says employees in the United States may treat the 4th of
July as a holiday, then anyone outside the United States who has any
superior inside the United States will be subject to this policy.
It has no bearing to XACML. What ever is the intended chain of
command can be presented to PDP as a list of ancestors without any
problem.
Why? Because the resources are treated as a
DAG. DAGs do not deal with resources individually, they only deal with
subtrees.
That is an unfounded assumption.
This is an invalid assertion. I leave the
profile unchanged, except for distinguishing the DAG and
forest/polyarchy distinctions.
The DAG is inherently is multiple "overlapping" hierarchies that can be
combined into a "single multiroot hierarchy" (see ref prev email)
http://en.wikipedia.org/wiki/Directed_acyclic_graph#Properties
No, it is not. You have created a definition of "hierarchy" that is
not applicable and trying to shoehorn it into the profile.
Daniel;
