Presentation for IMF and World Bank

Yeah.

All right, so you all should be able to see my screen. Can you see that?

Yes, we see it. Thank you.

Wonderful. So at UnumID, what we're all about is creating one identity online for each human offline. At a very high level, and this is really important for framing the rest of the conversation, It really is all about creating that glue that does not exist today between an offline human being in the world of atoms and their online identity in the world of bits. That is the glue that UnimyD is creating. So just a little bit about the leadership team so you know who we are, who you're talking to today. I actually co-founded UnimyD about 4 years ago with my brother Liam while both of us were at Stanford, as Sonia alluded to. Both of us have backgrounds in STEM. So Liam has background in physics. He's been leading our tech and product and actually wrote a book all about the problems of big data centralization called Data and Power. And my background outside of STEM is in startups. So I ran a social entrepreneurship incubator for a couple of years called Senza Labs, taking some of the most innovative early-stage startups with an impact mission in the Valley and giving them access to resources to succeed. So some awesome companies came out of that. And also helped to teach a class called Hacking for Defense about bringing innovation from the Valley into the DOD to solve national security problems for the US. We have some amazing advisors that you can see below, including Greg Roston, who's the Director of Public Policy at Stanford. And we actually came to identity through the lens of politics. So about 5 years ago, we started realizing that in the American political system, there's a huge identity problem. When people are trying to contact elected officials or federal agencies, there's entire industries of astroturfing to create bots and fake accounts, make it look like there's grassroots uprisings in specific districts, specific states, when those actually don't exist, and trying to inspire action based on those initiatives. So we started realizing back then that it's a problem here. It's a problem in the political system, and it's a problem across many other industries, as Sonya was mentioning as well. And it's an even bigger problem, of course, in developing countries around the world where it prevents access to voting rights. It prevents access to capital for things like loans and starting businesses and credit lines so you can purchase things and make your family better off. And we realized very quickly that this is one of the most foundational problems on the web today, is that identity is foundationally broken. So that's the story about how we got started here. And we've been doing it now for about 4 years full-time. We're also backed by some awesome investors, so some Stanford profs, Samsung Next, Draper Associates, and most recently Franklin Templeton, who we're excited to have as a strategic investor as of actually this week. We are the leaders in what we call "share-ified identity" or shared verified identity. So what our software does is it links many verifications about a user into a single identity that can be shared across entities. Whether those entities are government agencies, NGOs, nonprofits, for-profits, some combination of all of the above. It doesn't matter. We do this by creating a one-to-one connection between a digital identity and an analog person, as I mentioned a couple of times already. And we describe that as a two-step process, which I'll be going into more detail in, in just a second, of biometrics and behavioral authentication binding a person to to their device, and then cryptography binding that device to their digital identity. You'll note also in this diagram that you see that digital identity corresponds to many accounts. So you can use this in a pseudonymous way with many different organizations to share the exact data that they need to service you and nothing more. This effectively turns any mobile device into a virtual ID card that can securely store each user's data locally on their device and then encrypted cloud backups of that device. We use the user's phone as a secure identity wallet, leveraging the best-in-class biometrics and cryptography that are available on the market tied to the phone's secure hardware element. And a really critical thing, especially in this discussion, is this works for smartphones and for feature phones. And you might be thinking, okay, well, how does this work for a feature phone that doesn't have a secure hardware element? Well, you just have to add an additional step. So we essentially emulate exactly what would be happening on a smartphone in the cloud and give them access to that wallet over SMS, RCS, or by other means. And the point here is to get ahead of the curve. I think a lot of you are very well aware of this, I'm sure, but the future of commerce is mobile. 5 billion people around the phone have— around the world have a mobile phone. 4 billion of those are smartphone users. And it's estimated that by 2023, mobile device users will go up to 7.33 billion. That's almost everybody in the world having a mobile device. And 3 in 4 of all internet users will be using only the phone to access the web by 2025. So not only are there more mobile devices, more mobile device users, it's also becoming the primary portal by which people choose to interact with the web. COVID-19 has, of course, only accelerated these sorts of trends. And we've seen this borne out time and time again in our interactions with governments and companies over the last year. The goal of all of this is to create seamless commerce. Every industry you can imagine needs a better digital identity solution. This is another thing Sonja hit on the head at the very beginning. Whether it's healthcare, government, gig economy, financial services, e-commerce, retail, you name it, digital identity is broken for them. It's broken because they're getting breached. It's broken because there's high rates of fraud, because it's incredibly inefficient and expensive to administrate digital identity centrally. It's broken because it takes a ton of time for the end user, and it's broken because 1.1 billion people don't even have a digital identity in the first place to transact with these sorts of organizations. All of these are the reasons why McKinsey estimates that digital identities will unlock 4% of GDP globally a year by 2030. That's good digital identity. It's the kind of digital identity I've been describing to you so far. That's usable, secure, has user consent and privacy embedded by design and these sorts of characteristics. That's, of course, about 2 to 3% of GDP in developed countries like the US and 10% or more in developing countries around the world. And it's easy to see why, right? It's foundational to every interaction you have. This is also why the UN has as one of their core sustainable development goals giving everybody in the world a digital identity, of course, with an emphasis on the 1.1 billion people that don't have access to any sort of identification today. So how does this work in, in a little bit more detail? So I mentioned biometrics, behavioral auth binds person to their device, cryptography binds that device to their online identity. What we're actually doing on that device is we're creating with our software an UnimID wallet. Now, this is not necessarily a mobile app that you can download. This could also— this can be a mobile SDK in another company's app or another organization's app. It can also be an emulated wallet in the cloud. And what this does is it stores personal data and private keys in an incredibly secure location that's locked behind biometrics or some sort of PIN or behavioral authentication factors. And I'll get into that in more detail, I'm sure, in the Q&A. And it cryptographically signs credentials and sends them to different places. We also then tie that to a blockchain-based record. So that private key that's in the UnimyID wallet for each user, we put a public key on the blockchain. We do the exact same thing for every entity that they could interact with, every government agency, every NGO, every nonprofit, every for-profit company, every bank, every healthcare service, you name it. And what that creates is a shared zero-trust gateway a database of unique immutable identifiers. This is not personally identifiable information. It's not sensitive, but it gives you a record that everybody trusts that they can use signatures generated from private keys to check against and make sure they're always interacting with people that have been validated on the system and entities that they trust. So in a little bit more detail here, over on the left, you see the 4 primary components of what we provide at UnimyID. SDK, as I think Sonia was pointing out in some of the chat here, refers to software that embeds in some existing system. So we're essentially providing code. You can think of it a little bit like Stripe, if you're familiar with that, that goes into another existing platform. So on a website, web page, inside of a mobile app, on a server backend that a company or organization has stood up, et cetera. And essentially all that happens here is we have an identity engine. That suite of SaaS APIs. So things that programmers can call to do things like issue data to each user, revoke data from the user, request data from the user, and handle any sort of these complicated identity tasks in a way that's incredibly streamlined and seamless. We also provide, of course, this mobile SDK, the one that's turning it into an identity wallet, server SDK that handles all of the cryptography, and a web SDK so anybody can pop open a website, and start asking for these credentials. Anybody that's, of course, a valid entity that you trust. And this is super simple to do. It integrates on top of existing systems. So this is not designed to rip stuff up, right? So when we talk to governments, for example, that already have maybe hundreds of thousands of records in a centralized database that have a username and password flow that a lot of people are used to going through and they've already got that set up. Well, this is not designed to immediately replace that. Entirely. Instead, it's designed to sit on top to provide additional access, security, and usability. And all that they have to do is plug our software into their existing systems. The user doesn't have to download our app. They don't have to create an account with us. They don't even have to have an app at all, right, if they're using a feature phone. And they can use this system to securely and seamlessly authenticate themselves everywhere that they go. So here's some key design features of UnimID. It's key to note here that this is a totally new paradigm for how identity works online. It is not about storing lots of data centrally. In fact, we have literally no access of any kind to personally identifiable information. There is no way that we could access it. It's encrypted when we touch it, we route it to a user's wallet, and we couldn't access it. Even if, say, we like to say if the FBI came to us with a warrant, and demanded that we gave them some person's PII, we couldn't do it. There's not— it's not possible for us to do. Some design features of this: it's white label, right? It embeds in existing systems to deliver a frictionless experience. It works online and offline, so it works over Wi-Fi, cell data, no network at all, you name it, it'll work in that situation. There's decentralized storage, right? So it's not about centralized storage, it's about pushing it to each user's device or to a cloud wallet that's under their control. This limits honeypots and it limits legal liability. It's auditable, it's tamper-resistant, so the blockchain stores an immutable record of everything that's happening, all of the transactions, and a decentralized single source of truth for all of the identities in the system. There's context-adaptive MFA, so we can ramp up biometric and behavioral checks to whatever standard you want. So if you need 99.99999% certainty, that this is the actual person when they're interacting, say, with a really high-security government system, we can do that. We do it by layering independent biometric and behavioral checks back to back. So for example, Face ID followed by typing-based behavioral authentication followed by a PIN code followed by, et cetera. It's a hybrid deployment. So it's cloud-hosted and on-premise. So there's on-premise components that the institution will host that handles all of the cryptography tasks while we have a cloud API. You know, everything's going to the cloud, of course, that people can use to simply handle all of the complicated tasks involved with administering this kind of system. The reason that that's really key is that means we can handle all of the identification tasks locally. That means there's nothing that there is being sent around that can be intercepted. Or used to breach the system. It's also omnichannel and passwordless, so it works anywhere. It works if you're calling into a call center, walking into a physical location, logging in online on your tablet, on your phone, on your desktop computer, talking to a chatbot. Whatever the case is, it works in that situation, and it works with no passwords. It also has bidirectional authentication. So most authentication schemes, right, go and try to see, is this actually Aidan? Is this actually the correct user that's accessing the account? Ours goes both ways. It of course does that, but it also says, is this actually the correct bank? Is this actually the correct government agency? And that prevents against phishing attacks and makes it essentially impossible to breach this system through existing account takeover methods. Again, this is a paradigm shift. So traditional identity is all around centralized storage of sensitive data. Sometimes for good reason, sometimes just for, you know, doing AI algorithms on it. Shared secrets, right? It's all around passwords and biometrics and other kinds of increasingly sophisticated shared secrets, even OTPs over SMS. And centralized control and administration. So it's all through, you know, big centralized databases that have complete control constantly over what's going on. Modern identity looks a little different, right? It looks like a single source of truth, a sheriff identity across all of the business units, subsidiaries, partners, suppliers, government agencies, et cetera, that can just be used seamlessly everywhere. You don't have to anymore have every single organization independently collect troves of personal data and try to run anomaly detection algorithms to figure out if there's something going on. Instead, you have a single distributed source of truth, that they all contribute to and they all benefit from. It leverages biometrics and cryptography that can be resolved locally on the person's device or in the cloud, in the case of a feature phone, that has no shared secret. So there's literally nothing to steal. It gets rid of the problem associated with fraud and breaches, which is you steal a secret and you use it to access the system. In our case, the secret is the physical device and the physical person that's accessing the account. So unless you have those two factors, there's no way to access it. You'd have to physically coerce somebody to make that happen. It's also private and distributed. So it has user consent, privacy baked in by design, and the simplicity of something like SSO everywhere. So it really is this ID card that you give to somebody that is contributed to by all of the organizations they interact with that enables seamless commerce with all of them. There's a couple of key things I want to point out that we talk about as value props with government agencies, with NGOs, and with for-profits, of course. One is that it prevents data breaches. So over on the left, what you're seeing is a graph of the world's biggest data breaches and hacks since about 2018. To orient you on this, the Marriott Hotels breach, which breached 380 million records, is this little circle. In the bottom of that graph. This is why breaches cost $2 trillion annually to companies around the world, and this is a club that nobody wants to join. The problem here is two things. One is that companies and organizations store personal data in centralized databases. They're honeypots, they're single points of failure. You only have to breach one thing. And the second is they rely on shared secrets to access those honeypots. So they give their employees credentials to go ahead and access that. And the problem is that if you breach that credential, now all of a sudden you have access to troves and troves of user data. And this happens time and time again. Something like 86% of all breaches involve the use of a stolen employee credential. So with Unum ID, you can solve a lot of these problems. It's not going to get rid of the problem overnight. You still have to store a lot of stuff centrally, we get that. But you can at least mitigate it. You can at least reduce the risk that you have to your organization. And you do that by eliminating shared secrets, as I just talked about, but also by storing this data at the edge. We like to say with UnumID, an attacker would have to hack 1 million independent devices to get 1 million people's data, not 1 database. And maybe even more accurately, 383 million people's independent devices in the case of Marriott Hotels. Another point here is that you can secure the gold mine. So these organizations have a goldmine of data. That's why they're subject to things like breaches. We stop a lot of attacks on this in their tracks. So I'm highlighting two here that are common in account takeover situations. There's many more that are similar to these that I think you can get by inference. Those two are SIM swapping and phishing. So SIM swapping, of course, the problem is somebody will call up your carrier and say, hey, switch that number over to me, I'll pay you a few bucks, and I'm gonna intercept this OTP that you're gonna send this person. And now I can get into their account. And I can do things like transact on their behalf, maybe vote on their behalf if you're using this for digital voting, et cetera. The key insight here is there's no reliance on SIM. You're relying on a physical device and a physical person. And in the case of feature phones, in an emulated device that you're accessing via PIN and a physical person that's remembering that PIN. In the case of phishing, it's somewhat similar, right? I mentioned bidirectional authentication. There's this trusted group of entities, there's this trusted group of users, and they're authenticating each other to each other both ways, all with public-private key cryptography, the same stuff that powers HTTPS on the web. And the key insight here is that you literally, as an attacker that's gonna put up a website, cannot generate a valid request in our system. The only way you can generate a valid request is if you have a valid private key. So unless you steal a private key, which would be unbelievably difficult to do, there is no way that you can even create a valid request to try to phish somebody. Let alone actually get there. So the competitive landscape looks a little bit something like this. To orient you here, there's questions on the left. The yes and nos are answers to those questions. The green means good and the red means bad. There's other identity organizations over on the right, which are a little bit more tangentially related, and there's blockchain or decentralized identity startups on the left, which are much more similar to what we're doing. The really, the two columns I want to highlight first on the other identity organization side would be government ID programs and verification providers. I think it's more self-explanatory how IAM and password managers are distinct from us. So there's a number of government ID initiatives I'm sure you guys are extremely well aware of. Things like SecureKey, WKVerify, SingPass in Singapore, the BankID in the Baltics. There's a whole bunch of them. There's more that are emerging. The common trends that we see with these are that they're centrally administered. They run into a lot of kind of bureaucratic hurdles. They're not about really binding it to a person offline. Most of them are some sort of glorified version of OAuth or similar standards. SecureKey, for example, will have you log into your bank so that you can then share data with telcos and government providers. There's certainly interesting models. A lot of them have had some success. SecureKey, certainly in Canada, has done, I think, some amazing work. But they're really V1 of digital identity, I would say. Whereas where we're trying to go is something that is maybe even jumping over V2 to V3, right? It's something that is private and secure and does not rely on these shared secrets that even SecureKey and others rely on. It is much, much more robust over time to bring in other entities and enable seamless commerce. I can get into the really nitty-gritty of all of the details in that in the Q&A if you guys are interested. The other one here is verification providers. So there's a million companies like Onfido and Trulioo and Jumio, and I can go on, that do essentially the same thing. They do things like scan a driver's license, match it to a live photo of a person, or scan a passport, match it to a live photo, and return some sort of result, right? Return, yes, we think this is actually Aidan with 95% certainty, and our OCR stuff says that this is his data that we pulled off of his driver's license. This is a valuable service for a lot of different organizations. Hopefully from what I've presented so far, it's clear how it's distinct from what we're doing. These organizations prepare and present identity data, and they say, they make claims. In other words, they'll make a claim about me at a given point in time. What UnumID is all about is taking claims that organizations like Unfido, like Trulioo, like banks, like government agencies make, and tying them all together to a single person really robustly, right? That glue that I talked about at the very beginning, so that it's reusable over time and enables seamless transactions. So now over on the left, there's a number of decentralized identity startups. Of course, this is a small sampling. I feel like there's more that are launched every day. This is very hot space right now. The ones that I chose for the slide are primarily the ones that are best funded or were earlier in the space. So these are Civic, Bloom, Avernim, and Cambridge Blockchain. So I can go again into an amazing amount of detail if you like, maybe later in the Q&A. A couple of key things to point out right away. We have no cryptocurrency. That's unique among especially the early players in the space. So companies like Civic and Bloom raised a lot of money on an ICO and then have run into significant issues because nobody, of course, wants to use their startup cryptocurrency for transactions. And if they don't use it in their ecosystem, you know, now they're liable with the SEC. SEC. There's also others like Evernym, Cambridge Blockchain, and a number that I would classify along similar lines. And a key insight here is that these organizations rely on one, maybe two different blockchains for what they provide. Now, the problem with that I can illustrate through a quick anecdote, which is Evernym early in the space, right? We're running a number of POCs with some big organizations. One of those organizations was IBM. So they're working with IBM. They were running it all on their sovereign blockchain, which they run everything that they do through. And the problem was that they made an update to the chain that allowed anybody to write to it. So anybody to put data on the blockchain. Now, the issue came in when people, just independent developers, started putting PII on the chain. They were doing some development. They weren't very careful, a little bit sloppy, and they put it on there. And IBM's lawyers freaked out and said, This is a GDPR violation. We're on the chain, they're on the chain, there's PII on the chain. This is not OK. And that actually resulted in them coming to us and saying, hey, we're looking for a new provider. We can't deal with this anymore. So it's really critical that you don't lock vendors into a given blockchain, and certainly that you do not have your own proprietary blockchain when you're going about these things. So to just— I think this is my last slide, and I would love to jump into Q&A. But just to clarify some of what I was just talking about. Our business value here and our value to NGOs and government organizations is informed by extensive customer discovery, right? So all of this for us is about delivering value to the people that are using it and the companies and organizations that use it. And we've noticed that organizations are not ready for cryptocurrencies. They may be ready for Bitcoin in some niche cases. They are not ready for startup cryptocurrencies like Bloom and Civic. They do not want blockchain lock-in, so we provide a solution that's blockchain agnostic. We support many chains. You can choose any of the ones that we support, whether it's Hyperledger or that's Ethereum or that's EOS or no blockchain at all. We can also do this on just a private database, which a lot of organizations are more comfortable with anyway. They want the option not to use a third-party app. Well, we provide a mobile SDK, right? We provide something that plugs into the existing infrastructure. They don't want to destroy existing infrastructure. So it's an add-on SaaS, right? It sits on top of what the organization is already doing to provide additional value, additional usability, security, and access. And they need it to work for everybody. This is device agnostic. It works on Apple, it works on Samsung, it works on Google, it works on feature phones. It works even if you have no phone at all. So this is really designed to be an incredibly flexible solution, all based around best-in-class biometrics, behavioral authentication, cryptography, and technologies like that. So thank you so much for listening. Happy to jump into a little bit more detail here in the Q&A.

