vLEI Hackathon Proposal

This article is the proposal for Contract Level Identity: A Decentralized Fuzzy Extractor. Hackathon questions are formatted as titles/subtitles and answers are normal text.

Proposal title

Contract Level Identity

Short description

At its core, Contract Level Identity (CLID) is a Decentralized Fuzzy Extractor, to address the critical need for absolute sybil-resistance by consensus.

Here’s the current problem with identity: there is no secure and reliable way to cryptographically guarantee that an onchain tx was executed by a unique individual. To put this more in context with GLEIF: there is no guarantee that the private key controlling a credential through KERI is always used by the unique individual authorized to do so.

To really understand this problem in the simplest of terms, we must understand that identity and identification are not the same thing. Identity is the aggregation of all the physical bits of data about a person that makes them uniquely identifiable out of all other humans on the planet. Whereas identification is physically separate to (and derived from) identity, like a passport, SBT, driving license, social media handle, AID. The conflation of these concepts is the cause of identity oracle attacks.

Fuzzy extractors are a cryptographic technique for deriving a key from “noisy data” like biometrics. Noisy data is data that is not exactly the same each time it is used, but close enough it can reproduce the same key. Examples of biometric data being noisy could be dust on a fingerprint scan, hair being longer/shorter, or increased wrinkles on a face as the person ages. The fuzzy extracted key can then be used as the base private key for identity. This process needs to be decentralized to make it securely reliable. Users are required to scan their biometrics everytime they sign a message.

Having a system like this as the base identity layer guarantees the prevention of unauthorized credential use, and would provide regulatory compliant institutions with the foundation they need to ensure non-compliant actors are unable to participate in smart contracts on public blockchains.

1. Accelerate Mainstream Adoption of Digital Asset Infrastructure:

How vLEI can unlock institutional participation in regulated on-chain finance? Please describe your idea in terms of process, business model, technology design and architecture as well as other relevant features.

As development progresses, the exact technical implementation is subject to change.

The current thesis is as follows: The computation for the core fuzzy extractor application runs via Multiparty Computation (MPC). An external user’s biometric data is provided to the fuzzy extractor MPC as input for enrollment. Reed-Solomon (or similar error correcting) will be applied to the noisy biometric data, and compared against all previous public enrollment helper data stored on IPFS, to check for duplicate enrollment. If the noisy input successfully decodes against any helper data, a duplicate is confirmed and enrollment is rejected. Otherwise, fresh helper data is generated and stored, enabling future duplicate rejection.

The biometric input is then used in the fuzzy extractor’s generate() function to create a reproducible key, which signs an enrollment message and produces helper data for subsequent key reproductions. The MPC outputs an attestation/signature confirming the signing key was derived from a unique human. Enrollment signatures can be used onchain to register the user with a contract (and pay a fee). Subsequent uses require reproduce(), ensuring the same individual is always present when signing.

By binding this process to vLEI credentials, financial institutions can anchor legal-entity verification (via vLEI/KERI) to biometric enforcement of “who is authorized to act.” This enables vLEI-based KYB/KYC at both the signer and contract level, reduces settlement risk, and ensures that tokenized securities, cross-border stablecoin/CBDC flows, DEX activity, and even custodial/non-custodial operations are always restricted to verified, compliant actors. In this way, CLID provides the missing trust/identity layer for institutional participation in regulated digital asset ecosystems.

What is the expected result from using your idea, product and/or service? If you have already achieved a result, please provide details, providing quantitative data wherever possible.

The result from this idea for GLEIF will be the prevention of unauthorized credential use through the integration of a reliable and secure identity layer.

Consider this scenario: The private key used for controlling an AID can be given to (or stolen by) someone who is not authorized to use it. This scenario may be unlikely, but it is still a vulnerability that exists. When a vulnerability exists, it will eventually be exploited. When dealing with smart contracts, Chainlink, immutable ledgers, etc. end-to-end security is essential. A decentralized fuzzy extracted key can NOT be given to someone else, because it can only ever be derived from a unique individual’s biometrics.

This will illustrate the foundations for “solving” identity in the age of smart contracts and AI. The philosophical implications are huge and this piece of tech is essential for smart contracts to progress to the next plateau of potentiality.

I have already confirmed that a transient key, fuzzy extracted from biometric data, can reliably control a stable, deterministic AID through KERI. (Very exciting!)

