This is an important topic, as part of the discussion we could also think about other manner of assigning default permission, such as based on a type - i.e. have a type define a set of defaults. think of a model based on DI that has a type with three functional groups in it. one for Tuning, one for configuration and one inputs. In the type each of the functional groups could have there own default permissions. These defaults could be actually applied to instance when they are created or the instance could reference the type. In short we may need more then one standard reference type. One that is used to create the hierarchy and one that is used to point to a template type (much like an HasInterface - that indicate security inherited from here)

Using references for applying permission to as set of nodes is not easier than setting the attribute on all affected nodes but will introduce a massive performance hit.

The permission check needs to be executed for every service request (read, write, call etc.). Checking permissions for a list of roles is already an overhead but if there would be also an internal hirarchical browse necesary for every read/write access to a node, this would be a major performance problem.

from UA meeting: - An alternative was discussed – where the hierarchy is not for checking but for assigning permissions. If the permission on a parent is changed then all of the children can optionally also inherit the permission - maybe this would be part of the operation that assigns the permissions. The run time checking will still be very simple since it is just the node that needs to be checked. The assignment of a permission (changing it) may take some time, but this is an infrequent activity. This would allow roles to be assigned and managed.