All this talk about these role-based versus attribute-based stuff is confusing. I quite like the "Cedar Design Pattern" approach of mapping the rules into the following classes (and what distinguishes them is the type of additional information they rely on):

1. Membership permission

   . These cover classic role-based permissions. The rule relies on a group membership relation (who belongs in which group) that is defined externally.

2. Relationship permissions. The main example here is document ownership. This kind of rule relies on an application-level relation between resources and principals.
3. Discretionary permissions. These are ad-hoc rules created that a principal can access a concrete resource. This kind of rule does not rely on any outside data; all the information is stated in the rule.

Then, attributes can be used to implement these rules and augment with specific capabilities. Select what kind of permissions are used in the rules expressed below; some of these require membership information about the principal as well as relationships between resources and the groups.