An identifier for a Participant.
All Participants in a session must agree on the ParticipantIdentifiers. That is, these are not local identifiers controlled by a single Participant; they are unique, agreed-upon identifiers for the Participants in a session. Each entity participating in a session should have a different ParticipantIdentifier.
ParticipantIdentifiers can be used across multiple sessions. For example, if a set of participants run keygen, auxinfo, and then compute several signatures, they can use the same set of identifiers for each of those sessions. However, a single ParticipantIdentifier should not be used to represent different entities (even in different sessions with non-overlapping participant sets!).
ParticipantIdentifiers should be unique within a deployment, but they don't necessarily have to be globally unique.
Up to now, I thought that ParticipantIds where ephemeral objects which we could arbitrarily choose to run a subprotocol: e.g. keygen and then forget about them. It turns out that the same set of ParticipantIds must be used to for all sub-protocols for a given key. This is somewhat implied by the documentation:
if a set of participants run keygen, auxinfo, and then compute several signatures, they can use the same set of identifiers for each of those sessions
Note the above say "they can use the same same of id..." but it should actually say "they must use...". We should improve the documentation for ParticipantIds.
Notes, Suggested Improvements, Questions:
It is not clear what session is in the documentation above, we should define it, or use a better term. It seems, in this context, a session refers to what I call a "single sub-protocol execution".
Make it explicit that we need to remember/persist the mapping of ParticipantIds to key material, for a given key.
Every Participant probably needs to remember the Ids of all members of it's quorum? For the lifetime of a key.
I don't quite understand the relation and differences between the session ID and the participant ID.
From the documentation: "a single ParticipantIdentifier should not be used to represent different entities (even in different sessions with non-overlapping participant sets!)". This implies that we should not assign a "static" ParticipantId to each node and reuse it across keys? Should we be generating a new ID per key and persisting this information for the lifetime of the key? Not only this ID, but the IDs of all others Participants in this quorum? Just wanted to highlight this is quite a bit of bookkeeping.
Our current documentation of
ParticipantIds is:Up to now, I thought that
ParticipantIds where ephemeral objects which we could arbitrarily choose to run a subprotocol: e.g. keygen and then forget about them. It turns out that the same set ofParticipantIds must be used to for all sub-protocols for a given key. This is somewhat implied by the documentation:Note the above say "they can use the same same of id..." but it should actually say "they must use...". We should improve the documentation for
ParticipantIds.Notes, Suggested Improvements, Questions:
ParticipantIds to key material, for a given key.Participantprobably needs to remember the Ids of all members of it's quorum? For the lifetime of a key.ParticipantIdto each node and reuse it across keys? Should we be generating a new ID per key and persisting this information for the lifetime of the key? Not only this ID, but the IDs of all othersParticipants in this quorum? Just wanted to highlight this is quite a bit of bookkeeping.