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