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

I think we may be getting closer to a resolution, because these discussions have, in fact, imo, been converging to place focus on the core issue I have been trying to address.

There is no question that this is a difficult issue to conceptualize, but I think we have been talking about a core model of a collection of resources that have hierarchies associated with them. And this all exists prior to us coming along with the hierarchical profile in order enable the use of XACML to protect these resources.

Here is how I would conceptualize your example use case (which I think is similar to some use cases I ref'd earlier about an "intersecting" org chart hierarchy and facilities hierarchy):
  1. For the sake of discussion let's say the budgeting department has hierarchy of employees, each of whom has a PC on their desk that they use in the budgeting process.
  2. Let's also say the IT-svcs has hierarchy of employees as well and that those employees are in charge of taking care of all the PCs in the company including the budgeting dept pcs.
How to model this: this is the approach I have been describing:
  1. All the entities identified so far may be considered to be resources: the individual people and the individual PCs
  2. As you have described I think all the people can be identified within an org chart hierarchy and all the PCs probably can be considered to be a flat pool of resources (at least when they arrive on the shipping dock) each of which can be assigned to one or more people for specific purposes when they are unpacked and put into service. Let's say there are 2 purposes defined: primary-user and maintenance-person. So, when a PC is put into service it gets a parent in the budgeting dept who will be its primary-user, and a parent in the IT svcs dept who will be its maintenance-person. So, effectively each PC when put into service belongs to two hierarchies: primary-user and maintenance-person.
  3. The way this could conceptually work is that the head of the IT-dept is responsible for the activities of the maintenance-people in the IT-dept. So each maintenance-person will have an identity within the maintenance dept as a maintenance-person, as will the head of the IT-dept as the top maintenance-person. So, the IT-head assigns PCs to maintenance-persons and all the maintenance-persons report to the IT-head directly (small company), so there is a 3 level maintenance-person hierarchy and they maintain all the PCs in the company, including those in the budgeting dept.
  4. Now you also said that the budgeting dept was superior to the IT-dept, so let's assume the IT-head reports to the budgeting-head. These relations, maybe we can call the org-person relation, where every person in the company has an identity as an "org-person", and let's say that for the PC's, the primary-user hierarchy they belong to means that the PC will identify an "org-person" as its parent.
  5. Now all PCs can have 2 parents, each in a different hierarchy: one parent in the org-person hierarchy and one in the maintenance-person hierarchy.
  6. You have also mentioned that budgeting, itself, has some ownership of entities so we could also add a budgeting-parent to each PC, which similar to IT could have a hierarchy reporting to the budgeting head.
From my point of view, this is simply a forest of 3 hierarchies, where each PC is a member of 3 hierachies, and the budgeting people and IT people are members of 2 hierarchies.

For section 3.2.2 in the v5-02 draft, each PC would have ancestors straight up to the 3 roots: IT-head, Budgeting-head, and Organization-head (being the top org-person).

I don't see any inconsistencies yet, so let's push it a little further:
  1. Let's say that the budgeting people also are assigned a maintenance person, who is a person they call when they have a problem with their PC, and let's say the IT-head assigns the maint-people in his dept as the authority who can go up to the budgeting person and say "I need to do something to your PC right now, so please move aside". Let's assume this also applies to the budgeting head to whom the IT-head reports. i.e. a maintenance-person reporting to the IT-head who reports to the budgeting-head is identified as a parent of the budgeting-head, as the budgeting-head's maintenance-person who has authority of the budgeting-head's PC and can tell the budgeting-head to "Step aside, please.".
I think this would characterize the "cycle" that you are referring to as the inconsistency.

At this point I simply would say that the only reason there is an "inconsistency" is that for some reason there is a requirement to model this situation as a DAG. This has been my point all along: with the forest, there is no problem. There are multiple hierarchies and you can put a policy set over all the hierarchies that can resolve conflicts between the hierarchies. I agree that with the DAG you are stuck, and don't know which hierarchy is which, plus the system gets stuck in a loop.

Again, I cannot understand why one would want to try to wedge this use case into a DAG. The forest handles it without any problems.

Please let me know if I have missed anything and if you agree that the modeling steps represent the use case, and hopefully we can develop this example further, if necessary, in order to somehow work toward a solution.

Erik Rissanen wrote:
49B87922.9060009@axiomatics.com" type="cite">
Thanks Rich,

If you put it this way, then it's "Way A".

With Way B I meant that there exists multiple hierarchies which are
defined independently from each other. Maybe the relation to naming was
confusing, and I'm not sure I understand that myself yet clearly.

As a (contrived) example of Way B, think of an organization which has,
among others, two units: "IT-services" and "Budgeting".

There exists a hierarchy for a budgeting process in which the budgeting
department is superior to IT-services, so Budgeting is an ancestor to

There also exists a hierarchy for management of IT infrastructure, in
which the IT-services department controls the IT-resources of the
budgeting department, so in this hierarchy the IT-services department is
an ancestor of Budgeting.

If we would combine these two hierarchies, the result won't be consistent.

The point I am trying to make is that if there are multiple hierarchies,
it is not guaranteed that their combination is even a DAG. It can be
entirely inconsistent (a graph which contains cycles).

So I think we have to assume that there exists a consistent hierarchy,
before we can say anything. The above counterexample proves that there
cannot exist an algorithm which turns any set of hierarchies into a
joint DAG.

With the discussion on naming I meant that if you do have a consistent
hierarchy, it is no problem that the nodes may have multiple "normative
descriptions" (names). You seemed to indicate in an earlier email that
multiple "normative descriptions" (which it says in the 2.0 profile) is
a problem.

Best regarsd,

Rich.Levinson wrote:
Hi Erik,

I think that you are misinterpreting what I said in the previous
email. Let me try to be more explicit:

   1. Start with an unnamed collection of resources. Let's say there
      are N individual identical resources.
   2. On a laptop, using a program, create an array of N variables,
      for example
          int parent[] = new parent[N];
   3. Now I can start creating my hierarchy by assigning a value to
      these parent ints which somehow identifies another of the
      resources in the collection. I believe at this point that I must
      pick some method to identify the elements of the collection,
      otherwise there is no meaning to this value.
   4. For the sake of discussion, let me choose to use the index of
      the element in the array as the way to identify the parent.
      Therefore, I can pick any element in the array and assign it a
      value in the range 0->N-1. For example, I can say:
          parent[i] = j;
   5. Using this technique I can create a hierarchy of these resources.

This is basically an implementation of the example I gave in this
email I was asked to prepare to help the TC understand the issue by

The bottom line is that in order to assign parent child relationships,
you need to have something to hold the assignment artifact. There will
be one artifact holder for each resource. When you assign an artifact
to a holder, this artifact must somehow identify another resource in
the collection in order for it to have any meaning in terms of this
operation of assigning a parent child relationship.

So, in the example I gave in the email, each of the 2 customers
assigned parent child relations to the empty boxes on the piece of
paper they were each handed.

When customer 1 handed the paper to the collection manager, the
manager did the equivalent of the above.

The fact that I had id-numbers painted on the box was just to help
people understand the problem. The example works equally well if you
paint the numbers on the boxes later after the customers have handed
in their papers and the manager entered their data into 2 arrays.

The manager would then create a 3rd array and assign these painted
numbers then.

This is totally consistent with what you are calling "Way A":

    "In way A, one first defines the parent-child relations on the
    resources themselves, independent of anything with names. After
    that is done, one can give name to the nodes. There is no risks of

So, I do not understand, what you are trying to indicate in your
email, since it appears to premised on an assumption you are making
that appears to be inconsistent with what I have been saying in these
emails. Since I believe I have been totally consistent in my
representation of the problem, we should be able to unambiguously
resolve this "Way A", "Way B" discussion, and possibly come up with
some terminology on which we agree so that we may continue this
analysis without having to continually re-explain what we are talking


Erik Rissanen wrote:
Hi Rich,

What you describe is what I meant with "Way B".

In way A, one first defines the parent-child relations on the
resources themselves, independent of anything with names. After that
is done, one can give name to the nodes. There is no risks of

In contrast, in Way B, you initially have a set of hierarchies. Once
you start adding a resource to multiple, independently defined
hierarchies, you can get inconsistencies. Two nodes may have reverse
ancestor relationships in two different hierarchies. This is inherent
in this model, and has nothing to do with how we formulate the profile.

Anyway, all this is outside the scope of the profile itself if we
define the profile in terms of the ancestor attributes. This
corresponds to that for the purposes of the profile, there is an
already defined, _single_ "hierarchy" (if we allow a general
interpretation of the term), which is "flattened" to ancestor
attributes. The profile does not have to deal with inconsistencies in
multiple hierarchies.

The single "hierarchy" which the profile works on, may be a the
result from a preprocessing step where a number of independent
hierarchies have been merged. But not, it's not always possible to
merge hierarchies consistently.

Best regards,

Rich.Levinson wrote:
Hi Erik,

In fact, my view has always been "Way A". My conceptualization is
that there is a collection of physical resources and that an
organization organizes the resources in various ways, and, in
particular, as hierarchies. Every time someone adds a resource to a
hierarchy, the resource gets a new name and parent attached to it.
After this has been done for a while the net result is that the
collection of physical resources can be viewed as having one or more
hierarchies "draped" over it. For every hierarchy a resource belongs
to, it, in general can be assumed to be assigned a name and a
parent. Hopefully, we agree that is "Way A" and based on that
assumption, it should be fairly straight forward to understand the

Ok, so, based on your formula, what I do is:

    * follow the parent-child relations
    * this is fine at the requested resource, I find all my parents
    * now I go to each parent and collect all of its parents ***

This is where the problem is introduced. As soon as I collect a
parent of my parent that is not a member of a hierarchy I am in, we
have defined a DAG.

If I stick to parents of parents that are members of hierarchies I
am in, then I am in a forest.

The diff in these 2 methods is that the DAG method doesn't bother to
look at whether the requested node is a member of the hierarchy that
it is following from the requested node's parent.

The problem compounds as you follow each generation.


Erik Rissanen wrote:
Rich, Hal and All,

Just a quick comment. I don't think that just because a resource,
or an ancestor, has multiple normative names, the hierarchy would
become a DAG. We need to differentiate between resources and names
of resources.

One way ("Way A") to think of the problem is that the parent-child
relations are bound to resources, not the resource names. To
collect the ancestors to the request, one has to follow the
parent-child relations, and then include all names of all ancestor
resources. That is what the profile tries to say. (I think.) And
that would be correct in my opinion. And would not necessarily mean
that the profile was made to support a DAG.

An alternative way ("Way B") is to think that the parent-child
relations are tied to the resource names, not the resources
themselves (or that there are no resources independent of names). I
get the feeling that at least Rich looks at it like this.

I think way B is problematic since it opens up the possibility that
parent-child relations between different names for the same
resources conflict with each other. This is what I meant with
"consistency" in my post last week. By adopting way A, we avoid the

Best regards,

Rich.Levinson wrote:
/ /I agree with that. However, it is the algorithms that allow and
appear to encourage collection of non-member ancestors. Here is
the text:

    For each ancestor of the node specified in the “resource-id”
    attribute or attributes, *and for each normative
representation of
    that ancestor node*, an <Attribute> element with AttributeId

    The <AttributeValue> of this <Attribute> SHALL be the normative
    identity of the ancestor node.
    The DataType of this <Attribute> SHALL depend on the
    representation chosen for the identity of nodes in this
    This <Attribute> MAY specify an Issuer.
    For each “resource-parent” attribute, there SHALL be a
    corresponding “resource-ancestor” attribute.
    If the requested node is part of a forest rather than part of a
    single tree, *or if the ancestor node has more than one normative
    representation*, there SHALL be at least one instance of this
    attribute for each ancestor along each path to the multiple roots
    of which the requested node is a descendant, *and for each
    normative representation of each such ancestor*.

It is the addition of all the "...each normative representation of
each such ancestor" which clearly opens up these algorithms to
imply a DAG. Without these phrases, it is still not particularly
tight, but alone they could be interpreted to imply a forest. With
the phrases DAG is inescapable.

The point is that these are ancestor nodes and nothing ties their
normative representations to be those that are in the hierarchies
of which the requested node is a member.

This IS the problem. It is these specific algorithms and what they
say about ancestors that forces you into a DAG. It clearly
includes hierarchies of which the requested node is not a member.

Therefore, it sounds like we are in agreement. That there is a
problem that needs to be fixed.


Hal Lockhart wrote:
As I have said repeatedly, the only problem with combining the
initial hierarchies into a DAG arises if the original hierarchies
include hierarchies of which the Resource is NOT A MEMBER.





From: Rich.Levinson [mailto:rich.levinson@oracle.com] Sent:
Tuesday, March 10, 2009 8:56 AM
To: hal.lockhart@oracle.com
Cc: Erik Rissanen; xacml@lists.oasis-open.org
Subject: Re: [xacml] Summary of what I think I said on the call
about the hierarchical profile


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.


Hal Lockhart wrote:
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.
    -----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,
                   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
               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,
    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
    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
               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
    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
               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.

        To unsubscribe from this mail list, you must leave the
        generates this mail.  Follow this link to all your TCs in


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:

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:

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:


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