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] Working toward solution to Hierarchical profile Issue

Hi Daniel,

I think this appears to be a step in the right direction, and I have modified the Subject line above to indicate this.

Let me try to find common ground inline below:

Daniel Engovatov wrote:

On Feb 20, 2009, at 8:15 AM, Rich.Levinson wrote:

Hi Erik,

The problem presented by the commenter is analagous to:


Just because two separate cities have a street named MainStreet does not mean these are the same street. These are two distinct normative identifiers for two distinct resources.

Yes, those are too distinct identifiers, and XACML does not need to know anything about its internal structure.    You could identify streets by there geographical coordinates, cities by zip codes and states by the last name of its governor.  It will work the same.   No naming schemes are needed in any form or shape.
While it is true that xacml does not "need" to know anything about the internal structure of the identifiers, xacml at the same time "defines" functions such as anyURI-regexp-match and a host of others designed to deal with the internals structure of identifiers and capitalize on the value inherent in those value-added constructs to a basic string.

You also want to be able to inherit the policy for a "street" from county.  County may be represented as "State/County" and city will not be on the path.  All you need to supply to PDP is an unordered bag containing
{"State/City01/MainStreet", "State/County1", "State/City01"}  If you decide to change county identifier to "Nevada County, CA", you do not need to change any naming schemes.   You will just need to update rules that target county and its descendants.   PDP should not care what do you use for identifying policy targets.
I agree that it is desirable to be able to inherit policy. However, DAG only offers a limited form of inheritance which is that all subordinate nodes in all hierarchies of the node being attached to, as well as the node itself inherit from the attaching node. In DAG this is automatic and there is no stopping it.

A "Forest" which is a "disjoint set of trees" is a functionally specialized value-added subclass of DAG. The value add is that all nodes retain the knowledge of the tree in which they originated. Therefore when a tree is added to a forest its member nodes retain their original tree identity. As such, one has options on inheritance not available in the more general DAG.

Some examples include that an attaching node can have its policy apply to only the attached node, or any or all of the attached nodes subordinates. This is a classic "task force" type capability where the members of a task force are subordinate to the task force leader, but the subordinates of the members are not unless explicitly selected to be members.

DAG cannot support this construct, because it retains no information about its connections other than source and destination node. i.e. any hierarchical information in a set of attaching nodes is automatically lost when joining the DAG.

This approach introduces the absolute minimum (none) of new concepts that PDP need to understand.   You do not need to maintain and process any naming schemes.   It covers all possible structures for the purpose of policy inheritance.  It does not need to cover anything else.
Hierarchical naming schemes are really irrelevant for this discussion, because their value is primarily for use with Forests. They have little or no value in the more general DAG, so I can understand why you consider them unnecessary and extraneous. However, for a Forest they can have significant value.

From this perspective, I suppose one could say that section 2.2 is "Forest-oriented" and section 3.2 is "DAG-oriented" since the mechanisms in the two sections are really only useful for the framework for which they have just been identified as "-oriented".

The root of this whole discussion is that we have tried to use one document to describe two different solutions. 
I agree that the root of the discussion is that the document has co-mingled two distinct conceptual frameworks for ordering a collection of nonXML nodes:
  • DAG: a collection of (overlapping) trees with no cyclic routes (also no memory or way to identify the original trees to which a node belonged)
  • Forest: a disjoint collection of (overlapping) trees which may have the exact same structure as any DAG (the disjoint property means that the explicit trees of which each node is a member is retained, which means one can always navigate the original hierarchies).
  • if one applies a hierarchical structure of nodes across a DAG the connections are retained but they are indistinguishable from the connections already present in the DAG and so the hierarchical properties of the added structure as distinct from the rest of the DAG, are, in general, lost.
  • whereas if one applies the exact same hierarchical structure of nodes across a Forest, which has the exact same connectedness within its class as the DAG, the hierarchical connections within the structure being added are retained AND they are permanently distinguishable and one can use them to walk the original hierarchy and members can be added and removed within the retained hierarchical structures within the Forest.
Proper course would be to split it, and leave one for XML documents/URI and one for "ancestors" approach.
I think there are a variety of options available in addition to the one you suggest.

Basically, I do not believe the public, in general, or even the highly technical public can be assumed to understand the distinction between Forest and DAG, at least not without a brief explanation similar to what I tried to do above, so I recommend including such information, possibly in the Glossary of any option.

Here are some options in addition to an explanatory glossary, I consider reasonable:
  1. Modify existing document so that nonXML nodes are described with DAG option and with Forest option. This can be done minimally as follows:
    •  Change the identifier in section 2.2 to indicate that it is forest-oriented:
      • "urn:oasis:names:tc:xacml:2.0:profile:hierarchical:forest:non-xml-node-id"
    • Add an identifier in section 3.2 to indicate the forest algorithms:
      • "urn:oasis:names:tc:xacml:2.0:profile:hierarchical:forest:non-xml-node-req"
    • Add an alternative set of bulleted algorithms to section 3.2, which are the same as the existing ancestor algorithms except specify that only the parent and ancestor nodes of the requested node are collected which are direct ancestors of one of the normative identities of the requested node (which is possible, because with a forest the original parent identifier is always retained for each hierarchy the requested node still belongs to or has been added to since joining the forest).
  2. Any variation, rearrangement, separation, or enhancement, building on the contents identified in #1.
I think that's it. The whole discussion boils down to definition of Forest and DAG and the minor changes to the spec required to identify the changes those objects imply, which simply boils down to retaining some information when a node is added and using that information when ancestor nodes are collected.

Notice also, that the forest can use either set of algorithms, since it contains the information necessary for both.

Similarly, the URI naming scheme can, in principle, be used for both, although it is much more useful in the Forest, however, it can, remarkably, be used in the DAG to impute the properties of the forest to the DAG.

P.S. On the side note, when we designed a protection scheme for XML data structures for what is now known as Oracle Data Service Integrator, we found it next to useless trying to rely on XML data structure for the purpose of policy inheritance.   We chose to bind schema elements directly to protected resources that followed their own separate and more generic hierarchy.   That allows a reuse of policies independent of transformation and re-factoring of the XML.   That is similar to the issue of maintaining any hierarchical naming schemes for enterprise resources - you do want to decouple them from access policy rules.

Hopefully, some other people will be able to objectively review this information in its consolidated form and provide input. Personally, I can't think of much more to say about it. Also, I think it has been a useful exercise, and I appreciate the time and effort that Daniel has expended to help reach the current level of understanding of the situation. I know I have learned a lot.


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]