Re: [xacml] New core and multiple resource profile and hierarchical

[Daniel Engovatov <daniel@streamdynamics.com>]

That is a very good list of suggestions, Erik.

>
> - Remove all the new definitions of "polyarchy", etc. They are not  
> needed. Use only the term "DAG".
>
> - Define a hierarchy as a DAG, where the nodes correspond to  
> resources and the edges correspond to child-parent relationships.
>
> - Define that each node in the hierarchy has one or more "normative  
> representations" (names). A normative representations is defined as  
> an XACML datatype value instance, which is provided in the request  
> (through the context handler or the PEP). A representation which is  
> not provided in the request is not normative, and may not be  
> referenced in policies.
>
> - This is actually already implied, but maybe worth stating: if one  
> merges a number of hierarchies in the pre-processing step, the  
> merged hiearchy must be consistent with respect to node  
> representation/naming and the parent-child relationship. That is,  
> if A and B are two representations of a node and C and D are  
> representations of another node, and there is a relationship  
> between the nodes, the same relationship applies to all  
> representations/names. So all of the following would apply, not  
> just some of them: A-C, A-D, B-C and B-D. I think the complexities  
> in what you have done Rich is much due to that you have tried to  
> cover hierarchies where this is not true. But those hierarchies are  
> not internally consistent, so we cannot make them work.
>

I think we should avoid any mentioning of "multiple hierarchies", or  
"merging" altogether.   There are NO multiple hierarchies as far as  
XACML should be concerned.   What people may want to do to present a  
hierarchy applicable to policy evaluation - we can not possibly have  
a say.


> - The ancestors of a node are defined as simply the transitive  
> closure of the parent-child relationship.
>

I am not sure that this must be restricted that way at all.    
"ancestors" are provided only for the resource being queried, one at  
a time.   So if "A" is ancestor of "B", when checking access to "B",  
and "B" is ancestor to  "C" when checking access to "C", that does  
not need to imply that "A" is an ancestor to "C", when checking  
access to "C".   "Ancestors" is a set of nodes that a given node  
inherits from.  That should be a sufficient definition.     Though  
for practical purposes it does not matter, as nothing restricts users  
to present the same hierarchy for different evaluations.

> Note that the above points imply that there is a single hierarchy  
> which is a DAG. Also note that I don't make use of the term "root".  
> It's not needed.
>

It is not only not needed, it is extremely confusing.

> - Add in a couple of examples with illustrations showing a simple  
> tree formed DAG and a more complex DAG which is not a tree and show  
> how the ancestors are found.
>
> - Remove section 1.1.1. It's not needed if we specify the  
> algorithms on a sigle DAG only.
>
> - Make a separate section about the URI-only scheme, saying that  
> "in some cases when the resources are represented as URIs, it may  
> be possible to simply do matching on portions of the resource  
> representations". Also make it clear that the PEP and PDP must  
> agree on which scheme is used, or the policies won't work.
>

I think we should do a separate profile for URI hierarchies altogether.

> - I think that a node may be represented by any XACML data type,  
> like a string for instance, not just URIs. This is what the user  
> posted to the comments list and requested that we change.
>

+1

> - I think there are some problems with section 2.2. In particular,  
> it should not say anything about UTF-8 encoding. That's already  
> defined by the core schema and it's unicode consistency  
> requirements. I think actually that we can drop the whole of  
> section 2.2 and allow any form on the normative representations of  
> nodes. There is no reason to restrict it to a particular form of a  
> URI. (The section on the URI-based schema should of course contain  
> some restrictions for how that scheme is made to work.)
>

If we want to say anything about encoding, we should also consider  
switching to IRI from URI.


> - We should not define a new identifier for a functionality named  
> "...:forest:...".
>
> - There is no need to various subsections on multi-rooted  
> hierarchies or polyarchies. See for instance 3.2.1 and 3.2.2.
>

+1



Daniel;