- From: 함윤식 <ham3798@o.cnu.ac.kr>
- Date: Tue, 10 Dec 2024 11:04:16 +0000
- To: "public-vc-wg@w3.org" <public-vc-wg@w3.org>
- Message-Id: <TYZPR02MB790765C048F3DA43DB3D0E86B93D2@TYZPR02MB7907.apcprd02.prod.outlook.com>
Dear W3C Verifiable Credential Working Group, Hello, my name is Yunsik Ham, and I am currently a senior at Chungnam National University. I am conducting research on DID authentication systems at our university's lab. I am reaching out to propose an idea related to Verifiable Credential 2.0 and to seek expert feedback on its feasibility. This idea revolves around defining a scheme for verifying Verifiable Credentials (VC) outside of a ledger-based environment. Idea Overview In the current DID ecosystem, Verifiable Credential (VC) issuers are often considered official entities. However, I envision a system where any individual or organization can act as an issuer. In this context, trust should not depend on the governance policies of a ledger but instead be defined independently, based on the issuer's private key. To address this, I propose the following: Providing cryptographic integrity verification only: Trust in the issuer is established through a cryptographic policy independent of any ledger, even in Byzantine environments. Ledger-free verification: Using Sparse Merkle Tree (SMT) structures and BabyJubjub-based signatures, VCs can be signed and verified outside a ledger. Exportable scheme: VCs issued on a ledger can be exported to other environments and verified externally. Specific Scheme Definition The attributes of a Verifiable Credential are structured into an SMT and summarized as a Merkle Root. The issuer signs the SMT Root using a BabyJubjub-based EdDSA signature to issue the VC. Zero-Knowledge Proofs (ZKP) enable selective disclosure, allowing specific attributes to be verified without revealing the entire VC. This proposal does not define a trust policy. Rather, it argues that trust should exist independently of the ledger and be based on private keys. The scheme fundamentally provides "simple cryptographic integrity verification," enabling cryptographic independence from both the issuer and the ledger in Byzantine environments. Third-party verifiers can trust the VC based on their trust in the ledger or the external trust policy of the issuer. Request for Feedback I would greatly appreciate your feedback on whether this idea aligns with the direction of W3C Verifiable Credential 2.0 standardization. Specifically, I seek input on: The feasibility of verifying Verifiable Credentials in a Ledger-Free environment. The practicality of integrating SMT-based data structures with zk-SNARKs (this is a conceptual demonstration with a basic implementation). The potential for extending this scheme to ensure interoperability across various blockchain networks. Additional Materials I am sharing links to my draft paper (both translated and original versions) and the GitHub repository for the proposed scheme. Please note: paper link: https://file.notion.so/f/f/5dd3d83a-3cd7-420c-8b62-6aba3f45ca84/9987b8de-c765-40e8-9a1c-21bb703446a4/PoS___Proceedings_of_Science_template.pdf?table=block&id=1575e32c-5955-80a4-8817-d0832b592e8d&spaceId=5dd3d83a-3cd7-420c-8b62-6aba3f45ca84&expirationTimestamp=1733911200000&signature=bGnmIo_xLb_ANUrFMOgfroqKDXI_mFUQajOdTUH5dA8&downloadName=PoS___Proceedings_of_Science_template.pdf notion_link: https://satisfying-scorpio-da7.notion.site/zk-Embedded-Authentication-1-1575e32c595580409254de94a76dfa2b Github_link: https://github.com/Ham3798/zk_did_scheme This document was translated using GPT, as my English skills are limited, so there may be translation inaccuracies. The draft paper has not been submitted yet, and the references within are not fully organized. I kindly ask for your understanding in this regard. I hope the experts at W3C can help evaluate the persuasiveness of this idea.. Please feel free to reach out for further discussions if needed. Thank you for your time and consideration. Best regards, Yunsik Ham Affiliation: Chungnam National University, Information Security Lab Email: 5023798@naver.com <mailto:5023798@naver.com>, ham3798@o.cnu.ac.kr <mailto:ham3798@o.cnu.ac.kr> Contact: +82 2789 3798
Received on Tuesday, 10 December 2024 12:54:04 UTC