Thank you very much for this super informative presentation. I personally learned a lot about something, novel approach to digital identity, but I actually, while you were presenting, Aidan, I kind of chatted up our cybersecurity expert, Majid. And sorry to put you on the spot, Majid, but I chatted and asked him, or actually I commented, I was like, I'm sure you have questions. So I would give the floor to him first, if you don't mind. And then I think Tao, Tao next, and then I'll just park my questions for later. I'll yield the floor to Majid first. Majid, please go ahead and then Tao.

Perfect. Thank you, Sonia. Thanks, Aidan. Thank you very much for the presentation. Informative information. I had a question about the onboarding process because you're dealing with biometrics, and biometrics basically deals with, with some characteristics of the human. Who does the, the onboarding process? And basically, you know, who verifies it and approves the request? Where does that fall in, in your line of, you know, of the chain of processes that you've described?

Yeah, Majid, really great question. I'm going to answer it from the perspective of a smartphone. Obviously, the answer is different depending on the context, right? So to give you the full answer would take a little bit longer. Happy to dig into that if that's also of interest. In the smartphone case, the way that this works is an organization either has an existing mobile app, and that's the easiest case, so I'll run through that first, and I think you can probably extrapolate how this would work if they didn't have a mobile app existing in the first place. So if they already have a mobile app, let's say it's an organization that has, I don't know, 100,000 users that have that mobile app downloaded. What we do is we come in, we integrate the SDK, so we integrate our software inside of that mobile app. That amounts for the end user effectively to an app update. So the very next time that that user logs into their account through whatever mechanism they currently do, right, usually that might be a username password followed by OTP over SMS, You trust that that user at that point in time is actually them, right? That that's actually them that's holding this phone and this phone relates to them. At that point on your backend as the institution, you call one of our API endpoints. So essentially what you're doing is you're saying, yep, we at this point trust that it's Majid, right? That now creates a private key inside of that user's app on their phone. And a public key that is now posted to the blockchain. That can now be used to authenticate at any later point in time. To the point of biometric enrollment, really great question. So the cool thing about mobile device use, right, is you can piggyback on Apple and Google and Samsung and all of the biometrics that are locally on the phone that almost everybody already has set up, right? So if you've got Face ID already set up on your phone, we can rely on that as the base biometric factor and you're pre-enrolled. Because you've already set it up for your device for all sorts of other things that you're using it for. So there's a lot more subtlety here. So I'm happy to go into more detail if you have additional questions on top of that.

