MSC4056: Role-Based Access Control (mk II)

[turt2live]

Rendered

[turt2live]

@gabrc52 says:

(I'm not sure what's the process for regular users to leave comments, so let me know if I'm doing it wrong)

Thanks for this MSC! I really like the role feature (but I am biased because I'm also a Discord user)

• Another alternative to consider with ordering is to put it in the m.role itself, in a similar way to m.space.child. However, it might make it harder for clients to implement reordering. What are the arguments for and against having a separate m.role_map (other than consistency)?
• I can confirm that in my experience, Discord's per-user role ordering is barely used if at all.
• How would looking up someone's roles in a specific room look like? (for example, if clients want to implement displaying the color for the highest role, or showing someone's roles when clicking on their profile) Would it make sense to have an endpoint for this, or should clients be responsible for keeping track of the state events (as is done for names and avatars)?

Off-topic(?) suggestions for future MSCs which may inform design of this MSC:

• (Discord feature) It would be nice to be able to mention roles
• (Discord feature) It would be nice to have the ability for roles to be space-wide as opposed to/in addition to room-wide. How could space-wide display names, roles, etc look like?

(please post comments on the Files Changed tab)

[turt2live]

• Another alternative to consider with ordering is to put it in the m.role itself, in a similar way to m.space.child. However, it might make it harder for clients to implement reordering. What are the arguments for and against having a separate m.role_map (other than consistency)?

This isn't done due to the state resolution concerns raised in the MSC. It opens the door to two roles having the same order, creating problems (aside from the problems associated with non-canonical events).

• I can confirm that in my experience, Discord's per-user role ordering is barely used if at all.

I couldn't even find it as an option.

• How would looking up someone's roles in a specific room look like? (for example, if clients want to implement displaying the color for the highest role, or showing someone's roles when clicking on their profile) Would it make sense to have an endpoint for this, or should clients be responsible for keeping track of the state events (as is done for names and avatars)?

This MSC assumes clients have ways of managing state events in rooms on their own. If a dedicated endpoint is required, it would be in another MSC.

Off-topic(?) suggestions for future MSCs which may inform design of this MSC:

• (Discord feature) It would be nice to be able to mention roles
• (Discord feature) It would be nice to have the ability for roles to be space-wide as opposed to/in addition to room-wide. How could space-wide display names, roles, etc look like?

These suggestions sound very reasonable and desirable, though they'd be handled by a future MSC (or two).

[cvwright]

Can users have multiple roles? And if so, how do you decide which role to use for each user in the power struggle?

For a given sender you could take their role with the highest order. But then does this require that the powers given to higher-order roles must be a superset of lower-order roles? Because what if the highest-order role does not itself include the power to send the given event?

You could decide whether the event itself is authorized by looking at the user's total powers as the set union of all their roles' powers. And to resolve conflicts, you could take the user's highest-order role as the user's order in the power struggle. Does that work?

[Mathias-g]

@cvwright I think going with how it works in Discord whenever possible is preferable, and in Discord it is the cumulative powers that roles assigned to you give you. So for instance, if you have the ability to join a sub-room in a space with one role, but not the ability to post messages in it, but you have the ability both to join the room and post from another role, you can both join the room and post in it, no matter the order of the roles.

[cvwright]

Yes, it seems important to have all of the orders for all the roles kept in one place so you can guarantee it's always internally consistent.

Would it be possible to move the assignment of users to roles out of the role map? If you had one "authorization" event per user, then that could save you from some of the challenges with the current m.power_levels event:

1. You're no longer limited by the max size of an event. For a very large room, you could have tens of thousands of muted users.
2. Less chance of conflicts in state res when you have mods / admins on different servers all taking action at the same time. You could have mod A muting user X, mod B muting user Y, and mod C promoting user Z all at the same time.

[Cloudwalk9]

I just want to throw my idea in. I already mentioned it to @turt2live a while ago but I want to share it more publicly.

What if we implement something like this in two stages that don't necessarily depend on each other, and maintain backwards compatibility with the existing power level system, essentially retaining it and making migration to newer room versions very seamless?

Per-user permission overrides

Allow users to be granted permissions on an individual basis regardless of their power level, and they can perform an action/send an event with the authority of their power level. Say, kick requires PL50, User is PL25 but is granted kick. User can only kick users PL24 and below.

Groups

Implement "roles" as groups. Users can be in multiple groups. Groups are assigned power levels just like users, and inherit permissions in the same way as users. Multiple groups can have the same power level, obviously. Power levels are retained for hierarchy and precedence in the member list, etc.

Putting these together

Per-group permission overrides and you got RBAC as an emergent property of both of these.

Security considerations

Overrides would usually take precedence over power levels, and ultimate authority must be evaluated based on the power level of the group or user that the override is set. A few example scenarios:

If a user of PL25 is denied kick, but is in a group of PL50 that grants kick, and kick otherwise requires PL25, nope, the user cannot kick. The user's override takes precedence because he is a lower power level than the group.

If a user with PL75 is denied kick, kick requires PL75, but is in a group with PL50 that grants kick, the user can only kick PL49 and below.

(This section has changed numerous times as I overthink and flesh out the potential pitfalls of this approach so bear with me.)