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
>
