We have been discussing adding a method is_controller to the system API which would allow a canister to determine if a given principal is a controller of the canister.
During the discussions, we considered a more general API that would allow the canister to fetch the entire list of controllers. However, our internal consensus was that that API is more complex to implement and use and the canister can already get that information, asynchronously, from via the management canister. Furthermore, when this issue came up before, is_controller was sufficient and no other compelling use cases came up in our discussions.
We’d appreciate any inputs into this discussion from the community.
Since you linked my post, sure for me is_controller would be suffisant from my point of view. e.g. I can imagine that I could use it in guards. Will the information be available synchronously? i.e. will I be able to use it in query too?
Adding the method to the system API ensures that the method is available synchronously; it should also be callable in a non-replicated execution context so you can do access control in query calls.
Creating canisters happens rather seldomly and passing the controller list even more seldomly. So, although less awaits are nice is it worth the complexity?
Well…I don’t know the complexity…but I see a world where canisters are created and destroyed regularly, and it would be nice if a created canister inherited the controllers of its creator, but this likely much easier to implement at the replica level.