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: