Use case name
Upload to the system a new SSH key for a given user
The user to update (objective) has to be registered
The user that performs the update (actioner) has to be registered
The actioner has to be a credential of higher level than the objective (this condition also prevents admins from changing other admins info)
A registered user with some credentials level uses the server interface (or server API) to upload one SSH key to another user (or himself)
Main Success Scenario
The actioner selects an objective and clicks on updaload new SSH key 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 update)
LEANDRO: The server updates the keys at each involved sliver
The server notifies to the objective user that one more SSH credential has been uploaded
DAVIDE: What happen if the key is in use? There exist a limit?
IVAN: What are the problems of two users sharing an SSH key?
LEANDRO: no problem, that is out of scope of the system
DAVIDE: There isn't a specific reason to limit the number of users that shares an SSH key, but we have to decide if it's possible or not.
LEANDRO: This case is similar o same as user update information