@turboblitz using the international passport schema is one step. There also needs to be a root of trust that does the passport reading and digital translation. That is a second credential that establishes the legal identity of the passport data reader and attester. So one is not enough.
Generally speaking, to simplify the circuits, one should also use W3C Verifiable Credentials (at a minimum, ideally with W3C DIDs). Here is a recent write-up on the topic as well as a link to the whitepaper on the topic of identity and standards and key management across chains from the Ethereum Open Community Projects L2 Standards WG.
Thank you for the clarification. I agree that using the international passport schema is just the first step, and having a root of trust for passport reading and digital translation is crucial to ensuring legal identity verification. This second credential would indeed strengthen the system by confirming the validity and trustworthiness of the passport data reader and attester.
I also appreciate your point on simplifying the process using W3C Verifiable Credentials, which would offer a more streamlined and interoperable approach, especially when combined with W3C DIDs. This would facilitate secure and decentralized identity management. I’ll review the write-up and whitepaper from the Ethereum Open Community Projects L2 Standards WG to further understand how these standards can be applied effectively across chains for identity verification and key management.
A feasible implementable approach may be to split the passport verification and its usage process into two:
Solely verify a passport on-chain and issue a “bond” of validity if the verification is successful.
This is a tricky part as passport verification is a three-step process.
Verify the passport data is signed by a certified authority (via ZK proof).
Verify the certified authority is signed by an ICAO master.
Verify the ICAO master belongs to the ICAO masters list (not expired, etc).
Every part requires a handful of algorithms to be supported both by circuits and smart contracts.
Having the already issued “bond” of validity, one can skip the heavy passport verification ZK proofs and use a light one to prove the possession of a bond instead. This light ZK proof will also be used as a disclosure mechanism of particular passport data (e.g. age, nationality, etc).
@Arvolear your approach is both elegant and pragmatic, striking a balance between robust security and user experience. By decoupling the verification process into an initial, computationally intensive phase and a subsequent lightweight proof phase, you address two critical pain points: scalability and usability.
The “bond” concept is particularly compelling as it abstracts the heavy lifting of passport validation into a reusable artifact. It not only reduces redundant computations but also enables a more efficient way to interact with applications that require selective disclosure of identity attributes. The light ZK proof for possession of the bond is a smart trade-off, ensuring privacy-preserving data sharing while minimizing the computational burden on-chain.
I also appreciate how you’ve outlined the three-step passport verification process with clarity, especially emphasizing the role of certified authorities and the ICAO master list. This demonstrates a solid grasp of both the technical and regulatory aspects. The next challenge might lie in ensuring the integrity and timeliness of the ICAO masters list on-chain, but your framework sets a strong foundation to tackle such nuances.
