WebOfTrust
Multisig: establish new group with member as another group
Hey,
The current event schema assumes k is a list of public keys that are members of an identifier utilizing mutlisig feature -- simply a group. Creating another group that could involve the participation of the previous group is therefore not explicitly available.
Consider a such example:
group1 = { ... , k: [pubkey1, pubkey2, pubkey3] , ...}
Creating group2, where group2 consists of group1 and some additional identifier:
group2 = { ... , k: [pubkey1, pubkey2, pubkey3, pubkey4] , ...}
Such an approach imposes that groups are distinct from each other, particularly when group1 changes, i.e., rotates, group2 does not know group1 has changed.
Is there any other mechanism that enables group membership in another group I am missing?
The problem is that the top level group is only consuming one public key from each group member. So a group member could be a group but it would only contributed one key its zeroth key in its key list. So the security of a thresholded multi-sig of the group member has dimished security because only the decision of the controller of the first key in the group member’s group would actually matter. now a rotation could change who the first memeber controller is so there is some marginal utility to having a group member be another group. The way the code is written its actually could work that way. I suspect there would be some code that breaks but in general because the key list is a list the code just gets the zeroth element in the list and ignores the other ones if any. It doesn’t force it to be single sig by checking the length of the key list and raising an error if its more than 1.
If you truly wanted the full spectrum of security that have group members be groups then instead of a key list KERI events of group identifiers would have to support graphs of keys lists and have nested thresholds for satisfaction. This is really complicated and I doubt there are any use cases that really need such complexity.
Single layer multi-sig already provides an exponential increase in security over single sig. And fractionally weighted thresholded single layer multi-sig with AND clauses provides a type of multi-layer (each and clause is its own threshold). So I don’t see any significant use cases for nested group multi-sig that ANDed fractionally weighted multi-sig is not sufficient for.
Moreover if group members are delegated single sig identifiers but the delegator is multi-sig then you effectively have a nested group multi-sig at least for rotations because the delgator must approve rotations. So the most important security is around rotation authority and a delegated single-sig whose delegator is multi-sig can’t rotate without the delegator’s approval. So rotation authority using multi-sig delegators of delegated single-sig group members of some multi-sig identifier is essentially multi-level multi-sig. Signing authority is still only single level but we want signing authority to be more performant and scalable so the trade-offs for current KERI seem appropriate. If there is a compelling use case for adding mulit-layer multi-sig for signing (which would be extremely cumbersome from a UX perspective) then we could consider the feature. But without a compelling use case I see no reason to add such complexity.
There are several variations:
- A multi-sig AID controlled by a distributed group of members AIDS where each member AID is single-sig controlled by a single-sig set of keys i.e. one signing key and one rotating key.
- A multi-sig AID controlled by a non-distributed multi-sig group of keys.
- A multi-sig AID controlled by a distributed group of member AIDS where each member AID in turn is a multi-sig AID controlled by a distributed set of members AIDS each controlled by a single-sig set of keys.
- A multi-sig AID controlled by a distributed group of member AIDS where each member AID is controlled by a non-distributed multi-sig group of keys.
I am not sure of a good use case yet for 3. The other 3 use cases are much simpler and have known use cases.