OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [xacml] New core and multiple resource profile and hierarchical

Hi Erik,

Thanks for the reply. I have only been able to go thru it once briefly and do not have time to respond in detail before the meeting, however, it appears to me that we are now converging toward a solution.

Specifically, your last comment:
If we do DAG for the ancestor scheme and tree for the URI scheme then we cover both cases.
which was in reply to my last comment:
...the path I have represented in the profile which is that you can choose either, as appropriate, for specific subset of the overall enterprise resources.
sounds to me like we are in the same ballpark.

I am assuming that when you say "tree for the URI scheme", that you include "multiple disjoint trees" (forest) for the case where a physical resource is identified by 2 or more URIs with different roots. If you agree on this point then I think the v5-02 is currently structured consistent with that approach and we can transition from there (note the v5-xx versioning scheme is based around personal drafts, a technique I ended up with after submitting docs w minor typos that I wanted to correct before doc came up for discussion since all versions kept in archives at oasis).

Note: will plan to reply in detail point by point, but, as indicated, I think even on a comment by comment basis we are beginning to converge.


Erik Rissanen wrote:
49AFC7C9.8080807@axiomatics.com" type="cite">Thanks Rich for the response,

See responses inline.

Rich.Levinson wrote:
Hi Erik,

Thanks for the input. I think there are still some fundamental misunderstandings of what exactly the issue is that I have been raising here (maybe not, maybe I am misunderstanding something in which case, I will be happy to close the issue, but not there yet). I will address your comments below after prelim comment:

First, for people who have been observing this seemingly endless sequence of extremely detailed emails, please rest assured that I believe there is a significant issue that needs to be addressed. Here are a couple introductory points to consider:

    * As a result of the natural complexity of the problem of
      identifying the applicable policies to apply to a requested
      resource that can be known to policies under more than one
      "normative hierarchical name" (where the "hierarchical" name
      either contains the hierarchical info internally, as in the case
      of URI, or whether the name is an unstructured unique string
      that uniquely identifies the resource in some external resource
      collection, whereby the contexthandler before submitting the
      request is able to identify and collect all the relevant names
      of "hierarchical" ancestor nodes to the requested resource
      node), these emails have had to contain enough detail to address
      some specific somewhat subtle characteristics of the process for
      collecting the list of ancestor nodes.
    * To further help frame the issue, it should be commonly
      understood that when a PEP submits a request, it is first
      handled by a context handler, which is defined in XACML to
      handle input requests as follows:
          o "converts decision requests in the native request format
            to the XACML canonical form"
    * Therefore the context handler needs to know, given a requested
      resource, how to assemble the list of ancestors for that
      resource to submit with the request as part of its
      responsibility of converting the request to "XACML canonical form".
    * The current document, before the modifications I made, had
      effectively defined two methods of ancestor collection:
          o an explicit method: defined by the algorithms in section 3.2
          o an implicit method: implied by the definition in section
            2.2 of how to form a URI that could be used with the
            hierarchical profile, and by the anyURI methods described
            in section 4.3 intended to be used by policies that apply
            to resources identified using the guidelines of section 2.2