Thank you. Thanks for answering the question. Because the question basically, what I'm just trying to reach is that when you're dealing with the biometrics of the phone, it's a device type of biometrics. It's not specifically connected to the identification that you're you're trying to, me, myself, because it could be somebody else and it's local to the device. So there is that, and maybe I'm sure when I look at the white paper, there's that connection, but the connection between the specific person and the device and then the device and the biometrics is where I think the line has to, for example, I'll just give you an example. In Saudi Arabia, they do have biometric connected to the phone itself. So they've, they've went that far to say, okay, you go and you do your biometric at a specific center and you connect the, the number to that specific person with the biometrics. So you already have that connection to rely on. So I think with, with your example, um, there is, there is definitely, um, some other way. You mentioned also the behavioral biometrics as well. Could you elaborate on the behavior? Because I've seen so many approaches to that. What's your approach?

Yeah, so our approach on this, and you're getting to a really great point, right? So as I mentioned, there's a lot of subtlety here to get into, so it's a great point to be pushing on. So in terms of the biometric that's resolved locally on the device, that's a great base level that's good for most things that you want to do, right? It's quite secure. Most people aren't sharing their phone login with a lot of people. If, of course, you read the iOS, Android security specs, it's really just an alias for the passcode. So you're really just relying on the passcode. But it's very difficult for most people to get into your phone unless they're loved ones that you explicitly given access to. And you probably want them to be able to take most actions on your behalf anyway. The other piece of it, right? So you're talking about behavioral checks. And that's a different one, right? So that's not something that's pre-enrolled. So that's not already set up on the user's device. And so for those sorts of things, you need to get the user enrolled in the initial setup process or at some point down the line when you think you're going to be using that in the future. And how that process works is we work with a variety of different vendors. Some of it we do in-house, but most of it we do through vendors to do that. So we have vendors for things like typing-based authentication, accelerometer-based authentication, voice-based biometrics, third-party Face ID biometrics, you know, these sorts of things. And what is the rationale for doing that? It's so that organizations can have a single point of contact with us and tell us what usability and security properties that they desire, and then we can plug in the correct vendors to create that experience for them. Now, why that's so important, and this is again a subtle point that I think is important to point out, is all of these sorts of checks, whether it's voice-based biometric, face that's in the cloud, typing-based behavioral, all of these things are really just glorified shared secrets, right? So what I mean by that is they're spoofable, right? You can create something that looks a lot like the person. You can create a voice fingerprint that looks a lot like the person's voice fingerprint. And so these are constantly arms races. Between companies that are trying to get better and better and better at preventing fraudulent actors and fraudulent actors that are getting better and better and better at spoofing the behavior that you're using as that shared secret. And so the key for us is to make sure that we have a very flexible solution on that side of things, that we can plug in the best vendors at any point in time, depending on the solution characteristics you want. So an example I always use is voice biometrics, or not biometrics, I don't know if you qualify that as biometric or behavior, but in the case of voice, right, that used to actually be a really great way to identify somebody. But today I can take a 5-second snippet of somebody's voice on a call and go to a free website online and create a deepfake of them saying whatever I want, and it sounds incredibly realistic. That's not something that you can necessarily anticipate in advance, but completely destroys the notion that this is a secure system, right? So you need to be able to swap these sorts of things in and out. And we don't want those organizations all to do this independently, right? We'd rather have them have one relationship with a vendor that's an expert in it, is constantly looking at the space, and can give them the properties that they want on their system.

