Veri secure creds

screenshot of our test frontend + console
Smart contract can easily integrate with us
Users call our registry and pass ZK proof
We verify the proof, and pass metadata further to the target contract

Inspiration

Privacy protocols and regulation are becoming increasingly important. After looking at court documents from high-profile cases like Tornado cash, it became clear that regulators are well aware that the web3 industry is falling behind in terms of compliance, and simply restricting Frontends is not enough with regards to technically-sophisticated criminals. Something must be done on the smart-contract level, without compromising user privacy.

What it does

Our project is heavily inspired by Microsoft's paper: snark-credentials, and the ZK-Creds paper.

On one side, we enable credential issuers (institutions, KYC companies, event organizers, or even individuals themselves!) to assign credentials to their users (think JSON files, for now), and commit to them by publishing hashes to our on-chain credential registry (a smart contract on NEAR).

On the other side, developers who wish to put some rules on who can interact with their contracts are able to integrate with us in 3 simple steps:

Choose a list of credential issuers that they trust. Users will only be able to present credentials issued by parties on this list.
Encode their requirements as a Rhai script. For example: if they would like to test the user's age, they can so something like credentials[0]["age"] > 18. We even have a ChatGPT integration to help with this.
Implement one function on their smart contract: on_credential_call. It is similar to ft_on_transfer from the fungible token standard, where the flow in our case is: user -> cred_call (on our registry contract) -> on_cred_call (on the target contract)

How we built it

Our solution is made of 3 parts:

A registry smart contract: This is where issuers publish hash commitments to all credentials issued by them. It is also where the ZK Proof is verified before we parse some metadata from it and pass it to the contract that the user wishes to interact with. An example deployment of this contract can be found here
A Rust backend: this is where we run the risc0 zkVM to generate ZK-Proofs showing that the user correctly ran the required script, and that his credentials fulfill all requirements specified by the script's developers.
An example frontend BOS component: This is an example frontend for an application integrating our infrastructure to gate who can interact with their contract. The smart contract to this example application can be found here

Challenges we ran into

Time constraints! We started working on this project in this hackathon, and we were always aware that time is going to be a challenge for a project of this magnitude and technical complexity.

Accomplishments that we're proud of

We wrote a substantial amount of code in a relatively short time, and we overcame multiple technical challenges as a team. We learned a lot

What we learned

We got the chance to learn and use some new exciting technologies, such as BOS, Axum & Tokio for managing the load on our

What's next for Veri secure creds

We envisage 2 main improvements:

Verifying that users are the rightful owners of the credentials that they hold: currently we enforce that issuers specify a user's public key in the credential object, this key is then compared to the key used to sign transactions on NEAR. However, we would like to explore the possibility of verifying biometrics (face images, fingerprints...) in a privacy-preserving way
Allowing users to issue their own credentials: Modern government documents support digital scanning features (RFC...). Digital data on such documents is also protected from falsification thanks to digital signatures. We can take advantage of this by allowing users to prove that they own an official government document and use the attributes on those documents to show that they fulfill some requirements (age...), all without the need to go through a KYC provider. A kind of a "self-KYC".