OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [xacml] New core and multiple resource profile and hierarchical


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.


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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]