EIP-5851: KYC certification issuer and verifier standard

This standard defines the interface for issuing on-chain DID identifiers for the wallet address which have done their off-chain verification. while keeping the privacy intact by only verifying via the private attributes (using ZK-based schemes).

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 MiCA compliant.

Hello, @GrandGarcon01. It looks like the EIP number is wrong.

5185 → 5851

thanks for correction, this is changed . happy to address other queries that you might have

1 Like

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.

1 Like

You could link the EIP here for ease of reference.

The diagram shows ERC6595 (I’m assuming refers to this EIP) needs to be updated.

1 Like

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

Thanks @Jooeys for your great optimism,

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.