OASIS eXtensible Access Control Markup Language (XACML) TC

I am finding the Hierarchical profile ambiguous and inconsistent and 
therefore incomprehensible, which may, similarly to the Multi-Resource 
profile be because there are essential contextual paradigms missing from 
the specification.

For the Multi-Resource profile, the missing contextual paradigms included:

    * It is necessary to pre-process the multi-resource request and
      submit individual requests to the PDP, and then to package up the
      responses into a single response.
    * The PDP, itself, can only process Request elements that in 2.0
      contain a single Resource element, single Action element, single
      Environment element, and multiple Subject elements, but each
      Subject element has to have a distinct SubjectCategory attribute,
      and in 3.0 there can be multiple Attributes elements, but each has
      to have a distinct Category attribute.

Once the above paradigms are established, the Multi-Resource profiles 
become comprehensible.

I suspect something similar is going on w the Hierarchical profile also.

Here is the background on the Hierarchical profile that I am trying to 
work thru (each bullet represents a potential issue to resolve or 
suggestion for improvement):

    * There needs to be a definition of "hierarchy". In particular, a
      "hierarchy" defn should state that the fundamental properties are
      that there must be a single root node with no parent, and that
      every other node in the hierarchy must have one and only one
      parent, and can have zero, one, or more children.
    * Section 3.2 is the biggest problem. To begin, the following needs
      confirmation: it appears that the key structural sentence for 3.2
      that explains what the four bullets that follow it are is lines
      314-315 (which is sandwiched between a negative statement on
      ResourceContent and subsequent 3 sentence "note") that state:
          o "The request context 

On Jan 14, 2009, at 10:54 PM, Rich.Levinson wrote:

>    * There needs to be a definition of "hierarchy". In particular, a
>      "hierarchy" defn should state that the fundamental properties are
>      that there must be a single root node with no parent, and that
>      every other node in the hierarchy must have one and only one
>      parent, and can have zero, one, or more children.

I am not sure why do you think this is a requirement.   It is a  
normal use case to inherit policy from more then one parent, and  
"ancestors" attribute approach allows such models without undue  
restrictions.

>    in order to submit a request  one has to somehow identify all  
> the hierarchies the given node
>      belongs to, all the hierarchies the node's parent(s) and  
> ancestors to, and include an Attribute element for each.

And why is that a problem?   Yes, if one wants "inheritance", graph  
needs to be defined, and attributes is a natural way to define it.

>  I suspect that at most one would need to collect all the normative  
> representations of only the resource-id node (i.e. identify all the  
> hierarchies it belongs to), then for each hierarchy, one would  
> evaluate the policies that apply to that hierarchy.
>

Policy evaluation does not need to know anything about hierarchies  
that are represented with an "ancestor" attribute.

Daniel;

  
  


Hi Daniel,


Thanks for the feedback. Let me try to clarify a bit.

My first objective is to understand what the spec currently says, and I
am finding that the terminology is inherently ambiguous, and as a
result, to me at least, that makes the details of the spec impossible
to understand. So, what I did was try to disambiguate by defining
"hierarchy". Let me be more explicit:


Lines 73-77 state the following:

In this Profile, a resource organized as a hierarchy may be
a “tree” (a hierarchy with a single root) or a “forest” (a hierarchy
with multiple roots), but the hierarchy may not have cycles. Another
term for these two types of hierarchy is “Directed Acyclic Graph” or
“DAG”. All such resources are called hierarchical resources in this
Profile. An XML document is always structured as a “tree”. Other types
of hierarchical resources, such as files in a file system that supports
links, may be structured as “forests”.


This is an inherently self-contradictory definition. A hierarchy has a
single root. It is an "ordered set", where each entity in the set has a
defined relationship to every other entity. A "forest" is not a
hierarchy. It is multiple hierarchies. The "definition" above is not
meaningful because it equates the singular and plural.


As a result of this self-contradiction, the spec then goes to introduce
what, to me are meaningless concepts, such as lines 315-316:

Note that a node in a hierarchical resource that is not
represented as an XML document MAY have multiple parents.


Therefore, in order to understand what the spec says, I first found it
necessary to come up with an unambiguous term for "hierarchy", which
allows sentences such as the above to be restated in a "meaningful"
way, such as:

Note that a node in a hierarchical resource that is not
represented as an XML document MAY belong to multiple hierarchies
and have a parent associated with each one.


I am not saying anything so far is "wrong", simply that it is not
understandable without firming up the definitions.


wrt to the "somehow identify all the hierarchies a node belongs to"
comment, I was not saying it was a problem, but simply observing that
that was what the spec was saying in terms of specific defn of the term
"hierarchy".


Finally, I do not understand your comment that says:

Policy evaluation does not need to know anything about
hierarchies that are represented with an "ancestor" attribute.


I am trying to understand what policies are supposed to do with the
definitions in the spec. i.e. it is the spec that says in section 3.2
that all the parent and ancestor nodes need to be assembled in the
request context. What "policy evaluation" are you referring to? Are you
saying what I indicated in original email that a policy does not need
to know anything about hierarchies that the resource-id node does not
belong to?


    Thanks,

    Rich




Daniel Engovatov wrote:
1448A6CC-1532-40B4-BFC0-DC9D0413097E@streamdynamics.com" type="cite">

On Jan 14, 2009, at 10:54 PM, Rich.Levinson wrote:


  
   * There needs to be a definition of
"hierarchy". In particular, a

     "hierarchy" defn should state that the fundamental properties are

     that there must be a single root node with no parent, and that

     every other node in the hierarchy must have one and only one

     parent, and can have zero, one, or more children.

  


I am not sure why do you think this is a requirement.   It is a normal
use case to inherit policy from more then one parent, and "ancestors"
attribute approach allows such models without undue restrictions.


  
   in order to submit a request  one has to
somehow identify all the hierarchies the given node

     belongs to, all the hierarchies the node's parent(s) and ancestors
to, and include an Attribute element for each.

  


And why is that a problem?   Yes, if one wants "inheritance", graph
needs to be defined, and attributes is a natural way to define it.


  
 I suspect that at most one would need to
collect all the normative representations of only the resource-id node
(i.e. identify all the hierarchies it belongs to), then for each
hierarchy, one would evaluate the policies that apply to that
hierarchy.


  


Policy evaluation does not need to know anything about hierarchies that
are represented with an "ancestor" attribute.


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

Rich.Levinson wrote:
> I am trying to understand what policies are supposed to do with the 
> definitions in the spec. i.e. it is the spec that says in section 3.2 
> that all the parent and ancestor nodes need to be assembled in the 
> request context. What "policy evaluation" are you referring to? Are 
> you saying what I indicated in original email that a policy does not 
> need to know anything about hierarchies that the resource-id node does 
> not belong to?

Hi Rich,

I don't understand all the questions you have, but here's the basic 
approach of the profile in a simple example.

Assume the following simple hierarchy:

A <- B <- C

If someone requests access to C, the request will contain these 
attributes. this is from the top of my head, so it might be slightly 
inaccurate and I might have forgotten some of the attributes, but 
hopefully you get the idea.



All these attributes are there so it is possible to write policies which 
apply to parts of the hierarchy, not just individual nodes.

For example:



Matches only the resource C, nothing else.




matches the immediate children of B. In the example this is C, but if C 
had a sibling, it would also match.





Matches B or any node below B. In this case also C.

Best regards,
Erik

  


Hi Erik,


Thanks for this feedback. Unfortunately I did not have time to process
this email before today's meeting, but now that I have, it addresses
one of my major concerns which was the motivational context. i.e. by
seeing the actual example you provided, I can see that a Policy can now
base decisions knowing that some node happens to be an ancestor of the
requested node.