Please briefly outline the critical success factors, and steps, required to bring this idea to life, and a reasonable timeline in which this can be achieved. You may set these out in bullet point.

• fuzzy extract key from noisy data — complete
• control an AID through KERI with fuzzy extracted key — complete
• biometric input for noisy data — complete with basic input, if there is enough time during the hackathon, will look at implementing additional biometrics
• decentralize fuzzy extraction process
• secure handling of fuzzy extractor helper data

These can very reasonably be achieved within the 4–5 week timeframe of the hackathon development period to demonstrate a functional MVP. Once these core requirements are achieved, the focus will shift to optimizing security, user experience, and possibly implementing “multi-factor fuzzy extraction” — which is when multiple biometric sources plus a password are used for key generation/reproduction.

What are the key benefits to the wider community if we were to go ahead to implement your proposed solution?

A base layer of identity, or “absolute sybil-resistance by consensus”, that CLID seeks to demonstrate, would enable:

• voting
• fairdrops
• auctions
• public access compliance for smart contracts (institutions would have the assurance a sanctioned or high-risk actor is not participating in the same public DeFi protocols as they are)
• prevention of identity oracle attacks / sybil attacks
• justification of the word “identity” in Chainlink’s CCID
• securely restricted sections in next-generation/metaverse environments such as professional or NSFW settings

As a bonus, this system will also inadvertently solve the problem of society plunging into chaos from AI deepfakes and agents in the next few years, where noone can distinguish reality in the digital world. The world will need reliable cryptographic guarantees that they are interacting with a unique human, as opposed to a duplicated identity/sybil attacker or bot/AI agent.

What other companies or organizations already offer a similar solution?

Everest.org is the only thing that comes close. They use a biometric login to access their onchain wallet. They do not use a fuzzy extractor as far as I know, they use a third-party biometrics provider. https://wallet.everest.org/

Everest previously did a PoC with GLEIF: https://medium.com/about-everest-updates-and-news/everest-gleif-and-adb-to-streamline-cross-border-transactions-between-companies-80eda13fcd57

It was actually Everest that inspired this research. I previously developed an automated compliance framework for public access smart contracts with Chainlink and Everest: https://github.com/contractlevel/compliance Unfortunately, Everest’s provision of absolutely sybil-resistant identity data to the Chainlink network was not reliable, due to their identity infrastructure not being sufficiently decentralized.

Here is an article I wrote on the topic where I first publicly considered the application of fuzzy extractors in this context: https://medium.com/coinsbench/the-problem-with-contract-level-compliance-f81528e55866

Worldcoin and Humanode also incorporate biometrics into their approaches, but neither achieve absolute sybil-resistance, and both have a history of being exploited because of this.

I also found this whitepaper on decentralized digital identity which discusses the application of fuzzy extractors: https://ceur-ws.org/Vol-3550/paper4.pdf However their approach is also easily exploitable.

What are the key competitive advantages that your team and your proposed solution have over your competitors?

Everest is the only serious competitor, and they are not sufficiently decentralized and reliable. Everest’s identity infrastructure is also closed source, whereas Contract Level Identity will be open source.

Worldcoin has a history of being sybil-attacked where users were able to exchange their “world identities” due to their infrastructure not verifying identity for every action taken: https://www.coindesk.com/policy/2023/05/24/black-market-for-worldcoin-credentials-pops-up-in-china https://cointelegraph.com/news/worldcoin-singapore-investigation-money-laundering-terrorism-financing Worldcoin has questionable user data handling: https://x.com/CA_Kenya/status/1686718736940580864 Worldcoin has impractical user onboarding. They require users to sign up via one of their “orbs” — a physical device for scanning biometrics. It is unreasonable to expect people to travel to a limited location. Users should be able to enroll from their own device and location.

Humanode is the same thing. They scan a users’ biometrics once to enroll them into the system, but then never again. So you’d use a typical EOA wallet to scan your biometrics, and get approved as a “unique human” in their system. Then all it takes for an attacker to gain an advantage over this system is hire a village from the third world to sign up and then give the attacker the private keys to the EOA associated with their confirmed “uniqueness”. Humanode even goes as far as describing themselves as “not ideal” in their own marketing material: https://x.com/humanode_io/status/1919462537612976174

Another project called zkKYC has the exact same approach and problem.

