Purpose-built for privacy: How zPass architecture & participants create a more secure web
zPass is a novel technology that makes it easier and safer to share your data online. Built on the Aleo blockchain, our solution prioritizes user privacy and data security using advanced zero-knowledge (ZK) cryptography to enable decentralized identity verification.
Our lives operate on systems of trust, whether we fully realize it or not.
You can drive to the grocery store because your local government has issued you a driver’s license that verifies you can be trusted as a safe driver.
You can work at a job because an academic or industry institution issued you a certification that verifies you are qualified to do that job.
These systems of trust rely on three key actors. The holder of the credentials: you. The qualified authority that gives you the credential: the Issuer. And, lastly, the Verifier, the individual or organization tasked with approving your credentials, whether it’s a police officer checking your driver’s license or a new employer checking your academic degree.
In practice, most of these trust systems are conducted by physically presenting your verified physical documents directly to the person looking to prove them. However, that process unnecessarily exposes information above and beyond what is required to verify you.
For example, if you go to a nightclub that serves alcohol, you must be above a certain age. However, when you show the bouncer your driver’s license, you don’t just reveal that you are over 21 — you reveal your exact age and birthdate, your home address, and extraneous details like your height and eye color.
The same is often the case when you access services online. Some sites ask for your credit card information when trying to prove you’re an adult, unnecessarily exposing you to financial fraud.
Others may ask for a full credit report when trying to prove you qualify for financial services, revealing your credit details when all they really need to know is whether your credit score meets the required threshold.
In this piece, we’ll explore how zPass combines off-chain and on-chain workflows to verify identity online safely and securely.
How the zPass architecture works
In most current online identity verification systems, people must upload their private documents onto the web to access services. Once they do so, they have little to no control over how that data is used, shared, or, in many cases, compromised by its entrusted institutions. In other words, their data is exposed.
With zPass, you, the holder of your private documents, can upload them on your private device or server first. Then, you can create a “proof” that validates what you are saying is true without revealing the actual documents themselves or any other extraneous information about you. That proof can then be passed onto the Verifier, who confirms that you have met their verification requirements. The Verifier can do all this without seeing and storing your personal data.
Who are the System Participants on zPass?
Like in the physical world, three major participants work together on zPass to provide proof and validate a user’s information online: the Holder, the Issuer, and the Verifier.
The Holder is the person whose identity or other claims are being verified.
You are the holder of…
Your work history
Your financial history
Your personal history
You hold these things as part of your identity, even if you may not hold physical proof of them.
You still have your name and age, even if you lose your driver’s license.
You still have earned your degree, even if your school holds your transcript.
You still have your financial history, even if you don’t have a bank statement.
The more the Holder can prove their claims without relying on others to provide proof, the more autonomy they have to decide who gets that information and who doesn’t.
When job hunting, you can present proof of your employment history and work references to an employer.
When visiting a doctor, you can quickly share your entire health history.
When applying for a loan, you can provide your full credit report.
As you may have already guessed, these documents are typically provided by …
The Issuer is a trusted authority that provides proof — typically in the form of an ID or other documents — that what you claim is true.
What the ID says matters. However, the authority of the Issuer is just as important.
Let’s say you call off work sick. Your employer asks for proof. If you provide a doctor’s note saying you have the flu, they will likely accept it. If you provide a note from your mother saying you have the flu, they likely won’t.
Why? Because your employer trusts the medical authority of a doctor but doesn’t trust the medical authority of your mother.
When hiring, an employer validates references to check your work history.
When administering treatment, doctors cross-check your medical history.
When admitting a student, colleges look into prior academic achievements.
All these actions hinge on the Verifier.
Their importance is based on their ability to validate information accurately and fairly. Verification is almost second nature in our everyday life (like the bouncer checking your driver’s license to ensure you’re old enough to enter the nightclub).
Traditional IDs often rely on being able to match physical cues to identity.
A police officer checks your physical appearance against your driver’s license photo to confirm your age and height.
A bank compares the physical signature on a check to records of past signatures to confirm the same person wrote it.
Visual cues are absent online. It’s harder to “show” proof in the digital realm. As deep fakes rise, making it easier to adopt and mimic identities, our standard identification methods are challenged even more.
And on the web, there's an additional challenge: How can a Verifier be certain that the digital credential hasn't been tampered with or falsified?
This is the value of building zero-knowledge proofs (ZKPs) on the privacy-focused Aleo blockchain.
Why using zPass on the Aleo blockchain improves safety and security
We can verify information online and who it came from with digital signatures. Think of them as evolved counterparts of your handwritten signature. When data comes with a digital signature, it's like an endorsed document in the real world.
When scrutinized and matched, that signature confirms both that the content is valid and that it is a credible source in a way that can’t be replicated or forged by anyone. Verifying these digital signatures with the Issuer’s public address ensures the data's truth and its trusted origin.
When holders generate their zPass from their documents privately, the signatures from the physical documents are verified before adding the credential data to the digital record on Aleo, confirming the origin of that information automatically for Verifiers. And because the blockchain is immutable, those transactions cannot be digitally altered or changed, meaning all parties can trust the data’s integrity.
From here, the zPass can be presented as a private input to a Verifier’s Aleo Program and used to prove claims. The Verifier does not need to worry whether or not it should trust the proof; for the proof to be issued, the signature and, therefore, the source and integrity of the data have already been authenticated. The Verifier only needs to focus on the claims it wants the credential holder to prove.
Through the process, zPass shows itself to be a trusted intermediary built on Aleo that allows all parties involved to have confidence in the integrity and security of the data they are sharing and verifying online.
Our blog features the stories of developer and privacy advocates building a better internet with zero knowledge.
About John Reynolds
John Reynolds is a Product Manager at Aleo, focusing on the strategy and development of identity solutions. Prior to Aleo, he was a Deployment Lead at Blend Labs supporting them through their IPO. John also held cybersecurity roles in the U.S. Air Force where he served as a Cyber Operations Officer.
For further information contact us at firstname.lastname@example.org