Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ERC standard for ZK based KYC verification #87

Open
1 task
dhruvmalik007 opened this issue Oct 18, 2022 · 5 comments
Open
1 task

ERC standard for ZK based KYC verification #87

dhruvmalik007 opened this issue Oct 18, 2022 · 5 comments
Assignees
Labels
documentation Improvements or additions to documentation

Comments

@dhruvmalik007
Copy link
Contributor

dhruvmalik007 commented Oct 18, 2022

  • Initial description in the EIPs repo here.
@yuliu-debond
Copy link
Member

yuliu-debond commented Oct 23, 2022

https://github.com/yuliu-debond/KYC_verifier-/blob/main/EIP/EIP6595.md

  • 1, first check the file link,make sure the link and naming is correct.

  • [] 2. use grammly to fix all the potential issues

  • 3. create PR ASAP

@dhruvmalik007
Copy link
Contributor Author

HI yu,

i had some queries regarding the description of the metadata,

  • if the metadata defined here is ok to be defined or not.

  • and whether do we need to define the workflow of the different parties (DID , KYC provider and others) in the specification, because rightnow I find the standard lacks the context.

@dhruvmalik007
Copy link
Contributor Author

currently it will be reviewed this afternoon for merge. i have added another diagram along with the updated description

@dhruvmalik007
Copy link
Contributor Author

Following concerns posed by the reviewer during the office hour calls:

I think my biggest concern with this EIP as written is that it doesn't provide enough substance for a third party to come along and implement a compatible contract. Some of that information is likely in the Reference Implementation, but the body of the EIP itself doesn't explain enough.

Assorted other questions:

Why are the requirements published on-chain at all?

"What is the value of standardizing this interface instead of each dapp handling it themselves (or put in other words, when are multiple EIP-5851 implementations going to talk to each other)?

Why not represent each validated requirement as its own SBT?"

@dhruvmalik007 dhruvmalik007 added the documentation Improvements or additions to documentation label Nov 29, 2022
@dhruvmalik007
Copy link
Contributor Author

I will rewrite the standard again as the interface is essentially very specific to our use case and not enough generalized in order to be used it as standard.

So I will study the implementation of how sismo does that and then rewrite a reference example that works. meanwhile, it will be better not to rush this proposal unless all of the dev team members do agree on the implementation specs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

2 participants