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;
