Trust

Solving Privacy: Zero-Knowledge-Proof to the rescue

By Creepto | Creepto on Crypto | 5 Feb 2020


TL;DR: There's a way to prove your identity without going through an long KYC process with every service provider.

Note: In this post, I'll do my best avoid diving too deep into cryptography, math, and actual research. Where possible, I'll mention researchers and papers that I liked. Google Scholar (or equivalent) will easily get you to the source material.

Problem introduction

In the first 2 parts, we've introduced the issue of privacy: why it's essential, and how it's being violated by the services we'd like to use.
The extreme cases we've encountered had to do with "modern" services requiring you to jump through KYC/AML loops, to prove who you are, while "traditional" services are still content to serve you without knowing your blood type.

Part 1: KYC/AML is off the rail
Part 2: Privacy - It's a right, not a privilege

The solution: ZKP

Let's introduce the premise for a solution. It relies on a cryptographic scheme called Zero Knowledge Proof (or ZKP for short).
Suggested in 1985 by (Goldwasser, Micali, Rackoff [1985]), ZKP is "an elegant technique to limit the amount of information transferred from prover A to a verifier B, in a cryptographic protocol."
In (Feige, Fiat, Shamir [Journal of Cryptography June 1988]) ZKP was extended into Zero Knowledge Proof of Identity, where prover A can now prove his identity to verifier B, without reveling any detail of his real identity.

If you are interested in the computer science behind this amazing concept, watch Silvio Micali introduce his idea:

The Players

Player 1: the customer

So far we met 2 entities: a prover ("the customer") who wants to prove his identity to the verifier ("the service provider").
The customer has many PII (personally identifiable items) that can help verify his identity: his real name, his physical address, phone number/s, email/s, photos, a government-issued ID, other verifiable entities who know him (banks, credit reporting agencies, employers, schools, etc.).
One or two of those PII can be faked, stolen, etc., but the more PII the prover provides, the closer we are to a 100% identification.

Player 2: the service provider

If the customer wants to use the service, the service provider needs (or is required by law) to know who is he dealing with.
But let's look at that for a second: does the service provider really needs to know the customer's real name? Where he went to school? Is his drivers license valid?

If the service needs to send you physical documents, it will need your real name and address. If it intends to send you texts, it will need your phone number. If your username is tied to your email, you'll need to verify you have a valid one, so you can log in, or retrieve your password.
If you're asking for a loan, the service needs to verify you're gainfully employed, and that you have collateral.

The point is: the service needs some PII to prove you identity, and satisfy its needs, but not all PII (or more than what it needs). There should be a way you can limit what you share with a service, while still providing enough PII that can get you served.

A verifying authority

Before we introduce a 3rd player, let's do a little exercise: look to the left of the URL in your browser's address bar. See that little lock icon? It verifies that your connection to publish0x is secure.

Browser security lock

But who verifies it? Click the Certificate line:

Certificate Authority

We now see there's a third party involved here: the Certificate Authority (or CA).

A CA is a "trusted entity that manages and issues security certificates and public keys that are used for secure communication in a public network" (read more on Technopedia). So we trust the CA (in this case, Let's Encrypt - a free CA - give it a shot if you're a developer) to verify that publish0x is indeed providing a secure connection.

Obviously your bank will use a paid CA, and so would any other service dealing with funds. The more respected the CA is, the more verification and hoops they make you jump through, to verify your company's ID, and therefore the more expensive they are (I recently had to go through a Symantec verification for a business - not fun, but necessary.)

Player 3: The Identity Verifying Authority (IVA)

The IVA can ask for any PII it deems necessary to verify the customer's ID, to a high degree (lets say 90% accuracy). Once they have that, they issue a DID (a distributed ID) that identifies the customer on the network. The customer can now use his DID with any service that uses the network for identification, and the service can be sure that whoever he's talking to is that customer (at least 90% sure).

Let's look at some usage scenarios - some are simple, but some are quite complicated.

Scenario 1: using a new blog service

