Use case name
#4: User update information
Update some information about an user (not related with security)
The user to update has to be registered (objective)
If the actioner is different from the objective user, he needs to have a higher level credential than the objective
A registered user (actioner)
A registered user uses the web server interface (or an appropiate public API method) to delete another registered user
LEANDRO: 'delete'? shouldn't this be 'modify' ?
Main Success Scenario
The actioner selects an user and clicks on update information option
As alternative: the actioner sends a valid request with all information to the Public server API
The server verifies the actioner credentials
If the request is not for himself, the server will verify that the actioner current credentials are enough (policy: higher than the objective user)
LEANDRO: Policy: admin or himself
The server changes his information
The server notifies to the actioner that the operation is OK
DAVIDE: Other topics are: It's interesting to maintain an unique external UID for each researcher that can't change, for example email?
IVAN: That may be a compulsory, unique (alias) key to some numeric id, since mail can change.