Makes sense. Thank you so much.

Thanks very much for that extensive explanation, Aidan. I think, Tal, you were next, and then Sally had a question. Please go ahead.

Thank you, Sonia. Aidan, thank you very much for the great presentation. I have two questions. Let's assume I know that decentralized ID or digital ID is very important in terms of transaction anyway, right? Let's assume in theory, everywhere we have one ID system in the whole world, right? That will be very easy for everybody to make any transaction. Cross-cutting border and sectors, industries. So that's an ideal way. Let's come back to the reality. So you produce a new ID system, it's wonderful, right? So I assume you have some users, individual users, government or industry users. How do you encourage incentivize different users to use your ID. Why I want to use that? If I use that, I can get a lot of benefits. What's that? So that's one question. Second question related to the first one. If you, for example, we have 100 people in this world, you someday you create a user ecosystem of 50. There is another 50 in another world. Different ID system. How do you make them to be interoperable across the border, across industry? How does that work in your system? Thank you.

Yeah, so both really great questions. So in terms of interoperability, I'll address that first. I would make two key points on this. One is that there are emerging standards in this space. So I'm sure a lot of you are aware of them, but around the W3C, things like DIDs, Verifiable Credentials are specs coming out of that. Those are specs that we're following, right? So the idea here is to make it an interoperable solution that would be the same as other decentralized identity solutions. You know, it's not reasonable to expect any single company to get 100% market share or something like this, right? I don't even think that would be good for anybody. And so instead, the idea is to make a system that's very, very easy to implement, extremely secure, really usable. And that's what we're doing, right? Building out all of the additional features on top of that spec and building new tech to make that more usable, more secure, easier to deploy, all this stuff, but it's fully interoperable. And so if there's others that are using those emerging standards as well, it would interoperate with those things. The other key point is that part of the value here is doing the translation. So it's saying, OK, well, we've got this bank data from a US bank. We've got this bank data from a bank in Africa. We've got this government data from Saudi Arabia, and it's all relating to this one person, right? How are we going to resolve this? What kind of data are we going to use to pass to a given entity, how are we going to make that available? Part of the value here is solving that problem. It's not an easy problem to solve and you just have to have a lot of backend infrastructure to do that work, to do the translation, to match up all this stuff. It's basically identity resolution is what you're doing. Those would be the two key points there. In terms of incentive models, really great question. This depends actually on the implementation. In a lot of our implementations, the incentive model you can think of in a marketplace. right? Where it's a three-prong marketplace where you've got the end user, you've got some organization that's supplying data, you've got some organization that's consuming data, right? So to give you a concrete example around that, it might be a government agency that's issuing a passport or a driver's license or other government identification, a user that's storing that on their phone, and a bank that they're trying to go sign up for a savings account with or sign up for a credit card. So there's always kind of this marketplace dynamic. And sometimes it's the same entity is receiving and issuing the credential and this kind of thing. But essentially, what is the model there? Why are all the players doing this? Well, the government would be doing this for two main reasons. One is efficiency. The McKinsey stat that I showed earlier in the presentation, I think, hits on that. This makes for a way more usable experience that can really boost up the economy. And I think they're starting to realize that. And then secondly, for a lot of institutions that sit in that bucket, they can use this as a way to monetize user data with full consent and privacy and full compliance with GDPR, CCPA, and even other regulations like PSD2 that are emerging all around the world. And how does that work? It works because the user is explicitly choosing to interact with the third entity, right? To interact with the bank, in my example, that they're signing up with. They're choosing and consenting and saying, yes, I want to send all of this data over to that entity. It's coming literally, in the case of at least of a smartphone, physically from their phone over to that other entity. And what's happening in the background is the government can be paid for access to that as a service, right? So the bank would be paying, say, just like they do today, $5, $10 to verify that user and collect all of this data. And then we as the vendor would be taking a fee in the marketplace, something like, you know, 10%. And then passing on the rest of that fee to the government. This works as well if you think about the case of a bank providing data to, say, an e-commerce website or to a retailer. They can monetize that data, again, with full user consent, with full compliance with GDPR, CCPA, all of these emerging privacy regulations. That's a really key point. The last thing I want to say on that, and again, all of these things, there's a lot of subtlety in this. I can go to whatever level of detail you want. But the last thing I'd say is a lot of private sector use cases, especially— and this would be true for NGOs and those sorts of organizations, I'd say, as well— there's a big brand component where they benefit a lot from being seen favorably in the eyes of people that are using them. And so in the case of, say, a bank, that can look like creating a sign up with your bank button. Right. So you've seen this obviously with Facebook and Google and Apple. Part of the reason those are the most powerful brands in the world is they have sign up with their brand buttons that people use on a day-to-day basis. Banks would absolutely love to have the same thing, as would healthcare providers, as would, I think, a lot of government entities, NGOs, anyone that really values the relationship with the end user.