Alice wants to use a new blogging platform she heard about, that pays out in crypto for blogging.

  • Alice: Hi blog platform! I'd like to use your services!
  • Service: Hi Alice! We use IVA t verify identities, and get the details we need from you. This link will get you started.
  • Alice: clicks link, gets to IVA with the info needed encoded in the link.
  • IVA: Hi Alice! If you've used our services before, log in with your private key. If not, let's start creating your DID.
    • The service provider who sent us here requires, at the minimum, a valid email, a verified crypto wallet address, and a real name.
    • Please provide the email and wallet address. We'll send you a unique code to both to verify.
    • As for the real name, please upload a picture of a government ID through this app.
    • Verification takes 10 minutes, but the good thing is, you'll only ever need to do it once. And no one will ever see your government ID but our verification service.
  • Alice: verifies both addresses, provides photo of driver's license. Get's a link back to service.
  • Alice: hi service, I'm back! And I have a brand new DID.
  • Service: Cool! We asked IVA to provide us with you name, email and wallet address. Are you OK with that?
  • Alice: Yes, and here's my key verifying this.
  • Service: Hi IVA, we have a certificate request here from Alice, allowing us to get her real name, email and wallet address.
  • IVA: we checked Alice's signature, and here's the info you need, encrypted, of course.
  • Service: Welcome to our blogging service Alice! We sent you a welcome email, and a small welcome gift to your wallet!

Looks like a lot of traffic going on, right? No worries, in reality, it's mostly automated, handled by apps talking to each other. And while the initial verification process might be a bit of a pain, you won't need to go through it again (unless your PII changes in real life).

Let's look at a much more complex scenario:

Scenario 2: let's get a loan

Suppose Alice wants to get a loan from Bank of the Future. Both are using a known IVA and network, that is used by millions of other satisfied customers and services. A digital dialogue between the entities might look like this:

  • Alice: Hi BoF, I need a $1000 loan. I'm Alice, btw.
  • BoF: Hi Alice! Nice to meet you! We use IVA to verify our customers. Here's a link that will get you started.
  • Alice: clicks the link, get's to IVA site with a special link.
  • IVA: Hi Alice! If you've used our service before, please log in with you secure private key.
    • Oh hey, you've been here before, so we know it's you, and we have your name and email.
    • The bank also requested a proof of current employment, and a bank statement. Could you please upload those?
    • As a feature of our network, you can specify how long will the bank have access to these documents, so they won't be able to build a database of users' data. It might take 3 days to verify your docs.
  • Alice: uploads letter from her current employer, and a current bank statement.
  • IVA: Hi Alice. We've verified with your bank and employer. You're good to go, here's a link.
  • Alice: hi BoF, I'm back! You may have access to my real name and email, and access to my current employer and bank statement for the next week.
  • BoF: Hi IVA, we have a certificate request from Alice, allowing us to get her name and email, and a week access to her current employment and bank statement.
  • IVA: signature checked. Here's the info you need. Remember! A week from now, some of the info evaporates, and you'll have to request it again!
  • BoF: Hi Alice. We verified all we need. We'd be glad to issue you a $1000 loan, to be sent to your specified bank account.

This was way more complicated, and took longer than the first scenario - as it should. Financial transactions will always need more validation than social ones. 

Let's look at the third, and final scenario: employment.

Scenario 3: seeking employment

