Dim, не уверен, что формирование допуска с помощью подписания ключей пользователя специальными ключами, это хорошая идея. Т.к. она не очень гибкая. Проблема возникает когда нужно забрать доступ. Можно, конечно, отозвать ключ, но это долго (пока отзыв распространится по сети). И, кстати, не уверен что после отзыва подписи этот ключ можно будет снова ею-же подписать.

Кроме того, кто именно будет заниматься таким подписанием и отзывом?

Просто системе надо дать систему формальных признаков по которой она будет знать кто участвует в субъекте, а кто нет. Мы говорим о том что участники субъекта могут создать набор правил участия в субъекте. Вот только следить за соблюдением этих правил должна система голосований.
Надеюсь достаточно ясно выразился?

это обнаружится на клиентах других голосующих и у них его голос просто не учтется.

Вот про них то и толкую. По каким признакам они это будут решать? Составить список субъекта, и подписать его всеми участниками? Тогда как его затем менять?

Вот про них то и толкую. По каким признакам они это будут решать? Составить список субъекта, и подписать его всеми участниками? Тогда как его затем менять?

Менять той же процедурой голосования.

Именно. Но только, конечно, не сам список участников субъекта (хотя, возможен и такой вариант), а набор фильтров, которыми будет определяться участники.

Итак, имеем фильтр работающий по списку признаков(свойст) и подписанный всеми (или некоторым большинством?) участниками субъекта. И имеем список признаков привязанный к аккаунту и подписанный...
Кем подписанный?

Андрей, заговорили о графах и пришла мысль использовать как критерий минимальное количество не пересекающихся путей в графе представляющем связность доверия в группе.