I see the value of the URI scheme, and I think we should add it to the profile as a separate section. For those cases where it works, it is simpler than the full DAG scheme.

    * As it turns out, as can be understood in detail by reviewing the
      chain(s) of emails on this subject in Jan-Feb-Mar 2009,
          o the explicit methods in section 3.2 imply that the
            resources are collected in a manner that assumes that
            policies will be written with the "mindset" of protecting
            a hierarchical resource structured as a DAG.
          o the implicit methods of sections 2.2/4.3 effectively imply
            that the resources are collected in a manner that assumes
            that policies will be written with the "mindset" of
            protecting a hierarchical resource structured as a forest.
            (For example, if a node has 2 normative URIs, then it is a
            member of 2 trees in the forest - policies written using
            anyURI will be applicable if their scope includes either
            of the 2 normative URIs

Are you referring to the original profile, or the latest draft? I think we should forget about the original profile for now. It is clearly not consistent, so let's focus on what we want the new profile to be. :-)

When we talk about what we want the profile to be like, I think it should support three schemes: the "ancestor scheme", the "XML doc scheme" and the new "URI scheme" which you have proposed.

    * This is roughly the point I was at when I started raising this
      issue. The first thing I noticed was that there were effectively
      2 different ancestor collection methods at work, which had the
      following curious properties:
          o the methods in section 3.2 involve collecting ancestors of
            the resource that are not "direct" ancestors, in the sense
            that if the resource's parent has a parent that is not
            directly connected then policies associated with that
            ancestor apply to the requested resource
                + To use the common "sibling" terminology, a "direct"
                  ancestor would be a bloodline ancestor, such as a
                  grandparent. In "indirect" ancestor would be
                  equivalent to a "step-grandparent", i.e. one not
                  connected by bloodline, but that established a
                  relation with the bloodline parent "after the fact"
                  and now has an "indirect" relation with the
          o So the question which "lights all the fires" on this issue
            is whether a "step-grandparent" should have an equal
            relation with the requested resource as a bloodline
          o It turns out that with the DAG model there is no way for
            the context handler to differentiate between
            "grandparents" and "step-grandparents", so the answer is
            ALWAYS that these are treated equally.
          o By comparison, it turns out that "by default" (i.e. the
            contexthandler just collects the set of URIs from the
            resource with no need to search for ancestors because all
            the needed URIs are right there) using URIs that only
            grandparents will be selected. "step-grandparents" could
            be obtained if desired, but simple out of the box URIs
            give you only the bloodline ancestors.

I don't think the profile should support telling apart the "bloodline" and "step-grandparents". They should all count as ancestors. Telling them apart is probably not worth the effort and extra complexity which would be introduced.

    * The reason I am concerned about this issue is that from a
      security perspective, it makes little sense to me to force
      commonly understood hierarchies, such as organization charts,
      geographic breakdowns of organization operations, whether within
      a building or around the world, to suddenly have policies that
      are intended only to apply to the resources within these
      specified domains, suddenly apply to resources outside of these

I don't understand this. Could you try go give an example?

    * Similarly, resources within these domains will find themselves
      subject to policies applied to resources outside of these domains.
          o For example, if I am a manager in the United States, and
            there is a policy that says employees in the United States
            may treat the 4th of July as a holiday, then anyone
            outside the United States who has any superior inside the
            United States will be subject to this policy.
          o Why? Because the resources are treated as a DAG. DAGs do
            not deal with resources individually, they only deal with

I don't see why this would happen. If you write a policy which says that "every one belonging to the organization of manager Rich may have a holiday on the 4th of July", then naturally that would apply to even those outside the US if they belong to the organization of Rich. If that's not what you intended, don't write such a policy. :-) Instead you should write a policy which says that everyone who has an attribute "location=US" may have a holiday on the 4th of July. Not use a hierarchy which does not correspond to the effect you intend.

With that background, let me address Erik's points:

Erik Rissanen wrote:
Rich and TC,

I have reviewed the draft you have posted (wd 05-02) as well as the recent discussion on the list, and I think the draft needs some more work.

I agree with you that the old profile had lots of ambiguities and small errors in it, and I think you have done a good job at spotting them and you have improved the text in many places.

However, I also think that the new work you have added in there complicates matters needlessly. There are two reasons for that:

1. You try to write the profile so it works with multiple intersecting hieararchies. I think that is the wrong way to do it. It should be specified for a single hierarchy only. If you need to apply it on multiple hierarchies, the way to do it is to preprocess the hierarchies by merging them into a single hierarchy. This joint hierarchy also needs to meet some consistency criteria, or the whole thing becomes meaningless and inconsistent. See more about that below.
This is an invalid assertion. I leave the profile unchanged, except for distinguishing the DAG and forest/polyarchy distinctions.

I don't see that there is a distinction which is relevant to the profile. I think the "ancestor scheme" should be defined for a DAG. Forests and others which are special cases of a DAG would be supported as special cases. I don't think the profile should support any form of hierarchy which is not a DAG because that would expand the scope to more complex models which we (or at least I ;-)) don't know how to handle.

The DAG is inherently is multiple "overlapping" hierarchies that can be combined into a "single multiroot hierarchy" (see ref prev email) http://en.wikipedia.org/wiki/Directed_acyclic_graph#Properties
The forest is inherently multiple "intersecting" hierarchies, that can be combined into a "single multiroot disjoint hierarchy" identical in every way to the DAG except that:

   1. it retains the identity of the multiple hierarchies as its
      disjoint property
   2. it is not restricted from having "cycles" as long as the circuit
      travels over at least segments from 2 disjoint hierarchies

I don't understand the above. A DAG by definition has no cycles.

And a DAG is not inherently multiple hierarchies. It may be the case that multiple hierarchies of certain limited form may in general be mapped into a single DAG, but I don't think it is primarily relevant to the profile. I think we should keep the profile algorithms constrained to a single DAG. We can add explanatory text about how some special case hierarchies can be mapped to a DAG. But we should not try to define algorithms for multiple hierarchies because the algorithms become more complex to define, and in come cases the combination of multiple hierarchies won't lead to a consistent DAG.

