Re: Some Burning Questions on Decentralized Identity/Self-Sovereign Identity - Please help? -- Nathan Aw from Singapore

Hi Stephen, Mike and Daniel, thank you very, very much for chiming in.

Its a lot for me to digest and understand so thanks very much for being so
helpful. Appreciate it.

I truly, truly believe with all my heart that a pan ASEAN decentralized
identity platform could be a reality in the next 5 to 10 years so I am keen
to be part of this revolution.

Nathan Aw

On Fri, 16 Nov 2018, 04:02 Daniel Hardman <daniel.hardman@evernym.com wrote:

> 1. Understand that Indy Node maintains a public permissioned distributed
>> ledger and arrives at consensus via RBFT. In this ledger (rocksDB), it
>> contains the transaction logs which are connection requests/proof request
>> correct? Key-value store.
>>
>
> The ledger does use RocksDB for persistence.
>
> Connection requests and proof requests are NOT stored on the ledger --
> they are just messages between two parties. Schemas (a description of the
> fields that belong in a particular type of credential) and Credential
> Definitions (an announcement of intent by a particular org to publish
> credentials with a given schema and revocation strategy) ARE on the ledger.
>
> 2. Other than a trust anchor, what could be the reason (i.e., incentives)
>> for one to run a validator node? In short, why should anyone run a indy
>> validator node?
>>
>
> Most people and orgs shouldn't. It's like asking the question, "Why should
> someone run an ATM?" Answer: most of us never even consider doing that,
> because we can use an ATM to interact with our bank without ever running
> one ourselves.
>
> The network doesn't *want* lots of orgs to run nodes right now. 50 or 100,
> maybe. 1000? Probably not. It would bog down consensus.
>
> Organizations that want to do go for the world, want the reputation
> benefit, or want faster-than-average access to the ledger could consider
> running a node. If you are interested in running a node in an indy network
> of your own making, you can do it without any help. If you are interested
> in running a node on Sovrin (a governed instance of Indy), contact the
> Sovrin Qualification Committee or support@sovrin.org.
>
> 3. Since RBFT is the chosen consensus mechanism, what happens when more
>> than 1/3 of the nodes turn malicious? Highly unlikely of course but
>> assuming these nodes start to collude, etc, will the network come to a
>> screeching halt? i.e., one is unable to issue claims, verify claims, etc
>>
>
> The number of nodes on the network = 3F+1.
>
> When F+1 nodes are malicious, then consensus can be blocked. This could
> prevent new transactions from being written. Meanwhile, the other 2/3 of
> the network would be screaming about the blockage in their logs, and the
> whole world would know about the attack. The remediation would be to
> disable the offending nodes.
>
> When 2F+1 nodes are malicious, then the malicious nodes can force
> consensus according to rules other than the ones the network chose.
> Meanwhile, the other 1/3 of the network would be screaming about the
> misbehavior in their logs, and the whole world would know about the attack.
> The remediation would be to disable the offending nodes.
>
> When 3F+1 nodes (100% of nodes) are malicious, then it becomes possible to
> silently subvert the network, and to rewrite history, without anybody
> noticing.
>
> 4. I like to explore a pan ASEAN decentralized identity solution where
>> one's identity could be portable across the different ASEAN countries -- my
>> driver license registered in Singapore can be used in Indonesia, for
>> example. Can I assume that I need a Indy validator node in Indonesia as
>> well? What are the technical setup required for a pan ASEAN/supra nation
>> setup?
>>
>
> The short answer is: you don't need a node in a given country to be able
> to create identities there. You just need to be able to reliably reach
> nodes from that country using TCP connections.
>
> The slightly longer answer is that it would be desirable to have a node
> nearby any significant sources of network usage, for performance reasons.
> However, even with a "local" node, the advantage is only mild. This is
> because clients of the network always have to talk to multiple nodes, not
> just the nearest one. This is required because if the local node is
> malicious, clients need to not be subverted by it. They do this by talking
> to multiple nodes at the same time.
>
> If you are interested in running a node, I strongly recommend that you
> contact Sovrin. It is the only production instance of Indy in the world,
> and joining is free. They have a procedure, onboarding instructions,
> support people, and so forth. Setting up a new and independent network of
> your own, in production, is a substantial undertaking that may need legal
> consultation and many other types of expertise besides just what you can
> get from a short Q&A on a chat channel.
>
>
>> 5. Understand that privacy risk is mitigated through the use of unique
>> pairwise DIDs with different trust anchors. pseudonym, that is. This is
>> achieved through ed25519 cryptographic primitive. Is this idea/concept
>> similar to public key private key relationship? Sort of mathematical
>> relationship? Lastly, Is ed25519 quantum resistance?
>>
>
> Ed25519 keypairs are technically called signing keys and verfiication
> keys. Signing keys are private keys; verification keys are public keys.
> There is a transformation of Ed25519 keys that we do seamlessly for certain
> operations that makes them more similar to classic public/private key
> pairs; this is a subtlety that crypto experts can comment on.
>
> To my knowledge, no elliptic curves are inherently quantum resistant.
> However, certain operations that involve elliptic curves might be. Indy
> will have to be upgraded when QR becomes a requirement. The good news is
> that Indy has been thinking about this for a while, There is some
> experimentation happening on plugging in different crypto algorithms. The
> algorithms being plugged in in these experiments are not quantum
> resistant--but the abstractions that are being developed will allow a QR
> algorithm to be plugged into the same fixtures.
>