This standard defines the interface for issuing on-chain DID identifiers for the wallet address which have done their off-chain verification.
link of the documentation is here is currently under review and will be added as draft section.
we will also organize soon some workshops on this topic in order to get more feedback from the KYC providers and other use cases in the space in order to get adoption of the standard that the DeFI desperately needs in order to comply with the standards like EBSI
EIP-5851: Zero-Knowledge KYC Certificates, I really believe this could be a solution for reusable KYC and could be a good implementation of Proof of Identity to benefit everyone involved with regulations and compliance required scenarios.
However, centralization and decentralization in this world are not binary oppositions, they should coexist to serve all sovereign individuals. We need to obtain trusted public certificates (e.g., national identity cards and/or ePassports, resident permits, driving licenses and eSIM, etc.) from a centralized party like governments and financial institutions or corporations as an original identity certificate, from this source ID, to derivate a federated identity architecture to allow implementing zero-knowledge proof of identity in order to access a real trustless and permissionless blockchains to build trust from anonymous.
Apologies for the mismatch of the details . the EIP was recreated that’s why some of the details are being re-written . i will get the details corrected
but it will be great if you can define the specific specifications that we need to add in the standard. currently, we are modeling the standard based on the W3C DID standards with the possibility of the admins being able to adapt to the changes in the requirements and being uniquely recognizable across various platforms. if you have example of the jurisdictions and the usecases that we need to integrate, will be great to check out.
We’re trying a new process where we get a volunteer peer reviewer to read through your proposal and post any feedback here. Your peer reviewer is @kalloc!
If any of this EIP’s authors would like to participate in the volunteer peer review process, shoot me a message!
@kalloc please take a look through EIP-5851 and comment here with any feedback or questions. Thanks!
Normally we don’t request peer review until the proposal has reached the Draft status (and its associated pull request is merged), but in this case I do not feel qualified to judge if the EIP is understandable by someone more familiar with the zero knowledge space.
Recently we are in process of restructuring the EIP standard to create verifiable claims rather than zero-knowledge focused standard, and thus you will not find the Specification section which is up to date, we will do the changes this afternoon and will edit the details on this board also. thanks
Also we are going to organise some seminars with Ethereum Magicians and other projects interested in collaborating on onchain / privacy preserving VC standards and will share the followup soon.
Do you have a diagram showing the flow of how this is intended to be used? That would certainly help to explain how this EIP works.
Where does the root of trust lie? ie: Is the trust in the minter of the SBT or is there cryptographic data placed on chain that can be used to independently verify the credential?
KYC can have a lot of composable elements, especially when looking at the breadth of VC standards. This appears to be a simpler, cut down verification mechanism. Perhaps the name of the EIP should be more generic, but have KYC as a potential use case?
We do have a general workflow diagram of how its intended to be used in the case of providing KYC services for DeFI protocols here.
Where does the root of trust lie? ie: Is the trust in the minter of the SBT or is there cryptographic data placed on chain that can be used to independently verify the credential?
On this part maybe the author @yuliu-debond can give more precise response. but in my understanding, it will be based on the minter of the SBT(that will be first onboarding the KYC identity of the wallet holder as shown in diagram link before).
KYC can have a lot of composable elements, especially when looking at the breadth of VC standards. This appears to be a simpler, cut down verification mechanism. Perhaps the name of the EIP should be more generic, but have KYC as a potential use case?
This is indeed you are correct, and indeed we have changed the name of the EIP to On-Chain Verifiable Credentials, thanks for the reminder and we will do the updating here also.
Is there a demo of this you can link to?
We are currently building a non custodial wallet, this will be launched most probably till Q1/Q2 2023.
I think also there needs to be variable corresponding to whether the SBT status needs to be verified periodically or is issued for once for lifetime. this distinction is needed in order the developers being more conscious in developing required logic for claimer to accordingly re-certify the user their claim as SBT based on the condition.