Hi Erik,
In fact, my view has always been "Way A". My conceptualization is that
there is a collection of physical resources and that an organization
organizes the resources in various ways, and, in particular, as
hierarchies. Every time someone adds a resource to a hierarchy, the
resource gets a new name and parent attached to it. After this has been
done for a while the net result is that the collection of physical
resources can be viewed as having one or more hierarchies "draped" over
it. For every hierarchy a resource belongs to, it, in general can be
assumed to be assigned a name and a parent. Hopefully, we agree that is
"Way A" and based on that assumption, it should be fairly straight
forward to understand the issue:
Ok, so, based on your formula, what I do is:
follow the parent-child relations
this is fine at the requested resource, I find all my parents
now I go to each parent and collect all of its parents ***
This is where the problem is introduced. As soon as I collect a parent
of my parent that is not a member of a hierarchy I am in, we have
defined a DAG.
If I stick to parents of parents that are members of hierarchies I am
in, then I am in a forest.
The diff in these 2 methods is that the DAG method doesn't bother to
look at whether the requested node is a member of the hierarchy that it
is following from the requested node's parent.
The problem compounds as you follow each generation.
Thanks,
Rich
Erik Rissanen wrote:
Rich,
Hal and All,
Just a quick comment. I don't think that just because a resource, or an
ancestor, has multiple normative names, the hierarchy would become a
DAG. We need to differentiate between resources and names of resources.
One way ("Way A") to think of the problem is that the parent-child
relations are bound to resources, not the resource names. To collect
the ancestors to the request, one has to follow the parent-child
relations, and then include all names of all ancestor resources. That
is what the profile tries to say. (I think.) And that would be correct
in my opinion. And would not necessarily mean that the profile was made
to support a DAG.
An alternative way ("Way B") is to think that the parent-child
relations are tied to the resource names, not the resources themselves
(or that there are no resources independent of names). I get the
feeling that at least Rich looks at it like this.
I think way B is problematic since it opens up the possibility that
parent-child relations between different names for the same resources
conflict with each other. This is what I meant with "consistency" in my
post last week. By adopting way A, we avoid the problem.
Best regards,
Erik
Rich.Levinson wrote:
/ /I agree with that. However, it is the
algorithms that allow and appear to encourage collection of non-member
ancestors. Here is the text:
For each ancestor of the node specified in the “resource-id”
attribute or attributes, *and for each normative representation of
that ancestor node*, an <Attribute> element with AttributeId
“urn:oasis::names:tc:xacml:2.0:resource:resource-ancestor”.
The <AttributeValue> of this <Attribute> SHALL be the
normative
identity of the ancestor node.
The DataType of this <Attribute> SHALL depend on the
representation chosen for the identity of nodes in this particular
resource.
This <Attribute> MAY specify an Issuer.
For each “resource-parent” attribute, there SHALL be a
corresponding “resource-ancestor” attribute.
If the requested node is part of a forest rather than part of a
single tree, *or if the ancestor node has more than one normative
representation*, there SHALL be at least one instance of this
attribute for each ancestor along each path to the multiple roots
of which the requested node is a descendant, *and for each
normative representation of each such ancestor*.
It is the addition of all the "...each normative representation of each
such ancestor" which clearly opens up these algorithms to imply a DAG.
Without these phrases, it is still not particularly tight, but alone
they could be interpreted to imply a forest. With the phrases DAG is
inescapable.
The point is that these are ancestor nodes and nothing ties their
normative representations to be those that are in the hierarchies of
which the requested node is a member.
This IS the problem. It is these specific algorithms and what they say
about ancestors that forces you into a DAG. It clearly includes
hierarchies of which the requested node is not a member.
Therefore, it sounds like we are in agreement. That there is a problem
that needs to be fixed.
Thanks,
Rich
Hal Lockhart wrote:
As I have said repeatedly, the only problem
with combining the initial hierarchies into a DAG arises if the
original hierarchies include hierarchies of which the Resource is NOT A
MEMBER.
Hal
________________________________
From: Rich.Levinson [mailto:] Sent: Tuesday,
March 10, 2009 8:56 AM
To:
Cc: Erik Rissanen;
Subject: Re: [xacml] Summary of what I think I said on the call about
the hierarchical profile
Hi Hal,
The fact is that it is the algorithms in section 3.2 that imply that
the hierarchies are combined as a DAG. There is no problem, in general,
if the one or more of the original "hierarchies" happens to be a DAG.
The problem is that the algorithms force the combination of the
originals, DAG or forest.
The recommended changes to the spec that I have proposed is to have a
choice of algorithms for combining the hierarchies. That way customers
can decide for themselves which is appropriate for their resource
collections.
Thanks,
Rich
Hal Lockhart wrote:
I think the source of confusion was this. Daniel's point was that the
initial representation of each hierarchy could be a DAG, since it is a
generalization of a tree. Rich's point was that if you start out with
all the hierarchies in whatever form, and you include defined
hierarchies which do not include the Resource in question as a member,
even though ancestors of the Resource are members of the hierarchy, if
you combine all the hierarchies you lose the information about the
original hierarchies necessary to be able to distinguish whether the
nodes above the Resource are true ancestors or not.
My comments on the call and below on the DAG were based on the premise
that we started out with one or more hierarchies merged them into a DAG
and then determined the parents and ancestors. Under this premise, the
use of a DAG seemed like a intermediate step of no particular interest.
I now see that Daniel was trying to say that at the very beginning, any
of the distinct hierarchies may be multi-rooted and thus represented as
a DAG.
My feeling now is to make minimal changes to the document. I think if
we make it clear that the starting point is one or more hierarchy each
of which may be singly or multiply rooted, but only hierarchies which
contain the resource. I don't object to the individual hierarchies or
their union as being described as a DAG, but the ancestors could also
be computed by examining each hierarchy in turn.
I have some concerns about the URI part, which I will put in a separate
email.
Hal
-----Original Message-----
From: Erik Rissanen [mailto:]
Sent: Monday, March 09, 2009 7:43 AM
To:
Cc:
Subject: Re: [xacml] Summary of what I think I said on the call
about the
hierarchical profile
Hi Hal and all,
If I understand you correctly, then what you propose is the
exact same
thing as I proposed, except I used the DAG term because I thought
we
wanted to specify how you would get the list of ancestors from a
graph.
If that is not the case, then we can drop the terms DAG, forest and
so on.
So, basically we just say that you have one or more
hierarchies in which
the resource is part of and for the request context you send in the
resource itself, and its ancestors.
The only thing which I am still uncertain about in your email
is whether
you are trying to ban the use of a DAG. Sending a list of ancestors
this
way would work for a DAG, which I think is ok.
Best regards,
Erik
Hal Lockhart wrote:
This is an attempt to summarize what I said on the call today.
I have
changed the order a little and added a few extra comments.
First, let us agree that the hierarchical profile assumes that
some
party needs an AZ decision about a resource that is part of one or
more
hierarchy. The profile does not define what the hierarchy is, the
semantics of the relationships among its members or anything like
that. It
does define how to extract a small subset of the information and
put it in
the Request Context.
Now let us consider the two modes of operation in the draft
Rich created.
He called them DAG and Forest mode. If we look at my msg from
Tuesday I
give a small example of some hierarchies and a case where the two
methods
produce different information in the request context. Note that
they will
never differ in their parents, but the DAG mode can include
ancestors
which are not actually in the same hierarchy as the resource. In
the
example, Z is an ancestor of an ancestor (parent actually).
Another way to express this is that in the DAG model, the "is
an
ancestor" relationship is transitive. Every ancestor of an ancestor
is an
ancestor. In the forest model, it is only transitive within a given
hierarchy.
It is my opinion that the intent of the 2.0 profile, although
it is
certainly not clear and definitely contains mistakes, was that the
information put in the request context only include hierarchies of
which
the resource is a member. In my example, the Z-A hierarchy would
not even
be considered. Therefore the issue of transitivity does not arise.
In
effect, we are always using the forest model.
Therefore I do not believe it is necessary to have the forest
and DAG
modes. I do not see any valid usecases for the transitivity
property and I
do not think it was intended in the 2.0 version of the profile. As
an
example, my father is a navy officer. I am below him in a family
hierarchy,
but that does not make navy admirals my ancestors in any way. If my
father
was the resource, the navy hierarchy would be relevant, but if I am
the
resource, it is not. I think all that is required is to clarify
that only
hierarchies of which the resource is a member will be given any
consideration in computing parents and ancestors.
Next I talked about loosening the requirement that resources be
named
using a hierarchical URI. We previously agreed to allow strings. My
only
concern was to allow strings or URIs, not URIs carried in strings.
This
allows URI typed operations to be used when the name actually is a
URI.
Eric proposed that we allow any XACML datatype, and I agree. People
who
want the functionality of parsing a hierarchical URI can use a URI
and
others can use whatever is convenient for them. Of course it is
possible
that the information on ancestors and parents might be inconsistent
with
the structure of the hierarchical URI, but that was true in the 2.0
profile and there are lots of other legal ways for the request
context to
contain inconsistent information. If you put sand in your car's gas
tank,
it will not run, an XACML PDP is the same. In other words, GIGO.
Finally I said I generally supported Erik's proposed plan of
action with
one exception. Thinking about the problem independently, I had come
to the
conclusion we should totally eliminate mention of a DAG, before
reading
Erik's email. Here is my reasoning. As I said above, we start out
with a
rich set of information about the various hierarchies, at the end
we end
up with a request context which contains nothing but an unordered
list of
parents and an unordered list of ancestors. A DAG is simply a
possible
intermediate step. It contains more information than the request
context,
but less than the original set of multiple hierarchies. Talking
about a
DAG doesn't seem to me to help in explaining what the context
handler must
do, because it represents neither the starting point nor the ending
point,
just one possible intermediate step.
What I did not say on the call.
During the call I was thinking of the distinct
hierarchies as being
singly rooted as in my simple example. However, after the call I
realized
that the algorithm I mentioned completely eliminates the problem of
transitivity regardless of whether the initial, distinct
hierarchies are
singly or multiply rooted. Therefore it doesn't matter whether the
individual hierarchies or their union is represented as a forest,
dag,
polyarchy or database table.
To be explicit here is what I mean:
1. Start with all hierarchies in the space of resources of the
type of
interest.
2. discard all descendants of the resource.
3. discard all resource hierarchies (and their members) which
do not
contain the resource.
Now, however you represent the information, any reasonable
algorithm to
enumerate the parents and ancestors, discarding duplicates will
produce
the same results, ignoring order. The issue of transitivity will
not arise,
thus Rich's concern is satisfied.
Hal
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
