I saw some conversations about this, but I was wondering what would be your folks suggestion on storing the roles as higher-level templates for permissions. So if we wanted to have a role that encompasses few permissions (similar e.g. to the Custom Roles case in your examples), and have that assignable at different levels in the permission hierarchy - for different sets of users. Would it mean such a single role would have plenty of relations (so for each node it was actually assigned to for any user), plus assignments to all users to have that role, plus we need to use intersection on the nodes to make sure that for specific user this role should actually be used? I am wondering what would be the best approach, so our users are also going to be able to e.g. modify the role from their perspective, and so the updates permissions would trickle down to every already-existing assignments (so a role definition should not be strictly bound to a single resource). I saw that there is https://authzed.com/blog/google-cloud-iam-modeling#user-content-roles-and-role-bindings approach, with wildcards, and I also saw that there were discussion about this additional granting https://discord.com/channels/844600078504951838/1290751077443960874/1290772212890210324 , as the IAM model was modified in github to showcase the non-wildcard option of Google Cloud IAM. Basically, what would be the suggestion to do here: is it additional nodes for "role binding" approach, or would it be roles + user-granting relation with intersection on the resource node. I am trying to figure out the trade-offs on performance and flexibility of either. This is a multi-tenant system, and roles will be defined per-tenant, but those roles can be assigned to nodes at various levels of hierarchy (and then evaluated recursively)

the example in the blog will be slightly less performant and slightly more flexible than the variant without wildcards

Yup, makes sense. Thanks!