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] Summary of what I think I said on the call about thehierarchical profile


Hi Hal,

This is great input and characterization of the problem space and what is needed to address the concerns.

In this context, I think that all that would be required to fix the original spec, (Erik's version 3 from November:, separated here from the zip file:  http://www.oasis-open.org/committees/document.php?document_id=30981&wg_abbrev=xacml)  aside from whatever changes people might like to make to the introductory sections, is that in section 3.2 after line 244 and prior to the first bullet on line 245, that we need to state the following:
the information put in the request context SHALL only include hierarchies of which the resource ORIGINALLY is EXPLICITLY a member.
where I have copied the text from your email and inserted the word "SHALL" in order to make it a readable sentence The words "ORIGINALLY" and "EXPLICITLY" are inserted so as to remove any ambiguities that might arise as to determining a resource's membership in a hierarchy, where the term "EXPLICITLY" is intended to remove what  you refer to as transitive membership, and the term "ORIGINALLY" is intended to make clear that if there is any pre-processing done of original hierarchical memberships which later become ambiguous, that this specification is referring to the original memberships and not derived or implied relationships which possibly could be acquired during the pre-processing.

    Thanks,
    Rich



Hal Lockhart wrote:
20090306093200378.00000000612@hlockhar02" type="cite">
This is an attempt to summarize what I said on the call today. I have changed the order a little and added a few extra comments.

First, let us agree that the hierarchical profile assumes that some party needs an AZ decision about a resource that is part of one or more hierarchy. The profile does not define what the hierarchy is, the semantics of the relationships among its members or anything like that. It does define how to extract a small subset of the information and put it in the Request Context.

Now let us consider the two modes of operation in the draft Rich created. He called them DAG and Forest mode. If we look at my msg from Tuesday I give a small example of some hierarchies and a case where the two methods produce different information in the request context. Note that they will never differ in their parents, but the DAG mode can include ancestors which are not actually in the same hierarchy as the resource. In the example, Z is an ancestor of an ancestor (parent actually).

Another way to express this is that in the DAG model, the "is an ancestor" relationship is transitive. Every ancestor of an ancestor is an ancestor. In the forest model, it is only transitive within a given hierarchy.

It is my opinion that the intent of the 2.0 profile, although it is certainly not clear and definitely contains mistakes, was that the information put in the request context only include hierarchies of which the resource is a member. In my example, the Z-A hierarchy would not even be considered. Therefore the issue of transitivity does not arise. In effect, we are always using the forest model.

Therefore I do not believe it is necessary to have the forest and DAG modes. I do not see any valid usecases for the transitivity property and I do not think it was intended in the 2.0 version of the profile. As an example, my father is a navy officer. I am below him in a family hierarchy, but that does not make navy admirals my ancestors in any way. If my father was the resource, the navy hierarchy would be relevant, but if I am the resource, it is not. I think all that is required is to clarify that only hierarchies of which the resource is a member will be given any consideration in computing parents and ancestors.

Next I talked about loosening the requirement that resources be named using a hierarchical URI. We previously agreed to allow strings. My only concern was to allow strings or URIs, not URIs carried in strings. This allows URI typed operations to be used when the name actually is a URI. Eric proposed that we allow any XACML datatype, and I agree. People who want the functionality of parsing a hierarchical URI can use a URI and others can use whatever is convenient for them. Of course it is possible that the information on ancestors and parents might be inconsistent with the structure of the hierarchical URI, but that was true in the 2.0 profile and there are lots of other legal ways for the request context to contain inconsistent information. If you put sand in your car's gas tank, it will not run, an XACML PDP is the same. In other words, GIGO.

Finally I said I generally supported Erik's proposed plan of action with one exception. Thinking about the problem independently, I had come to the conclusion we should totally eliminate mention of a DAG, before reading Erik's email. Here is my reasoning. As I said above, we start out with a rich set of information about the various hierarchies, at the end we end up with a request context which contains nothing but an unordered list of parents and an unordered list of ancestors. A DAG is simply a possible intermediate step. It contains more information than the request context, but less than the original set of multiple hierarchies. Talking about a DAG doesn't seem to me to help in explaining what the context handler must do, because it represents neither the starting point nor the ending point, just one possible intermediate step.

What I did not say on the call.

During the call I was thinking of the distinct hierarchies as being singly rooted as in my simple example. However, after the call I realized that the algorithm I mentioned completely eliminates the problem of transitivity regardless of whether the initial, distinct hierarchies are singly or multiply rooted. Therefore it doesn't matter whether the individual hierarchies or their union is represented as a forest, dag, polyarchy or database table.

To be explicit here is what I mean:
1. Start with all hierarchies in the space of resources of the type of interest.
2. discard all descendants of the resource.
3. discard all resource hierarchies (and their members) which do not contain the resource.

Now, however you represent the information, any reasonable algorithm to enumerate the parents and ancestors, discarding duplicates will produce the same results, ignoring order. The issue of transitivity will not arise, thus Rich's concern is satisfied.

Hal



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

  


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