Hey guys can someone explain how a scenario like this would work.
Suppose I want to purchase alcohol from an online website. I want to prove that I am 21. I upload my id to an enigma based verification app. The verification app confirms my age, reports it to the alcohol website and I can purchase alcohol.
My questions are:
Who verifies that id? If it’s a 3rd party app that verifies, that means they will have access to the data on my id?
How do they know it’s not a fake id?
How do they know that when I log in to purchase the wine, it will always be me purchasing and not somenone else using my id?
Hi @Cryptojoe – good question. There are a few ways this works currently (there is no determination about how it should be done specifically in Enigma, it would be up do the dApp developer / implementer).
This is generally called a “verifiable claim” in the DID specifications.
Whoever creates the dApp (in this case, let’s say the wine-seller) must decide what types of verifiable claims they accept. For example, they may say “only claims signed by the city”.
The burden of proof is on the signer of the claim. They can say “i will only sign this claim if you come in person, show me an ID, I call both your parents and the hospital you were born at, and then I carbon date your skeleton”. This would be a very trustworthy, if invasive, signed verifiable claim.
This is tricky-- it could be someone else at the computer, but that person would then have access to your private key. I guess this would be like having your ID stolen by someone who looks very similar to you. Mitigations could include requiring a signature renewed within a certain time-frame, either by owner or by claim verifier.
Let me know if I can give more info! Signed verification doesn’t have a clearly defined general specification yet, but I believe a general answer to your question is: it depends on what entity the dApp developer is willing to trust (and whether that entity is willing to create a signed verifiable claim about you).
Thank you for your reply. Basically is the case of an id, there still needs to be a centralized entity that verifies and confirms my identification. Once that has been done, no one else needs to see my identification by using enigma protocol to share the confirmation.
That’s correct. However you can also check out a POC we’re working on with Datawallet for Sybil prevention. The basic idea here is that users are able to submit facebook data to a secret contract which runs an algorithm intended to estimate likelihood that the user is a bot, and return that prediction & confidence level. This is a more decentralized way (tho bootstrapped w/ existing data) but doesn’t require any centralized entity to see the unencrypted facebook data. It depends on what type of attestations a dApp is willing to accept.
Thank you again. This also assumes that Facebook data is accurate. Some people use fictitious names etc, so the level of security for a dapp that will accept this will be pretty low. For high security situations, we will still need third party verification right?
I don’t believe entities like DMV or governments currently have the incentive to attest for our IDs in a decentralized way. The uPort - Zug pilot is very exciting but to my knowledge it’s scope and reach is very limited.
As you said, there will be different levels of requirements for different dApps. What I like about this pilot is that the user can initiate the validation process using existing data. The secret contract datawallet is developing cannot (to my knowledge) identify fictitious names but can identify human activity. I believe that would be good enough to prevent sybil attacks say during an airdrop