In addition, for your example, I think it would be instructive to show
when a node belongs to two or more hierarchies, that the collection of
attributes should probably have a mechanism to indicate which hierarchy
a node belongs to. For example, if C had an alias C', and parent B' and
ancestors A'->D' where, while (C = C'), that in general (B != B')
and (A != A') and obviously D' has no relation to the unprimed nodes at
all. We would then have a request:

<Resource>

 resource-id = C

 parent-id = B

 self-or-ancestor = C

 self-or-ancestor = B

 self-or-ancestor = A

 resource-id = C'

 parent-id = B'

 self-or-ancestor = C'

 self-or-ancestor = B'

 self-or-ancestor = A'

 self-or-ancestor = D'

</Resource>


It would seem to me that there needs to be a mechanism whereby one
would be able to tell the primed from unprimed attributes. Possibly
using Issuer


In any event, it is useful information to have this additional context
for understanding the current spec.


As agreed at the meeting, I will try to find some cycles to say what I
think needs to be done to make the spec easier to understand, which is
possibly just including the above information (i.e. your email extended
to multiple hierarchies with some example policy concepts, also such as
you provided).


Also, I think, as I mentioned at the end of the meeting that "scope"
may also have a meaningful role to include in this profile as well.
i.e. one can easily see that if policies are defined whereby certain
conditions apply when a resource-id node is within scope (as defined by
multi-resource spec) of some other node, that some if that ""other
node" happens to be a parent or ancestor of the resource-id node, then
those "certain conditions" would apply to the current resource-id being
requested.


    Thanks,

    Rich






Erik Rissanen wrote:
496F4DC8.4030200@axiomatics.com" type="cite">Rich.Levinson
wrote:

  
I am trying to understand what policies are
supposed to do with the definitions in the spec. i.e. it is the spec
that says in section 3.2 that all the parent and ancestor nodes need to
be assembled in the request context. What "policy evaluation" are you
referring to? Are you saying what I indicated in original email that a
policy does not need to know anything about hierarchies that the
resource-id node does not belong to?

  


Hi Rich,


I don't understand all the questions you have, but here's the basic
approach of the profile in a simple example.


Assume the following simple hierarchy:


A <- B <- C


If someone requests access to C, the request will contain these
attributes. this is from the top of my head, so it might be slightly
inaccurate and I might have forgotten some of the attributes, but
hopefully you get the idea.


<Resource>

 resource-id = C

 parent-id = B

 self-or-ancestor = C

 self-or-ancestor = B

 self-or-ancestor = A

</Resource>


All these attributes are there so it is possible to write policies
which apply to parts of the hierarchy, not just individual nodes.


For example:


<Target>

 resource-id = C

</Target>


Matches only the resource C, nothing else.



<Target>

 parent-id = B

</Target>


matches the immediate children of B. In the example this is C, but if C
had a sibling, it would also match.




<Target>

 ancestor-or-self = B

</Target>


Matches B or any node below B. In this case also C.


Best regards,

Erik

  
  


Hi All,


I am choosing this point (in the email threads) to continue discussion
of the issues with the Hierarchical profile as I think it contains the
best context to start from.


As indicated in the last couple of TC meetings, the update I proposed:

http://lists.oasis-open.org/archives/xacml/200901/msg00079.html


only goes part-way to addressing the problems I have found in the
Hierarchical profile specification. The update only includes
effectively a glossary with definitions of the terms that are currently
used in the spec that make the rest of the spec comprehensible (at
least from my perspective), and based on that glossary, the spec
includes a few clarifying edits, which are primarily intended to make
the statements in the spec consistent in terms of the definitions in
the glossary.


Primarily, the glossary simply defines "hierarchy" and "DAG" (Directed
Acyclic Graph), where DAG is a collection of hierarchies that are
mapped onto a flat collection of resources, where any resource can be a
member of multiple hierarchies within the DAG.


Based on this starting point and Erik's suggestion as to how the
concepts might be applied in the real world, I did further
investigation and have come to some additional preliminary conclusions
on which I think the next step to address this spec should be based.



  
The most significant conclusion I have reached is that the
primary "problem" with the non-xml resources (section 3.2) is that the
details here are solving a much more complicated problem than is
necessary for most common use cases, which is that the resources are
identified with URIs as described in section 2.2 and 4.3.


In particular, this "more complicated problem" is one where the
resource-id, itself, is not sufficient to describe the hierarchy of
which it is a member. An example might be resources identified by
serial number (a flat namespace), as opposed to resources identified by
URI, which is an inherently hierarchical namespace
(http://www.ietf.org/rfc/rfc2396.txt).


With a hierarchical namespace there is no need to collect parent and
ancestor nodes since they are already built in to the URI itself. In
fact, there is an example document that I "found", that was produced as
an artifact of the XACML 2.0 development effort, that appears to have
gotten lost from the active XACML collection:

http://www.oasis-open.org/committees/download.php/7315/xacml-profile-hierarchical-resources-nonXML-1.0-draft01.pdf


that demonstrates this quite clearly: section 4.2 shows policies based
on resource-ancestor and resource-parent attributes, and section 4.3
shows the same policies based on matching anyURI. i.e. if the resources
are identified by URI there is no need to use resource-parent and
resource-ancestor attributes either in the RequestContext or in the
Policies.


Based on this situation, my proposal is to enhance the existing
Hierarchical spec using the URI representation in section 3.2 and
indicating that this approach can be used instead of resource-parent
and ancestor when the hierarchies are represented by nodes with URI
resource-ids.


  
  
A 2nd significant problem I believe I have found is that the
algorithms defined in section 3.2 are incorrect in some significant
ways, which I believe should be addressed (I will give an example
below).


My proposal here is to simply fix the algorithms.


  
  
A 3rd significant problem I believe I have found is that there
are important concepts that are either left out or not given sufficient
emphasis in the spec, which, imo, cause conceptual ambiguities that
make it effectively impossible to say what problem the specification is
actually addressing.


In particular, there is no explicit definition of "normative identity",
which is a key term used in the algorithms defined in section 3.2.

My proposal here is to assert that the normative identity may use
either the recommended representation of URI described in section 2.2,
or a functionally equivalent representation, such as can be constructed
using resource-parent and resource-ancestor node collections.


In particular, there is insufficient development of the concept of
"consistent representations for identities" as mentioned in section 1,
lines 68-72,  section 2, lines 175-178, section 3, lines 227-229. While
the point is made that such consistent representations are necessary,
the essential fact that in a DAG that a single node can have multiple
normative identities AND that those identities each belong to a
separate distinct hierarchy within the DAG is not established. The
result is that it is conceptually ambiguous that when a node is said to
have multiple parents, the essential fact is that the node must then
have multiple normative identities, each of which is traceable to one
and only one parent (or self, if the current node happens to be the top
of one of the hierarchies within the DAG).

My proposal here is to adjust the text to emphasize these notions
accordingly.

One final note: I appreciate the significant effort that went into the
development of the Hierarchical specification. A review of the emails
from April 2004 -> September 2004 will show anyone interested that a
lot of work went into the development of this specification. My own
interpretation of the problems I have had with this spec is that it was
a relatively small, but considered to be important, part of XACML 2.0
and that while the ideas collected in this spec are generally properly
targeted, it appears there was simply not sufficient time available for
the TC to consolidate the findings of their studies of the hierarchy
problem and to structurally sort the results into separable pieces that
would have made the results easier to understand and apply.


This effort is intended to build on the existing spec and emphasize
aspects of it that currently are not, and to correct any problems that
may be found in the process.


As indicated above, I will give an example of what I consider to be an
"error" in the algorithms of section 3.2:

In section 3.2 the descriptions appear to be lterally
"over-specified": for example, consider lines 324-327:

  
" For each immediate parent of the node specified in the
“resource-id” attribute or attributes, and for each normative
representation of that parent node, an <Attribute> element with
AttributeId “urn:oasis::names:tc:xacml:2.0:resource:resource-parent”. "

  
This statement is indicating that the node "specified in the
'resource-id' attribute or attributes" can have multiple parents and
that each of those parents themselves can have multiple normative
representations.


I claim that the quoted statement is incorrect because while the given
node can have multiple parents, because the current node may belong to
multiple hierarchies, there should be no concern for hierarchies that
the parent belongs to that the current node does not belong to.


The following example will show why this is doubly and actually triply
specified and also why it is essential that the changes described in
1-3 above are needed.


Consider 3 hierarchies:

  

    
/a1/b1/c1
    
/a2/b2/c2
    
/a3/b3/c3
  
Let's say that a1, a2, and a3 are distinct roots and represent 3
separate nodes (or resources) in the overall collection.


However, let us also say that b1 is a node that belongs to all 3
hierarchies and that, in fact, /a1/b1, /a2/b2, and /a3/b3 all represent
normative identities of the same node.


Now let us further assume that c1 and c2 represent the same physical
node, but that c3 is a different node.


Let's also assume that these physical nodes have serial numbers r*,
which serve as alternate unique identifiers of the nodes. We can then
see the relation as follows:

  

    
Let r1, r2, r3 be serial numbers of the 3 separate root nodes.
    
Let r4 be the serial number of the b1,b2,b3 node.
    
Let r5 be the serial number of the c1,c2 node.
    
Let r6 be the serial number of the c3 node.

  
The logical and physical resources and hierarchies can now be
represented together as follows:

  

    
/a1(r1)/b1(r4)/c1(r5)
    
/a2(r2)/b2(r4)/c2(r5)
    
/a3(r3)/b3(r4)/c3(r6)
  
From the above, it is clear that if we are requesting access to, say
node /a1/b1/c1, then to apply the rules quoted above for parents, we
would need to first include:

  

    
/a1(r1)/b1(r4)/c1(r5)
    
/a2(r2)/b2(r4)/c2(r5)
  
where the 2 parents of c1(r5) are

  

    
/a1/b1
    
/a2/b2
  
i.e. c1, which is r5, which is then also c2, effectively has these 2
parents.


However, the rule then requires us to collect all the normative
identities of each of the parents.


First of all in this case the parent rule requires us to collect the
normative identities of r4 twice, once in its a1/b1 incarnation at
which point it also picks up a2/b2, and once in its a2/b2 incarnation,
where it picks up a1/b1 again. Therefore it is already "over-specified"
because it requires collecting these identities twice resulting in 4
instead of 2 "normative parent identities".


Furthermore, the algorithm also requires us to pick up /a3/b3, which is
another "normative identity" of this parent node, which means we will
have 3 copies of each normative identity of the "parents" of c1 for a
total of 9 "normative parent identities", which are, of course triply
redundant.


In fact, we really only need /a1/b1 and /a2/b2 since r5 does not belong
to the /a3/b3 hierarchy.


Therefore this algorithm needs at least 2 corrections:

  

    
Correct it so that it only includes one copy of each normative
identity of each parent.
    
Correct it so that it does not include normative identities of
the parent which are part of hierarchies to which it does not belong,
since policies on those hierarchies can have no bearing on this node
because the normative representations within those hierarchies cannot
refer to this node because it does not have a normative representation
in those hierarchies to which it does not belong.
  

Comments and suggestions are welcome. I will wait for feedback on
emails and discussion at the next TC meeting before proceeding with the
recommended changes.


    Thanks,

    Rich









Rich.Levinson wrote:
496F6636.9010801@oracle.com" type="cite">

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                
Original Message --------
  

    

      

        
Subject: 
        
Re: [xacml] Issue: Hierarchical profile appears ambiguous
and inconsistent
      
      

        
Date: 
        
Thu, 15 Jan 2009 11:37:10 -0500
      
      

        
From: 
        
Rich.Levinson <rich.levinson@oracle.com>
      
      

        
To: 
        
Erik Rissanen <erik@axiomatics.com>
      
      

        
CC: 
        
Daniel Engovatov <daniel@streamdynamics.com>, xacml
<xacml@lists.oasis-open.org>
      
      

        
References:
        
        
<496EDDA0.4070707@oracle.com>
<1448A6CC-1532-40B4-BFC0-DC9D0413097E@streamdynamics.com>
<496F4B67.1040700@oracle.com>
<496F4DC8.4030200@axiomatics.com>
      
    
  



Hi Erik,


Thanks for this feedback. Unfortunately I did not have time to process
this email before today's meeting, but now that I have, it addresses
one of my major concerns which was the motivational context. i.e. by
seeing the actual example you provided, I can see that a Policy can now
base decisions knowing that some node happens to be an ancestor of the
requested node.


In addition, for your example, I think it would be instructive to show
when a node belongs to two or more hierarchies, that the collection of
attributes should probably have a mechanism to indicate which hierarchy
a node belongs to. For example, if C had an alias C', and parent B' and
ancestors A'->D' where, while (C = C'), that in general (B != B')
and (A != A') and obviously D' has no relation to the unprimed nodes at
all. We would then have a request:


   <Resource>

    resource-id = C

    parent-id = B

    self-or-ancestor = C

    self-or-ancestor = B

    self-or-ancestor = A

    resource-id = C'

    parent-id = B'

    self-or-ancestor = C'

    self-or-ancestor = B'

    self-or-ancestor = A'

    self-or-ancestor = D'

   </Resource>


It would seem to me that there needs to be a mechanism whereby one
would be able to tell the primed from unprimed attributes. Possibly
using Issuer


In any event, it is useful information to have this additional context
for understanding the current spec.


As agreed at the meeting, I will try to find some cycles to say what I
think needs to be done to make the spec easier to understand, which is
possibly just including the above information (i.e. your email extended
to multiple hierarchies with some example policy concepts, also such as
you provided).


Also, I think, as I mentioned at the end of the meeting that "scope"
may also have a meaningful role to include in this profile as well.
i.e. one can easily see that if policies are defined whereby certain
conditions apply when a resource-id node is within scope (as defined by
multi-resource spec) of some other node, that some if that ""other
node" happens to be a parent or ancestor of the resource-id node, then
those "certain conditions" would apply to the current resource-id being
requested.


   Thanks,

   Rich





Erik Rissanen wrote:

  
Rich.Levinson wrote:
I am trying to understand what policies are
supposed to do with the definitions in the spec. i.e. it is the spec
that says in section 3.2 that all the parent and ancestor nodes need to
be assembled in the request context. What "policy evaluation" are you
referring to? Are you saying what I indicated in original email that a
policy does not need to know anything about hierarchies that the
resource-id node does not belong to?


Hi Rich,


I don't understand all the questions you have, but here's the basic
approach of the profile in a simple example.


Assume the following simple hierarchy:


A <- B <- C


If someone requests access to C, the request will contain these
attributes. this is from the top of my head, so it might be slightly
inaccurate and I might have forgotten some of the attributes, but
hopefully you get the idea.


<Resource>

 resource-id = C

 parent-id = B

 self-or-ancestor = C

 self-or-ancestor = B

 self-or-ancestor = A

</Resource>


All these attributes are there so it is possible to write policies
which apply to parts of the hierarchy, not just individual nodes.


For example:


<Target>

 resource-id = C

</Target>


Matches only the resource C, nothing else.



<Target>

 parent-id = B

</Target>


matches the immediate children of B. In the example this is C, but if C
had a sibling, it would also match.




<Target>

 ancestor-or-self = B

</Target>


Matches B or any node below B. In this case also C.


Best regards,

Erik


  
  


Original Message --------
  

    

      

        
Subject: 
        
[xacml] Issue: Hierarchical profile appears ambiguous and
inconsistent
      
      

        
Date: 
        
Thu, 15 Jan 2009 01:54:24 -0500
      
      

        
From: 
        
Rich.Levinson <rich.levinson@oracle.com>
      
      

        
To: 
        
xacml <xacml@lists.oasis-open.org>
      
    
  



I am finding the Hierarchical profile ambiguous and inconsistent and
therefore incomprehensible, which may, similarly to the Multi-Resource
profile be because there are essential contextual paradigms missing
from the specification.


For the Multi-Resource profile, the missing contextual paradigms
included:


   * It is necessary to pre-process the multi-resource request and

     submit individual requests to the PDP, and then to package up the

     responses into a single response.

   * The PDP, itself, can only process Request elements that in 2.0

     contain a single Resource element, single Action element, single

     Environment element, and multiple Subject elements, but each

     Subject element has to have a distinct SubjectCategory attribute,

     and in 3.0 there can be multiple Attributes elements, but each has

     to have a distinct Category attribute.


Once the above paradigms are established, the Multi-Resource profiles
become comprehensible.


I suspect something similar is going on w the Hierarchical profile
also.


Here is the background on the Hierarchical profile that I am trying to
work thru (each bullet represents a potential issue to resolve or
suggestion for improvement):


   * There needs to be a definition of "hierarchy". In particular, a

     "hierarchy" defn should state that the fundamental properties are

     that there must be a single root node with no parent, and that

     every other node in the hierarchy must have one and only one

     parent, and can have zero, one, or more children.

   * Section 3.2 is the biggest problem. To begin, the following needs

     confirmation: it appears that the key structural sentence for 3.2

     that explains what the four bullets that follow it are is lines

     314-315 (which is sandwiched between a negative statement on

     ResourceContent and subsequent 3 sentence "note") that state:

         o "The request context <Resource> element SHALL contain
the

           following elements and XML attributes."

   * Each of the 4 bullets in section 3.2 contains the phrase "(for

     each) normative representation (of some node ...)". I think this

     is the core of the problem I am having understanding this spec.

     What I think it means is that for a given collection of physical

     resources, such as files in a file system, that in additional to

     the conventional file identification by directory path, which

     includes all the files in the file system, that other logical

     hierarchies that can span part or all of this set of resources

     also needs to be taken into account. And that the "normative

     identity" of a specific "file" is within the context of a specific

     hierarchy. i.e. each hierarchy that covers all or part of this set

     of resources has its own "namespace" and within that namespace has

     a scheme for hierarchically naming its members. As such, a given

     physical resource can belong to any number of these hierarchies

     simultaneously, and has one "normative representation" for each

     hierarchy it belongs to. And presumably, the point is that each

     hierarchy the resource belongs to may have its own restrictions to

     apply to resource, so we have to identify all of them to get the

     full picture.

   * Given the above characterization of the multiple "hierarchies" a

     given resource can belong to, it then appears that the four

     bullets in section 3.2 state that in order to submit a request,

     one has to somehow identify all the hierarchies the given node

     belongs to, all the hierarchies the node's parent(s) and ancestors

     to, and include an Attribute element for each.

   * There appears to be some over-specification above and beyond what

     is presumably intended (assuming the above characterizes what is

     "presumably intended"). For example, since a node in a hierarchy

     can have only one parent, and if a node belongs to multiple

     hierarchies, then that node will have one and only one parent for

     each hierarchy it belongs to, the following sentence (lines

     324-325) appears to doubly state this relationship:

         o "For each immediate parent of the node specified in the

           “resource-id” attribute or attributes, and for each

           normative representation of that parent node ..."

           i.e. the node specified in the resource-id can only have one

           parent wrt the the node's normative representation with a

           specific hierarchy. There seems to be no point to looking at

           a parent node in any other context than the normative

           context of the resource-id node. i.e. if a node only belongs

           to one hierarchy, but its parent belongs to many, then the

           other hierarchies the parent belongs to should have no

           impact on the child since the child is not a member of those

           hierarchies.


Assuming the above characterization is even close to correct, I am
still wondering "why" all this information is being assembled and what
the Policy is expected to do with it. i.e. what is the policy
evaluation paradigm that is being represented here? I suspect that at
most one would need to collect all the normative representations of
only the resource-id node (i.e. identify all the hierarchies it belongs
to), then for each hierarchy, one would evaluate the policies that
apply to that hierarchy.


Thanks,

Rich



---------------------------------------------------------------------

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

  

Based on this situation, my proposal is to enhance the existing Hierarchical spec using the URI representation in section 3.2 and indicating that this approach can be used instead of resource-parent and ancestor when the hierarchies are represented by nodes with URI resource-ids.

Using URI is a very limited approach, and it can be trivially mapped into "ancestor" approach.    Requiring a unique URI for resources is often not feasible

 The following example will show why this is doubly and actually triply specified and also why it is essential that the changes described in 1-3 above are needed.

 Consider 3 hierarchies:
  
    
/a1/b1/c1
    
/a2/b2/c2
    
/a3/b3/c3
  
 Let's say that a1, a2, and a3 are distinct roots and represent 3 separate nodes (or resources) in the overall collection.

I think you are confusing physical resources and policy resources.    Such mapping is outside of XACML.    There is no real hierarchy in XACML, we just provide a convenient normative way to represent them - only for the purpose of using it in a policy target.

For the purpose of a single policy evaluation hierarchy that is used is uniquely defined by the provided "resource-ancestors" attribute.   The fact that there is some persistent identity that may participate in different hierarchies should be outside of the scope of this profile.

Daniel;

  


Hi Daniel,


See replies inline:


Daniel Engovatov wrote:
daniel@streamdynamics.com,0E0925E7-45E3-468F-B4FF-08BC9" type="cite">
  
Based on this situation, my proposal is to
enhance the existing Hierarchical spec using the URI representation in
section 3.2 and indicating that this approach can be used instead of
resource-parent and ancestor when the hierarchies are represented by
nodes with URI resource-ids.

  


Using URI is a very limited approach, and it can be trivially mapped
into "ancestor" approach.    Requiring a unique URI for resources is
often not feasible


I am not recommending removing or replacing what is there, but simply
representing the URI approach and the manner in which it can be used in
parallel. When the URI is present, there is no need to create the
ancestors, and one may simply use the anyURI-regexp-match as specified
in section 4.3 (which I notice now needs to be updated to be consistent
w core). Also, as stands, 4.3 really should have corresponding
description in 3.2, which it currently does not.

I am not recommending requiring URI, but only making it available when
convenient, which I think includes quite a broad range of use cases and
I would not characterize it as "very limited" despite the fact that it
may not be "universally applied".

My objectives are usability of the policy language. Scoping based on
URI  regular expression matching is a universal technique, which is
much easier than parsing URIs into parents and ancestors and then using
XPath-type referencing, which is the approach indicated by Erik's
example.

As you and others have indicated in the 2004 emails, there are use
cases where URI is not readily available or desired, and the mechanisms
from XPath are very useful there and I have no intention to remove
them, but only to "correct" them, if need be, as indicated by the
example I included in prev email.

daniel@streamdynamics.com,0E0925E7-45E3-468F-B4FF-08BC9" type="cite">

  
The following example will show why this is
doubly and actually triply specified and also why it is essential that
the changes described in 1-3 above are needed.


Consider 3 hierarchies:

/a1/b1/c1

/a2/b2/c2

/a3/b3/c3

Let's say that a1, a2, and a3 are distinct roots and represent 3
separate nodes (or resources) in the overall collection.

  


I think you are confusing physical resources and policy resources.   
Such mapping is outside of XACML.    There is no real hierarchy in
XACML, we just provide a convenient normative way to represent them -
only for the purpose of using it in a policy target.


I do not believe I am confusing the two. Physical resources are a fact
of existence and in the case of XACML, the hierarchical identifiers are
simply labels that the managers of those resources have applied to
them. In the example I gave, it is the r* that represent the physical
labels on the physical resources. They are an unordered flat
collection. All the /a*/b*/c* are hierarchical representations of
subsets of those resources. A given instance of "*" represents one
hierarchy that is mapped onto the physical resources. All the policies
deal with are the hierarchical representations. The physical is only
mentioned to give people some context for understanding what is being
discussed.

For example, all the PCs in a company have serial numbers.
When managers create policies, they have the physical resources in mind
and may organize them hierarchically for various purposes. A department
manager may label the PCs in his/her dept according to some
hierarchical structure in the dept organization and assign policies
accordingly. At the same time these PCs are company property and may be
labeled independently by the IT dept in terms of who is responsible for
maintenance on them.


If someone wants to take one of these PCs out of the building, maybe
there is a policy that says even if the employee's manager says it is
ok, the facilities manager must also approve before permission is
granted. This can be modeled with a dept hierarchy and a facilities
hierarchy, and there are rules within the hierarchy producing a result
and policy combining between the 2 hierarchies that can resolve
conflicts such as described above.


In the above example the /a1/b1/c1 might be the dept hierarchy and
/a2/b2/c2 might be the facilities hierarchy.


daniel@streamdynamics.com,0E0925E7-45E3-468F-B4FF-08BC9" type="cite">

For the purpose of a single policy evaluation hierarchy that is used is
uniquely defined by the provided "resource-ancestors" attribute.   
It is also uniquely defined by a URI if a URI scheme has been applied
to the same resources, since all the ancestors are readily identifiable
within the URI.

daniel@streamdynamics.com,0E0925E7-45E3-468F-B4FF-08BC9" type="cite">The fact that there is some persistent identity that may
participate in different hierarchies should be outside of the scope of
this profile.


As indicated above and original email, the r* persistent identity is
only used as contextual reference for humans to know what is being
discussed. Within the policies themselves, there would generally be no
need to include this attribute except possibly for reporting purposes.


    Thanks,

    Rich

daniel@streamdynamics.com,0E0925E7-45E3-468F-B4FF-08BC9" type="cite">

Daniel;

> For example, all the PCs in a company have serial numbers. When  
> managers create policies, they have the physical resources in mind  
> and may organize them hierarchically for various purposes. A  
> department manager may label the PCs in his/her dept according to  
> some hierarchical structure in the dept organization and assign  
> policies accordingly. At the same time these PCs are company  
> property and may be labeled independently by the IT dept in terms  
> of who is responsible for maintenance on them.
>
> If someone wants to take one of these PCs out of the building,  
> maybe there is a policy that says even if the employee's manager  
> says it is ok, the facilities manager must also approve before  
> permission is granted. This can be modeled with a dept hierarchy  
> and a facilities hierarchy, and there are rules within the  
> hierarchy producing a result and policy combining between the 2  
> hierarchies that can resolve conflicts such as described above.
>
> In the above example the /a1/b1/c1 might be the dept hierarchy and / 
> a2/b2/c2 might be the facilities hierarchy.

There is no need for separate hierarchies here if the "remove from  
building" is a single access decision.  In your example, let's "PC"  
be a resource, "DEPT" be a department, and "FACILITIES" be  
facilities.     In this case resource-ancestors will be {"PC",  
"DEPT", "FACILITIES"}    (or {"a1", "a2", "b1", "b2", "c"} )  There  
is no need for two hierarchies.   That is the advantage of not being  
pidgeonholed into a single inheritance URI-like scheme.

> It is also uniquely defined by a URI if a URI scheme has been  
> applied to the same resources, since all the ancestors are readily  
> identifiable within the URI.

That's a bit of a contorted way to represent a simple bag of strings.

>  Within the policies themselves, there would generally be no need  
> to include this attribute except possibly for reporting purposes.

Then what exactly is the problem?   Policy, as specified, can be  
evaluated deterministically.   The mapping of physical entities into  
policy resources is outside of the scope of this profile.   I do not  
see anything broken here.

Daniel;

  


Hi Daniel,


I am not sure exactly what you are driving at here, but I include
comments below:


Daniel Engovatov wrote:
daniel@streamdynamics.com,4BD684A8-1AF9-4E23-AB83-0EB76" type="cite">
  
For example, all the PCs in a company have
serial numbers. When managers create policies, they have the physical
resources in mind and may organize them hierarchically for various
purposes. A department manager may label the PCs in his/her dept
according to some hierarchical structure in the dept organization and
assign policies accordingly. At the same time these PCs are company
property and may be labeled independently by the IT dept in terms of
who is responsible for maintenance on them.


If someone wants to take one of these PCs out of the building, maybe
there is a policy that says even if the employee's manager says it is
ok, the facilities manager must also approve before permission is
granted. This can be modeled with a dept hierarchy and a facilities
hierarchy, and there are rules within the hierarchy producing a result
and policy combining between the 2 hierarchies that can resolve
conflicts such as described above.


In the above example the /a1/b1/c1 might be the dept hierarchy and
/a2/b2/c2 might be the facilities hierarchy.

  


There is no need for separate hierarchies here if the "remove from
building" is a single access decision.  In your example, let's "PC" be
a resource, "DEPT" be a department, and "FACILITIES" be facilities.    
In this case resource-ancestors will be {"PC", "DEPT", "FACILITIES"}   
(or {"a1", "a2", "b1", "b2", "c"} )  There is no need for two
hierarchies.   That is the advantage of not being pidgeonholed into a
single inheritance URI-like scheme.


The hypothetical scenario I am describing is based on two
sub-organizations within a larger organization which operate
independently on the same set of physical resources. In general, the
operations are independent, but in some cases there is need for both
organizations to be brought into some kinds of decision. The dept
manager has set up a hierarchy for controlling the PCs in his
department, while the facilities manager has set up an independent
hierarchy on the same set of PCs for controlling the maintenance on
those PCs from within the facilities organization.


The parent organization recognizes that there may be situations where
the decisions of the two organizations may come into conflict and have
set up combining algorithms above the two hierarchies to resolve
differences.


From what you are saying, and I do not follow your example, it sounds
like it is possible to restructure the existing hierarchies into a new
framework where somehow the existing hierarchies no longer need to
exist. This may be useful as an academic exercise, but operationally,
one would need to educate the company, the facilities and the
department about this new uniform paradigm and explain to the people
involved why they no longer need the hierarchical representations.


However, I do not understand precisely what you are recommending:


  
I do not understand how {"PC", "DEPT", "FACILITIES"} relates to
the scenario I have described. I have specific PCs, in the example they
have serial numbers r5, r6. One of these PCs, r5, is identified in the
"dept" as /a1/b1/c1. In the facilities org the same pc is identified as
/a2/b2/c2.

  
  
The ancestor nodes of /a1/b1/c1 and /a2/b2/c2 are the same,
namely {/a1, /a1/b1, /a2, /a2/b2}. I do not see how you can say {"a1",
"a2", "b1", "b2", "c"}. "c" is not one of the terms. "a2" and "b2" by
themselves are not normative identities. 

daniel@streamdynamics.com,4BD684A8-1AF9-4E23-AB83-0EB76" type="cite">

  
It is also uniquely defined by a URI if a URI
scheme has been applied to the same resources, since all the ancestors
are readily identifiable within the URI.

  


That's a bit of a contorted way to represent a simple bag of strings.


URIs do not represent bags of strings. Possibly one might choose to
represent a URI as a bag of strings, however, one loses the ordering in
the process. If one wants to identify the specific set of nodes
represented by a URI, it is a simple matter to sequentially strip one
component at a time off the URI, and at each step one has the normative
identity of the next node up the chain until one reaches the root.

daniel@streamdynamics.com,4BD684A8-1AF9-4E23-AB83-0EB76" type="cite">

  
 Within the policies themselves, there would
generally be no need to include this attribute except possibly for
reporting purposes.

  


Then what exactly is the problem?   Policy, as specified, can be
evaluated deterministically.   The mapping of physical entities into
policy resources is outside of the scope of this profile.   I do not
see anything broken here.
I was addressing the statement you made that you thought I had a
problem confusing the physical and policy resources. I was showing that
the physical mapping was simply an orthogonal property of the node
which of necessity must include an identity for each of its purposes,
in this case: one for the dept, one for the facilities, and one for the
physical identifier. However, for policies, the physical identifier
need not be used and may be regarded as a resource attribute on the
node entity outside of the policy structures, but available to be
included if necessary.


At this point I fail to understand the purpose of specifically not
using a hierarchical naming scheme in order to identify a set of
resources that will be managed as a hierarchy. I understand that there
may be cases where for some reason it may not be possible or practical
to use such a naming scheme, but in those cases where it is possible
and practical, I do not understand why it would not be a good idea to
use it.


    Thanks,

    Rich


daniel@streamdynamics.com,4BD684A8-1AF9-4E23-AB83-0EB76" type="cite">


Daniel;

>
> However, I do not understand precisely what you are recommending:
> I do not understand how {"PC", "DEPT", "FACILITIES"} relates to the  
> scenario I have described. I have specific PCs, in the example they  
> have serial numbers r5, r6. One of these PCs, r5, is identified in  
> the "dept" as /a1/b1/c1. In the facilities org the same pc is  
> identified as /a2/b2/c2.
No, PC is identified by "r5".   The fact that a PC is governed by a  
policy of the "dept" does not change that fact.   The only purpose of  
hierarchy is to determine an applicable set of rules for a particular  
evaluation.   That is it.  Constructing a hierarchical identifier is  
beyond the scope of that task.

So in my example access to a  "PC" is governed by rules applied to  
both "DEPT" and "FACILITIES".   Very simple.


>>> It is also uniquely defined by a URI if a URI scheme has been  
>>> applied to the same resources, since all the ance
> URIs do not represent bags of strings. Possibly one might choose to  
> represent a URI as a bag of strings, however, one loses the  
> ordering in the process. If one wants to identify the specific set  
> of nodes represented by a URI, it is a simple matter to  
> sequentially strip one component at a time off the URI, and at each  
> step one has the normative identity of the next node up the chain  
> until one reaches the root.
>>

For the purposes of defining a hierarchical policy in this model all  
you need is a bag of strings.   Using URI for that is not needed.    
Use cases that can be represented that way are a subset of use cases  
that can be represented wit "ancestors" approach.  Ordering is not  
important in this model, just like for the rest of our rules.


> At this point I fail to understand the purpose of specifically not  
> using a hierarchical naming scheme in order to identify a set of  
> resources that will be managed as a hierarchy. I understand that  
> there may be cases where for some reason it may not be possible or  
> practical to use such a naming scheme, but in those cases where it  
> is possible and practical, I do not understand why it would not be  
> a good idea to use it.
>

The purpose is that a hierarchical naming scheme is not generic  
enough.   For those cases when it is possible, it is still easier to  
use, as it does not require one to introduce a superfluous naming  
scheme and preserves the ability to change the structure of the  
inheritance graph if needed.


Daniel;

  


Hi Daniel,


If you would care to elaborate on the use case of 'access to a  "PC" is
governed by rules applied to both "DEPT" and "FACILITIES" ', I would be
interested, however, with the info you have given, I simply do not see
a hierarchy represented there. I am truly interested, because when I do
not understand something, I generally assume that there is information
of which I am not yet fully cognizant, as was the case when Erik
responded with his example that showed usage of the ancestors
capability.


My experience with hierarchies includes the following as a common use
case:

A manager conceptualizes a project, large as a whole
company or govt or small as a simple team leader scoped project, and
creates a hierarchical structure within which resources: people,
equipment, facilities, etc. are deployed. As such, for one example, the
manager creates a hierarchical org chart of the people in the project
and defines responsibilities etc wrt to that org chart. When the
project commences, individuals are assigned their places within the
hierarchy and they have the hierarchical identifier added to their
identity properties. Such is the case with the /a*/b*/c* that I used in
my example. "r5" was the serial number on the PC that doesn't change,
however, the hierarchies that PC participates in will generally vary
over time, which is reflected by the identifiers from the various org
structures that it is assigned.


One additional realization that has occurred to me after last night's
email is that when resources are assigned URIs for the purpose of being
within a particular organization, that set of URIs satisfies the
requirements of the algorithms ("corrected" or not) in section 3.2.
This is because, as I pointed out, without being fully cognizant of the
implications at that point, the URI, itself, implicitly contains the
normative identity of "self", "parent", and all "ancestors" by nature
of its construction.


Therefore the augmentation of section 3.2 need be little more than to
emphasize this now obvious fact. More specifically, in the case of
multiple URIs as a result of belonging to multiple hierarchies, this
fully models the general DAG case as well. i.e. given a single
hierarchy (one root), it is obvious that a URI scheme can be used to
apply identifiers to the members of that hierarchy. Furthermore, given
a DAG, because the DAG can be transformed into a set of independent
hierarchies, a separate URI scheme can be applied to each hierarchy
there, and when transformed back into the DAG, the nodes that appear in
multiple hierarchies will simply have multiple URIs and the problem is
fully defined.


    Thanks,

    Rich



Daniel Engovatov wrote:
daniel@streamdynamics.com,EDC7CD31-7EFF-4D1B-B2BC-CED5F" type="cite">
  


However, I do not understand precisely what you are recommending:

I do not understand how {"PC", "DEPT", "FACILITIES"} relates to the
scenario I have described. I have specific PCs, in the example they
have serial numbers r5, r6. One of these PCs, r5, is identified in the
"dept" as /a1/b1/c1. In the facilities org the same pc is identified as
/a2/b2/c2.

  
No, PC is identified by "r5".   The fact that a PC is governed by a
policy of the "dept" does not change that fact.   The only purpose of
hierarchy is to determine an applicable set of rules for a particular
evaluation.   That is it.  Constructing a hierarchical identifier is
beyond the scope of that task.


So in my example access to a  "PC" is governed by rules applied to both
"DEPT" and "FACILITIES".   Very simple.



  

    

      
It is also uniquely defined by a URI if a
URI scheme has been applied to the same resources, since all the ance
  
    
URIs do not represent bags of strings. Possibly one might choose to
represent a URI as a bag of strings, however, one loses the ordering in
the process. If one wants to identify the specific set of nodes
represented by a URI, it is a simple matter to sequentially strip one
component at a time off the URI, and at each step one has the normative
identity of the next node up the chain until one reaches the root.


  


For the purposes of defining a hierarchical policy in this model all
you need is a bag of strings.   Using URI for that is not needed.   Use
cases that can be represented that way are a subset of use cases that
can be represented wit "ancestors" approach.  Ordering is not important
in this model, just like for the rest of our rules.



  
At this point I fail to understand the
purpose of specifically not using a hierarchical naming scheme in order
to identify a set of resources that will be managed as a hierarchy. I
understand that there may be cases where for some reason it may not be
possible or practical to use such a naming scheme, but in those cases
where it is possible and practical, I do not understand why it would
not be a good idea to use it.


  


The purpose is that a hierarchical naming scheme is not generic
enough.   For those cases when it is possible, it is still easier to
use, as it does not require one to introduce a superfluous naming
scheme and preserves the ability to change the structure of the
inheritance graph if needed.



Daniel;

> Hi Daniel,
>
> If you would care to elaborate on the use case of 'access to a   
> "PC" is governed by rules applied to both "DEPT" and "FACILITIES"  
> ', I would be interested, however, with the info you have given, I  
> simply do not see a hierarchy represented there. I am truly  
> interested, because when I do not understand something, I generally  
> assume that there is information of which I am not yet fully  
> cognizant, as was the case when Erik responded with his example  
> that showed usage of the ancestors capability.
>


This is the most basic example that is the whole idea of the  
profile.    What we are trying to achieve is to define a mechanism to  
write a rule that applies to a resource and all resources that are  
connected to it through "inheritance".

"PC" is a resource representing a PC.  "DEPT" is a resource  
representing a department.  "FACILITIES" is a resource representing  
facilities.    When I define an attribute of the "PC" resource that  
lists {"PC", "DEPT", "FACILITIES"} I implicitly define a hierarchy  
that make rule written on "DEPT" and "FACILITIES" to apply.   It does  
not matter what is the exact structure of that graph: "PC" may have  
two "parents", or "DEPT" may be part of "FACILITIES".   The only  
thing of concern is how to collect a bag of applicable rules.

The whole point here is that you do not want to and do not need to  
concoct any hierarchical naming scheme or to restrict it to any  
particular structure.

> My experience with hierarchies includes the following as a common  
> use case:
> A manager conceptualizes a project, large as a whole company or  
> govt or small as a simple team leader scoped project, and creates a  
> hierarchical structure within which resources: people, equipment,  
> facilities, etc. are deployed. As such, for one example, the  
> manager creates a hierarchical org chart of the people in the  
> project and defines responsibilities etc wrt to that org chart.  
> When the project commences, individuals are assigned their places  
> within the hierarchy and they have the hierarchical identifier  
> added to their identity properties. Such is the case with the /a*/ 
> b*/c* that I used in my example. "r5" was the serial number on the  
> PC that doesn't change, however, the hierarchies that PC  
> participates in will generally vary over time, which is reflected  
> by the identifiers from the various org structures that it is  
> assigned.
> One additional realization that has occurred to me after last  
> night's email is that when resources are assigned URIs for the  
> purpose of being within a particular organization, that set of URIs  
> satisfies the requirements of the algorithms ("corrected" or not)  
> in section 3.2. This is because, as I pointed out, without being  
> fully cognizant of the implications at that point, the URI, itself,  
> implicitly contains the normative identity of "self", "parent", and  
> all "ancestors" by nature of its construction.
>


Yes, but such a scheme is a subset of the profile, and there is no  
need to add it.   It will only confuse the users.      We do not want  
to imply that there is any tree behind it, so even using the "/"  
notation to represent a hierarchy is confusing.

We are not in the business of defining enterprise resource  
ontologies.   We are just providing a generic mechanism to map them  
into access control policy inheritance.

Current "ancestors" profile is definitely not the only possible  
approach.   We may want to add a different profile, but I do not  
think we should overload the current one with unrelated concepts.

Daniel

  


Hi Daniel,


I will try to continue the example below to see where it leads. I am
only taking it to the point of setting up the names of the resources,
starting with the serial numbers as a given, then suggesting one
possible manner that the 2 organizations might use to apply their own
labelling to these resources. What I am trying to do is determine the
point at which we begin to diverge on how we are envisioning this
general problem.


What I am also trying to do is come up with a "story" that I can tell
people, who I am advising on the use of xacml, how they might step by
step go about using xacml to represent policies to govern their
resources that they have chosen to organize in a hierarchical manner
(as explained in prev email, incl below, re: manager's
conceptualization of projects).



Daniel Engovatov wrote:
daniel@streamdynamics.com,B029CC63-A2F8-4A86-BFF2-BA62D" type="cite">


  
Hi Daniel,


If you would care to elaborate on the use case of 'access to a  "PC" is
governed by rules applied to both "DEPT" and "FACILITIES" ', I would be
interested, however, with the info you have given, I simply do not see
a hierarchy represented there. I am truly interested, because when I do
not understand something, I generally assume that there is information
of which I am not yet fully cognizant, as was the case when Erik
responded with his example that showed usage of the ancestors
capability.


  



This is the most basic example that is the whole idea of the
profile.    What we are trying to achieve is to define a mechanism to
write a rule that applies to a resource and all resources that are
connected to it through "inheritance".


"PC" is a resource representing a PC.  "DEPT" is a resource
representing a department.  "FACILITIES" is a resource representing
facilities.    When I define an attribute of the "PC" resource that
lists {"PC", "DEPT", "FACILITIES"} I implicitly define a hierarchy that
make rule written on "DEPT" and "FACILITIES" to apply.   It does not
matter what is the exact structure of that graph: "PC" may have two
"parents", or "DEPT" may be part of "FACILITIES".   The only thing of
concern is how to collect a bag of applicable rules.


In the use case I am considering, for the sake of concreteness, I am
assuming that each PC has a record in a table that in order to support
its management has at least the following 3 fields:


  
PC serial numberL: r*

  
  
DEPT id:  /a1/*
  
FACILITIES-id: /a2/*

Therefore, in the example of this use case from earlier email, my
"database" would contain the following records:


PC    DEPT-id     FACILITIES-id

r1    /a1

r2                /a2

r4    /a1/b1      /a2/b2

r5    /a1/b1/c1   /a2/b2/c2


Basically, the DEPT manager has decided to name the resources that
are under dept control, r1,r4,r5 using the /a*/b*/c* scheme where the
value "1" is used to indicate DEPT names. (Actually, I think all that
is necessary is for the root to have a unique name, but let's ignore
that for now)


Similarly, the FACILITIES mgr is using the names with the "2" suffix
for the resources under facilities control, r2,r4,r5.


My questions for you now are:


  
do you agree that it "could" be set up this way? (while
recognizing there are other ways as well)
  
is the issue that we are discussing simply that the naming I have
chosen for the DEPT-id and FACILITIES-id is simply an "unnecessarily
complex" naming scheme, and that I could have chosen something simpler?
  
if the above is the case, then what are the simpler schemes for
these ids that would represent a "better" approach?

    Thanks,

    Rich




daniel@streamdynamics.com,B029CC63-A2F8-4A86-BFF2-BA62D" type="cite">

The whole point here is that you do not want to and do not need to
concoct any hierarchical naming scheme or to restrict it to any
particular structure.


  
My experience with hierarchies includes the
following as a common use case:

A manager conceptualizes a project, large as a whole company or govt or
small as a simple team leader scoped project, and creates a
hierarchical structure within which resources: people, equipment,
facilities, etc. are deployed. As such, for one example, the manager
creates a hierarchical org chart of the people in the project and
defines responsibilities etc wrt to that org chart. When the project
commences, individuals are assigned their places within the hierarchy
and they have the hierarchical identifier added to their identity
properties. Such is the case with the /a*/b*/c* that I used in my
example. "r5" was the serial number on the PC that doesn't change,
however, the hierarchies that PC participates in will generally vary
over time, which is reflected by the identifiers from the various org
structures that it is assigned.

One additional realization that has occurred to me after last night's
email is that when resources are assigned URIs for the purpose of being
within a particular organization, that set of URIs satisfies the
requirements of the algorithms ("corrected" or not) in section 3.2.
This is because, as I pointed out, without being fully cognizant of the
implications at that point, the URI, itself, implicitly contains the
normative identity of "self", "parent", and all "ancestors" by nature
of its construction.


  



Yes, but such a scheme is a subset of the profile, and there is no need
to add it.   It will only confuse the users.      We do not want to
imply that there is any tree behind it, so even using the "/" notation
to represent a hierarchy is confusing.


We are not in the business of defining enterprise resource
ontologies.   We are just providing a generic mechanism to map them
into access control policy inheritance.


Current "ancestors" profile is definitely not the only possible
approach.   We may want to add a different profile, but I do not think
we should overload the current one with unrelated concepts.


Daniel

> In the use case I am considering, for the sake of concreteness, I  
> am assuming that each PC has a record in a table that in order to  
> support its management has at least the following 3 fields:
> PC serial numberL: r*
> DEPT id:  /a1/*
> FACILITIES-id: /a2/*
> Therefore, in the example of this use case from earlier email, my  
> "database" would contain the following records:
>
> PC    DEPT-id     FACILITIES-id
> r1    /a1
> r2                /a2
> r4    /a1/b1      /a2/b2
> r5    /a1/b1/c1   /a2/b2/c2
>

More often you would see a DB schema where each resource is linked to  
the "dept" or "facilities" it belongs to.



> Basically, the DEPT manager has decided to name the resources that  
> are under dept control, r1,r4,r5 using the /a*/b*/c* scheme where  
> the value "1" is used to indicate DEPT names. (Actually, I think  
> all that is necessary is for the root to have a unique name, but  
> let's ignore that for now)
>
> Similarly, the FACILITIES mgr is using the names with the "2"  
> suffix for the resources under facilities control, r2,r4,r5.
>
> My questions for you now are:
> do you agree that it "could" be set up this way? (while recognizing  
> there are other ways as well)
Possibly, but personally I would advise anybody against using such  
naming schemes as it would make it next to impossible to perform any  
reorganization.

> is the issue that we are discussing simply that the naming I have  
> chosen for the DEPT-id and FACILITIES-id is simply an  
> "unnecessarily complex" naming scheme, and that I could have chosen  
> something simpler?

Yes, they are not generic enough and unnecessarily complex.   I do  
not think that we should add anything like that to the standard.     
Existing "ancestors" profile uses opaque identifiers and does not  
introduce any ordering.
> if the above is the case, then what are the simpler schemes for  
> these ids that would represent a "better" approach?
This use case can be trivially mapped into the existing "ancestors"  
approach.   It is simpler, and it is not broken in any way.

Most often, link to "facilities" and "dept" will be stored in the  
"pc" record.   When performing authorization all that is needed is to  
define a shceme that populates "ancestors" attribute in the context.   
It will look like
{"r5", "dept-id", "facilities-id"}.  That is enough to apply policy.   
Nothing else is needed.

There are many way to create hierarchical structures.   If we are to  
publish anything, I think it should be the most generic one that does  
not introduce any additional concepts to the XACML (like naming  
schemes and such).

I strongly advise against inclusion of any naming schemes into the  
"ancestors" hierarchical profile.   WHile the language of that write- 
up can use some improvement, the fundamental approach is sound and  
non-ambiguous.  If TC feels that such an expansion is needed, a  
separate profile should be made for that. I will try to get on the  
call tomorrow to answer any questions.

Daniel;

All,

Personally I have never found the profile difficult to understand and 
the intent of it has been clear to me. I can agree that it's not 
described in a stringent manner, but I don't think it's too bad either. 
I also worry that if we make it too "correct", it will become hard to 
understand because it could get very verbose.

In any case, I would not like to wait for a rewrite of this profile 
before we proceed to CD with the core & friends. I haven't checked my 
notes, the issues list, mailing archives, etc, but I think as we stand 
now, we are pretty much ready with the core, delegation and the old 
profiles. I don't think the deficiencies in the hierarchical profile are 
important enough to hold back the rest right now.

So, I would propose that we either "ship" the current hierarchical 
profile together with the core, hopefully soon, or drop it all together 
from the package.

Best regards,
Erik


Rich.Levinson wrote:
> Hi All,
>
> I am choosing this point (in the email threads) to continue discussion 
> of the issues with the Hierarchical profile as I think it contains the 
> best context to start from.
>
> As indicated in the last couple of TC meetings, the update I proposed:
> http://lists.oasis-open.org/archives/xacml/200901/msg00079.html
>
> only goes part-way to addressing the problems I have found in the 
> Hierarchical profile specification. The update only includes 
> effectively a glossary with definitions of the terms that are 
> currently used in the spec that make the rest of the spec 
> comprehensible (at least from my perspective), and based on that 
> glossary, the spec includes a few clarifying edits, which are 
> primarily intended to make the statements in the spec consistent in 
> terms of the definitions in the glossary.
>
> Primarily, the glossary simply defines "hierarchy" and "DAG" (Directed 
> Acyclic Graph), where DAG is a collection of hierarchies that are 
> mapped onto a flat collection of resources, where any resource can be 
> a member of multiple hierarchies within the DAG.
>
> Based on this starting point and Erik's suggestion as to how the 
> concepts might be applied in the real world, I did further 
> investigation and have come to some additional preliminary conclusions 
> on which I think the next step to address this spec should be based.
>
>    1. The most significant conclusion I have reached is that the
>       primary "problem" with the non-xml resources (section 3.2) is
>       that the details here are solving a much more complicated
>       problem than is necessary for most common use cases, which is
>       that the resources are identified with URIs as described in
>       section 2.2 and 4.3.
>
>       In particular, this "more complicated problem" is one where the
>       resource-id, itself, is not sufficient to describe the hierarchy
>       of which it is a member. An example might be resources
>       identified by serial number (a flat namespace), as opposed to
>       resources identified by URI, which is an inherently hierarchical
>       namespace (http://www.ietf.org/rfc/rfc2396.txt).
>
>       With a hierarchical namespace there is no need to collect parent
>       and ancestor nodes since they are already built in to the URI
>       itself. In fact, there is an example document that I "found",
>       that was produced as an artifact of the XACML 2.0 development
>       effort, that appears to have gotten lost from the active XACML
>       collection:
>       http://www.oasis-open.org/committees/download.php/7315/xacml-profile-hierarchical-resources-nonXML-1.0-draft01.pdf
>
>       that demonstrates this quite clearly: section 4.2 shows policies
>       based on resource-ancestor and resource-parent attributes, and
>       section 4.3 shows the same policies based on matching anyURI.
>       i.e. if the resources are identified by URI there is no need to
>       use resource-parent and resource-ancestor attributes either in
>       the RequestContext or in the Policies.
>
>       Based on this situation, my proposal is to enhance the existing
>       Hierarchical spec using the URI representation in section 3.2
>       and indicating that this approach can be used instead of
>       resource-parent and ancestor when the hierarchies are
>       represented by nodes with URI resource-ids.
>
>    2. A 2nd significant problem I believe I have found is that the
>       algorithms defined in section 3.2 are incorrect in some
>       significant ways, which I believe should be addressed (I will
>       give an example below).
>
>       My proposal here is to simply fix the algorithms.
>
>    3. A 3rd significant problem I believe I have found is that there
>       are important concepts that are either left out or not given
>       sufficient emphasis in the spec, which, imo, cause conceptual
>       ambiguities that make it effectively impossible to say what
>       problem the specification is actually addressing.
>
>       In particular, there is no explicit definition of "normative
>       identity", which is a key term used in the algorithms defined in
>       section 3.2.
>       My proposal here is to assert that the normative identity may
>       use either the recommended representation of URI described in
>       section 2.2, or a functionally equivalent representation, such
>       as can be constructed using resource-parent and
>       resource-ancestor node collections.
>
>       In particular, there is insufficient development of the concept
>       of "consistent representations for identities" as mentioned in
>       section 1, lines 68-72, section 2, lines 175-178, section 3,
>       lines 227-229. While the point is made that such consistent
>       representations are necessary, the essential fact that in a DAG
>       that a single node can have multiple normative identities AND
>       that those identities each belong to a separate distinct
>       hierarchy within the DAG is not established. The result is that
>       it is conceptually ambiguous that when a node is said to have
>       multiple parents, the essential fact is that the node must then
>       have multiple normative identities, each of which is traceable
>       to one and only one parent (or self, if the current node happens
>       to be the top of one of the hierarchies within the DAG).
>       My proposal here is to adjust the text to emphasize these
>       notions accordingly.
>
> One final note: I appreciate the significant effort that went into the 
> development of the Hierarchical specification. A review of the emails 
> from April 2004 -> September 2004 will show anyone interested that a 
> lot of work went into the development of this specification. My own 
> interpretation of the problems I have had with this spec is that it 
> was a relatively small, but considered to be important, part of XACML 
> 2.0 and that while the ideas collected in this spec are generally 
> properly targeted, it appears there was simply not sufficient time 
> available for the TC to consolidate the findings of their studies of 
> the hierarchy problem and to structurally sort the results into 
> separable pieces that would have made the results easier to understand 
> and apply.
>
> This effort is intended to build on the existing spec and emphasize 
> aspects of it that currently are not, and to correct any problems that 
> may be found in the process.
>
> As indicated above, I will give an example of what I consider to be an 
> "error" in the algorithms of section 3.2:
>
>     In section 3.2 the descriptions appear to be lterally
>     "over-specified": for example, consider lines 324-327:
>
>         " For each immediate parent of the node specified in the
>         “resource-id” attribute or attributes, and for each normative
>         representation of that parent node, an 

Hi Erik,

Based on my email moments ago in reply to Daniel, I now see the task of 
advancing the hierarchical profile as quite straight-forward, which is 
to take my modified V4 and enhance accordingly w descriptive text 
explaining how URIs are a possible implementation of the general 
problem, which actually fits pretty cleanly with the URI discussion in 
sections 2, 2.2, and 4.3 policy.

I will also attempt to clean up the algorithms to remove the ambiguity 
of possibly including irrelevant hierarchical references (i.e. if a 
parent of the current node belongs to a hierarchy that the current node 
does not belong to, then there is no point including those hierarchical 
references in the algorithm). I can ignore the "over-specification" 
aspect by simply saying duplicates are reduced to a single copy, so as 
not to get involved optimizing the algorithm.

My intent is to keep the hier profile on track, however, it is important 
that it be generally recognized as of value to solving common 
hierarchical conceptual problems, which I believe my enhancements 
facilitate. Note: that I have proposed zero changes in functionality of 
the profile, but simply been trying to bring its current content to a 
more usable state.

    Thanks,
    Rich


Erik Rissanen wrote:
> All,
>
> Personally I have never found the profile difficult to understand and 
> the intent of it has been clear to me. I can agree that it's not 
> described in a stringent manner, but I don't think it's too bad 
> either. I also worry that if we make it too "correct", it will become 
> hard to understand because it could get very verbose.
>
> In any case, I would not like to wait for a rewrite of this profile 
> before we proceed to CD with the core & friends. I haven't checked my 
> notes, the issues list, mailing archives, etc, but I think as we stand 
> now, we are pretty much ready with the core, delegation and the old 
> profiles. I don't think the deficiencies in the hierarchical profile 
> are important enough to hold back the rest right now.
>
> So, I would propose that we either "ship" the current hierarchical 
> profile together with the core, hopefully soon, or drop it all 
> together from the package.
>
> Best regards,
> Erik
>
>
> Rich.Levinson wrote:
>> Hi All,
>>
>> I am choosing this point (in the email threads) to continue 
>> discussion of the issues with the Hierarchical profile as I think it 
>> contains the best context to start from.
>>
>> As indicated in the last couple of TC meetings, the update I proposed:
>> http://lists.oasis-open.org/archives/xacml/200901/msg00079.html
>>
>> only goes part-way to addressing the problems I have found in the 
>> Hierarchical profile specification. The update only includes 
>> effectively a glossary with definitions of the terms that are 
>> currently used in the spec that make the rest of the spec 
>> comprehensible (at least from my perspective), and based on that 
>> glossary, the spec includes a few clarifying edits, which are 
>> primarily intended to make the statements in the spec consistent in 
>> terms of the definitions in the glossary.
>>
>> Primarily, the glossary simply defines "hierarchy" and "DAG" 
>> (Directed Acyclic Graph), where DAG is a collection of hierarchies 
>> that are mapped onto a flat collection of resources, where any 
>> resource can be a member of multiple hierarchies within the DAG.
>>
>> Based on this starting point and Erik's suggestion as to how the 
>> concepts might be applied in the real world, I did further 
>> investigation and have come to some additional preliminary 
>> conclusions on which I think the next step to address this spec 
>> should be based.
>>
>>    1. The most significant conclusion I have reached is that the
>>       primary "problem" with the non-xml resources (section 3.2) is
>>       that the details here are solving a much more complicated
>>       problem than is necessary for most common use cases, which is
>>       that the resources are identified with URIs as described in
>>       section 2.2 and 4.3.
>>
>>       In particular, this "more complicated problem" is one where the
>>       resource-id, itself, is not sufficient to describe the hierarchy
>>       of which it is a member. An example might be resources
>>       identified by serial number (a flat namespace), as opposed to
>>       resources identified by URI, which is an inherently hierarchical
>>       namespace (http://www.ietf.org/rfc/rfc2396.txt).
>>
>>       With a hierarchical namespace there is no need to collect parent
>>       and ancestor nodes since they are already built in to the URI
>>       itself. In fact, there is an example document that I "found",
>>       that was produced as an artifact of the XACML 2.0 development
>>       effort, that appears to have gotten lost from the active XACML
>>       collection:
>>       
>> http://www.oasis-open.org/committees/download.php/7315/xacml-profile-hierarchical-resources-nonXML-1.0-draft01.pdf 
>>
>>
>>       that demonstrates this quite clearly: section 4.2 shows policies
>>       based on resource-ancestor and resource-parent attributes, and
>>       section 4.3 shows the same policies based on matching anyURI.
>>       i.e. if the resources are identified by URI there is no need to
>>       use resource-parent and resource-ancestor attributes either in
>>       the RequestContext or in the Policies.
>>
>>       Based on this situation, my proposal is to enhance the existing
>>       Hierarchical spec using the URI representation in section 3.2
>>       and indicating that this approach can be used instead of
>>       resource-parent and ancestor when the hierarchies are
>>       represented by nodes with URI resource-ids.
>>
>>    2. A 2nd significant problem I believe I have found is that the
>>       algorithms defined in section 3.2 are incorrect in some
>>       significant ways, which I believe should be addressed (I will
>>       give an example below).
>>
>>       My proposal here is to simply fix the algorithms.
>>
>>    3. A 3rd significant problem I believe I have found is that there
>>       are important concepts that are either left out or not given
>>       sufficient emphasis in the spec, which, imo, cause conceptual
>>       ambiguities that make it effectively impossible to say what
>>       problem the specification is actually addressing.
>>
>>       In particular, there is no explicit definition of "normative
>>       identity", which is a key term used in the algorithms defined in
>>       section 3.2.
>>       My proposal here is to assert that the normative identity may
>>       use either the recommended representation of URI described in
>>       section 2.2, or a functionally equivalent representation, such
>>       as can be constructed using resource-parent and
>>       resource-ancestor node collections.
>>
>>       In particular, there is insufficient development of the concept
>>       of "consistent representations for identities" as mentioned in
>>       section 1, lines 68-72, section 2, lines 175-178, section 3,
>>       lines 227-229. While the point is made that such consistent
>>       representations are necessary, the essential fact that in a DAG
>>       that a single node can have multiple normative identities AND
>>       that those identities each belong to a separate distinct
>>       hierarchy within the DAG is not established. The result is that
>>       it is conceptually ambiguous that when a node is said to have
>>       multiple parents, the essential fact is that the node must then
>>       have multiple normative identities, each of which is traceable
>>       to one and only one parent (or self, if the current node happens
>>       to be the top of one of the hierarchies within the DAG).
>>       My proposal here is to adjust the text to emphasize these
>>       notions accordingly.
>>
>> One final note: I appreciate the significant effort that went into 
>> the development of the Hierarchical specification. A review of the 
>> emails from April 2004 -> September 2004 will show anyone interested 
>> that a lot of work went into the development of this specification. 
>> My own interpretation of the problems I have had with this spec is 
>> that it was a relatively small, but considered to be important, part 
>> of XACML 2.0 and that while the ideas collected in this spec are 
>> generally properly targeted, it appears there was simply not 
>> sufficient time available for the TC to consolidate the findings of 
>> their studies of the hierarchy problem and to structurally sort the 
>> results into separable pieces that would have made the results easier 
>> to understand and apply.
>>
>> This effort is intended to build on the existing spec and emphasize 
>> aspects of it that currently are not, and to correct any problems 
>> that may be found in the process.
>>
>> As indicated above, I will give an example of what I consider to be 
>> an "error" in the algorithms of section 3.2:
>>
>>     In section 3.2 the descriptions appear to be lterally
>>     "over-specified": for example, consider lines 324-327:
>>
>>         " For each immediate parent of the node specified in the
>>         “resource-id” attribute or attributes, and for each normative
>>         representation of that parent node, an 

On Jan 15, 2009, at 6:42 AM, Rich.Levinson wrote:

> Hi Daniel,
>
> This is an inherently self-contradictory definition. A hierarchy  
> has a single root. It is an "ordered set", where each entity in the  
> set has a defined relationship to every other entity. A "forest" is  
> not a hierarchy. It is multiple hierarchies. The "definition" above  
> is not meaningful because it equates the singular and plural.
>


That is indeed an ambiguous usage of the term "forest", which is a  
disconnected acyclic graph.

But I am not sure I understand your objection about the term "hierarhy".

Definition of a hierarhy is " a graded or ranked series".    So that  
implies that we introduce a partial order relation between resource  
nodes that implies inheritance of applicable policy statements. (if A  
=> B, then rule applicable to A applies to B).  This does not imply  
that we have to define this as a rooted tree.   For example, we have  
three resources A, B, C and A=>C and B=>C, so C inherits policy from  
A and B.

I think ambiguity may be corrected by removing reference to "forest"  
and changing "ordered set" to "partially ordered set" (as we do not  
require comparability for the inheritance relation).

> Finally, I do not understand your comment that says:
> Policy evaluation does not need to know anything about hierarchies  
> that are represented with an "ancestor" attribute.
> I am trying to understand what policies are supposed to do with the  
> definitions in the spec. i.e. it is the spec that says in section  
> 3.2 that all the parent and ancestor nodes need to be assembled in  
> the request context. What "policy evaluation" are you referring to?  
> Are you saying what I indicated in original email that a policy  
> does not need to know anything about hierarchies that the resource- 
> id node does not belong to?

What I was trying to say is that we do express hierarchical  
relationship as an attribute on each resource X with value being a  
unordered set of nodes {Ai} for which Ai=>X is true.    We suggest a  
way on how to write rule target so that it is applicable to a  
particular resource and its children.   That does not mean that all  
rules in a a policy need to be written that way and it does not  
require that evaluation strategy be aware about any "hierarhies".


Daniel

A question I have is how many folks are really using this hierarchical 
profile in practice.

Daniel Engovatov wrote:
>
> On Jan 14, 2009, at 10:54 PM, Rich.Levinson wrote:
>
>>    * There needs to be a definition of "hierarchy". In particular, a
>>      "hierarchy" defn should state that the fundamental properties are
>>      that there must be a single root node with no parent, and that
>>      every other node in the hierarchy must have one and only one
>>      parent, and can have zero, one, or more children.
>
> I am not sure why do you think this is a requirement.   It is a normal 
> use case to inherit policy from more then one parent, and "ancestors" 
> attribute approach allows such models without undue restrictions.
>
>>    in order to submit a request  one has to somehow identify all the 
>> hierarchies the given node
>>      belongs to, all the hierarchies the node's parent(s) and 
>> ancestors to, and include an Attribute element for each.
>
> And why is that a problem?   Yes, if one wants "inheritance", graph 
> needs to be defined, and attributes is a natural way to define it.
>
>>  I suspect that at most one would need to collect all the normative 
>> representations of only the resource-id node (i.e. identify all the 
>> hierarchies it belongs to), then for each hierarchy, one would 
>> evaluate the policies that apply to that hierarchy.
>>
>
> Policy evaluation does not need to know anything about hierarchies 
> that are represented with an "ancestor" attribute.
>
> Daniel;

In the call, Seth stated that few used it. 

I stated that in my experience, systems may initially be set up in such a way that the hierarchy is congruent with the security properties of the Resources, but over time this relationship is lost and hierarchy becomes much less useful than attributes that categorize Resources directly, such as "Public", "Company Confidential", etc.

I also stated that in my career I had seen a wide variety of schemes used to control access to hierarchical resources, some of which had extremely non-intuitive behavior.

Seth agreed with both of these points.

The question remains. Are people not using this profile because it is not a practical strategy after the demo/initial installation phase or because the profile needs more features to be able to emulate more complex hierarchical schemes? In any event, unless a champion for this appears, I expect we will simply try to clarify the existing functionality and leave it at that.

However, this means we need to try to educate the rest of the world, as many people expect to see some kind of hierarchical scheme as a part of an access control policy.

Hal

> 

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
> From: Anil Saldhana [mailto:Anil.Saldhana@redhat.com]
> Sent: Tuesday, January 20, 2009 9:05 PM
> To: xacml
> Subject: Re: [xacml] Issue: Hierarchical profile appears ambiguous and
> inconsistent
> 
> A question I have is how many folks are really using this hierarchical
> profile in practice.
> 
> Daniel Engovatov wrote:
> >
> > On Jan 14, 2009, at 10:54 PM, Rich.Levinson wrote:
> >
> >>    * There needs to be a definition of "hierarchy". In particular, a
> >>      "hierarchy" defn should state that the fundamental properties are
> >>      that there must be a single root node with no parent, and that
> >>      every other node in the hierarchy must have one and only one
> >>      parent, and can have zero, one, or more children.
> >
> > I am not sure why do you think this is a requirement.   It is a normal
> > use case to inherit policy from more then one parent, and "ancestors"
> > attribute approach allows such models without undue restrictions.
> >
> >>    in order to submit a request  one has to somehow identify all the
> >> hierarchies the given node
> >>      belongs to, all the hierarchies the node's parent(s) and
> >> ancestors to, and include an Attribute element for each.
> >
> > And why is that a problem?   Yes, if one wants "inheritance", graph
> > needs to be defined, and attributes is a natural way to define it.
> >
> >>  I suspect that at most one would need to collect all the normative
> >> representations of only the resource-id node (i.e. identify all the
> >> hierarchies it belongs to), then for each hierarchy, one would
> >> evaluate the policies that apply to that hierarchy.
> >>
> >
> > Policy evaluation does not need to know anything about hierarchies
> > that are represented with an "ancestor" attribute.
> >
> > 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
>