Guidance Needed around scopes, I'm not sure if I'm thinking about them wrong or if what I'm trying to do isn't supported... I want to enforce a

companyX.exec.manager

scope chain. However, that scope is specific to the principal. Do I add that scope to the resource when sending the PDP request? Technically, sure, that should work right, but what am I missing conceptually on why we would have to send that "principal" scope to the resource?

Can you give more details about what you're trying to do? I am not sure I understood your use case. If you're trying to make decisions based on where the principal fits within a hierarchy, you can do that using the hierarchy functions and might not even need scoped policies.

That makes sense @Charith (Cerbos) and this is probably a situation where that would make sense. I guess my question is more general though. • When or would it make sense to use scopes based off of attributes on the principal? I'm trying to prepare for scale (I know famous last words) and understand a general data structure I can setup in my identity provider to get ready for customers that want "special" permission structures.

Scoped policies are meant for refining access rules based on hierarchical relationships. A common use case is multi-tenancy where you have a base set of policies that might then be customized per tenant. Another use case is regional/departmental permissions where you might have organization-wide rules that are then customized per region or per department. I haven't come across a case where the hierarchy is purely based on the principal. In such a case I'd probably reach for the hierarchy functions and derived roles rather than scoped policies. The general guidance for using scoped policies is to use them where there's some sort of hierarchy that requires customization of some rules at different scopes. Hope that helps.

That does help @Charith (Cerbos) I'm going to repeat this back to you to make sure I'm on the same page. Use Scoped policies when there are situations where rules need "slight" tweaking based on hierarchy. Otherwise, use derived roles and hierarchy functions.

Yes. Of course, nothing's set on stone. But, generally, that's the approach that fits most use cases.

Thank you so much!