Server-initiated removal

[bifurcation]

Long-term inactive users undermine the FS and PCS properties of the protocol. Obviously, users can remove each other if they notice that a participant is inactive. We should consider whether we want to allow the server to do such a removal.

[bifurcation]

Discussion at interim 2019-01:

• Could do this as "server-instructed" vs. "server done"
  • i.e., server instructs a client to do a remove
  • But this causes some ambiguity w.r.t. the rest of the group
• The only difference between Remove and a server-initiated variant would be signature
• Other use cases:
  • User deletes account
  • User is no longer authorized to be in group
• Application would need to set policy about whether / when server-initiated actions would be allowed

[bifurcation]

I'm assigning this to draft-04 under the theory that the signature changes that will come about as a result of #101 will make it straightforward to have an additional key for the server that can be used to sign Adds / Removes. If that doesn't turn out to be the case, this might get deferred.

[bifurcation]

After discussion with @beurdouche and @raphaelrobert:

• There will be a need to signal that a non-member key is being used, e.g., with some reserved sender values
• Do the participants in the group need to agree the set of allowed non-member signers? If some members accept a signer, others don't, then you can get partition
• -04 will focus on Remove, not Add, and punt on the agreement question; we assume the application maintains consistency of the view of authorized signers.

[raphaelrobert]

We should push some of this to the application layer in order to not introduce a new handshake message with problematic authenticity (agreement on the list of non-members who can sign handshake messages).

The server could publish an "intent to remove" that will be honored by the first client to come online.
The actual Remove HS message will be issued by a member of the group. It can additionally be attached to the server intent to remove, so that clients can convey more contextual information to users.

Example:

• Server issues the intent to remove Alice from the group.
• Bob comes online first after that and send a regular Remove HS message to remove Alice and links it to the sever intent.
• Other members of the group can now display "Alice was removed" instead of "Bob removed Alice" to the user.

In this example Bob is the first member to come online, but it could really be any other member.

This has the advantage that the protocol remains unaffected as such, while the desired behavior is still achieved.