Use case name
Delete an existing user of the platform
Server (Software) and Nodes (Software)
The user to delete (objective) has to be registered
The user that performs the deletion (actioner) has to be registered
The actioner has to be a credential of higher level than the objective (this condition also prevents admins from deleting other admins)
LEANDRO: I would allow admins to delete users, including other admins: simpler.
A registered user with some credentials level uses the server interface (or server API) to delete another user (or himself)
Main Success Scenario
The actioner selects an objective and clicks on delete option
As alternative: the actioner sends a valid request with all information to the Public server API
The server verifies the actioner credentials
The server verifies that the actioner current credentials are enough (policy: higher than the objective user to delete or the objective user is himself)
LEANDRO: Policy: admin or himself
The server verifies which slivers have been created (and are active or running) by the objective
The server notifies to each sliver that it will be deleted by a user deletion
In case the objective user is not the same as the actioner, the server notifies to the objective user that he/she will be deleted by another actioner request
The server stops and removes all assigned slivers
The server deletes the information (or disables it) about this objective user
DAVIDE: Open topics are: What happens if the researcher is logged on a node? What about their slices/slivers?
LEANDRO: no problem, all gone.
IVAN: Following the out-of-band access proposal, researcher users only exist in the
node while the sliver exists there, so I don't see a problem in removing them
from the server straight away, maybe with the exception of the slice owner
(which could be devoid of all capabilities so it becomes harmless and removed
when the slice finishes). The slice owner or an admin may have the option to
force immediate removal of other researcher users from nodes for that sliver.