Thank you. Follow up, a quick question. Regarding the interoperability you mentioned, you have some work to do on translation, right? Data from different bank, right?

Yes.

It could be data from bank and third party like Apple Pay, right? Could be data among different players. So what's the major technology requirements for that? You mentioned the cryptography. It's a kind of, you have to read the data, you have to understand the data, you have to transfer data. So what's the basic technology requirements for that?

If I'm understanding the question right, so essentially what's happening, right, is with every organization that we work with, we can standardize formats. So we can— when they issue the data initially, the API that we provide is going to standardize that data inside of the user's file. That user can now present that data over to a third-party entity. And now the really cool thing, right, is you can do things like you can ask the question, obviously with code through our API endpoint on the other end. You can ask questions like, is this user over 21? So in the US, if you want to purchase alcohol, right, for example, and what we can do is we can provide software that runs locally on the phone, right? So we're not seeing any of the data and goes and looks at any of the data points issued by any of the providers and says yes, according to this bank and this government agency, As of a year ago, this person, you know, this is their birth date, so they should be 28. Right, and return only that data point and nothing else, right? So you can do all sorts of this stuff once you have that in place where you're running code that's local on the user's device that we're not interacting with the data anywhere that we can see it. We're running code on the user's phone in the background to return results about almost any question that you can imagine asking. Encode. So you can start to do— hopefully that kind of gets to the core of your question. If it didn't, let me know. I'm happy to go into more detail.

