Privacy-Preserving Verification for Ticketing with Self Protocol

Devcon Improvement Proposals (DIPs)
1

Privacy-Preserving Verification for Ticketing with Self Protocol

Authors: Alexandra Solderer, Alexandra@self.xyz
Resources Required:Communication support, Tech support

:brain: What do you suggest?

We propose using Self, a ZK-powered identity protocol, to enable privacy-preserving verification of qualifications necessary for discounted Devconnect tickets.

Self helps Devconnect attendees:

  • Prove they are based in Argentina or the broader LatAm region to access region-based discounts
  • Prove they are under 18 to qualify for the Youth Tickets

Self is a privacy-first identity solution leveraging ZK to verify proof of humanity and key characteristics like age and country of residence (without disclosing sensitive information). Users verify only the information needed to claim their discount, and nothing more (e.g. confirming they are under 18 without sharing their actual date of birth.)

For people eligible for discounts such as the Youth or LATAM tickets, Self offers a smooth, secure way to claim their discount - without uploading personal documents or exposing sensitive data.

:dart: Motivation & Rationale

Benefits for Devconnect Attendees

  • No upload: no need to upload photos of personal documents that are stored by a third-party.
  • Minimal disclosure: only the required information is revealed.
  • User-controlled: individuals choose which attributes to verify and explicitly need to give consent

Benefits for Devconnect

  • Instant verification: verification happens in a matter of seconds on the user’s device using biometric passports or national IDs
  • No retention: personal data is neither stored by nor exposed to the third party ticketing platform, keeping sensitive information fully in the user’s control.

Self makes the ticketing experience faster, safer, and more inclusive by offering an additional way to safely verify eligibility for discounted Devconnect ticket discounts.

:hammer_and_wrench: Implementation

Self is already used by multiple partners, including Google Cloud, Velodrome, Farcaster, Talent Protocol, and Lemonade.social - each leveraging Self’s verification functionalities, e.g., proof of age or humanity.

We offer a lightweight, developer-friendly SDK that can be easily integrated into existing flows. Given that Devconnect already works with zkPassport, adding Self would be straightforward, while giving users more choice in how they verify, without compromising privacy or security.

:gear: Operational Requirements & Ownership

What’s needed to make this work at Devconnect?

  • Agreement on categories e.g., LATAM, Youth should be supported by Self based verification.
  • The integration point in the ticketing flow

The Self team is happy to support running this.

What other projects could this integrate with?
Event badges or poaps for anyone who verifies through Self?

:link: Links & Additional Information

https://x.com/SelfProtocol

4 Likes
2

Thanks for the idea - can you elaborate on how it is different to https://zkpassport.id ?

3

Hey ligi, thanks for asking. Wanna start by mentioning we worked with the zkpassport team in the past and we really like their work!

To me there are three main differences in our approach right now:

  • We have the widest support for countries (see our map for full coverage) because we implemented and put in production all the signature algorithms used by issuing authorities (RSA with all exponents and ECDSA with all curves, all hash functions). This includes support for some ID documents outside passports (EU ID cards, Singapore ID cards, and a few of them coming up before Devcon such as Aadhaar)
  • We’ve been audited by zksecurity and we used audited primitives implemented in circom, which have existed for the longest time and are used in production already in multiple projects. We really like Noir and its ease of use, but it doesn’t look like it’s ready for production-grade applications or audited yet (this is according to Aztec)
  • Experience with larger scale partnership (like with Google which we just announced) that forces us to improve the reliability in NFC scanning and accessibility above SOTA of other zk passport projects.
    Happy to answer any questions!
3 Likes
4

Hey everyone!

Just to straighten things up here a little, most of the points made by Florent regarding ZKPassport are moot. Let me care to explain:

  • Our support is as wide if not wider than Self. We support both passports and national IDs (mostly EU but some other countries across the world as well), and even residence permits. And it’s not like it’s hard to support one or the other, they are following the same standard (only the MRZ changes between the two, so the difference is trivial). We support all variations of RSA and ECDSA used by the different countries issuing electronic passports and ID cards, just like they do. Looking at the map shared by Florent (assuming it’s not outdated), there are multiple countries where their coverage is limited while our coverage is complete. Example: Nigeria where we cover all the variations of signature algorithms (with the unusual exponents for RSA). Same thing goes for Senegal, Austria, Turkey, Pakistan, Iran, Iraq and Zimbabwe
  • Regarding audit, our codebase will be audited before the end of the year, and so will Noir and Barretenberg (the current backend we use).
  • The integration mentioned by Florent with Google is not live yet, just announced. We have gone through a heavy load recently with the Aztec integration with thousands of users, from over 70 different countries, notably in Africa and South East Asia, but also elsewhere. After rapid improvements over the past few weeks, we now stand at a high success rate for both proof generation and NFC scans. We are working on making the NFC scanning as robust as possible to improve it even further, so our reliability is not so different. Note that this is not just a technical problem but also a UX one
  • One difference as well, is that we do everything client-side under 1GB of RAM, unlike Self who relies on using hosted TEEs to generate their proofs. We are committed to do actual mobile proving and truly keep the data of the user on their device only
  • And one last thing, ZKPassport is a fully credibly neutral project not attached to any specific ecosystem or token. Our goal is purely to provide a base layer for true private and verifiable digital identity

Happy to extend further and clarify any more misunderstandings.

1 Like
5

Thank you to everyone who has weighed in on the DIP to add Self as an identity verification option for Devconnect ticketing!

To clarify, the initial proposal recommended Self as an additional verification option, highlighting the potential benefit of “giving users more choice in how they verify.” This is intended to complement the existing ZKPassport integration.

Offering multiple ZK-ID solutions is in line with Vitalik’s recommendation for implicit pluralistic identity, outlined in his post “[Does digital ID have risks even if it’s ZK-wrapped?]” Rather than any single solution, we propose offering multiple privacy-preserving ways for attendees to confirm their identity and eligibility for age and/or nationality-based discounts.

We are excited to support the team’s efforts to welcome LatAM-based and young Ethereum developers to Devconnect this year. I look forward to any additional feedback.