alkem-io
User identity flexibility
Description
Allowing changing of user emails Allowing a user to have multiple email addresses
Goal
Allowing users to have better identity management
Hypothesis
The current usage of email address as the core user identifier is limiting in terms of how users both authenticate and how they evolve their identity
Must have scope
- [ ] Updating of the Kratos schema, and cached of the schema, to have subjectID as the core identifier
- [ ] Extend Kratos schema to also support multiple email addresses?
Stakeholders
Right now if someone wants to change email there is a nasty hack that is carried out that sort of works, but is not sustainable and is fragile. It also means people currently lose access to their Matrix interactions
Design
A clear deployment plan will be required for this change.
@valentinyanakiev @antst in the end I put this into the matrix comms epic due to Anton's comment: the current steps used for updating an email address would mean users lose access to their Matrix accounts, which is a problem.
For email flexibility we have to decide on one important aspect. There are two choices:
- user have multi-email identity, which means same password can be used with different emails.
- user have multiple identities, which means multiple email-password combinations.
Those are two distinctively different use cases. First one, indeed, kratos schema with multiple emails. Second one is multiple identities attached to the user. As we separate business logic from password and use universally Alkemio UserID, we have zero issues to support both cases, as we untie identity/authentication from rest of business logic. Second option can be implemented via simple pivot table.
Also, choice of 1 or 2 will define different logic in the process of attachment of another email or identity to existing user profile.
@antst to be discussed, several factors to weigh off against each other. Key priority now is to allow users to change their email address, both in the user profile and in their kratos account i.e. to support the case where a user moves from one org to another and wants to keep their Alkemio profile.
Once core of user is userID across the system, we open possibility to do both, identity replacement or identity edit. It will not affect rest of business logic. But we need to have educated design choice here. Which means we need information :) I will look into that.