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
