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:
State/City01/MainStreet
State/City02/MainStreet
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).
Basically,
- 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:
- 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).
- 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.
Daniel;
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.
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
|