Global Proof of Personhood with World ID - ETHGlobal Singapore 2024

OK. Hello everyone. I'm Ian. I handle developer relations and partnerships at Tools for Humanity, supporting the Worldcoin ecosystem. And I'm here to tell you about global identity verification with World ID.

So in this workshop I will explain what World ID is, how to integrate it, and what you can create based on it. These are some of the uses it really works well for. So works well for. So , World ID, right? If you have World App, our mobile app, on your phone, you might recognize this little passport, right?

But what was World ID really created for? World ID was created to answer this very big and very important question. How do you know who or what is a real and unique person, especially on the internet, right? AI is getting better and better at everything, well, almost everything. He becomes so skilled at solving captchas that they become too difficult for humans.

And when captchas cease to be an effective way to distinguish humans from bots, many sites will start resorting to methods like requesting a photo of your driver's license or passport, which is bad for your privacy as well as accessibility. Many people don't have government ID cards , right? We designed World ID to be private private , inclusive, and secure, right? Regarding privacy: we don't care who you are, only that you are a real person who registers with World ID only once. We want it to be inclusive.

We want it to be as accessible as possible to people around the world. Isn't that right ? As I mentioned ? As I mentioned , less than half of the world's population has a digital government document, which can make services quite exclusive if you abandon captchas and require people to verify, for example, through a passport. And we also want World ID to be reliable, right?

We want to make sure that when it's used to protect against a Sybil attack, it's really one person—one World ID, right? Other mechanisms ID, right? Other mechanisms that may have been used in the past to protect against a Sibyl attack. For example, the “ For example, the “ one email—one account one email—one account ” scheme didn’t work very well. That's why I had a bunch of free Netflix trials.

So, with all of this, there are many different ways to try to identify that we have a real person in front of us, right? Email or phone don't really work. It's very easy to get a few email addresses or phone numbers, but at least they're available, right? We looked at the possibility of verifying official government documents, but as I said, less than half of the world's population has a government ID that can be verified digitally, and that also creates scalability issues. We investigated trust network systems.

Scalability is a problem there too, isn't it? A network of trust can work great, well, let's say, for a certain community, right? For several thousand people. But most existing trust network systems can't really cover all of humanity, right? They start with an initial group of trusted individuals, somewhere in the hundreds or perhaps thousands of users, who define the initial state of this network of trust.

But to scale to billions of people, you have to be very far from that initial group of trusted individuals. And in a network of trust system: the more links of verification between you and the initial group, the less you can trust the result, as there are more opportunities for fraud. Therefore, we settled on using biometrics as the basis for World ID. And when it comes to biometrics, there are many different biometric indicators that can be used. We looked at fingerprints, facial scans, palm scans, right?

Yes? These are things that palm scans, right? Yes? These are things that people may already be more familiar with, but they don't really scale very well to all of humanity, do they? Touch ID or Face ID on Apple devices can distinguish about one person in 30 million, and for unlocking my phone, I like those odds, right?

In the case of a six-digit password, there's a one in a million chance that someone will guess it on the first try, right? And with Face ID, it's one in 30 million. And it's also not something that can be changed or easily picked up by " picked up by " brute force". Yes? I like that there are only about 14 people in the US where I live who could unlock my phone with their face if it were stolen .

And yes, I feel very, very confident with those odds. If you are one of these 14 and managed to steal my phone, you know what? Well done. You deserve it. On the other end of the spectrum for biometric uniqueness —we looked at DNA, but that's not private at all that's not private at all , is it?

We couldn't possibly work with DNA and still claim that we don't know who you are as a real person, right? Therefore, we focused on the iris of the eye. It has high entropy. She is extremely unique, right? Even identical twins have very different irises.

And that's something that doesn't reveal anything about who you are at all, right? Especially if it's an image in the infrared spectrum, not RGB, right? So you don't even see the color of the iris. You can determine whether it is light or dark, but it doesn't say anything about your personality. It's just something unique to each person.

This hardly changes over time. This is very difficult to change intentionally. And this is not something that can be captured unnoticed. Right? So in terms of how we get these biometric iris scans, we looked at the sensors and cameras that are already in today's phones.

They don't have enough image quality to analyze your iris pattern in detail and distinguish you from all of humanity. There is some equipment for this kind of thing. Again, in the US I use Clear at airports: instead of checking documents, they scan the iris. Similarly, Apple's Vision Pro with Optic ID uses the same iris pattern analysis technology , but on off-the- shelf hardware. It was awkward.

It was very expensive. Often this still did not provide the desired level of detail. So we decided to create our own equipment, right? So our desire to define who a real person is has turned us into a hardware company. If you've ever worked with equipment, you know it's a real headache.

This is extremely expensive. This is very slow. But for such a big and important issue, it's absolutely worth it. Here is the equipment we created. This is Worldcoin Orb.

Orb has been in development since early 2020 and has gone through many different versions. But Orb's job is Orb's job is to make sure you're a real person. There are over a dozen machine learning models running locally on your device, verifying that you are not a cat, a dog, a photo of a person, or a mannequin, right? Orb takes a picture of both of your irises and calculates an "iris code"—a digital representation of your iris pattern—on the device itself. This code is then checked for uniqueness in the MPC system, where the codes of everyone who has been verified are stored, but they are divided into several protected parts.

So no structure has access to your full iris code. Once the uniqueness of the iris code is confirmed, your World ID is considered verified. And your World ID's public key is added to the Merkle tree on the Ethereum mainnet. So, everything here is built with a priority on privacy, decentralization, and open source, right? We never ask for your name, email address, place of residence, passport number, or anything like that, because we don't care who you are, only that you are a real person.

As for decentralization, right? When it comes to porting World ID to other networks, you can link these routes from the Ethereum mainnet to other blockchains without permission. The Worldcoin Foundation focuses on decentralizing the protocol at an even lower level, right? We are exploring the possibility of involving other companies in the creation, production and operation of orbs, or even developing alternative devices from scratch. Regarding open source: every smart contract we deploy on the network as part of the protocol is open source and available on GitHub today.

95% of the Orb's hardware is open source, as is most of its software, and we are gradually opening up everything that is not already in the public domain. So, World ID has a lot of different potential use cases, right? Knowing that your user is not a bot, that they are not performing syphilitic attacks, and that they only have one account per real person can be useful in many scenarios. Voting is one of the most obvious examples, right? You want to know that every vote was cast by a real person, but at the same time you want the vote to remain anonymous remain anonymous .

In terms of social media, we see that paying $8 a month for a "tick" doesn't really help fight bots on one very large platform, which I won't name, but you probably know what I mean. On the airdrop issue, you obviously don't want to deal with airdrop farmers and Sybil airdrop farmers and Sybil attacks. And customer incentives are something I personally find quite interesting, right? I mentioned the Netflix free trial earlier. I always say that one of the most important use cases for World ID would be to bring back the Netflix free trial , because the problem was that people never paid for the service.

They simply created a new email, got another free two-week access, and two weeks later did it again. With World ID, since you as a person only have one ID, if they restrict access to the free period through World ID, they will know for sure that it is a real person that it is a real person , not a bot. they get this free trial and if you try to get it again with a new email you will still only have one verified World ID to use. So, you will only be able to use this free trial once trial once . And if you want to finish a season of a series you left off in the middle of after the two-week trial period ends, you'll probably have to pay for Netflix.

We also made World ID integration super easy, right? You can use it in web applications, mobile applications, and on-chain projects. There are two main ways to integrate World ID. Sign in with World ID, which is pretty similar to signing in with Google, Facebook, or Apple, right? This is the same standard, and there are also incognito actions, which are more custom, more powerful, interact directly with the protocol, but require a little more manual configuration.

So let's start with how to use Sign in with World ID, but first I'll show you what it looks like in practice and log into our developer portal. So, developer.worldcoin.org is where you can find our developer portal. I'll click "Login" here.

I'll select "Sign in with Worldcoin" and I'll be shown this QR I'll be shown this QR code. Now in the World App, I will scan this QR code and then authenticate with my World ID to log in to the developer portal, and then it will redirect me further. Perfectly. Now I'll quickly show you how to create a new app. For the application name, let's choose, for example, ETH Global Singapore.

I need to choose between a staging and a staging and a production application. For the test app, I will not use World App as a user. I will use a simulator and talk about it in a little more detail later. If you are using your application application on-chain, then for test networks, choose staging, and for main networks, choose and for main networks, choose production. Next, you need to choose cloud or on-chain.

So if you want to use Sign in with World ID, you need to choose cloud. For incognito actions, you choose cloud or on-chain depending on where you will verify evidence with zero disclosure. And again, I'll talk about this in more detail later. Since we're focused on Sign in with World ID, I think it's worth giving you a little introduction to the developer portal developer portal . So let's create a test cloud application here.

And for incognito actions I can create a separate create a separate action. But let's just take a look at Sign in with World ID, okay? I will get a customer ID. I'll get the client's secret here. I will add some redirect URIs.

And any OIDC library you use should explain this in a bit more detail. So, now that we know where our client ID and secret are and where to add the redirect URI, let's look at how to integrate World ID login into our application. There are many different ways to integrate OIDC, Open ID Connect, right? This is the standard used for logging in through Google, Facebook, and other popular authentication services. Auth0 is one way.

NextAuth.js is a way. NextAuth.js is a great library for this. This is what our template repository uses template repository uses .

You can use your own OIDC library with our OIDC well-known file to quickly configure everything you need. You can implement OIDC flows yourself. But I recommend sticking with NextAuth.js. This is usually the easiest, most flexible, and convenient option to get started with, and as I said, we use it in our template.

So, with NextAuth, to support World ID login, you only need to add this piece of code, right? This is a snippet for one provider, and again , you don't need to take a picture of this; everything is in our repository. I promise it's much easier to copy code from GitHub than from a photo on your phone. But I want to break it down here so you understand what's going on. You set ID as the name of your authorization provider.

Here I mentioned the well-known file mentioned the well-known file , which contains many machine-readable settings for logging in via World ID as a provider that other applications can use. It tells you where to exchange the authorization code for an access token, right? All these really important details that you don't want to worry about. You just provide this link and it already has all the configuration. Now we have the client ID and secret that we configured in the developer portal, and we match the information obtained from World ID with the user profile.

True? In OIDC terminology, this " OIDC terminology, this " sub" is simply a user ID. Since we don't know the username in World ID , we simply return this "sub" as the name of that user. Um, in this case, sub is a revocation hash, a unique identifier for a user in the context of a particular application or action. So, this means that when I use my World ID to log in to two different websites, they get different IDs from me.

So even if they try to exchange databases, they won't be able to find out that I control these two accounts on both platforms unless I decide to give them different information. True? I could set my display name on both sites as Jan Dilik, right? I could use the same profile photo, but World ID doesn't provide that information. This is information I choose to provide on my own.

Likewise, I can be completely anonymous on one platform and completely de-anonymized on another, right? But there is no way to de-anonymize this account just because I revealed my identity on another account where I used World ID login. No one, not even WorldCoin, can say that these two accounts belong to the same person. Another thing we return in the profile is the credential type or verification level, right? We talked about verification through Orb, remember?

Using the iris code ensures that you are unique and have only registered a World ID once, but we also have what's called a device verification layer device verification layer , where after you install the World App on your phone, the program checks to see if it's real, right? Not a virtual machine, not some Android app cloning environment , and this provides a better- than-usual defense mechanism against Sibyl-type attacks, right? This doesn't prove you're human, right? But that at least confirms that it's a real mobile device, right? So the cost of the the cost of the Sibyl attack, right?

The cost of each additional device-verified World ID you wish to obtain will be equal to the cost of another mobile device that supports World ID and the World App. So, device verification level is useful for accessibility, right? Users are not required to visit Orb. They only need to download and install the World App, but it is not as secure as Orb credentials. So thanks to this, depending on the user's verification level, your app will know if it's someone verified through Orb or just through the device.

You can give more privileges or a sign-up bonus to someone who is verified through Orb, which you wouldn't give to someone who is only verified through a device. It's entirely up to you. That's all you really need to know about need to know about how to integrate a signature with World ID. This should be very, very simple, right? I was talking to someone earlier and they asked, "Am I eligible for a reward if I just integrate the signature with World ID?"

And I said, "Yeah, that's actually the point, it should be that easy, right?" Protection against bots and bots and sibyl attacks is useful for almost any application, and protecting your application from such attacks shouldn't be a difficult task. And now I'll talk a little about incognito actions. With anonymous actions, you know that your user is a unique person who performs the action only once or as many times once or as many times as you want, right? This can be an infinite number of times.

It could be three times, ten times, but most use cases limit the user to performing the action only once, right? For example, social media account verification, right? In the case of voting, for example, this signal could be signal could be who you vote for in an election in an election , right? Something where if this value is even slightly different between the moment the proof is generated and the moment it is verified, the proof will not be confirmed. The basic process here is this: you integrate our widget into your application, and it will show the user a QR code.

The user scans this QR code, and this will let World App know for which application and action this zero- disclosure proof should be generated. A zero-disclosure proof will then be generated when the user clicks the button to generate it. The zero- disclosure proof is then returned to your application, which verifies it using our smart contracts onchain or via our developer portal API offchain. Yes. So let's see what it looks like from the user's side.

For this, I will use our simulator instead of World App. Yes. So, for the test action, we have some kind of made-up action ID here. I click "Continue with Worldcoin" and it opens ID Kit. For a product application or if I want to run the simulator on my phone, which is also possible, I would scan this QR code with the camera.

But for a test app, to make it a little easier, you can just tap on the QR just tap on the QR code to copy all the information from it. In the simulator, click "Insert Code" and paste the data. Yes, I allow insertion. And it works exactly the same as scanning a QR code from my phone. So now I'll click " now I'll click " verify via Orb verify via Orb " because I've configured this action to require the Orb verification level.

But for the simulator, you can choose which level of verification you want to use in the World App. It will simply use the Orb verification level if you passed it, or revert to the device verification level device verification level . So, I click " . So, I click " verify via Orb verify via Orb ". The simulator creates a proof, sends it back to IDKit, our frontend widget, which calls our developer portal API to verify that proof.

Pretty simple proof. Pretty simple , right? So, everything for your World ID integration starts with IDKit. IDKit is commonly used as a React widget. We have a pure JavaScript version.

If you are interested. We also recently released Swift and Kotlin libraries. We have a Rust library that is sometimes used. So, if you're not using the React version or pure JavaScript, you might pure JavaScript, you might want to come join me at the booth and we'll discuss the details of using the other libraries we provide. But here it's just one React widget.

We have the application ID from the developer portal. An action that we again configure in the developer portal. You can create multiple such actions for a single app ID, or just one . OnSuccess and handleVerify are two callback functions that I will talk about a little later. And then we can set the minimum level of verification that we want to require.

If you are using TypeScript, we have a list of verification levels where you can simply specify verificationLevel.device or .orb. By default, it requires Orb verification level. Yes?

So this zero- disclosure proof that you get from World App looks like this. You have the root of the Merkle tree that you need to check against. You have a nullifier hash, which is a unique identifier for the user in the context of your action. You have the zero- disclosure proof itself, which is this very long hexadecimal string. As well as the verification level with which the user created the proof—this proof response is used as input for the handleVerify and onSuccess callback functions.

Of course? So onSuccess callback functions. Of course? So , we get this proof and use it as input for this callback. But we have to test this evidence, right?

I cannot emphasize clearly enough that we must test this evidence. If you don't verify this evidence, zero disclosure, okay? If you just output this to the console and say " console and say " great, let's move on," you won't be able to get our rewards, okay? You should verify this confirmation. So, one way to verify this confirmation is through our developer portal API .

You can take this confirmation and pass it back to the backend of your application. I saw several phones go up. We again have a repository template for this. All the code you see here is publicly available on GitHub. So please, I don't want to deal with how to help people transcribe it from pictures on their phones.

So, you pass this confirmation object to the backend of your application. We have a helper function verify cloud proof for calling our developer portal API, right? And you pass it that confirmation, the app ID, the action, and the alert that you set up, right? Make sure the signal exactly matches what was in IDKit. After that, we will receive a response code of 200 if the verification was successful, or 400 if for some reason it was not.

With these callback functions, handleVerify is great for validations via the Developer Portal API, as IDKit will call handleVerify as soon as it receives confirmation from the World App. And if you throw an error in the handleVerify callback function, that error will be beautifully displayed in World App or, sorry, in IDKit. So when you're in a situation where you can instantly take a confirmation, pass it to the API, get a success response, and show it to the user, it usually creates a better user experience. OnSuccess is called when the IDKit widget closes. So if you are performing a validation check via the Developer Portal API, in OnSuccess you can redirect the user to the next page since they are already validated, right?

And one more note: if a user verifies their account once via World ID, and you store information that their account is verified, you should update that user's data in your backend database , right? Don't send a message to the frontend about successful verification and then make another call to your backend from the frontend to let you know that the user is verified. Of course? Keep everything within the safe context of your backend as much as possible. Now for onchain verification: it's a little more complicated, but it's actually not that difficult.

So, in our constructor, we will set the World ID router contract address, which you can find in our documentation. I'll be happy to help you find this for any network if you come by our booth. You will set the App ID and Activity ID in our developer portal as before. And we calculate the external nullifier, well, in Semore terms, right? the protocol on which World ID is based.

This is an area of ​​uniqueness for what you do. For us, it's simply hashing the application ID and the action ID in a certain way. Overall, it's not very interesting. We have code that does all of this, so you don't need to worry about it too much. And then we will have a function, which for our example we will call verify and execute.

Right? This happens in your smart your smart contract. You will get the signal, root, nullifier hash, and confirmations returned from IDKit, right? In applications that use on-chain verification, we rarely see the use of the handleVerify callback function, instead, the on success callback function is more often used to temporarily store a verification object from IDKit, which is then used as input to call a smart call a smart contract on the network. So, in this function we have a mapping of nullifier hashes to boolean values, which should have been defined in the constructor, but wasn't.

It's my fault. This is simply a check to see if we have seen this nullifier hash before, and if so, we cancel the action, as we only want to allow users to perform it once. The key difference between on-chain difference between on-chain verification and cloud-based verification of confirmations is that for cloud-based verification, our developer portal tracks how many times users perform an action. You can set how many times you want to allow them to do this. For on-chain do this.

For on-chain verification of confirmations, you have to do it in your smart your smart contract yourself contract yourself , right? And this is an example of how to allow the user to do this only once. So, after making sure they haven't already done this action, we call verify proof in the World ID router smart contract, right? We pass the root. The group ID will always be one because we only support the Orb verification level on the network.

If you want to use the device verification level, you must verify the confirmation through our developer portal API . So this group ID will always be one. We hash the signal in a certain way for this confirmation verification. We pass in the nullifier hash, the external nullifier defined in our constructor, and the confirmation itself. If something in the confirmation fails verification, it will be canceled.

If the check is confirmed, it simply continues. It doesn't return a value or anything like that. It simply stops further execution if something goes wrong. Otherwise, we will simply proceed to mark this nullifier hash as true in this mapping to prevent the user from performing this action again . And after that, you should implement the functionality of your smart contract to do what is needed when you know that the user is verified via World ID.

This could be a token issue for them. This could be storing the wallet address in another mapping to know that this address has been verified via World ID, and checking this for other actions in other functions of your smart contract. But your functionality should be after everything I described here. And again, we have a repository with a template for this. We have $20,000 in prize money.

It's pretty simple. Use World ID for tasks where protection against bots or Sybil attacks is useful. Be creative with this. Uh, and we also have two separate prizes for use cases in governance and public goods. For the prize pool, again, you have to check the confirmation.

You have to integrate World ID correctly, you have to make an effort to integrate World ID correctly, right? But if you just add the kit ID to your package.json and don't use it anywhere , you won't get the prize pool. Sorry, but no. So, that's all you need to know.

You can go to worldcoin.org/sg24/pacsg24 to see the Notion page with a lot of the information the information I've shared here, including our template repositories. And if you have any more questions, please questions, please find me at our booth and I will be happy to help you.