Forums » Suggestions
Request for Comments: Hierarchical Authentication and Ownership of Dynamically Conquerable Content.
«123Inc, I have no idea how you came up with this, but it seems like it should work beautifully. I can't imagine a more forward-looking and cleanly designed way to do dynamically owned content.
I'm sure concepts will get a lot clearer when youguys get the UI and implementation for this down, but here are my two, (or three as it may be), cents for the time being.
1. I would personally shy away from using the same key for multiple privileges unless there's a clean way to split/merge these privileges and keys after initial assignment. That said, I have so far failed to come up with a good way of doing that.
Say Players A and B are both owners of Key 1 which provides Asset X and Player B is also the owner of Key 2 which provides Asset Y. If Player B wants to merge Key 1 and Key 2, does Player A automatically become an owner of Key 2 as well? What if the two keys have different user lists?
2. If you stick to the one key per asset model, then a quite a few annoying questions disappear. However, there should preferably still be some mechanism for associating and organizing multiple keys.
I was thinking this could be solved be allowing keys to be collected into groups. A group would basically function as a "meta-key", or a key that is not linked to any assets but allows owners to assign privileges to all keys contained in that group. Take, for example, a key group for all the assets of a particular guild. Player A owns Key 1, Player B owns Key 2, and Player C owns Key 3. Player A creates Group 1 and gives owner status of the group to Players B and C. Players B and C then add Keys 1 and 2 to Group 1, giving all three users ownership privileges to all three keys. Player A now decides to give Players D, E and F, who are guild members, user status to Group 1. Players D, E and F are then automatically granted user status to Keys 1, 2 and 3 because the belong to Group 1.
Basically, a group would not provide any separate privileges of its own but would instead serve to synchronize privileges across multiple keys. When a key belongs to a group, its access tables become that of the group and cannot be configured independently. I really wanted to find a way to use groups for designating privilege hierarchies, but couldn't think of any way of doing that without screwing everything up, and in the end I think this simpler solution will actually work better.
3. If you provide different methods for granting key status, (ie. guild affiliation, faction standing, buddy lists, individuals, etc.), then these should be able to operate in tandem and in order. For instance, owners could grant user status to anyone with sufficient standing, then disallow members of a particular guild, and still be able to override both directives for individual players should the need arise.
I'm also not sure how dynamic grants would work with respect to owners, as you've set it up so an owner could only de-ownerize themselves. Let's say Player A gained control of Key 1 and gave ownership to Player B, C, and D who are executives of his/her guild. If Player D is removed from office, does he/she lose ownership of Key 1? What if Player D decides to add an individual override before he/she is deposed?
-Calder
I'm sure concepts will get a lot clearer when youguys get the UI and implementation for this down, but here are my two, (or three as it may be), cents for the time being.
1. I would personally shy away from using the same key for multiple privileges unless there's a clean way to split/merge these privileges and keys after initial assignment. That said, I have so far failed to come up with a good way of doing that.
Say Players A and B are both owners of Key 1 which provides Asset X and Player B is also the owner of Key 2 which provides Asset Y. If Player B wants to merge Key 1 and Key 2, does Player A automatically become an owner of Key 2 as well? What if the two keys have different user lists?
2. If you stick to the one key per asset model, then a quite a few annoying questions disappear. However, there should preferably still be some mechanism for associating and organizing multiple keys.
I was thinking this could be solved be allowing keys to be collected into groups. A group would basically function as a "meta-key", or a key that is not linked to any assets but allows owners to assign privileges to all keys contained in that group. Take, for example, a key group for all the assets of a particular guild. Player A owns Key 1, Player B owns Key 2, and Player C owns Key 3. Player A creates Group 1 and gives owner status of the group to Players B and C. Players B and C then add Keys 1 and 2 to Group 1, giving all three users ownership privileges to all three keys. Player A now decides to give Players D, E and F, who are guild members, user status to Group 1. Players D, E and F are then automatically granted user status to Keys 1, 2 and 3 because the belong to Group 1.
Basically, a group would not provide any separate privileges of its own but would instead serve to synchronize privileges across multiple keys. When a key belongs to a group, its access tables become that of the group and cannot be configured independently. I really wanted to find a way to use groups for designating privilege hierarchies, but couldn't think of any way of doing that without screwing everything up, and in the end I think this simpler solution will actually work better.
3. If you provide different methods for granting key status, (ie. guild affiliation, faction standing, buddy lists, individuals, etc.), then these should be able to operate in tandem and in order. For instance, owners could grant user status to anyone with sufficient standing, then disallow members of a particular guild, and still be able to override both directives for individual players should the need arise.
I'm also not sure how dynamic grants would work with respect to owners, as you've set it up so an owner could only de-ownerize themselves. Let's say Player A gained control of Key 1 and gave ownership to Player B, C, and D who are executives of his/her guild. If Player D is removed from office, does he/she lose ownership of Key 1? What if Player D decides to add an individual override before he/she is deposed?
-Calder