The comment #28 of Tim seems a good use case for me.
It is easy to handle the use case at a single config of policy.json without another user operation if supporting user-id auth.
In general(I feel), developers tend to name virtual machines temporary with some common names like "dev", "test", "foo" or something. and it is easy to duplicate names between users. Then it would be easy to mis-delete different user's machine in the situation Tim said(150 developers in a single tenant). And the other developer gets angry.. So I am not against having the user-id policy for the use case.
The comment #28 of Tim seems a good use case for me.
It is easy to handle the use case at a single config of policy.json without another user operation if supporting user-id auth.
In general(I feel), developers tend to name virtual machines temporary with some common names like "dev", "test", "foo" or something. and it is easy to duplicate names between users. Then it would be easy to mis-delete different user's machine in the situation Tim said(150 developers in a single tenant). And the other developer gets angry.. So I am not against having the user-id policy for the use case.