ZeroKnowledge Proofs — The Basics
The last few years have seen a big jump in the use of ZeroKnowledge Proofs (ZKP), and rightly so, given the many benefits it offers over traditional cryptographic methods.
Let’s look at some different applications and scenarios where ZKPs are being implemented to give you an idea of their future potential and more importantly, to enthuse you to think of the different areas where they can be implemented.
But before that, a touch on the basics.
A Brief Explanation of ZeroKnowledge Proofs
At the most fundamental level, a ZeroKnowledge Proof (ZKP) is a cryptographic protocol where one entity can prove its identity to another entity without having to reveal the identifiable data of the transaction.
When you say that an entity has an identity, what you mean is that the entity has a series of claims that are used to uniquely identify it. Breaking it down further, we can say that this process comprises of two steps,

Creating a claim, where each claim is a subset that contributes to making an individual unique. Some examples of claims are date of birth, passport number, driver’s license, Social Security Number, or any other governmentID that belongs only to an entity and can be used solely to identify it.

Proving the claim — A means by which this claim is proven without the actual information.
So, you have two parties to the transaction — a prover and a verifier. The prover is the entity that is claiming while the verifier is the entity that wants to know whether the claim is authentic.
If you dig deeper here, you’ll notice that these claims are not information about the entity per se, rather it is a need for some proof of the prover’s claims. So, it is enough if the prover can send some data to the verifier to prove the claim without having to give the actual information.
Let’s understand this with an example. A prover wants to prove to a verifier that she is over 21 years old. In an interactive environment, she simply walks into a store and buys some alcohol. That’s enough for the verifier to know that she is over 21 years old without knowing her exact age.
Here, two entities are interacting directly, all that the prover has to do is perform a series of actions in front of the verifier to prove a claim.
But, what happens in a noninteractive environment?
The prover has to deliver claims in such a way that they can be verified independently by the verifier, and without sending the Personally Identifiable Information (PII) that can allow the verifier to “know” the prover.
At the most basic level, let’s say that the prover decides to electronically send (email/text/message) her age in the form of an algebraic equation, 7(x+3), where x is a positive integer. When the verifier solves the equation, the value can be anything, but more than 21. Regardless of the “x” value chosen by the verifier, it proves that she is over 21 years. Clearly, the prover has sent the values in such a way that she tells the verifier of her eligibility for the services offered without revealing her exact age.
But think about it for a moment. Just because she sends an equation, it doesn’t really mean she must be over 21 years. She can just be a smart 12yearold!
So, this brings up the need for another entity — someone of authority who can assert that the prover’s claims are right. In the above example, a parent or guardian can vouch that the girl is over 21 years, and it should suffice as the adult takes the responsibility for any legal action, if the girl is less than 21 years of age.
But what about reallife scenarios? Who takes the responsibility to back the claims of the prover?
An issuer.
So now, there are three entities to every claim.
 Issuer — An independent third party entity that collates the holder’s claims, verifies the same and creates an identity representation (a ZKP that validates the claims without giving PII)
 Holder — The entity that owns/makes the claims and wants to prove it. In our above example, the claim is that the holder is over 21 years old.
 Verifier — The entity that verifies the claim
In such a setup, every claim made by the holder is backed up by the issuer, and only the information that the verifier needs is sent to that entity. This way, the verifier knows that the ZKP is a valid one because it has been digitally signed by the issuer, an entity that is authorized to prove the claim.
Going back to our age example, the holder claims she is more than 21 years old. Her claim is validated by an issuer, which is, let’s say, the Department of Motor Vehicles (DMV). Since this issuer had generated the license, it has all the information needed to verify the age of the holder. So, it sends a credential that simply says that the holder is more than 21 years old.
The holder, in turn, sends this credential to the verifier. Now, the verifier sees the digital signature of the issuer and since this is a trustable source, the verifier accepts the holder’s claim and gives the holder access to its services.
Here’s how a ZKP would look:
As you can see, there are no specific details about the person and all that it does is verifies that the holder is over 21 years old using the “ageOver” field in the claim.
This idea can be extended across many fields, especially the ones that deal with sensitive information.
Affinidi provides building blocks for an open and interoperable SelfSovereign Identity ecosystem. Check out our developer portal for more information.