Re: [xacml] Summary of what I think I said on the call about thehierarchical profile

["Rich.Levinson" <rich.levinson@oracle.com>]

Hi Hal,

The fact is that it is the algorithms in section 3.2 that imply that the hierarchies are combined as a DAG. There is no problem, in general, if the one or more of the original "hierarchies" happens to be a DAG. The problem is that the algorithms force the combination of the originals, DAG or forest.

The recommended changes to the spec that I have proposed is to have a choice of algorithms for combining the hierarchies. That way customers can decide for themselves which is appropriate for their resource collections.

    Thanks,
    Rich


Hal Lockhart wrote:

20090309164020399.00000005672@hlockhar02" type="cite">

I think the source of confusion was this. Daniel's point was that the initial representation of each hierarchy could be a DAG, since it is a generalization of a tree. Rich's point was that if you start out with all the hierarchies in whatever form, and you include defined hierarchies which do not include the Resource in question as a member, even though ancestors of the Resource are members of the hierarchy, if you combine all the hierarchies you lose the information about the original hierarchies necessary to be able to distinguish whether the nodes above the Resource are true ancestors or not.

My comments on the call and below on the DAG were based on the premise that we started out with one or more hierarchies merged them into a DAG and then determined the parents and ancestors. Under this premise, the use of a DAG seemed like a intermediate step of no particular interest. I now see that Daniel was trying to say that at the very beginning, any of the distinct hierarchies may be multi-rooted and thus represented as a DAG.

My feeling now is to make minimal changes to the document. I think if we make it clear that the starting point is one or more hierarchy each of which may be singly or multiply rooted, but only hierarchies which contain the resource. I don't object to the individual hierarchies or their union as being described as a DAG, but the ancestors could also be computed by examining each hierarchy in turn.

I have some concerns about the URI part, which I will put in a separate email.

Hal 

  

-----Original Message-----
From: Erik Rissanen [mailto:erik@axiomatics.com]
Sent: Monday, March 09, 2009 7:43 AM
To: hal.lockhart@oracle.com
Cc: xacml@lists.oasis-open.org
Subject: Re: [xacml] Summary of what I think I said on the call about the
hierarchical profile

Hi Hal and all,

If I understand you correctly, then what you propose is the exact same
thing as I proposed, except I used the DAG term because I thought we
wanted to specify how you would get the list of ancestors from a graph.
If that is not the case, then we can drop the terms DAG, forest and so on.

So, basically we just say that you have one or more hierarchies in which
the resource is part of and for the request context you send in the
resource itself, and its ancestors.

The only thing which I am still uncertain about in your email is whether
you are trying to ban the use of a DAG. Sending a list of ancestors this
way would work for a DAG, which I think is ok.

Best regards,
Erik



Hal Lockhart wrote:
    

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


      

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