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] Issue: Hierarchical profile appears ambiguous and inconsistent

On Feb 20, 2009, at 1:34 AM, Erik Rissanen wrote:

> Hi Rich,
> The ancestor scheme is more general since the hierarchy is  
> completely independent from naming.
> You could have a hierarchy where http://example.com/A is the parent  
> of urn:oasis:xacml:D
> You could also have a hierarchy where http://example.com/A is not  
> the parent of http://example.com/A/B
> Regards,
> Eri,k

You got it.

> Rich.Levinson wrote:
>> Hi Erik,
>> A few points I'd like you to consider with respect to your first  
>> point:
>>    1. I am not sure why you have chosen to refer the URI scheme as  
>> the
>>       "limited URI scheme", because as I showed in previous  
>> emails, it
>>       appears that the URI scheme is, in fact, more general than what
>>       you refer to as the "more general approach advocated by  
>> Daniel".
>>       The reasons for this are quite simple. First, the URI scheme is
>>       functionally equivalent and more efficient as can be easily  
>> seen
>>       as follows:
>>           * in the ancestor scheme, as I understand it, we might have
>>             a node, "a", which is a normative identity for a
>>             particular node, and it might have 2 ancestors, a parent,
>>             "b", and ancestor "c".
>>             Presumably, if a request to access "a" comes in, the CH
>>             will have to gather the ancestors. This means the CH must
>>             have some means of finding out that "b" and "c" are the
>>             ancestors of "a". Since this information is not included
>>             in the node name of "a", the CH must look elsewhere.
>>           * in the URI scheme, I would name my "a" node as "/c/b/a"
>>             using the same strings as above. In the URI scheme, a
>>             request for "a" would come in as "/c/b/a". In this case,
>>             the CH is done, it doesn't have to go looking for
>>             ancestors for 2 reasons: 1. because it doesn't need them,
>>             2. even if it did need them, they are already there.
>>    2. The reason why the URI scheme is more general is a bit subtle,
>>       but still should be straight-forward to understand. The  
>> subtlety
>>       is that when presented from an inverted perspective, it  
>> might at
>>       first appear that the ancestor scheme is more general, but a  
>> few
>>       quick points should explain why that is not the case:
>>           * Sticking with the same use case as above as a starting
>>             point, let us consider the case where "b" has 2 parent
>>             nodes "c" and "d". I don't believe there are many people
>>             who would argue that this structure is still a hierarchy,
>>             however a rational case could be made that it is actually
>>             2 hierarchies, one headed by "c" and one headed by  
>> "d". In
>>             this case "b" would be a member of 2 hierarchies.
>>           * At this point the differences in the two methods becomes
>>             clear. Let us first look at the ancestor case. Because a
>>             relationship between "d" and "b" has been established,
>>             does that mean there is now a relation between "d" and
>>             "a". In the ancestor case, the answer is "yes".
>>           * If we now look at the same use case with the URI method
>>             and ask the question whether there is now a relation
>>             between "d" and "a" the answer is "no".
>>           * One says yes, the other says no. Does this mean they are
>>             simply "equal" in capability, but different in "result"?
>>             Similar to a xacml Rule that can be designed for  
>> Permit or
>>             Deny?
>>           * If that was the end of the story, then one could say they
>>             are equal in capability, but it is not the end of the  
>> story.
>>           * In the URI case, we may now establish a 2nd relation
>>             /d/b/a, which now will produce the answer yes, when asked
>>             the question whether there is now a relation between "d"
>>             and "a".
>>           * Therefore the URI scheme can produce both a yes and a no
>>             to this question, while the ancestor scheme can produce
>>             only a yes. Therefore the URI scheme has greater
>>             capabilities and is thus, more general than the ancestor
>>             scheme.
>>           * QED
>> Again, this is not a change to the profile, this is simply  
>> exposing a capability of using the URIs in the profile that is not  
>> present when using the ancestors.
>> There is a 2nd issue that I will also comment on shortly in a  
>> separate email, so that we may reference these use cases in a  
>> discrete manner.
>>     Thanks,
>>     Rich
>> Erik Rissanen wrote:
>>> All,
>>> I've been in a rush today, so I haven't followed every detail in  
>>> the discussion, but basically, here is how it appears to me:
>>> * The profile, as it stands today, does specify the limited URI  
>>> scheme which Rich describes. It says in section 2.2 that:
>>> --8<--
>>> The <pathname> portion of the URI SHALL be of the form
>>> <root name> [ “/” <node name> ]*
>>> The sequence of <root name> and <node name> values SHALL  
>>> correspond to the individual hierarchical component names of  
>>> ancestors of the represented node along the path from a <root>  
>>> node to the represented node.
>>> --8<--
>>> So it in fact says that the identifiers must consists of paths  
>>> with the names of the ancestors.
>>> * If I understand Daniel correctly, he says that each node should  
>>> be allowed to have a name which is entirely independent of the  
>>> other nodes in the hierarchy. Relations between the nodes are  
>>> maintained in a manner not specified by XACML and are expressed  
>>> in XACML Requests and policies in the form of the attributes  
>>> resource-parent, resource-ancestor, etc. I think that the more  
>>> general approach advocated by Daniel would be the correct way to  
>>> go, so I agree with him (and Seth I believe. :-))
>>> * I also think as suggested on the XACML comments/users list that  
>>> the data type of the node identifier should not be limited to  
>>> URIs only.
>>> But I would prefer to leave major changes to the hierarchical  
>>> profile out of the first batch of CD documents.
>>> Best regards,
>>> Erik
>>> Rich.Levinson wrote:
>>>> Hi Daniel and TC,
>>>> Hopefully, those who have followed the details of these emails  
>>>> recognize that each step in the sequence has advanced the  
>>>> discussion in a consistent manner and as a result we have done a  
>>>> fairly thorough job of mapping out the problem space that is  
>>>> under discussion. In any event I believe my comments in this  
>>>> email continue to advance the discussion in a worthwhile manner,  
>>>> and I think will describe the complete problem space as well as  
>>>> give a clear description of the options available, all of which  
>>>> offer full functionality.
>>>> In the current phase, if I am not mistaken, it is a straight- 
>>>> forward matter to apply definitions to the distinct categories  
>>>> of problems and simply observe that we have two sets of tools  
>>>> which are equally effective at solving each category of problem,  
>>>> where
>>>>     * one set of tools (let's call it the "ancestor method") is  
>>>> most
>>>>       effective when one is dealing with resources where it is not
>>>>       possible or desirable to apply URIs as normative identifiers
>>>>     * a second set of tools (let's call it the "URI method")  
>>>> which is
>>>>       available when one is dealing with resources where URIs  
>>>> can be
>>>>       applied as normative identifiers, and the designers want  
>>>> to take
>>>>       advantage of the powerful features inherent in URI  
>>>> objects, esp
>>>>       when applied to hierarchical problems.
>>>> Let me address Daniel's points below, then try to summarize the  
>>>> present state of the discussion:
>>>> Daniel Engovatov wrote:
>>>>> On Feb 18, 2009, at 3:05 PM, Rich.Levinson wrote:
>>>>>> Daniel, Seth, Erik, and TC,
>>>>>> If we stick to the generally accepted definition that an  
>>>>>> object in a hierarchy can have at most one parent, then a URI  
>>>>>> solves the problem without having to look beyond the URI itself
>>>>> It is NOT a generally accepted definition and we did not stick  
>>>>> to it on purpose.
>>>> Whether it is generally accepted or not is probably not  
>>>> important here, however, it is consistent with the structure of  
>>>> XML documents, such that when we are talking about a "single  
>>>> hierarchy" of nonXML resources that if we assert that this  
>>>> implies a structural relationship equivalent to the structural  
>>>> relationship of the nodes of a well-formed XML document, which  
>>>> is that each element can have at most one parent, and the top  
>>>> element or node has zero parents.
>>>> This gives us a crisp unambiguous definition of the term  
>>>> "hierarchy" which can be applied both to the XML and nonXML  
>>>> resources, and it totally avoids trying to determine whether it  
>>>> is an "accepted" definition or not, since that property is no  
>>>> longer relevant.
>>>> The point of this definition is to give us a conceptual  
>>>> framework within which to evaluate the two primary use cases of  
>>>> the DAG, which as will be explained are also clear and  
>>>> unambiguous well-defined use cases.
>>>>>> However, if we allow the hierarchies to break down and lose  
>>>>>> their inherent hierarchical properties, then more complicated  
>>>>>> approaches, such as going outside the initial request context  
>>>>>> to get more nodes, although still solvable w URIs as demo'd  
>>>>>> below, are needed.
>>>>> It is NOT "broken down"
>>>> True, in an absolute sense nothing is "broken", however, what  
>>>> has happened is that we have allowed one class of DAG  
>>>> representation to be impacted in such a way that we have allowed  
>>>> it to become the second class of DAG representation because we  
>>>> did not clearly define the distinction and what was to be  
>>>> allowed and not allowed. This has nothing to with whether the  
>>>> ancestor or URI method is used. It has only to do with the  
>>>> relationships that are allowed to be represented when two  
>>>> resources are "connected" by virtue of their hierarchical  
>>>> relationship being established.
>>>> Specifically, one has a choice of:
>>>>    1. only allowing the relationship that is being established  
>>>> to be
>>>>       active. For example if my boss is assigned to be  
>>>> subordinate to
>>>>       a task force leader when a cross functional team is being set
>>>>       up, this case would say that has no impact on my relationship
>>>>       with the task force leader unless I am a member of the task
>>>>       force. i.e. the task force leader has control over my boss's
>>>>       resources to whatever degree is implied by the task force
>>>>       situation, however the task force leader has zero direct  
>>>> control
>>>>       over my resources as a result of this assignment. In this  
>>>> model,
>>>>       that direct control could be simply be established by either
>>>>       assigning me directly to the task force leader, or  
>>>> assigning me
>>>>       a second subordinate relationship to my boss in the  
>>>> context of
>>>>       the task force relationship.
>>>>       This is a clearly defined process, where there is no  
>>>> ambiguity
>>>>       about relationships between the resources. If you want the
>>>>       relationship, you explicitly establish it, if not, you don't.
>>>>    2. the other choice is the exact opposite, namely allowing
>>>>       incidental relationships to be established simply because  
>>>> they
>>>>       connect to a node with direct relationships. To take an  
>>>> extreme
>>>>       light-spirited example, for the purpose of showing how
>>>>       "extraneous" relations are introduced, if the company CEO  
>>>> was a
>>>>       member of a company bowling team, where the captain of the
>>>>       bowling team happened to be a junior software engineer who  
>>>> just
>>>>       joined the company, then everyone in the company would  
>>>> suddenly
>>>>       have this junior engineer as their ancestor. Possibly this  
>>>> would
>>>>       be disallowed by acyclic graph rules, but a similar situation
>>>>       would occur if the VP of engineering was on a bowling team
>>>>       captained by the junior sales trainee, who would now be  
>>>> ancestor
>>>>       to everyone in engineering organization.
>>>> Both methods are acceptable for assigning relationships, but one  
>>>> or the other may be more effective for one or another type of  
>>>> organization. Personally, I think most enterprise security  
>>>> departments would favor the first approach, because it appears  
>>>> to offer more direct control and less chance of unintended  
>>>> consequences resulting from the assignment of a direct  
>>>> relationship.
>>>> However, either choice can be used with either the "ancestor  
>>>> method" or the "URI method". Which choice is made is a function  
>>>> of the node collecting algorithm that is used for policy  
>>>> evaluation. i.e. when you collect the parent nodes of the  
>>>> requested node,
>>>>     * choice 1 above means only collect those nodes to which the
>>>>       parent has a direct relationship with the requested node,
>>>>     * and choice 2 means collect all the nodes of choice 1 plus all
>>>>       other nodes where the parent has a hierarchical relationship
>>>>       that does not directly involve the requested node.
>>>> These are the two primary use cases of the DAG, which were  
>>>> mentioned above. Which use case is chosen depends only on the  
>>>> node collection algorithm and not how the nodes are represented.  
>>>> i.e. parents and ancestors exist whether or not they are  
>>>> incorporated for handy access within a URI or not.
>>>> When the URI can be used, the URI collection within the  
>>>> requested node itself contains all the nodes that will be  
>>>> collected with method 1 and there is no need to access any  
>>>> additional information.
>>>>>> Again, I am not trying to add or change any of the existing  
>>>>>> functionality,
>>>>> You are proposing an addition that is a subset of the more  
>>>>> general approach.
>>>> Hopefully, the description above satisfactorily demonstrates  
>>>> that the URIs are simply a concrete mechanism to implement the  
>>>> general solution. It is also a mechanism that, if used  
>>>> effectively, appears to be much more efficient since all nodes  
>>>> that need to be collected in method 1 actually are already  
>>>> contained in the URI collection of the requested node.
>>>> Therefore it is a concrete representation of the general  
>>>> approach, however it is a concrete representation that  
>>>> capitalizes on the fact that the object used to represent the  
>>>> node (the URI) has an equivalent structure to the spatial  
>>>> relationships of the nodes in the DAG that need to be collected  
>>>> in method 1, and so those nodes do not need to collected at all  
>>>> since they are already present.
>>>> The same structural relationship exists in method 2, however,  
>>>> method 2 fans out so far so fast that collection outside the  
>>>> requested node will be required to fulfill the needs of method 2.
>>>> It is functionally equivalent to the general approach, however,  
>>>> it has the advantage that a single URI contains the normative  
>>>> identity of all the required nodes for method 1 and some for  
>>>> method 2.
>>>>> I understand that you favor a different approach to this  
>>>>> problem. It may be worth our while to create a separate profile  
>>>>> for such an approach, but I do not see any reason to muddy the  
>>>>> existing one.
>>>> It should be clear from the above discussion that showing how  
>>>> URIs address the same problem is not a "different approach". It  
>>>> is the same approach, except the work required to collect the  
>>>> nodes is a lot less, and can be eliminated almost completely  
>>>> depending on what node collection strategy is chosen, method 1  
>>>> or method 2.
>>>> Finally, it should be clear that the bulleted algorithms in  
>>>> section 3.2 of the spec represent a nonURI approach using a  
>>>> method 2 collection algorithm.
>>>> Now that the problem is clearly defined, I expect it will take  
>>>> much fewer words than have been exchanged in these emails to  
>>>> explain the available options in section 3.2, which are:
>>>>    1. method 1 node collection, URI method (all nodes required  
>>>> are in
>>>>       requested node)
>>>>    2. method 1 node collection, ancestor method: (requested node  
>>>> has
>>>>       pointers to parents, but need to recursively navigate to  
>>>> parent
>>>>       to advance up the hierarchy, but does not navigate thru  
>>>> nodes of
>>>>       which the requested node is not a hierarchy member)
>>>>    3. method 2 node collection, URI method (subset of nodes  
>>>> required
>>>>       are in requested node, the rest must be obtained by  
>>>> recursively
>>>>       navigating based on parent hierarchy nodes of which requested
>>>>       node is not a member)
>>>>    4. method 2 node collection, ancestor method (this is the  
>>>> algorithm
>>>>       currently in section 3.2 bullets and need to recursively
>>>>       navigate thru all parent nodes regardless of whether  
>>>> requested
>>>>       node is a member of the hierarchy or not.)
>>>> These 2 choices of node collection are implicit in the DAG  
>>>> problem definition and are not currently explained in the  
>>>> document and I believe need to be. i.e. a DAG is the result of a  
>>>> set of hierarchies (as defined above) being layed across a set  
>>>> of resources. i.e. it is the result of a set of explicit  
>>>> relations being applied between pairs of nodes. The "choice" is  
>>>> whether to retain the "history" of why those relations were  
>>>> applied (i.e. the direct relations) or not. If you don't then  
>>>> additional, indirect, extraneous relations automatically appear  
>>>> and there is no way distinguish between them and the direct  
>>>> relations, at least in the "general" or "ancestor" case. In the  
>>>> URI case, the direct and indirect relations are always present  
>>>> and may be used or not as a matter of choice.
>>>> The choice of ancestor or URI method for node identification is  
>>>> simply whether URI "can" be used and whether URI is "desired" to  
>>>> be used. Functionally, URI will produce the same results.
>>>> Thanks,
>>>> Rich
>>>>> Daniel;
>>> -------------------------------------------------------------------- 
>>> -
>>> 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]