Protocol: implicit revocation

I continue on my roll with protocol changes.

Now this is about an existing rule I want to slightly change: identity revocation.

Today this rule doesn’t exist, so for example if you don’t renew your membership to the currency after 6 months being in, you are kicked. And 3 years later, you can still come back. Your certifications will be expired of course and you will have to find new ones, but still can join back with the same identity.

But this is causing me a security problem: what if you though you lost your key, created another identity, get the necessary certifications and join, and finally your previous identity key shows signs of life? (because someone stole it)

This gives you 2 identities, even if you might not control the first.

I think it would have been a good thing if the first identity had been considered revoked in the first place, by not being used. This would also help people in certification process by showing our previous identity indicating it is now revoked, thus won’t lead to a sybil account. This case already occured with meta_brouzouf, I think about Moul for example.

Any good reason for me not to implement this implicit revocation?

The rule would be simple: if an identity is not renewed at its expiracy date, is becomes revoked.

1 Like

The act of renew membership get more value here, as membership as well. That is good.
Software should not failed to alert about expiration date.
So let’s say my identity vit is revoked. What about my account linked to this identity. Can I use it.Can I create a new identity and link it to this same account ?

I don’t see why we have a membership document with such a rule. Publishing an identity should becomes the same as asking for membership.
Anyway, I think it’s too strict. Errors are human and here, errors become really annoying. When security makes a system annoying, people will circumvent it. The would use services to automate membership renewal, for example. And it becomes worse than before.
I like the idea, but it being instantaneous is too hard. Maybe, give it some time to renew, for example the same time as the expiration of a membership document.

1 Like

You can use the money on this account. But you cannot create another identity with this key, neither reuse the identity nor certify anyone. The WoT functions of the key becomes locked forever, for this currency.

Because we need to differenciate two messages:

  • this is my identity
  • I am alive & I want to be in with this identity

So, say you publish an identity: even if people certify you, your identity won’t be written unless you explicitely say to do so with a membership. It gives control to the user.

Even if we consider that sending an identity is equivalent to say “I want to be in”, how do you say “I am alive”?

Your answer is interesting, because you do not mention any time at all: for example, if membership validity is 1 year, it seems punishing to have the identity revoked after 1 year. But if validity is 6 months and implicit revocation occurs at 1 year, it seems OK.

Like if the real problem was to have a “2 steps” process, not something linked to time.

Well, when you publish your identity, you could explicitely say “here I am and I want to join the community !”
I feel that “I want to be in” is the same as “I am alive” if the membership document revokation means “I am dead”.
Also, how do you handle Memberships “OUT” documents ?

What do you mean in this sentence ?

I mean what I’ve said in my example:

Because, for a same duration (1 year expiracy), the second solution with two steps of 6 months each is OK to you, whereas the first solution with only 1 step of 1 year is not. Isn’t it?

Yes but membership OUT document does not mean “I am dead”: how could he send the document if he is dead?

I should rather say the membership IN document means “I want to be in”, which implies “I am alive”. Renewal is a way to say “I want to continue” implying “I am alive”. So when you don’t renew, the cause may either be:

  • I don’t want to continue
  • I am dead, so I cannot send the renewal

When written, other members cannot certify the identity anymore, which finally leads to the member be excluded by lacking of certifications. This process can be canceled at any moment by sending a RENEW.

Oh, ok, I get it. Yes 2 steps seems better. But we should not over complicate things. The parameters of the community should follow the KISS principle. We start here to have many expiration time for many different documents, I fear it will be hard to follow.

I don’t know, maybe it is hard for us because things are not really established, we change rules and also consider the potential ones.

Anyway, I don’t want to make things more complicated than needed, that’s why I also propose a rule removal here.

However, I felt like an identity control was a core liberty of users. Not only because one might want to have the control over its identity (because maybe for some reason, he cannot explicitely revoke it), but also for others who want to be sure that if they sign someone who already have an identity, the latter won’t come back from the dead and give the identity 2 accounts.

And I’ve no problem with the fact to say “implicit revocation occurs at twice the delay of membership expiracy”, without it being a parameter. :slightly_smiling:

1 Like

I think two steps system is better too.

Because if someone dies, the time before the WoT reflects it is shorter. So automatic expiration is more close to reality.
But as human, we make lot of errors, and having a second chance to renew when we realize we are out by mistake is a good thing.

But then, this rule should be clearly mentioned in the client alerts : “Your membership has expired ! But you can renew it before the ultimate revocation DATE”.

3 Likes

Yes. Being that humans are visually responsive, I feel that the client should alert users of multiple things:

  • Impending Membership Expiration : “Your membership is about to expire! (Expires DD Month YYYY) (Renew)” (Renew sends a Renew request to the network). (The DD Month YY format will satisfy users from the USA (we use MM/DD/YY) and those from elsewhere (who use DD/MM/YY)).
  • Low Identity Certification Count : “Your identity certification count is getting low! (Try to get more soon).” (e.g. The member has minimum certifications for membership; or, enough of their current certifications will expire within D days so they will no longer be a certified member.)
  • Low Member Certification Count : “Your outward certification count is getting low! (Make sure to certify new members).” (Perhaps the word certify redirects them to the certification guide.)

The feature is on the way to implementation.

https://github.com/ucoin-io/ucoin/issues/336

2 Likes