Currently, ParticipantId contains an email address. This is not a stable long term identifier for a user, and can cause problems. For example, let's say "Bob Smith" b...@example.com leaves the organisation, and then someone else "Bob Jones" takes over the same address b...@example.com. Jones could then potentially gain access to Smith's waves.
I propose adding an additional field to ParticipantId, "opaqueId" or "stableId" or similar. This would be an opaque string that is guaranteed to only ever correspond to a single user. To start with, to avoid a massive change, we can leave ParticipantId's single arg constructor in place and have it use the email address for the opaque id, even though this is incorrect. Servers that wish to stably identify users could ensure that they only construct and serialize ParticipantIds that contain a proper opaque id. A full fix might eventually require an addition to the Federation protocol, for example a way to ask for the current opaque id given an email address the user just typed. I don't intend to propose a full plan to address this issue but we might want to start thinking about it, and the initial fix mentioned above is in my opinion a step in the right direction. Thoughts? Dan
