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

ZThese 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."

Unfortunately, we have been over this so many time that I can not just keep repeating the arguments.  But I will try again.

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.

DAG does not select ancestors.   It is defined by the selection of ancestors.   Any useful information that is thrown away is irrelevant to policy evaluation.   The only thing that PDP needs to know is a collection of applicable rules.    This is the only input needed to reach a decision.    

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".

You keep bringing in concepts like "accountable line of authority".    Where is it defined?  I do not see any relevance to the purpose of policy evaluation.

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.

You are making an assumption that I have not "read the text".   I want to assure you that I did.

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”."

We have started the whole dialog by admitting that that statement was an error.   To fix that error reference to "forest" needs to be removed.

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.

I assert that it does not bring any additional clarity for the reason that it introduces multiple additional concepts.

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.

Yes, I think that removing references to "forest" and to any URI naming schemes from the existing spec will help.    


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