I'm showing slides from the presentation we gave at Internet Identity Workshop last month. This project, there is a little bit of information out there. It hasn't been publicly announced yet. That's coming up this summer because it's coming out of work, going on together at the Linux Foundation, Linux Foundation Decentralized Trust, of which Trust over at RIP. I'm one of the steering committee members there. We're a member of that. Decentralized Identity Foundation, you just heard from Steve in the last group.
The Open Wallet Foundation and also another nonprofit called IRA, which is Global Trust Registry Utility. So I'm just going to go quickly through. Some of these slides were more for IW. This is a deck. I've created it, so I'm going to go straight to the relevant slides here. The reason we're doing the first-person project is that personhood credentials are extremely useful, but they're useful beyond just proof of personhood. This article written by Doc Searles over 10 years ago is all about why we need first-person technology.
We need technology to represent the individuals on the internet, where they can prove not only their person, but they can prove their personness and their personal relationships. This quote from Doc Searles' article, I really think, captures why being able to prove you're a real person with real relationships is going to be so essential to the evolution of digital society, not just protection from bots.
Now, what we're actually tackling at the first person, as I said, first-person technologies need to be able to work on a person's behalf. This is not just about people. It's how we effectively work together in groups and communities and even in very large communities. I don't probably need to tell anyone that social media is having, you know, it's not just bots, but the way that people can effectively collaborate at large scale has turned out to have some really serious problems. We need to bring more of what we have in the real world to our online worlds.
So, with first person, as I mentioned in the previous talk, we're not just doing proof of personhood. What we're about is building a decentralized social graph, one that does not exist in any centralized place and is not controlled by any single company or government.
So, to do this, realistically, we need to be able to do it from the bottom up. That means we absolutely need governments that are working on and talking about the government issue identity it was referred to before, but we also need people to be able to work from their side.
Now, the governments that you've probably been hearing about that are starting to issue digital credentials, I list a group of them up here at the top. They're doing, you know, they're doing everything they can to build safe, secure digital credentials for their citizens.
So, that is excellent. But if you ask the other question, are those governments producing universally interoperable technologies that always put citizens first and let citizens interact around the world? That's a harder question.
And one, you know, you're probably hearing lots there at the conference about how that's not necessarily happening. The interoperability, for instance, between these, the governments you see up here, even, I hate to say it, California and Utah mobile driver's licenses, there's interoperability challenges just between those two issuing the same format of a credential.
So, with First Person Project, we're trying to tackle how we can have interoperable technologies for individuals to solve this proof of personality problem and the decentralized social graph problem from the bottom up. And I'm not going to be able to cover all of this.
Actually, it will be helpful that this is a longer presentation, but I'll cover at least the high level. There are five steps involved with what we need.
And this, to anyone at EIC, you know about these. And we're going to have to tackle the interoperability of each, at each of these stages of the use of verifiable credentials. And what we have the opportunity to do here is to address interoperability for this one class of credentials. We call them first person credentials, this combination of personhood and verifiable relationship credentials, all the way across that stack.
And, you know, it's a different approach than governments are taking, which have to solve the problem for their citizens. We need to solve the problem for people at all five of those steps.
So it'll look like this, that for every one of these areas, all the way down to the identifiers you're using, so that you can use them with zero-knowledge cryptography, the types of credentials, wallets and agents that will support those credentials, ecosystems that will issue those personhood credentials and recognize the verifiable relationship credentials, and finally, interoperable trust networks that will allow this to work across all the ecosystems that adopt this in the world. That's the key goal of the first person project.
Now, I don't, again, based on the time we have, I'll cover as much more. I'm actually not sure how much longer I have. Is there anyone who can tell me what the time load is? Because they didn't actually say how long we would have. I believe you have still about 30 minutes, but we can exceed, this is the last session of the day, so take your time. Did you say 30? 13. 13. Yes. I thought it was 13. Exactly. All right. I will continue to go, but I also, if there are folks that have questions, I want to leave time.
I can't see that from here, so if anyone does want to stop and ask a question, please just interrupt me. Okay. All right.
So, again, there's a lot more content in this deck, but we will, I'll cover the strategy. I'll try to get at least through the first three, so you understand how this will work.
Again, there's important aspects. The first person project is tackling all of these things. It's a lot to go into. I will point out the core thing at the basis is, guess what, decentralized identifiers. In this book, it's a little over three years old now, we called it the core building block of decentralized identity. It's still the core building block, and we are going to focus on a very specific type of DID that's risen, I think, of sort of the cream to the top of the over 200 DID methods now, and those are self-certifying identifiers.
These are slides that go back four years now, or three and a half, to introducing, it was a technology called Cary that really said, we're going to only use self-certifying identifiers, and we just quickly explained them this way. They're generated from any key pair, but the secret is that they're generated directly from the key pair. You don't involve a blockchain or a database or something else, so that the identifier, the skids, as they're called, is tied directly to that public-private key chain. You can prove it just using cryptography.
If you go about that that way, then they can be generated directly in anyone's digital wallet, and then the verification information, the DID document or documents, the series of them that, as you rotate keys or endpoints, as long as you have that history, anyone can verify them, and you can put that history any place. You don't have to store it in just one place, you can multi-anchor that. DID-SKID is the new DID method at Trust over IP that's been designed to do that, and it will work with all four of these different self-certifying DID methods.
All these current DID methods use skids, and with DID-SKID, we can use any one of these formats, and you can put the verifiable history any place. We're referring to this as a super method, and it's the one we're going to be using. If you're interested in that, you can scan that QR code, and it will take you right to this spec at Trust over IP. That's one point.
Again, this is the only DID method we're aware of that will work across all of these architectures, and the first two blockchains that are supporting DID-SKID, you just heard from Ankur Banerjee at Checked, and Hedera is also adding support for DID-SKID on their blockchain, so you can use it web-based, you can use it peer-to-peer, and then DHT as well. All right, so that's what we need for what we call first-person identifiers.
We think we've got that base covered, and now let's go to the second one, the credentials that are involved, and this is what I'll cover to just make sure everyone knows what we're actually doing. It's great that we have – or this is now at the proposed recommendation stage, VC 2.0, the data model. The challenge is we have five different major formats out there, and so interoperability is still proving to be a real challenge. The most important thing you heard from Steve in the last – in his talk is with personhood credentials and first-person credentials, we must have ZKP.
This is the paper that he was talking about that came out last August. Again, you can scan that QR code to go straight to it. I highly recommend it. It really explains the whole idea of personhood credentials, unique one per person. These are the two key things that are required. You have to have the issuers doing one per person. Any number of issuers can do that as long as you can identify that set. That's what you need a trust network for, but you need unlinkable pseudonymity. Only way to accomplish that is ZKP. That paper does not actually tell you how we're going to accomplish that.
This is what has led to first-person credentials. As I said, this adds the dimension, besides the personhood credential, of verified trust relationships of our own. A first-person credential is going to look something like this in a digital wallet. As you can see here, there's no personal data. There are numbers about the number of relationships, but we can further make this pseudonymous by making these simply thresholds. Just as you go to LinkedIn and see a person has 500 or more connections, all you know is they've reached a certain threshold.
The point is to reach a threshold of these three different types of relationships that you can have. As you add these relationships, you make it progressively harder and harder for anything that's not a real person to have those relationships. That's the essence of what we're doing. If I have time, I'll show one more thing here, which is how a VRC works and why, for instance, the Linux Foundation itself wants to adopt these. I'll do this fairly quickly.
This explanation is actually based on the keynote that Linux Foundation Executive Director Jim Zemlin gave at the Linux Foundation Summit in March. Anyone who's familiar with key signing parties, Jim said, hey, first person credentials are the ultimate key signing party. They want every developer contributing to every open source project at the Linux Foundation to prove it's a real person and not a bot and to prove they have trust relationships because what's happening now is malware is being injected into open source and it threatens the entire open source industry.
When he used this analogy, we actually created this next set of slides and said, okay, Jim, we're going to show you exactly how this works in the classic Alice and Bob. This is the last thing I'll walk through. Alice and Bob, we're going to give them each a wallet here, a standard digital wallet. The capability, imagine there are two smartphone users that are meeting at a conference just like EIC. Like you've probably done at EIC, one of them says, oh, I'll let you scan my first person connection QR code.
When Bob does that, he says, oh, yeah, I like this relationship, what we call first person connection. It's not network specific. It's directly between the two of them. As soon as Bob says that, his wallet will produce the key pair and the skid that he's going to use with Alice. Based on the QR code, we'll transmit that to Alice, whether it's done locally with an NFC or online with a protocol like DITCOM or the trust banning protocol. That's how it's transmitted to Alice's agent. Alice's agent will correlate, yeah, that's coming from my QR code.
I will generate my key pair in my wallet, the that skid, and that goes back to Bob. And what we have now is a pair of pairwise private dids between the two of them that establishes a unique private channel between those two wallets that they can use for as long as they need it. There's a lot of value just in that first step. But now what happens is the magic. Bob's wallet says, okay, I can now produce a verifiable relationship credential for this relationship with Alice. It contains the two dids and DAPE stamp, and Bob signs it with his private key and issues that to Alice.
And Alice verifies that and says, oh, I'm going to do the same thing for Bob and sign it with my private key, same two dids, and she issues that back to Bob. And guess what? We just accomplished in what should take a scan and each of them, this whole process should be exactly like connecting on any of the other networks except you now have a network independent connection. That's what we call a verifiable relationship credential.
It's now cryptographic proof that either Bob or Alice can prove to another party and do it privately with zero knowledge proof that they have a real world connection between two people. That's how verifiable relationship credentials work. I think I'm probably out of time or have time for a question if there are any. Are there any? Any questions from the audience? No? Okay. No questions.
Oh, yes. One question.
Thanks, Tromit. I got one question. AI agents are not acting on behalf of themselves. There is always a human player behind who wants to achieve something. So how can we protect this, what you just showed, against Alice being hired by someone who later on wants to use that relationship by an AI agent or something? Or did I get it completely wrong? No.
No, you ask an extremely good question. Alice now has a relationship with Bob.
And Alice, it's a great question because personal credentials, even the first person implementation of personal credentials and this decentralized trust graph, cannot solve trust problems that exist in the real world. If Alice is hired to do certain things online, she could delegate. And the thing is, how is Alice going to delegate to a bot? Look at this screen and just replace Bob with a bot. Alice can have a verifiable relationship with a bot. The difference is, Alice has a personal credential and the bot doesn't.
And so what you have to do, if you want now to have Alice do things in the bot world, is it's going to be Alice. And Alice is going to be able to prove, well, this bot's acting on my behalf. But if a bad actor wants that bot to do bad things, they're still going to be traceable back to Alice. And by the way, you need in the presentation to also be able to do that holder binding that Steve talked about earlier. We can't magically solve that with just verifiable credentials. You still need a proof of binding against which you need to be able to share in zero knowledge.
So it is a difficult set of problems being handled together, but they can only solve proving there is a real person there. And the other thing I'd like to point out is, they're not intended to, beyond proof of person, be used by themselves. If you need to still prove you're a citizen of a particular country, you're going to need another credential to do that. And so you need to be able to do that. You're going to need another credential to do that, probably a government-issued ID or something that works for that.
The power of the zero knowledge proofs being used here is they can also be used against those other credentials. That's how we get to real privacy preserving digital identity that's still trustworthy. But it can't solve trust problems. If people are being hired to do bad things, we don't have a solution for that with technology alone. I hope that helps. Any more questions? No? Okay.
Well, thank you, Drummond. Thank you for your time. And that's the end of today's talk. You're free to go and go get some lunch. Thank you.
