Many types of subjects in our system have attributes like

can_manage_accounts

in conjunction with a second attribute like

customer_id

which binds that permission to a specific scope of accounts. In the policy for determining whether someone can manage an account, one of the clauses will ask if the resource they're trying to manage intersects on customer_id AND whether that can_manage_accounts attribute is true. Transitioning these kind of boolean attributes that are specifically referenced in policies are what I'm interested in guidance/thoughts on. I could capture these as relations on a user (the customer id part here would be captured in a different relation on another namespace like an account):

class User implements Namespace {
  related: {
    can_manage_accounts: User[]
  }

  permits = {
    hasAccess: (ctx: Context): boolean => 
      this.related.can_manage_accounts.includes(ctx.subject)
  }
}

But this seems intuitively wrong to me using self-references this way? Another option is to define roles and relations to them, but then they need specific names and I'm not sure whether I can even do this:

class User implements Namespace {
  related: {
    roles: Role[]
  }

  permits = {
    hasAccess: (ctx: Context): boolean => 
      this.related.roles.some(role => role.name === 'can_manage_account')
  }
}

class Role implements Namespace {
  related: {
    users: User[]
  }
  name: string
}

This seems cleaner at first thought. But I don't know if I can use properties like "name" like this (chatgpt suggested this approach so...) or how I would be specific about particular "can_manage_accounts" role in the policy. I left the "customer_id" stuff out of here because that is strictly relational and translates very easily to Keto, not many questions about how to achieve that on my end - it is well covered by the existing docs.

This example is very messy for several reasons, try not to be distracted by "hasAccess" being on the User when it should be on an Account namespace. The important part is that "CanManageAccounts" property grants implicit access to all accounts for that customer id (as in we wouldnt want to go creating a new relation for every user with this permission whenever an account is created, but it might be ok to do so for a group of users, we do have a seperate attribute for explicit association with specific accounts) and needs to be considered as part of the Account.access policy.

Long term I am thinking that Keto might have a partial role in our system. While its true that most of the access check policies are relational, there are still aspects that seem difficult to migrate away from like time and ephemeral/contextual attribute values like geolocation that need to be considered at policy check time. So for me and my ABAC system, it's looking like Keto can replace a large chunk of it - the one that drives developers crazy especially - but that it may need to continue to "wrap" Keto.