Is anyone aware of recommendations for modelling credential restrictions/scopes in SpiceDB? Our software manages a set of devices; SpiceDB models which users have access to which devices. We use JWTs to represent end user credentials, and I'd like to mint a JWT that is restricted/scoped to a single device: This can be used to access a device if it matches the device it was minted for, and as long as the original user that the JWT represents still has access to the device. I'm thinking of it a bit like OAuth scopes, but instead of saying "This app can access my devices." I'm saying "This app can access device XYZ." I've considered a few different options and wondering if anyone has experience with these: 1. **hardcoded-scopes**: Don't use SpiceDB. Add

scopes: ["device:xyz"]

to the JWT and before/after calling CheckPermission, check for

resource_type+":"+resource_id

in scopes. 2. **two-spicedb-calls**: Create a new subject for the restricted credential, and add a relationship "credential 123 user device xyz". Change the permissions check to

CheckPermission(subjects.User, userID, perms.Access, rsrcs.Device, deviceID) && CheckPermission(subjects.Credential, credentialID, perms.Access, rsrcs.Device, deviceID)

. 3. **two-graph-traversals**: As above, but model the credentialID -> userID relationship in the SpiceDB schema. I tried this in the playground, but combined with the custom-role-binding pattern it got complex: https://play.authzed.com/s/03vCK2EBtdfA/schema 4. **caveats**: I thought maybe caveats could help here, but couldn't see how it would provide simplicity or flexibility: I think I'd just be adding a caveat

credential_scopes == "*" || credential_scopes == "device:" + resource_name

and then passing both credential_scopes and resource_name into CheckPermission instead of using them directly.

my knee-jerk response is that i'd go for #3. i'd make it so that the path walk goes from the device, through the credential, and on to the user. one of the benefits of using spicedb is centralizing authorization logic; if you're using other authorization mechanisms you're losing some of that benefit. i don't completely understand your use case yet; i can have a look at the schema. if the number of scopes would be small and centralizing in SpiceDB wouldn't work, i'd go for 1.

Thanks! I was also leaning towards #3 but it felt like I'm reinventing something. The user is the subject and the device is the resource. We're using the "Cloud IAM" custom roles pattern, so my playground example is based on the example from the blog post that uses spanner_databases_read (although in reality the permission is "user device_use device "). The main downside to #3 is the increased complexity at the callsite (need to provide both the "end user ID" and the "restricted credential ID" to SpiceDB), so I'm going back and forth with saying YAGNI and just checking against the device ID in the credential until I can see a clearer need for more complex scopes.