Okay, that's fine. Thank you.

I want to pick up a question from the chat that Sally asked. I don't know, Sally, if you want to ask yourself or I can— whatever you feel like. I can just pass it on. The question was around if you could elaborate on the statement, it's extremely hard to compromise a private key.

Yes. So there's two private keys involved in any interaction, uh, well, primarily involved. So that would be on the user's device. Uh, and that's stored in a secure enclave of the phone. At least again, I'm talking in the case of a smartphone and the case of a feature phone, this gets more complex, right? Uh, you have some security trade-offs that you make in that case. Um, on a smartphone, it's stored in a secure element of the device. So modern devices, I think it's iPhone 6 Plus, uh, and something similar on Android. Have secure enclaves where you can do that kind of cryptographic work and you can store it there. So even the device manufacturer, at least nominally, has no access to that private key. And so it's almost impossible to get access to that one. The other one that I was alluding to, and this is critical for the anti-phishing, right? This bi-directional authentication scheme that I talked about is on the entity's side. So if you're trying to, in my earlier example, take your government identity data and use it to sign up for a bank account or access a loan or access credit or whatever the case might be, That bank will have access if they're in the Unimighty ecosystem, right? Which is required for them, of course, to do this sort of data sharing. That bank will have generated a private key on their server. So this happens all the time, right? This isn't something that's super, super unique to us in a lot of respects, right? You generate API keys locally quite frequently if you're accessing different API services. Even simple things like Twilio and Stripe and these sorts of ones. So this is very common practice. Organizations are very well equipped to store those things securely, and it's mission critical that they store those securely. And usually they do that, you know, through a cloud provider like AWS where they can store it in some sort of secure hardware in the cloud. And so it's effectively impossible to access those sorts of keys unless there's some sort of mismanagement by the organization. Which of course is a bigger issue. We provide all of the tools that would be required even in that sort of catastrophic event to manage it, right? So you can revoke all of the credentials, for example, from the ecosystem and temporarily put that on hold and then just reissue them all once you've got the situation under control. So hopefully that addresses the question. Yeah, I have understanding of the model that you just described. So basically, And I don't know if you, if you meant to use the word private key or public key. I meant to use the word private key. For the, for both. For the one that's being generated by the, by the organization on behalf of the user. No, no. So let me clarify. So there's 2 public-private key pairs. So the user has a private key that's stored locally on the phone and a public key that's posted to the blockchain, and the organization does exactly the same thing. So the organization generates a private key locally in their organization on their own servers, stores it in some sort of secure place with all the rest of their secure stuff. And then they put the public key on the blockchain. So that happens for each one individually. And then what happens is when the user is sending data or trying to authorize or authenticate, they sign some data cryptographically. So that all happens in the software of the device, right? So their private key is signing data that can be checked against the public key on the blockchain. So, you know, this is actually— so that's what I'm saying. What you just described is the public-private-public key pair, not private-private. If I'm understanding you correctly, you're actually transferring the responsibility of the key management to the phone, to the hardware, which actually puts a higher risk of compromise because in case of the hardware, the phone gets stolen or lost. No, so again, we do this model on phones that have a secure enclave that's specifically designed to store this in a way that is not— you can't compromise it. So on phones that don't support that, right, on phones that do not have secure hardware, you're exactly right, right? So if you store this on something that just has your general storage or something like that, like an iPhone 2, you know, that would be a problem. And so we don't do that, right? So in that case, we emulate the secure hardware in the cloud and give the user ways of accessing that emulated hardware. Does that make sense? Am I missing what you're trying to say? I guess, I guess I come from a different school when it comes to that. So maybe it's okay, but, but thank you for the cool presentation. Yeah.

Thanks, Sally. And I think, Will, you could turn on your camera. Assume you have a question. And then perhaps Adrian, you can go next.

Thank you. Adrian going to ask a question now?

It's your turn. I don't know. You turn on your camera.

So, okay.

I thought Adrian was going to ask a question. So, yeah, Aidan, thank you for the presentation. Very, very good. Yes, a lot of great ideas. So one thing I was wondering is that either intentionally or unintentionally, are you potentially, you know, by building this system, going to kind of connect somebody's digital life that have been manifested by different identities? Like, say I was trying to be, you know, one identity on Facebook and a different identity on Twitter, but for some reason I wasn't careful, and then now you would be able to link those two digital identities together. You know, is that something that potentially could happen with, with Unum ID system?

Uh, not really. So, you know, the way that this is intended to work is you use pseudonymous identities, right? So there's no way that somebody could— like, the organization that's receiving the identity data knows what the original source of that data was in most cases, right? So they'd know, for example, that the government issued you this identity on this date and claimed that it was you and it hasn't been tampered with and it relates to you and you're definitely the one presenting it and this kind of thing. But there's no way for them to backtrack that to many other accounts. So it's not like this is something that you can— and this is actually a really, really critical point for privacy. And something that the specs for verifiable credentials and DIDs don't necessarily address really well. And there's actually a lot of concerns in the community about this exact kind of thing. And so we spent a lot of time and money working on this problem and making sure that we've got it pretty well addressed. And the problem is, or the solution essentially rests on making it not possible to relate any of the private or public keys that are being used with different entities. So, you know, the form that I presented it before may not make it clear how this is the case. The reality is every single time you're interacting with a new entity, you're using a different DID. So you're using a different public key effectively. And so there's no way to relate those things to one another. And so what that means is, yes, it all relates back to one person and one device. But there's no way for any of the entities involved, including the issuer, the original issuer, like the government, to relate all of those things together and tell that it was all you. The only thing that they can know is that, yes, this definitely was a real person, and this was the data that was presented about it at a given point in time. So I think the last subtlety that I'd want to point out there is, of course, this depends in large part to what data you're sharing. So if the user chooses to share, this is the full government profile that was put in place on me by the government using UnumID, and they share that full government profile with 30 different organizations, which this is something you have to be really careful about in some implementations. Some governments may really want that to happen and push very hard for it, and that can create serious issues which are independent of our platform, but then of course, if you have 30 different organizations all with the exact same data in their database, yes, it's very easy to relate those things. In most cases and in most implementations, that's not the case. So as I was pointing out earlier, you can ask questions like, is this person over 21, and not get any other information other than yes, they are, and these organizations claim it. Right? And so that's the kind of thing that this is really intended for, not for constantly sharing your entire profile of information with every organization you interact with. So it's a really, really great point. There's a lot of, again, subtlety around exactly how the implementation protects against that, but it's a key thing to make sure that not all of it can be related. But actually, a very, very final point on this. The really cool thing, to me anyway, that you can do with this and what this all means is that if you're, say, a Facebook or Twitter or another social network or something like that, and you want to prevent fake profiles with full privacy and with all of the things that I just mentioned to you, you can still know, even without knowing anything about me, if I take some horrible action on your platform, you can ban me and I can't create a new account unless I go like buy a new phone and create a whole new digital identity, right? So you can have really, really strong banning of people without even really knowing anything about them, right? Because what you're banning is that fundamental identifier. That you don't— it's abstracted from you as the organization, but you can still prevent it from signing up again.

Right. So I guess when you create that linkage between that digital identity and a real, you know, real-world identity, for example, in the US, right, say an email ID with a Social Security number, how do you accomplish that, right? How do you verify that this email ID indeed represents the owner or the person who has that Social Security number?

I love this question because it gets to the heart of like, what is identity in the first place anyway? Right. And really all it is is a sequence of claims made about some organizations or individuals about a person or a device or whatever you're trying to identify. Right. So why does anybody trust me to do anything? A lot of it comes down to the government gave me a couple of numbers early on and they just trust that if I can present those numbers, it's me. If I could present my driver's license, my Social Security number, my birth certificate, good enough for us, right? That's kind of what identity means today. And so what we're trying to say is the root of identity comes down to pulling in different attestations, different claims from various organizations, and showing that they relate to the same person over time, and they haven't been tampered with in any way. And that's what makes it really, really unique. So a government can issue me a driver's license, for example, right? And through the system, we can show this is definitely Aidan still, same exact person that they trusted initially. And this is definitely his driver's license that hasn't been tampered with in any way, because if it had been tampered with, none of this cryptography would work at all, right? If you tried to tamper with that data. And so the key point there is you're relying on the same mechanism, right? Which is there's some root of trust, and that root of trust is fundamentally based in human-to-human interactions. It's based on going to the government agency and saying, here I am, here's the information you had on me, now issue me an identity. We're going to, in some cases for people that are undocumented today, you could go to an NGO and they can issue you an identity. It's all about just making it possible for many organizations to make claims about you, and then other organizations can choose to trust or not trust those claims.

That's really fascinating when you think about it. It's probably easier to verify that you're over 21 than to actually prove that you're that and that person, which is like a completely different conversation. Thanks very much for that. I think there's one final question if we get to it, and then I think we have to wrap up because we're almost at the top of the hour. Aidan, you want to go online yourself, or do you want me to ask? There's a question on provisions to manually bypass by calling a help desk chat window in case a document is not available. That's just a learning coin, a project that we worked on internally. I can explain some other time.

But sorry, I kind of missed the question. So what was— is it in the chat? Maybe.

Aidan, you are mute. But, uh, thank you everyone for dialing in. For those who need to drop off because people are have other meetings and obligations, but for those who have maybe a moment for another last question, Aidan, please go ahead, but you were on mute earlier, so.

Thank you everyone for coming. Appreciate the time. It's great to talk to you.

You're still on mute, Aidan. Posted the question in the chat. It's like, are there any provisions for manually bypassing by calling a help desk chat window in case the document is not available for verification? But if there's an issue with a document or the data included on that document, I guess this depends exactly what you mean.

So I mean, yes, of course there's support, right, for issues if you're not able to verify and this kind of thing. Absolutely. And what that support looks like is different depending on the context. Right now the support team is completely internal, right? So we're not even relying on service centers or things like this. In terms of, you know, in cases where a document is not available, more what we default to is verifying the document the first time, right? So let's say the user is trying to take some action, they're trying to sign up for a bank account, um, and in the developing world or something like this, uh, and they, you know, don't have any data from the government, right? Because it just hasn't been issued to them yet, or maybe it was issued and it was faulty for some reason. What we'll do is we'll have a third-party provider like an Onfido go ahead and have them upload whatever documentation they have, scan them in, um, give them that verification, sign them up for that account. And what's really cool is because that was done using our protocol on the backend, you now bind that to the person so they can use it again. So they can go to another bank and create an account. They can go to their healthcare provider and show this is done. They can go to all of these other organizations. And that's the heart of it. So there's really two parts of it. Yes, there's absolutely support to talk through, like, why is it not working? You know, how can we make it work? And then secondly, if there's not the document available or the document's corrupted or something like that, We simply try to reissue the document, and the best way to do that is often working with a third-party provider. In the case where that's not an option, or where the government has strong support, we go directly to the government. We say, okay, let's have you log into your government systems, and they can issue you the data again through their backend.

Thank you. Thanks so much for explaining that. I'm afraid we ran out of time, but There's so many more questions. We might just reach out to you bilaterally because some people just had to drop off because, you know, we have like a lunch hour and people are— and I have other meetings and so on. But thanks very much for this presentation. This is very enlightening. I enjoyed it a lot. So please let us know if you yourself have any questions. I don't know, for me or Yeah, will do.

You know, I think we, we gotta run as well here in just a second, but it's a pleasure to meet you all and talk to you. And please follow up, you know, we're happy to jump on a call or answer some emails, whatever's easiest.

For sure. Thanks so much, Aidan and Brad.

Bye-bye. Thank you, Aidan.

Thank you all.

Bye-bye.

Thank you. Thank you.