The whitepaper I linked in the previous answer which discusses fuzzy extractors basically does the same thing. They suggested minting users an NFT based on fuzzy extracted data, which is completely useless because the private key holding the NFT can still be passed around to anyone in the world.

What differentiates you with your competitors? What is your unique value proposition?

Contract Level Identity’s unique value proposition is open sourcing absolute sybil-resistance by consensus. When I use the phrase “absolute sybil-resistance by consensus”, I am referring to the guaranteed impossibility of one actor in a system posing as more than that.

Where Everest fails to reliably provide absolutely sybil-resistant identity data to smart contracts, CLID will provide.

Where Worldcoin and Humanode have enabled sybil-attacks, CLID will prevent them.

Basically every so-called identity solution is exploitable because it is based around something that isn’t actually identity (except for Everest, which fails because it’s too centralized).

Please indicate any key dependencies on technical, governance or regulatory issues about which the community should be aware.

The currently identified technical limitations (which can be worked with/around for the context of a producing an MVP for the hackathon) are:

1. Secure handling of fuzzy extractor helper data. Fuzzy extractors have 2 key functions: generate() and reproduce(). Generate takes in noisy data and outputs a key and helper data. Reproduce takes noisy data and the helper data to output the same key. The helper data will need to be securely handled. The current working approach is for the user to store it safely themselves, and they are expected to provide it when they scan their biometrics to reproduce their key and sign a message. Secure alternatives for an improved user experience are being explored, such as splitting the helper data and storing its shares separately on infrastructure like IPFS. Though this would need careful consideration of the shares retrieval for the correct user.

2. The actual decentralization of the fuzzy extraction and message signing process. A lot of research time for this proposal was spent experimenting with running the fuzzy extractor logic in a Trusted Execution Environment, which would then output an attestation/signature anyone could verify. The issue with this though is TEEs are a closed box for secure execution, and the app would need to interact with IPFS for reading and storing helper data. The current working approach is to have the logic running via Multiparty Computation (MPC). Traditionally, participating parties in MPC provide input, so the current challenge is enabling an external user to securely provide input without being one of the computation running parties.

Another challenge will be handling of biometric input such that 2 persons do not reproduce the same key, whilst the noisy distance remains sufficient for a single person to reliably reproduce their own key.

Multifactor fuzzy extraction for increased security and user control will be a longterm preference.

Please indicate any specific dependencies, uncertainties or implementation risks related to GLEIF architecture or software

The only current uncertainty is insufficient familiarity with the software, though this is being improved with vLEI training resources repo. I’ve already confirmed that a transient, fuzzy extracted key can successfully control a persistent, stable AID through KERI. The video resources were beneficial and the LLM-compatible md file of the resources was particularly helpful, so thanks for that.

Please indicate commercial benefits for your organizations and clients as well as indirect benefits to regulators, infrastructure providers or other stakeholders.

Commercial benefits include the accelerated adoption of digital assets and market infrastructure by TradFi institutions, due to a safer public regulatory environment from the (private and user-controlled) identification of public participant uniqueness. Institutional clients would have securer access to tokenized securities, reduced settlement risk, and a superior compliant environment for stablecoin/CBDC flows, because of CLID’s inherent enforcement of arbitrary implementations at the signer level — as opposed to at the credential level. Private bank chain liquidity could be confidently connected to public chains, knowing that none of the users in the public access system are on sanctions lists, North Korean hackers, etc

Benefits for the average retail/end user would be enabling all of the things Web3 requires identity for but currently cannot efficiently facilitate (voting, fairdrops, reputation, auctions, etc) — actual sybil-resistant smart contract systems.

An indirect benefit to regulators would be enhanced oversight, without compromising privacy. CLID would provide regulators with cryptographic proof of unique, vLEI-verified participation in public ecosystems.

Chainlink’s ACE/CCID would benefit from having a base layer of identity via CLID, and would no longer be vulnerable to identity oracle attacks.

CLID could be monetized by requiring a registration fee, or fees for subsequent reproduce() signatures.

Private key compromises is one of the single biggest attack vectors in blockchain. CLID would solve that because biometric keys cannot be compromised (with a high enough multifactor fuzzy extraction threshold).

*Contract Level Identity (CLID) is a Decentralized Fuzzy Extractor currently being researched and proposed as a solution for the vLEI Hackathon.*