[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
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
IT-services.
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,
Erik
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
> example:
> http://lists.oasis-open.org/archives/xacml/200902/msg00058.html
>
> 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
> inconsistencies."
>
> 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
> about.
>
> Thanks,
> Rich
>
>
>
>
> 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
>> inconsistencies.
>>
>> 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,
>> Erik
>>
>>
>> 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
>>> issue:
>>>
>>> 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.
>>>
>>> Thanks,
>>> Rich
>>>
>>>
>>>
>>>
>>> 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
>>>> problem.
>>>>
>>>> Best regards,
>>>> Erik
>>>>
>>>>
>>>> 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
>>>>> “urn:oasis::names:tc:xacml:2.0:resource:resource-ancestor”.
>>>>>
>>>>> 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
>>>>> particular
>>>>> resource.
>>>>> 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.
>>>>>
>>>>> Thanks,
>>>>> Rich
>>>>>
>>>>>
>>>>> 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.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hal
>>>>>>
>>>>>>
>>>>>>
>>>>>> ________________________________
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> Thanks,
>>>>>> Rich
>>>>>>
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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]