1. If you're just checking if they have access in general, this is the correct approach. Otherwise, if you need to know to which specific capabilities the user has access, you can issue checks in parallel for each (which is basically what the combined permission will do, but it will also short circuit once it finds at least one) 2. lookup-resources can answer this question 3. see above for #1, but you can also do a ReadRelationships call to find all the `relation`'s the user has access in. 4. you'd issue a direct-check for that role 5. lookup-resources can answer this question over the role type 6. this is the one hard question because its now two pieces of context: the user and the role; you'd need to create a synthetic subject to perform lookup-resources or use a ReadRelationships call

1,2 awesome, thanks! 6. I'll investigate this further, maybe my other questions also need new synthetic relations, not sure. If you have documentation or videos going over designing synthetic relationships, I'd love to take a look. 3. Didn't fully understand this. Using the playground code, how would I go from input:

proj1

and

user:project_db_reader

output:

role:spanner_database_reader

,

role:some_other_role_user_has_access_to

, ... 4. Maybe the role_binding indirection is confusing me, trying to go from input:

user:project_db_reader

,

role:spanner_database_reader

,

project:proj1

output: yes/no 5. Can I do a direct lookup-resources on role type from user? Or do I have to find a way to walk it using role_bindings? input:

user:project_db_reader

Output:

role:spanner_database_reader

on

project:proj

Is there a better way than this? * lookup-resources to go from user -> role_bindings * for each role binding * lookup-resources to go from role_binding -> proj1 * lookup-subject to go from role_binding -> role Essentially, it seems what I need is some way to express and query a dynamically named relation (e.g. the user-defined role). given: user1 -> {roleA, roleB} -> proj1 -> {roleA,roleD} -> proj2 Be able to lookup: 1. What roles does user1 have access to in proj1 * roleA, RoleB 2. Similar to 1 but just checking for a specific role. Does user1 have roleB on proj1 3. What roles does user1 have in general? * roleA, RoleB in proj1 * roleA, roleD in proj2

3. Why do you want to check what roles a user has access to in a proj? The more typical pattern would be to evaluate what permissions a user has access to in a proj. 4. Since the role is known, there is no need to pass the user as an argument. You need to evaluate the perms for the role with a check. 5. Since roles have no direct relation with a specific user, you will need to walk it. Your proposal looks correct. 6. Here are the docs on synthetic relations. https://authzed.com/docs/reference/schema-lang#synthetic-relations

Thanks for all your answers, this gives me plenty of information to play around with. I should have clarified the "why" of 3-5 (and some others). These tasks are mostly around possible options for displaying custom roles to a user (e.g. in a UI). I'm conflicted on whether to track that information in a different DB and use SpiceDB strictly for AuthZ decisions. Or whether to use (abuse?) SpiceDB since it's ultimately a graph DB and walk it to get answers to those questions. 🙂