Implementing Membership Termination

[JanisErdmanis]

Under the current state of PeaceFounder, administrators face a significant limitation: they lack the capability to terminate memberships. This function is crucial in various scenarios. For instance, when a member fails to submit necessary authenticity documents within the allotted time post-registration, their membership must be annulled. Additionally, this feature is vital for addressing privacy concerns, such as when members wish to withdraw and have their associated records deleted. Furthermore, an essential aspect of membership management involves issuing new credentials in cases where a member loses their device or experiences a security breach with their key being compromised.

The process of terminating a membership in PeaceFounder presents its own set of challenges. The core difficulty lies in the inability to link a member's real identity and their current pseudonym, which prevents the removal of it in subsequent braidings. This link is only known exclusively to the member's client device, as it only knows the private key that can generate them.

A straightforward approach to address this issue involves resetting the generator in the braidchain and taking identity pseudonyms of the membership certificates as inputs to subsequent braidings. However, this method presents a significant hurdle, particularly for larger organisations. Implementing this reset each time a member is terminated can be prohibitively expensive. In particular, taking into account that the frequency of membership termination cases increases proportionally with the number of members as well as the required compute to do braidings, making this approach to scale as $O(N^2)$. Therefore, a more sophisticated and nuanced solution is needed.

To reduce the number of generator resets, the membership terminations could be batched together until some set threshold is reached. In between this time, we could leverage an assumption that members use a PeaceFounder client that has not been tampered with and thus could block terminated members from voting at the endpoint. One may argue that the best time to reset the generator is before the proposal is published; thus, such assumption would not be needed. Nevertheless, the client's device would need to inform if their membership is terminated in a timely manner rather than letting members be confused on the issue of why their cast votes can't be recorded. Thus, the implementation would essentially be the same.

To officially terminate a membership, the registrar issues a Termination record, which is submitted to the braidchain. In the most simple form, it points to the terminated membership certificate record index and contains the registrar signature:

struct Termination <: Transaction
    index::Int
    approval::Seal # also contains a timestamp
end

Perhaps we may need to rename it to MembershipTermination if specialised fields for the nature of the termination need to be provided. However, there is also a potential use for a termination record to cancel a malformed Proposal record before the vote in situations where urgent corrections are needed.

The next step is to inform the corresponding member's clients' devices about this record. It is not allowed for clients' devices to ask if their membership record is still valid before or after the vote casting as that provides a giveaway for the identity of the pseudonym with which the vote is cast, as it can be easily tracked.

To avoid such tracking, a bitmask that lists all terminated records could be included in the braidchain commit state retrieved along with the proposal record. So that upon receiving the proposal, the members' clients would know whether their membership is still valid. In case the bitmask shows that their membership is terminated, the member's client, instead of voting, would source for the termination record under a path:

/braidchain/terminated/{index}

which would return a terminated record for the client along with its inclusion proof. Retrieval of the record is necessary to provide the users with tangible evidence they can check with other sources. In particular, the device would show the Termination record index, timestamp and issuer, which, if made improperly, can be disputed by the affected individual.

When a sufficient number of members have been terminated, the relative generator needs to be reset from the base generator to flush out old pseudonyms. This is done by a generator reset record that has the following schema:

struct GeneratorReset <: Transaction
    approval::Seal
end

Then, in the next braid, input is taken from the generator as specified in the DemeSpec record, and the pseudonym set is constructed from identity pseudonyms recorded from the admission part of the member certificates.

A risk is that a corrupt member could exploit this behaviour by getting more votes than others. In the short term, this could be mitigated by limiting to a single new membership certificate until the generator is reset. In the long term, the behaviour of members frequently requesting new credentials would be suspicious and could form the grounds for permanent termination of membership.

One limitation for issuing new credentials is that a long-lasting member would be treated as a newly registered one. So, it would not be able to vote on already published proposals on the braidchain. In situations where the member is able to recover the key from the secondary source, it still could be cautiously used for old proposals by the member to check if someone else does not supersede it. Meanwhile, for new proposals, a new key would be used. This would require a modification of the termination record to include a field that the old key can still be used.

In large demes, the size of the bitmask could become large. To alleviate that, a bit of compression can be used. On top of that, GeneratorReset could contain terminated members, and then commits could show only newly terminated ones, which would significantly reduce a compressed bitmask size and make it practical for those contexts.

[JanisErdmanis]

The membership termination has been successfully implemented. This significant update is a result of the schema I meticulously set up, which includes a termination record:

struct Termination <: Transaction
    index::Int 
    identity::Pseudonym 
    seal::Union{Seal, Nothing} # issued by registrar
end

where the index points to a membership record index being terminated and the identity of its pseudonym.

The same record is used when admission is issued, but a member fails to register. In such a situation, the index = 0 and the identity is put into a blacklist, preventing client from registering. The same blacklist prevents a terminated member from reusing admission to register again.

Early termination has also been implemented. If a membership is terminated before a new braid is issued, it is also removed from the list of member pseudonyms; thus, resetting a braid is unnecessary. This can facilitate certain workflows where registration, braiding and voting are strictly separated. It can be used for membership authenticity reviews, after which one continues braiding.

The other part is resetting the braid. Instead of making a separate record, I added a reset field, which, if set to true, requires identity pseudonyms at input with the base generator. Only self-braiding can reset braiding to prevent accidental resets by external actors.

Here are some screenshots with how the termination and braid reset is exposed: