Enhanced KYC Compliance and ID Uniqueness

Proposals
1

Why it Matters:

The Concordium blockchain’s dedication to privacy, regulatory compliance, and seamless KYC processes marks it as a significant player in the digital identity landscape.

However, the challenge of ensuring ID uniqueness and enabling tiered KYC compliance has become increasingly crucial for the ecosystem and for Concordium in the pursuit of being a market leader in the global adaptation to the mass market through seamless and universal compliance.

Addressing these challenges is paramount for maintaining the trust and security foundational to Concordium’s ethos.

It’s about creating a digital environment where users feel secure and compliance processes are streamlined, further solidifying Concordium’s position as a leader in privacy-respecting, regulation-compliant blockchain technology.

This proposal proposes a community-driven approach to refine Concordium’s Base ID framework, aiming to enhance the integrity and functionality of digital identities within the ecosystem.

The Need for a Refined Base ID Framework:

The current Base ID system on Concordium, while groundbreaking, encounters challenges related to the consistency of data captured by various third-party ID providers, especially in fields critical for KYC compliance like Country of Residency and Nationality.

These inconsistencies can hinder our collective goal of offering a streamlined KYC process across the Concordium ecosystem.

Addressing these challenges is not just about improving a technical system; it’s about reinforcing the trust and security that are foundational to Concordium’s vision.

Proposed Solutions:

1. Tier-Based Base ID Classification:

To address the variability in KYC data, we propose the introduction of a tier system for Base IDs. This system will categorize IDs into Basic Tier and KYC Tier, depending on the depth and verifiability of the data they contain.

Potentially the new standard can consist of even more tiers including the new chaperone accounts but especially in relation to the use of eID’s which are KYC compliant in the specific country of the user, there is a lot to be gained towards ensuring seamless KYC compliance.

By standardizing meta properties across all Base IDs, we ensure uniformity and enable dApps within our ecosystem to ascertain a user’s KYC compliance effortlessly.

2. Uniqueness of ID:

To tackle the issue of ID uniqueness, our proposal suggests hashing critical fields from the ID document, such as document ID and type, to create a unique key for each user.

This method will prevent the duplication of IDs, ensuring that each Concordium wallet is as unique as its owner, thereby eliminating potential misuse in scenarios like AirDrop claims.

3. Concordium KYC – A Universal Web3 ID:

Building on the tier system, we propose the creation of a Concordium KYC Web3 ID, a comprehensive digital identity that satisfies KYC requirements across jurisdictions.

This Web3 ID would be obtainable through a dedicated Concordium service, ensuring it encompasses all necessary data fields for global compliance.

By aligning with national e-ID solutions like Denmark’s MitID and providing alternatives where such infrastructure is absent, we lay the groundwork for a universally accepted digital ID on Concordium.

Why propose the solutions:

1. Tier-Based Base ID Classification:

Implementing a tier system for Base IDs addresses the critical need for a standardized approach to KYC data across the Concordium ecosystem.

By categorizing IDs into Basic and KYC Tiers based on the depth and verifiability of data, this strategy not only streamlines the process for determining a user’s KYC status but also significantly enhances the reliability and efficiency of identity verification within the ecosystem.

It aligns with Concordium’s commitment to providing a secure, transparent, and user-centric blockchain environment.

2. Uniqueness of ID:

The proposal to ensure the uniqueness of IDs by hashing critical ID document fields directly addresses the challenge of preventing ID duplication and misuse.

This method guarantees that each user’s digital identity on Concordium is unique, fostering a more secure and trustworthy ecosystem.

It is particularly crucial for maintaining the integrity of transactions and interactions on the platform, preventing fraud, and ensuring equitable participation in activities like AirDrops.

3. Concordium KYC – A Universal Web3 ID:

The creation of a Concordium KYC Web3 ID represents a comprehensive solution for meeting global KYC requirements, facilitating a seamless and universal standard for digital identity.

By offering a Web3 ID that complies with international standards and incorporates data fields necessary for broad regulatory acceptance, Concordium is positioning itself as a leader in privacy-respecting, regulation-compliant blockchain technology.

This initiative not only enhances user trust but also significantly expands Concordium’s usability and accessibility worldwide especially in combination with the use of eID’s this also becomes an extreme improvement on user onboarding and seamlessness of the user experience, giving Concordium yet another advantage.

Use Case: Danish User Experience with MitID and Concordium

Scenario:

Jens, a Danish resident, decides to explore a new DeFi platform built on Concordium. He wishes to ensure his activities are compliant with KYC regulations and values his privacy.

Step 1: Concordium Wallet Creation with MitID

Jens starts by creating a Concordium wallet. He selects MitID as his verification method, recognizing it as a secure and nationally recognized eID. The process seamlessly verifies his identity, employing Concordium’s proposed tier-based KYC classification. His MitID provides a high level of KYC compliance, instantly categorizing his new wallet into the KYC Tier.

Step 2: Uniqueness of ID

To ensure Jens’s identity is unique within the Concordium ecosystem, his MitID information is hashed, creating a unique key. This guarantees that Jens can’t be mistakenly identified with another user, nor can others misuse his identity credentials to create multiple accounts.

Step 3: Seamless Ecosystem Access

With his KYC Tier wallet, Jens now accesses the DeFi platform. His Concordium KYC Web3 ID, underpinned by his MitID, automates the compliance check.

Use Case Scenario: Danish AesirX User Onboarding with MitID

Scenario:

A Danish user, let’s call them Alex, seeks to engage with a blockchain ecosystem offering secure, private, and compliant transactions and take ownership of his privacy with AesirX Shield of Privacy.

Alex chooses Concordium due to its commitment to privacy, regulatory compliance, and seamless KYC processes.

Step 1: Initial Onboarding with AesirX Shield of Privacy

Alex begins by accessing the Concordium platform through AesirX’s interface, which offers a privacy-centric onboarding process.

During registration, Alex is prompted to use MitID, Denmark’s national e-ID solution, ensuring a high level of KYC compliance from the start.

Step 2: Tier-Based ID Classification

Based on Alex’s MitID verification, the system automatically classifies Alex’s Base ID into the KYC Tier, indicating a higher level of data verifiability and compliance.

This classification enables Alex to seamlessly interact with dApps requiring a verified identity within the Concordium ecosystem.

Step 3: Ensuring ID Uniqueness

To ensure Alex’s ID is unique, the system hashes critical fields from the MitID document, such as document ID and type, creating a unique key.

This process prevents ID duplication, ensuring Alex’s Concordium wallet is unique and secure.

Step 4: Concordium KYC – Universal Web3 ID Creation

Alex opts to upgrade to a Concordium KYC Web3 ID through a dedicated service, further enhancing the ID’s compliance and utility across jurisdictions.

This Web3 ID is tied to Alex’s Base ID, facilitating seamless onboarding within the Concordium ecosystem.

Step 5: Country and Age Verification for Compliance

Utilizing the Verified ID from MitID and AesirX Shield of Privacy, Alex can now undergo country and age verification in a single click.

This verification is essential for accessing certain dApps or transactions within the ecosystem, ensuring compliance with legal requirements.

Outcome:

Alex now has a secure, unique, and compliant digital identity on Concordium, enabled by the integration of MitID and the innovative solutions proposed for the Base ID framework.

This identity allows Alex to navigate the ecosystem with ease, participating in transactions and dApps with confidence in the privacy and security of personal data.

This use case exemplifies how the proposed enhancements to Concordium’s Base ID framework can significantly improve the user experience for individuals requiring secure, compliant digital identities.

By leveraging national e-ID solutions like MitID and integrating advanced privacy and security measures, Concordium can offer a user-friendly, compliant, and secure environment for all participants while keeping an essentially seamless onboarding experience.

Community Engagement and Decentralized Development:

This proposal invites the Concordium community and ecosystem to partake in the development and refinement of these solutions.

The move towards a more community-driven approach in addressing these challenges not only democratizes the development process but also aligns with Concordium’s decentralization strategy.

I encourage feedback, discussions, and contributions from all corners of the Concordium ecosystem to ensure that the solutions we implement are robust, user-friendly, and forward-looking.

The proposed enhancements to the Base ID framework are aimed at solidifying Concordium’s position as a leader in privacy-respecting, regulation-compliant blockchain technology.

By addressing the challenges of ID uniqueness and tiered KYC compliance, we not only enhance the security and functionality of the Concordium ecosystem but also ensure it remains at the forefront of technological innovation and user trust.

This is a call to action for the community to come together, contribute to this pivotal development, and help shape the future of digital identity on Concordium.

Regards

Ronni K. Gothard Christiansen aka VikingTechGuy and Creator of AesirX

3 Likes
2

It is unclear what you are suggesting. Is “wallet” an “account”? Concordium’s ID layer does not mean that a user can only have one account. It was/is an explicit goal to be able to have many different accounts based on one identity.

And regarding uniqueness. This is a problem that is not solved anywhere other than in a context of a national registry. Document number and type do not uniquely identify a person in the sense that I have multiple documents (from multiple countries). So this hashing does not solve any problem.

Similarly, it is an explicit design goal that accounts are not linkable unless anonymity revocation is done. So “hashing” such fields in accounts is not something we want to do publicly since that would link those accounts.

With the current data that is there, a use-case can ask, in private (as in, not on the chain visible to everybody), a wallet-holder to reveal those details to the service, and the service can then store a fingerprint of that data to ensure that the same user with the same credentials does not use the service twice.

3

No i focus on Document Type and Document ID.

I need to prevent that a Indonesian using his Drivers Licenses can create 1000 different IDs with the same Drivers License and then take part in Airdrops.

We do nothing with Reveal and have no use case needs for Reveal at all, we only work with Verify and see it as a weakness to have to Reveal anything.

Also why any model using “eZealing” and Reveal is also completely unattractive - there is no privacy in revealing your personal data.

Same goes for the Concordia bot that Reveals your full personal name on a Telegram Channel with many 1000s users, i do not understand the use case either.

So this proposal very much addresses the need to ensure people can not make fake accounts or cheat or abuse ecosystem projects, which they can today because the only way to ensure the uniqueness of ID is by Revealing the data.

Reveal is not Privacy by Design.
Verify by ZKP is Privacy by Design

4

You can do this now, with wallets that exist, and protocols that exist, prevent the same user (unless they have multiple documents) in participating in airdrops multiple times.

The property you want is that they share some unique ID that they cannot easily fake. They will “reveal” it to you and you can choose to do what you want with it. All of these are zero knowledge proofs.

Currently that is the document number or some other attribute that is sufficiently unique. Even if the user could just “reveal” some digest of their document number and type, it would still leak information about different accounts being linked to the same person. Similarly, even if the user only revealed a fixed one way function (“a hash”) of their document number to you they have in practiced also revealed a document number since you can most likely brute force it, seeing that the space of all possible document numbers, e.g., CPR numbers in Denmark is quite small.

With regards to Concordia, the entire point of that demo is that you link a specific account on social media platform A to another specific account on social media B.
If instead you proved “I have an account on telegram and an account on discord” you’ve provided no meaningful information.
As I wrote, the entire point is to transfer reputation from one social media to another. If you don’t care about that you don’t have to use it either. And full name is also optional if you want to additionally enhance your credibility. But it is again optional. And funnily enough all of these proofs are indeed zero knowledge proofs.

5

I will stick to the issue of uniqueness of ID.

I need a way to ensure that i can Verify that a users ID document that has been used to create an ID on Concordium is unique.

I have requested this before and no one has been able to advice how.

There is a document id and a document type if you combine both and hash it into a new meta layer property that can be Verified using ZKP then we can in a simple way ensure that a user that comes in with a ID linked to a Wallet is a unique user and not just a user who used the same personal ID to create 1000 different IDs and then 1 Wallet per ID.

If it is already possible without revealing data so that we are allowed to do cross-border and also out of EU regional data transfers i would love to hear how.

If it is not and it can only be done with Reveal please chip in how to resolve it so that we can live up to Privacy by Design.

6

In the proposed enhancement to Concordium’s Base ID framework, a novel approach is taken to ensure the uniqueness and privacy of user IDs.

By combining document ID and document type into a single hash, the system creates a unique identifier for each user. This hashed value ensures the user’s ID remains unique within the ecosystem by leveraging Zero-Knowledge Proofs (ZKP) for verification purposes, without revealing the users data to ensure it can be used cross-border and out of EU without privacy concerns.

ZKP allows for the confirmation of ID uniqueness without revealing or compromising the underlying personal data. This method protects user privacy and data integrity, preventing the traceability back to the original document ID or type.

Furthermore, it supports a tiered classification of IDs, ranging from basic identification to full KYC compliance, facilitating diverse user engagement within the ecosystem without altering existing structures.

This model introduces four tiers of IDs:

  1. Chaperone Accounts (Tier 1): Designed for minors, such as children in GameFi environments, allowing limited, supervised access.
  2. Basic ID (Tier 2): Uses basic forms of identification like driver’s licenses for non-KYC-compliant users, offering a foundational level of interaction within the ecosystem.
  3. Passport Level ID (Tier 3): For users requiring a higher level of KYC compliance, leveraging passport data to provide enhanced access and capabilities.
  4. eID Level (Tier 4): The highest tier, utilizing nationally recognized eIDs (like Denmark’s MitID) for full KYC compliance, ensuring the most comprehensive access and security.

On top of these tiers, the Concordium KYC Web3 ID is introduced, offering a flexible and country-specific compliance solution. This Web3 ID adapts to the legal requirements of different jurisdictions, ensuring users meet local KYC standards while maintaining privacy through ZKP.

This tiered approach, combined with the Concordium KYC Web3 ID, aims to streamline user onboarding, enhance privacy and security, and ensure regulatory compliance across the Concordium ecosystem.

In terms of standards, the proposal seeks to ensure a new standard for the quality level of the ID used to ensure KYC compliance and uniqueness of ID to prevent fraud and abuse while also offering a foundation that can be extended by a universal KYC Web3 ID service which all projects in the ecosystem can utilize at a certain cost or fee, but in a model where the KYC legalization process of the user by going through the additional Web3 ID KYC formalization will mean that the user can 1 click join any ecosystem project and instantly take part or trade or what ever is required because that User is KYC compliant through a Tier3/4 Base ID + the KYC Web3 ID (depending on the country of the user).

I hope this further clarifies the request to the community and core tech team as to the problems we need to resolve and why they are very crucial not only in terms of Privacy and Compliance but also in terms of the User Experience of onboarding new users and the value having a ID on Concordium has.

7

That is a very nice post, @VikingTechGuy . I’ll start by making a few technical comments.

Firstly, uniqueness of ID is not possible. For every physical ID you have, you can have different IDs on chain which cannot be linked. Passport, ID card, drivers license, all give you different IDs. Resident permit in one country and passport in another give you different IDs. Physical IDs expire after some time, you get new ones, you can make new on-chain IDs. From what I gather from your reply, you don’t seem to care that someone can make 6-7 different IDs, you don’t want them to make 1000. That is a fair point, but then maybe we shouldn’t use the expression “uniqueness of ID”. Since that is impossible, I find that it just spreads confusion to use those words.

What can be done is a proof that different accounts do not belong to the same ID. You propose to hash some crucial ID info, and use that as some identifier for the ID used to create the accounts. That can already be done now, without needing to add it on chain. If a user wants to interact with a site that requires this hash, then they compute it on the spot and give it to the site along with a proof that it was correctly computed (i.e., they prove that they know randomness and ID information that are consistent with the hash and the commitment). The site can then check that no one with the same hash has already accessed their services.

In fact, adding this hash on chain is a bad idea, as it would allow accounts created under the same ID to be linked, which we don’t want. That is why sharing this hash should only be done in private, as described above.

Finally, there is a big misconception around ZKP, namely that they don’t reveal any private information. The correct statement would be that they don’t reveal more private information than necessary. But they still reveal a lot. For example, if I prove that I am over 18, then I have just revealed that I am over 18. I haven’t revealed my exact birth date, which is unnecessary information. But I have just revealed some private information. So if you aren’t careful with what ZKP you do, you might be revealing more information than you want. That is the case with your hash. When you send your hash to someone and prove that it is correct, you have essentially just revealed all info that got hashed, because someone could just try all combinations until they find the strings that got hashed.

All this said, your ideas of having more consistent data, different tiers and a web3 ID service are great ideas. What isn’t clear to me is if this should be achieved by changing the base layer ID or by having a layer run by a third party between the base layer and the services that want identity information. All the information that is needed seems to already be there in the base layer, but it hasn’t been nicely structured in tiers and could be a mess to access for the different services, because it changes depending on the country and ID type. An intermediary layer could specialize in recognising all the possible ID information from different countries, knowing which can be used for KYC and which can’t, and then provide a nicer interface to the services that just want the KYC without knowing about all the different types of national IDs, passports and drives licenses.

Do you see any concrete information that is missing from the base ID layer and can’t be computed from the information already present in the base ID layer?

1 Like
8

Let me address the core issues that links together, that stand out as we agree on the rest, and thanks for your inputs.

1) Privacy and Compliance

In terms of Privacy Laws and Compliance is it not revealing personal data to use ZKP to verify you are over 18, it is however a very crucial aspect if you decide to use Reveal to disclose the data, that is personal data, if you do so and hash it, as you have processed the data, you become the data processor.

Also, as it is not legal for a 3rd party to do cross-border transfer of your personal data, it can no longer be used systematically to verify data without revealing them, again i need to stress the importance here that it is not a breach of privacy to verify neither Age nor Country as long as it is done through verification with ZKP and each individual part can not be connected to link back to a person that can be identified.

This also means that if we ask the user to reveal the personal information the legal implications are huge: just one small example is that you can no longer do Criminal Background Checks in Vietnam for European based Companies because now both the VN and EU Data Protection Laws prevents any 3rd party from processing the data and transferring it cross-border.

This is only one example there are many more and as GDPR and Data Protection Laws are enforced globally, Privacy by Design has to be understood.

2) Uniqueness of ID

If a user can use the same drivers license to get 1000 IDs on Concordium that means Concordium have paid for 1000 x the same ID process for the same user on the same ID from the ID provider, which surely are happy, but how is that making sense for Concordium to spend money on?

I don’t see a business case.

I also do not see it as an ecosystem project, if i have an AirDrop and the same user claims all 1000 where is the use of ID?

We need to add a small meta data field that can be verified with ZKP which ensures uniqueness, that is the only way to guarantee that the primary USP of Concordium to prevent fake, fraud, bots etc. can be realized or else all of those claims are pointless.

Why? If you have to reveal data which makes it non compliant with privacy laws and makes it impossible to use for anything cross-border due to lack of compliance there is little value in using the ID base of Concordium.

Alternative Solutions
If the will to add to the base layer to add in the meta field for uniqueness of ID and also which tier level it lives up to in relation to KYC compliance, based on a new standard we all agree on, the solution could potentially be to put it all in a new Web3 ID based service that all ecosystem projects can utilize and pay a small fractional service for, which then would cover the cost of ID with KYC compliance collectively so all who are using the service are contributing to enabling more people with KYC compliance in an ideal user experience - it could be added here so that both uniqueness of id, KYC compliance tier and full KYC compliance could be put in one solution, but i still think that loosing out of enhancing the base ID so that any additional KYC intermediary layer or service is added directly on top of the base ID is a lost opportunity.

/R

1 Like
9

Hi Ronni,

Thanks for your reply.

Concerning your point 1): I honestly don’t know what you are talking about in this paragraph, or how it is connected to anything that was said before. We do not put (and will never put) any personal information on the blockchain (hence why we would not put the hash of data as you proposed). There are only ever two parties that hold personal data: the user and any service to whom they willingly provide data (e.g., they decide to reveal with a ZKP that they are over 18 or live in a specific country).

Also, you mention several times “Reveal” (with a capital R). I don’t actually know what you mean by that. If you reveal some information about your ID, it is always done via a ZK-proof. Whether you reveal your exact birthday, exact name, or just something more vague like being over 18 or not living in a country on a list of banned countries, it is always the same underlying cryptographic technique: you provide a ZKP that you know how to open the commitment to a value that is over 18 / not in a list / equals something / etc.

Concerning your point 2): I don’t know why you are talking about a user making 1000 IDs with the same license. I thought the topic was the different accounts made with the same ID object. Concerning making different ID objects with the same physical ID: that should be forbidden by the ID providers. But I don’t actually know if they enforce it, and we should probably check that.

Concerning linking accounts that have the same ID object as you propose: no, that is a clear violation of user privacy, and goes contrary to our policy so far. But what could be done is allow users to provide a ZKP that accounts have different ID objects. This would then not reveal any unnecessary personal information.

Summary
If I try to summaries your suggestions from the posts above, I have:

  • ID objects should be categorised in those that have lower and higher levels of KYC, and a user should be able to prove that their ID falls in one of these categories.
  • It should be possible to generate a ZKP that proves that different accounts do not have the same ID object.
  • Some web3 ID service that provides comprehensive KYC should be made available.

Did I miss anything?

Cheers,

Christopher

1 Like
10

Dear Christopher,

I appreciate your engagement with my proposals on enhancing KYC compliance and ensuring ID uniqueness on Concordium. The essence of my suggestions is to align Concordium’s operations with privacy-by-design principles, crucial for GDPR compliance and operational integrity in cross-border business cases.

The proposal for a new hashed field combining Document ID and Document Type is designed to ensure ID uniqueness without compromising user privacy. This approach, using zero-knowledge proofs, aligns with GDPR’s requirements by verifying user information without revealing sensitive data. This method mirrors the process we use in AesirX Single Sign-On, where we verify age or country without disclosing specific details to the website owner.

The necessity for ID uniqueness is not merely about preventing fraudulent activities like the misuse of AirDrop but also about establishing a verifiable trust mechanism that doesn’t compromise user privacy. By hashing critical ID fields to create a unique key, we can ascertain ID uniqueness without becoming a data processor or increasing business risk.

This approach aligns with the ‘Verify’ operation, enabling businesses to verify essential attributes like age or country without revealing or processing sensitive data through ZKP, thereby adhering to GDPR requirements. It’s a cornerstone for developing seamless, compliant business models, ensuring that businesses using the Concordium platform can confidently engage in digital transactions without legal concerns.

By implementing this, we can provide a GDPR-compliant solution that enhances the ecosystem’s security and trustworthiness, essential for cross-border business cases where revealing personal information is not permissible. This adjustment will fortify our platform’s integrity, ensuring Concordium remains a leader in privacy-respecting, regulation-compliant blockchain technology.

I believe these enhancements will significantly benefit the ecosystem, offering a solid foundation for a wide range of use cases, including those requiring age and country verification, like online alcohol sales. I look forward to further discussions on how we can collaboratively enhance Concordium’s KYC and ID uniqueness features.

I have not gone into details on tiered “quality level” of the Document ID used nor my proposal part for a shared KYC enabling service or layer that all ecosystem projects can utilize to improve user onboarding by preventing the need for KYC for each project, i.e. Concorpad, Arabella Bridge, AesirX etc. we all use the same KYC process that is a Web3 ID that is extending (abstracting) the Base ID, based on which tier from 2-4 the base ID has the cost of KYC gets cheaper and with eIDs and Tier 4 we can then automate KYC - just as a bank or any website owner in Denmark can with MitID because it is a KYC Compliant eID on National Level - Seamless KYC is the goal but it requires full priority and support of eID providers also for Concordium so we extend beyond Denmark and Finland. However i will not go more into detail on these additional proposals yet, as i want to ensure that the understanding of why i am proposing uniqueness of ID and a data model based on ZKP Verification and not Reveal - i can not as a b2b software solutions supplier use Reveal as it makes it impossible for me to scale to a global business due to compliance laws and cross-border regulations on personal data.

Verify using ZKP is Privacy by Design - Reveal is not unless used by the person directly, meaning if you want to do a Criminal Background or an Educational Certificate and its stored as a Web3 ID it can be verified Cross-Border without problems or legal risk, but if its using eSealing or Reveal logics the person needs to travel from their own country to the country where the company whop needs to verify their data is and then show them in person - which makes little sense compared to the need to systematic verification of data in a compliant way without making the company liable.

I hope this extensive answer gives the full picture of the Why.

Best regards,
Ronni K. Gothard Christiansen (VikingTechGuy)

1 Like
11

Hi Ronni.

I believe you’ve raised some important points, that needs resolving. In particular, a solution to sybil attacks in general needs more looking into from our side. Though whether this is actually solvable by anything we come up with is probably a longshot, because as has been pointed out in this thread, the uniqueness of IDs doesn’t really exist outside the government issuer space. However, we can probably get alot closer to a solution where the bulk of the problem is somewhat mitigated, for whatever that is worth. But this is inherently a very hard problem, whether the usecase is e-voting, a reputation system or in your case an airdrop. At least for a reputation system, a Verifiable Credential could be issued, proving the users right to have an opinion based on something tangible, like a receipt of a purchase that would present something unique. I believe the best-case for uniqueness you have, is to only airdrop to one “Jens Hansen” born on one specific day, from one specific country. Maybe… As hashing and storing these values might present other privacy issues as discussed further up this thread.

You seem to be very keen on not having to obtain any personal identifiable information of users, as this would make you become a “data processor” in terms of GDPR. This is entirely understandable, but are you sure the regulation really differs between getting a name revealed and proving a specific name with a ZKP? Because the outcome is the same: You get the full name.

Also, several IDP-related topics still remain. Like, whether it should be enforced by IDPs to not allow duplicates, whether IDPs should validate information with isusers. That would certainly only allow the 5-6 different IDs per human, as opposed to the the thousands you fear from an indonesian drivers license. From our end, this certainly needs rethinking, as AI is quickly making everything but eID questionable for enrollment, since drivers licenses and selfies can be easily faked by an AI. However, this headache is really on the IDPs - not us.

Anyway, I don’t have any answers yet to any of these questions, but let this be an opening for further discussion. Can you please quicky verify your use-case?:

  1. You want to only airdrop to unique humans
  2. You don’t want to process any personal-identifiable information
  3. ?

BR, Jonas Hansen

12

Hi Jonas,

Thanks for chipping in, let me try and address the issues.

Here are the three main problems clearly stated:

  1. Uniqueness of ID: Concordium lacks a method to ensure that each ID is unique using verification and Zero-Knowledge Proof (ZKP) logics. This absence of a mechanism to verify uniqueness could lead to potential ID duplications, affecting the integrity and security of the platform.

  2. Tiered ID: The platform does not currently have a tiered ID system to assess and classify the quality and compliance level of base IDs. Such a system is essential for categorizing IDs based on the reliability and depth of the data they contain, facilitating the ecosystem’s applications in accurately determining a user’s KYC compliance level.

  3. KYC Level ID: There is a need for a Web3 ID service that utilizes ZKP and verification for KYC compliance, depending on the tiered ID system’s quality assessment. This service would enable users to obtain a Concordium KYC Web3 ID that meets international compliance standards, enhancing the platform’s utility and legal operability, especially for cross-border use cases.

I aim to clarify the three main issues that I believe are critical for enhancing the platform’s ID system. These are the uniqueness of ID, tiered ID, and KYC level ID, each addressing a specific gap in the current framework that, if resolved, can significantly advance Concordium’s utility and compliance posture.

  1. Uniqueness of ID: The current system lacks a robust mechanism to ensure the uniqueness of an ID using verification and Zero-Knowledge Proof (ZKP) logics. This gap potentially allows for the duplication of IDs, undermining the trust and security inherent in the Concordium ecosystem. It’s crucial for Concordium to adopt a method where critical fields from the ID document, like document ID and type, are hashed to create a unique key for each user, ensuring each wallet and identity on Concordium is as singular as its owner.

This prevents abuse of AirDrops and all other scenarios of abusing ID for purposes that could be used for fraud, bots, fakes, misinformation etc.

  1. Tiered ID: The introduction of a tiered ID system would provide a structured way to assess the quality and compliance level of each base ID. This tiering would categorize IDs based on the depth and verifiability of the data they contain, aiding applications within the ecosystem to ascertain a user’s KYC compliance with ease. Such a system promotes a more nuanced and effective approach to identity verification, accommodating various use cases within the Concordium ecosystem.

This allows for simple valuation of ID quality level in relation of what is needed to get to a specific tier of qualification (as foundation towards KYC),

  1. KYC Level ID: Developing a Web3 ID service that uses ZKP and verification for KYC Compliance, contingent on the proposed quality assessment, is essential. This service or abstraction layer would enable users to obtain a Concordium KYC Web3 ID, aligning with global compliance standards. Particularly for KYC Tier 4 or 5, this service would facilitate seamless onboarding and interaction within the Concordium network, underpinning the system’s credibility and operational legality, especially in cross-border contexts.

This would allow a user who created their ID using an eID like MitId.dk to establish a Tier4 base ID which would need less of a KYC process to finalize it, if the KYC ID is abstracted and linked to the Base ID.

These enhancements are not just about improving a technical system; they are about reinforcing trust, security, and compliance — foundational elements to Concordium’s vision and commitment to privacy and regulatory adherence in the blockchain space.

Aside from these primary issues, it’s also important to note the broader privacy implications associated with the current ID system, especially concerning methods of Reveal and / or eSealing and its application in the education ecosystem. Utilizing eSealing without a proper privacy framework risks constructing an illegal data model cross-border, inadvertently positioning ecosystem projects as international data processors, which is fraught with legal and operational risks - i was going to attach two questions which i asked the AesirX Privacy Advisor (official launch 8am dk time today → https://privacyscanner.aesirx.io/ the questions are designed to clarify the GDPR, data-processor and cross-border aspects and differences between reveal and verify logics, however as it is not possible to attach a file instead i will paste it here:

User
concordium is a blockchain that offers 2 main ways to use data: 1 is to reveal your data if you have it stored in your digital wallet you can then show it in person which is legal however the reveal logics is not allowed by a company to use as it makes them a data processor and they can not cross-border transfer the data data, this leads to the other model of verification through zero knowledge proofs, please explain the importance of using verification of data through zero knowledge proofs so that there is no data processing happening and data can be verified systematically, cross-border without legal implications from a legal perspective in relation to GDPR and the ePrivacy Directive

AesirX Privacy Advisor
Zero-knowledge proofs (ZKPs) offer a revolutionary method for verifying the authenticity and correctness of data without actually revealing the data itself. This technology is particularly relevant in the context of data privacy regulations such as the General Data Protection Regulation (GDPR) and the ePrivacy Directive for several reasons.

  1. Minimizing Data Processing: Under GDPR, minimization of data processing is a key principle. Organizations are required to limit their processing of personal data to what is strictly necessary for the purposes for which it is processed. ZKPs align with this principle by enabling the verification of data without the need to process or expose the underlying data. This drastically reduces the amount of personal data being processed or transferred, mitigating risks associated with data breaches or unauthorized access.

  2. Cross-Border Data Transfer: GDPR imposes strict restrictions on the transfer of personal data outside the European Economic Area (EEA) to ensure that the level of protection guaranteed by the GDPR is not undermined. Utilizing ZKPs can circumvent the legal complexities associated with cross-border data transfers because the actual personal data does not need to be transferred or revealed across borders. Only the verification of the truthfulness or correctness of the data is communicated, thus avoiding the legal implications of international data transfers.

  3. Data Controller and Processor Responsibilities: The GDPR differentiates between data controllers (those who determine the purposes and means of data processing) and data processors (those who process data on behalf of the controller). With the traditional data reveal model, companies become data processors when they handle personal data, thus incurring specific legal obligations and liabilities. Through ZKPs, since the data itself is not revealed or processed, companies can avoid being categorized as data processors, thereby sidestepping the associated responsibilities and potential liabilities.

  4. Enhanced User Privacy and Autonomy: ZKPs empower individuals with greater control
    and autonomy over their personal data. Users can prove certain aspects of their data, such as age or nationality, without having to disclose the actual data. This is particularly important in contexts where personal data is sensitive or where there is a high risk of misuse. It also aligns with the ePrivacy Directive’s emphasis on confidentiality and user consent in the processing of personal data.

  5. Legal Compliance and Trust: Implementing ZKPs can help organizations demonstrate compliance with privacy regulations’ data minimization and protection requirements. This not only mitigates legal risks but also enhances trust and confidence among users and stakeholders, which is crucial in the digital economy.

In summary, the adoption of zero-knowledge proofs enables systematic and cross-border
verification of data without the legal and privacy concerns associated with traditional data processing methods. This technology presents a strategic approach for organizations to comply with GDPR and the ePrivacy Directive while fostering an environment that prioritizes data privacy and security.

User
What if i am an educational project that stores educational certificates with eSealing i.e. i then make it possible to reveal by the user, that is ok if the user is there in person but what is the impact on my business if i use a method based on reveal rather then verification and zero knowledge proofs like concordiums web3 id feature supports where i can actually store the entire data in the Web3 ID and make it accessible to verification worldwide with out making me the data processor, is that correct?

AesirX Privacy Advisor
If your educational project stores educational certificates with electronic sealing (eSealing) and allows users to reveal their data in person, you’re initially providing a level of security and control over personal data. However, this approach has limitations, especially when considering scalability, privacy compliance, and the flexibility of data verification across borders. Let’s explore the impact on your business of relying on a reveal-based method versus adopting a method based on verification and zero-knowledge proofs (ZKPs), such as Concordium’s Web3 ID feature.

Using a Reveal-Based Method:

  1. Data Processing Responsibilities: When opting for a reveal-based method, your project may need to handle personal data directly. If your platform facilitates the revealing process by storing and possibly transmitting this data upon request, it could be considered a data processor under regulations like the GDPR. This designation comes with obligations regarding data handling practices, security measures, and potential liabilities in the case of data breaches.

  2. Cross-Border Data Transfer Limitations: Facilitating the reveal of educational certificates across borders may face challenges due to stringent data protection laws, such as the GDPR’s rules on international data transfers. Ensuring compliance could necessitate additional legal mechanisms or agreements, potentially complicating the process and hindering scalability.

  3. Privacy Risks: A reveal-based approach inherently involves exposing personal data.
    This exposure can increase privacy risks, especially if the data is transmitted across networks or accessed by multiple parties. Maintaining high levels of data protection and privacy can be more challenging.

Switching to Verification and Zero-Knowledge Proofs:

  1. Eliminating Data Processing Role: By leveraging Concordium’s Web3 ID feature with ZKPs, your project can verify the authenticity and correctness of educational certificates without processing the actual data. This method reduces your responsibilities and potential liabilities as a data processor because the certificates’ details aren’t exposed or transferred, only the verification of their authenticity.

  2. Facilitating Global Verification: ZKPs enable secure and private verification of certificates worldwide without transmitting sensitive data across borders. This is highly advantageous for international students and institutions, removing legal barriers associated with data transfer regulations.

  3. Enhancing Privacy and Security: Since ZKPs only prove certain truths about the data without revealing the data itself, they offer a significantly higher privacy level. This approach aligns with privacy-by-design principles and strengthens user trust in your platform.

  4. Scalability: Utilizing a Web3 ID for verification through ZKPs could significantly increase
    your project’s scalability. Institutions and employers worldwide can verify academic credentials without direct access to the personal data, streamlining the verification process.

Conclusion:
Although a reveal-based method may work well in controlled, in-person scenarios, transitioning to a verification model using Concordium’s Web3 ID and ZKPs presents several advantages. This shift can dramatically reduce your legal obligations as a data processor, minimize privacy risks, and enhance the global usability and scalability of your service. In aligning with privacy regulations and embracing cutting-edge technologies, your project stands to gain in terms of efficiency, compliance, and user trust

I hope that clarifies the main problems, objectives and also gives insights to the privacy considerations in terms of privacy by design and why verification through zero knowledge proofs is the only path forward for seamless compliance - it can see our differences of opinion but i am quite sure my interpretation of using ZKP is correct.

Regards
Ronni

13

For practical purposes please go to:

Here you can sign up for a Shield of Privacy using your Concordium Wallet.

We use Country + Age to ZKP verify without revealing your personal information so that the Dapp (could be any entity web-based) know that you qualify through ZKP verification, without having access to the data.

Our AesirX Single Sign On can also be 1-click installed in WordPress and if you set it to only allow wallet based logins to the admin, its also using ZKP to verify its you and this ensures that the login is now anti-brute force secured (there are over 100 million attacks on WordPress admin daily).