make stable identities for users possible

[davidschlangen]

The goal is to let users choose their own username and password, through which they can repeatedly log into the system (and for example play the same game / do the same task whenever they log in).

It might be possible to do this with a wrapper around the server, or it might require changes to it. In any case, exposing the tokens that we currently use (of the format 01234567-89ab-cdef-0123-456789abcdef would not make great passwords.. The users must be able to choose them themselves, just like on any other website where you register.

[dmhowcroft]

I've been thinking about this a little bit as well, since in our experiments we are having participants complete the same task twice, once in each role.

In order to achieve this, we currently send them two different links which specify the token and their role (as a username) in the URL.

I'm less keen on usernames and passwords since folks often re-use usernames and passwords and it increases the potential risk in the event of a data breach if we're storing usernames and password (hashes) which are used elsewhere.

On a related note, if I give a user a token and the only thing that token is associated with (on the slurk server) is responses in a collection of related experiments, then I think it may be easier to ensure GDPR or pseudonymisation/anonymisation compliance. This depends a bit on the scope of the user management system and slurk deployment, though.

One caveat I thought of in terms of implementation is that managing users and tasks differently will require presenting users with a way of selecting what room or task to join from the set of tasks they are allowed to join.