DApp specific HumanID
Last updated
Last updated
The personal data represented in zkKYC provides the basis for self sovereign identity (SSI) on the Galactica blockchain. It allows to combine the pseudonymous nature of wallet addresses with personal identities. So Galactica can support uses cases, such as human based DAO voting (instead of token based) and negative reputation.
The concept is based on the idea to assign each human a unique id, the HumanID. This id is derived from personal data in the zkKYC: The name, date of birth and citizenship. Thus even when creating another zkKYC with another Guardian Node, the HumanID derived from it will be the same. Also when using another blockchain wallet, the id of a user stays the same. It is as hard to change as the personal details it is based upon.
Because a unique id for a human is prone to being tracked online, Galactica uses a DApp specific HumanID instead. The id is a hash of the personal details combined with the DApp address it is used for. So users receive different ids for every DApp they interact with. If this is combined with using different wallet addresses, no one besides the user him/herself can track the on-chain activity across DApps.
See Privacy Precautionsfor more details on how to prevent tracking effectively.
To prevent guessing the HumanID, it also contains a salt. By default the salt is derived from a secret signature of the user's EdDSA key holding the zkKYC. The hash of it is the Holder Commitmentand registered on-chain for the hash of the user's name, birthday and citizenship. This is implemented in the and limits each user to one salt and and therefore one unique HumanID for each DApp.
Users can generate and provide their DApp specific Human ID in a ZKP about their zkKYC. A smart contract can verify it on-chain. The personal details making up the HumanID stay private. DApps can then use the HumanID for reputation scores, voting etc.
If required, it is also possible to prove the connection between HumanIDs on different DApps. By combining multiple ZKPs into one, the user can prove which human IDs belong to him for different DApps by providing them in public ZKP inputs.
The following diagram shows the registration process that limits the user to a single salt. When issuing a new zkKYC, the zkKYC registry checks with the HumanIDSaltRegistry if there is a different salt hash registered. In this case, the user has to switch to the same account that was used to derive the previous holder commitment. In the unfortunate case that a user lost his previous holder account, the salt registry has a reset function. It can be called by whitelisted guardians and requires that all zkKYCs previously registered for that holder commitment were made invalid by expiration, revocation or de-listing the guardian that issued it.
