Surely a user is identified by n...@waveserver.com where "waveserver" is the wave server your registered too :? The names being unque to that waveserver and thus name+domain being unique to the whole federation. -Thomas
~~~~~~ Reviews of anything, by anyone; www.rateoholic.co.uk Please try out my new site and give feedback :) On 23 March 2011 11:35, Daniel Danilatos <danila...@google.com> wrote: > 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 >
