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