Yes it does. Not fully trustlessly, but trust (in ZKorum) is still minimized. For the email-based functionality: - 1 community email address (= "uid") = 1 community credential issued by ZKorum. For the external community credential (e.g,: issued by your college or company): - your credential's unique college/company ID ("uid") can only be registered to one unique ZKorum account. You'd generate a proof with a deterministic pseudonym (Pedersen commitment) based on your "uid" attribute when associating the credential to your User Profile. Note that the User Profile is unlinkable with the user posts. For both use-cases: - One and only one "timebound" Secret Credential is issued to each user. Each poll expects a pseudonym generated from {scope+secret+uid}. Scope is a public value that's specific to each poll. "secret" is an attribute of the Secret Credential, and "uid" is an attribute of the community credential. Both are unique per user. A unique set {scope+secret+uid} deterministically generates the same pseudonym. So there is only one pseudonym per user per poll. That's how the server counts results to a poll. Note that knowledge of a pseudonym does not give knowledge of "secret" or "uid". And "secret" is only known by the user's device, so even the Issuer that knows "uid" cannot know who's behind the pseudonym. That's why it's anonymous, with privacy in the hand of the user. So long as the "secret" remains private in the user's device, anonymity is guaranteed, even when the proof is made public. - in case of revocation of "timebound" Secret credential on recovery when the user devices are lost, the user cannot respond to polls that were created before the recovery was initiated. That's because the user lost the unique "secret" attribute together with the credential, so the user's new "timebound" Secret Credential won't hold the same "secret" as attribute. This mechanism prevents malicious users from responding multiple times to the same poll after they recovered their account. That's why there are two "Secret Credential" per user: the "timebound" is only used for responding to polls or votes, and the "unbound" is used for everything else. The "unbound" Secret Credential is not subject to this condition on recovery. Feel free to join our Discord community if you have more questions.

So, I listened about 20 minutes or so. Sorry, it's not a business thing, it is technology thing. I still don't fully understand what SSI is, but apparently it's like when we get identified online by our bank sign up process, and then get to do all kind of stuff, like taxes and wellfare applications or change adresses online 😅 Like that, but just an identification tool and nothing else? About things being or not being useful if they don't get implemented in practice: I think history (and life) shows that we need to have pre-waves before the breakthrough. So sometimes, new things are forgotton in the history, but make way to next wave, that will change everything. And that change can't come without the preparation, which will seem like was in vain. I think it's how humans and humankind works on this part. Aah, anyway, I hope you get what you are working towards, not sure if I support the idea, or even understand it, but I wouldn't wish a failure to someone trying to make world work better.

I'm looking into probably using MACI to safeguard against censorship of key events

@@OliverHirstsLife what is MACI? google doesn't give anything relevant

That's a good question. Been wondering about it as well. Didn't see the direct answer, but have some guesses. A bit of context first. Embracing non-extractable keys (keys that can't be shared, stay on your device) would limit the damage done by having device lost (key exposed).This way there seem to be no need for "rotation". Device got comporimesed - unlink it / revoke the key. Sam showed how one can create identity with multiple keys from the start. Additionally one could authorize other devices as they acquire them. This way management of identity becomes decentralized, across your linked diveces. In another vid Sam showed that one can set up complex rules on how management of linked devices works. E.g., require 2 out of 4 linked devices to authorize removal of a device. This way, when device gets lots, you can revoke from your other devices. And malicious guy that got ahold of your device can't do that (2 authzorazations are required, he got only 1). Ookay, that's been a bit lengthy.:) Now onto your question. One can revoke authZ of a lost decive. But the malicious guy may not wish to adopt it as part of device's log. So how could a party that contacts a device be sure that its authZ hasn't been revoked? One way would be to have the log replicated in a publicly-known place. E.g., Doug. This may not be best as you would need to trust Doug. Although if you would communicate with Doug and others who communicate with Doug you would have a DAG and it'll be easy to detect duplicity. Yet Doug is not incentivized. He would be doing it for "public good". As an alternative, perhaps, you could define your "friends" (their DIDs), this way you'd be helping each other. At around 1:22:0 Sam showed how peers can back each other, interlinking logs, forming a DAG. Alternatively, third-party could contact many of your devices to get the latest version of your identity log. Contacting many devices and/or friends seems good in that it's grassroots - local-first, independent, all you need is p2p. Let me know any concerns of the approaches.

There are so many at this point

Yes, you are correct that he misspoke.

@@jopucayjopucay7612 the reason of key rotation is when user lost the control of current private key. or hacker stole the private key. the process of key rotation here is using stolen private key to sign the new DIDDocument? then attacker can sign that too with his own public key.

It's more like a mirror node. That I think is meant to hold _disjoined_ logs. And yeah, having such "public good" service raises questions. A more grassroots/p2p alternative would be nice.

It is stored in a ledger as a DID. And the ledger is distributed so it is not centralized.

By checking a revocation services which is also connect to the DLT. On creation you list your credential expiration in the service.