For instance, consider the following:

Resource A has normative "names" http://example.com/res/A and "res_1234".

Resource B has normative "names" http://example.com/res/A/B and "foo_56".

There exist two hierarchies. In the first hierarchy http://example.com/res/A is the parent of http://example.com/res/A/B.

In the second hierarchy "foo_56" is the parent of "res_1234".

These two hierarchies cannot be combined into a DAG, since the two hierarchies contradict each other. And we should not attempt to handle these cases in the profile. Instead the profile should require that there is a single consistent DAG which forms the hierarchy.

As should be clear from above description, and all previous emails on this subject, the preprocessing is done by creating a joint hierarchy. The only difference between the DAG and the forest is that with the DAG, potentially useful information about the joint hierarchy is thrown away, with the forest it is kept. All is done before contexthandler submits request based on what contexthandler is capable of doing with the resource collection of which the requested resource is a member.

Yes, I agree that the mapping to ancestor attributes throws away information. But I think that is a correct limitation for what we define as the scope of the profile. With the profile we intend only to support those policies which are possible to express with the limited set of information about the hierarchy. For instance, we can express that a policy should apply to all descendants to a given resource. However, we cannot express, for instance, that it should apply only three steps down the hierarchy, but not deeper.

Unfortunately, this statement appears to characterize the conceptual gap on this issue:

    "This joint hierarchy also needs to meet some consistency
    criteria, or the whole thing becomes meaningless and inconsistent."

All one needs to do is peruse the emails to quickly realize that it is the profile that mixes the DAG/forest concepts, which renders the existing spec "meaningless and inconsistent" and that my effort has been to separate these concepts in order to establish meaning and consistency to the contents of the spec.

Yes, I agree that the old profile mixes concepts such as DAGs and forests incorrectly. We need to fix that.

2. You use the "root" concept. That is actually not required at all. As you have realized, the concept of a root in a DAG becomes messy to define and handle. I think we should just drop any reference to a "root" in the whole profile. All we need are "ancestors", and those are found by following the edges upwards. Not down from the root, so the root doesn't have to be defined. (In fact, in a DAG, there is not necessarily a unique root anyway.)
DAG is a directed graph. If you keep following any parent relationship recursively from the requested node you will come to one of the roots of the DAG. If you chose different parents along the way you will come to a different root, in general. In a DAG, it doesn't matter from the perspective of the requested node, all roots are functionally equivalent in the sense that there is no inherent distinction as to the status of one root vs another.

Yes, it is possible to define roots. But what I say is that they are not relevant. We don't need the root in the profile. We only need to define ancestors to be able to express the kind of policies the profile is intended: policies which apply to sections of the hierarchy consisting of descendants of a given node.

In the forest model, you can have exactly the same layout as any DAG. And you can traverse the same recursive paths to any of the same roots. The only difference along the way is at each step you know whether you are proceeding along the same hierarchy as in your previous step or whether you are switching to another hierarchy.

In the world of security, these hierarchical paths are commonly known as "lines of authority". Generally, in security applications the notion of "clear lines of authority" is desirable, and the notion of "tangled lines of authority" is detrimental. This is precisely the distinction of forest (clear lines) and DAG (tangled lines).

Finally, I think we should write the normative sections so they target a DAG only. Trees and forests follow as special cases. We can add explanatory text to make this clear, but the normative parts become much simpler if we don't define many different types of hierarchies.
Obviously, from my above remarks, if we were to target "only" one of DAG or forest, I would choose forest because

    * forest  represents "clear lines of authority" for security
    * URI as recommended in section 2.2 already provides it out of the box

and I would not choose DAG, because

    * DAG represents uncontrolled ambiguous lines of authority
    * DAG is intended for sub-tree, or whole "sub-assembly at a time"
      type of operations, which is why it is popular in source code
      control systems. If we think global enterprises can be modeled
      as special case of source code control system then DAG will be
      great, otherwise, a forest is needed.

I would choose to target a DAG since it is more general than a forest.

Bottom line: I think when the dust and smoke is removed from this issue, we are left with what kind of model do we want for resources: a highly structured model as in forest, or a more loosely structured, "social network" type of model such as DAG.

Or we could follow the path I have represented in the profile which is that you can choose either, as appropriate, for specific subset of the overall enterprise resources.

If we do DAG for the ancestor scheme and tree for the URI scheme then we cover both cases.

Best regards,


I propose the following changes:

