Is it a good idea to make the PeopleObject replaceable private key

[waterflier]

Scenes：
An managed PeopleObject is migrated to an normal PeopleObject. If the private key replacement is supported, then all cyfs:// created by managed PeopleObject do not need to be changed.

Implementation idea:
There should be a field in the PeopleObject, indicating whether to support private key changes (not supported by default), which can reduce the query pressure of the chain.

The modification of the Private Key of PeopleObject must be an TX on the chain, which is directly supported by Meta Chain.

What do you think? Have a better idea?

[lurenpluto]

I think it can be considered from several directions

1. Under what circumstances do Someone need to change the private key? Generally, it should be that the current private key has been leaked, or there is a risk of possible exposure (it has been hosted by the service provider, eg). This situation is relatively common. In order to solve this problem, a mechanism for changing the private key needs to be provided. But if the private key is not exposed, is it a complete waste to change the private key, Or is there some kind of special case need?

2. What does the private key represent?
   According to the current design, for a People object with a single private key, the private key is the only proof of the "owner" of the people. In addition, there should be no better way to prove that a People object belongs to someone, or it has belonged to someone for a while; so combined with the above point in 1, when the private key is exposed, there are potentially multiple "owners" of the People object. In theory, these "owners" are equal. If The "true owner" has the right to change the private key, so "other owners" should have the same right to change it

3. Changes in case of private key leaked
   The change of the private key of the People object should be that only the "owner" of the People object has the right to change it. As mentioned in 2, at the time of the leak, the People object changed from a "single owner" to a "multi owner". This change also becomes unreliable

So I think it is contradictory for People to only use the current private key to "change the private key" in the case of a single private key design and when the private key is exposed. It may be necessary to introduce other identification mechanisms to change the private key. It is to prove that the initiator of the change operation is the "true owner" of People

[wugren]

The owner of the ood can be an organization, and the members in the organization support changes. There can be multiple members or only one member