Who of us hasn't gone through an annoying job search process. Contacting a potential new employer, and having to provide a myriad of details: resume, list of schools we attended, list of previous employers (trying to avoid the current one, so it won't get back to him before we're ready) - all just to get past the screener and to the actual interview. And then, years later, someone from that company contacts you again about another role. Yep, they kept everything in their ATS (applicant tracking system), and they see it as their data now.
Some of those employers actually have you type the data into their ATS on your own (next time you fill an online form for a company, and attach a PDF, know where it's ending up).

What if instead, the process went like this:

  • Alice: Hi company! I saw this link to a role on your "careers" page. I'm more than qualified!
  • Company: Hi Alice! We'll need some information about you to start the process. Here's a link to our IVA.
  • Alice: clicks link. It's an IVA she used before, so she just logs in.
  • IVA: Hi Alice! Company asked us to get your real name, email, current resume, schools you attended, and list of previous employers.
    • We see we have some of the info we need, but we will ask you to upload a resume.
    • We will then attempt to verify your schools, places of employment etc.
    • For institutions that have opted into our network, verification will be instantaneous.
    • Otherwise, it may take a week or 2 to corroborate each claim.
  • IVA: Hi Alice, we've verified all your schools, and your last 2 employers. Still working on the previous ones. You can start sharing with Company whenever you like, and more details will be fleshed in as we verify them. As always, you can decide which of your details to share, and for how long. Here's your share link.
  • Alice: Hi Company! I just verified all my data.
    • You can access all my schools, and my last 2 employers.
    • I elected to hide my current employer, and may share it with you later, as our process progresses.
    • Please note that all my information will disappear from your servers in 2 weeks.
    • Let me know if you need more time, or any further details.
  • Company: Thanks Alice. We received your application. A coordinator would contact you to arrange a video call!

FAQ

1. Wait a second. Didn't Alice have to provide tons of PII in these scenarios?

Remember the old New Yorker cartoon? 

On the internet, no one knows you're a dog

Yes. Alice needed to provide PII to the Identity Verification Authority. But then again, someone has to identify you somewhere. Better that it's an intermediary, trusted by your bank, your utilities, colleges, etc., than to have to repeat the identification process with every one of those separately.

2. This all sounds so futuristic. It would never work.

It's actually already working. Here an incomplete list of services that pertain to be the next Identity Verifiers as-a-service:

  • uPort - allowing you to log into sites, providing zero-knowledge to the actual site.
  • Civic - focuses on payment scenarios, but not just. Supported by a crypto token.
  • Sovrin - look at their use cases.
  • Workday - specifically for scenario 3.

3. What if I don't trust those IVAs?

Then feel free to roll your own Identity network. HyperLedger Indy is an open source project, providing the technologies you need to establish a blockchain that serves digital IDs. Even Sovrin uses Indy for their blockchain. It's all a matter of network effect, which brings us to question 4:

4. But my college/bank/workplace does not work with any IVAs?

You may be too young to remember the '90s. The internet was an empty wilderness, with very few businesses, and tons of bizarre web pages with blinking texts. Little by little, business started realizing that this is the new frontier, and that's where future money is coming from. And then the stampede started. Even the most backwards-thinking bank found out that if it doesn't have any web presence, it'd would find itself with no customers. And here we are today: everyone is on. Because users demanded it.

Identity networks are in the same place: they are needed, they are wanted by the customers (who are aware of it), and slowly but surely, services start joining. All it takes is a major bank to announce that they accept uPort logins, for example, or a large employer saying that you can apply with Workday Credentials, and the race to join would start.

5. What can I do to help?

First, educate yourself. Follow the links I provided, and find more. Next, see if you, your employer, or your service provider can join the Distributed Identity Foundation. They are trying to push all DID technologies forward. Third, be aware that a lot of people are working on a lot of solution in the identity space. These are exciting times, and you may be lucky enough to take part in the development, implementation, testing and early use of these technologies.

Summary

Over the last 3 posts, I've described how corporations mistreat our privacy, and how even we take it for granted. We also reviewed the potential solution to both problems: how to keep our PII safe, and how to still partake in services that need some information to operate.

I hope you've enjoyed this short series. I'll gladly expand on any issue you'd be interested in. Please let me know your opinion in the comments. I would also very much appreciate your opinions, corrections, and suggestion for future posts.

Stay safe!

How do you rate this article?


32

0

Creepto
Creepto

I'm a developer and technologist, and have tried every framework and gadget at least once. I used to blog religiously and am hoping to find my way back to writing. My current passion is getting "laypeople" to appreciate and use crypto products.


Creepto on Crypto
Creepto on Crypto

Detailing the adventures of a techie into the wonderful and terrifying world of crypto products. Let's explore exchanges, staking, interest earning, and smart contracts together.

Send a $0.01 microtip in crypto to the author, and earn yourself as you read!

20% to author / 80% to me.
We pay the tips from our rewards pool.