- First, a small nitpick. ;-) I don't like "Working draft 05-02". I think working drafts should progress 5, 6, 7, 8 and so on. It's confusing that there are several documents, all called working draft 5.

- Remove all the new definitions of "polyarchy", etc. They are not needed. Use only the term "DAG".

- Define a hierarchy as a DAG, where the nodes correspond to resources and the edges correspond to child-parent relationships.

- Define that each node in the hierarchy has one or more "normative representations" (names). A normative representations is defined as an XACML datatype value instance, which is provided in the request (through the context handler or the PEP). A representation which is not provided in the request is not normative, and may not be referenced in policies.

- This is actually already implied, but maybe worth stating: if one merges a number of hierarchies in the pre-processing step, the merged hiearchy must be consistent with respect to node representation/naming and the parent-child relationship. That is, if A and B are two representations of a node and C and D are representations of another node, and there is a relationship between the nodes, the same relationship applies to all representations/names. So all of the following would apply, not just some of them: A-C, A-D, B-C and B-D. I think the complexities in what you have done Rich is much due to that you have tried to cover hierarchies where this is not true. But those hierarchies are not internally consistent, so we cannot make them work.

- The ancestors of a node are defined as simply the transitive closure of the parent-child relationship.

Note that the above points imply that there is a single hierarchy which is a DAG. Also note that I don't make use of the term "root". It's not needed.

- Add in a couple of examples with illustrations showing a simple tree formed DAG and a more complex DAG which is not a tree and show how the ancestors are found.

- Remove section 1.1.1. It's not needed if we specify the algorithms on a sigle DAG only.

- Make a separate section about the URI-only scheme, saying that "in some cases when the resources are represented as URIs, it may be possible to simply do matching on portions of the resource representations". Also make it clear that the PEP and PDP must agree on which scheme is used, or the policies won't work.

- I think that a node may be represented by any XACML data type, like a string for instance, not just URIs. This is what the user posted to the comments list and requested that we change.

- I think there are some problems with section 2.2. In particular, it should not say anything about UTF-8 encoding. That's already defined by the core schema and it's unicode consistency requirements. I think actually that we can drop the whole of section 2.2 and allow any form on the normative representations of nodes. There is no reason to restrict it to a particular form of a URI. (The section on the URI-based schema should of course contain some restrictions for how that scheme is made to work.)

- We should not define a new identifier for a functionality named "...:forest:...".

- There is no need to various subsections on multi-rooted hierarchies or polyarchies. See for instance 3.2.1 and 3.2.2.

In short, I think we need very few changes compared to the original profile. We just need to clarify the terminology and definitions, put in a couple of illustrations, relax the data type restrictions and add a section of a URI matching based scheme as an alternative to the other two schemes.

Best regards,

Rich.Levinson wrote:
Hi Erik,

The hierarchical profile is ready for review as is. There are no more changes planned.

    Note: The two added identifiers in section 2.2,
    "...hierarchical:forest:non-xml-node-id" and 3.2.2,
    "...hierarchical:forest:non-xml-node-req" are for convenience only
    and the spec could be rephrased without them, if necessary.

The profile is located at:

The example that Hal requested, which provides further motivation for the changes, as well as detailed explanatory technical structure, is at:

A fresh example of application of the profile using URIs that came up yesterday on the xacml-users list is at:


Erik Rissanen wrote:

I have posted new drafts of the core and the multiple resource profile. See the change logs and tracked changes for details.

As far as I can tell, we don't have any open issues on the following specs:

- Core
- Multiple resource
- Administration
- Privacy
- Dsig

The hierarchical profile is being discussed currently and there was discussion about improving the RBAC profile.

The proposed work on the RBAC profile seems in very early stages and the issue (policies about management of roles) is a major topic, so I propose that we don't bring this in 3.0.

So, could we agree on a feature freeze on the above mentioned profiles? If so, all of the expect hierarchical are ready for review before going to committee draft.

I also propose that if we don't get resolutions on the issues in the hierarchical profile soon and it would appear that there are major changes required, then we use the old version of that profile. However, my understanding is that Rich has pretty much completed the work on that. I haven't had the time to review it myself yet, but I will do so now.

So, given the above, can we agree on the following?

- everybody reviews the above mentioned profiles
- We correct any mistakes
- I will fix the metadata, references, namespaces, etc,
- Go CD with the above

One final issue: we need to update the acknowledgements section of the core. What goes in there? My name is not in there, and I would like to include it. :-) I presume that we keep all the old names, right? John Tolbert has requested to be added. Anybody else?

Best regards,

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:

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:

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:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]