I'm just proposing a role namespace. i.e. Group A defines a role called
"Manager". Bill has role mapping A.Manager. I want to avoid
overlapping with what you are doing. Each group would have some built
in declared roles: i.e. add-user, manage-user, manage-group, etc...So
that a user can be permitted to manage the members of the group. A few
people have been asking for this.
So my understanding is correct. This is what I meant by "GroupRole"
relationships, which is also supported in PL. However, there we don't have roles
within a group. But you can just assign any existing role to an user in the scope of a
specific group.
Regarding the overlap, there is no overlap with what I'm doing. What I'm doing is
permission, what an user is actually allowed to do, considering the resources and the
actions that can be performed on them (plus other things related authz). Like I said, we
are going to use all the stuff you are doing to actually define permissions/policies for
protected resources.
Maybe the names "Permission" and "Rights" are not the best ones for
what you are doing ? Maybe you should keep "Role Mapping" instead ?
Conceptually, what you are doing is not permissions ...