And thanks to all of you for sticking around. When I saw it was like the last presentation of the last day of sessions, I thought, man, I'm gonna be speaking to me, can be me and Raj in here. So, so as Raj said, I am speaking about did come the self sovereign internet, and I'm gonna skip past that. But I want to go to here, which is cojito ergo, some discards, didn't say I have a passport. Therefore I am. He said, I think, therefore I am, we don't spring into existence because we are given some administrative identity. And I put this up here because I embrace the label, self sovereign. Some people like to say decentralized, some people say user-centric, but user-centric, and decentral, you can be user-centric you can be centralized without being self sovereign. And I don't mean that I don't say this to pick fights with somebody. I just mean that I believe that this is revolutionary. It's more than just making some minor tweaks to web 2.0, to make it more convenient for users or, or whatever.
So I'm gonna skip past most of this. I have a thing on my blog about identity architectures, where this is relevant, but the, for the most part, we, we can get past this and still talk about what we need to do in the interest of time. So in SSI, there are some terms we need to have straight. So there are entities, right? They could be things, natural things, organizations, individuals, there are agents and wallets that live on the edge. And there are cloud agents and wallets that obviously live in the cloud. And this is showing that, you know, you go back and forth between these and you see all of those. So we're gonna be talking about mostly edge agents today and we're so let's start with did exchange. So first of all, it did, if you're not familiar with that term as a decentralized identifier, and you can think of it as a indirect pointer to a public key in a location, right?
Obviously there's more details than that, but that's what we need to think about is it's, it's an identifier which points to a public key, not using the public key as the identifier itself. One of the big advantages of this is that you can rotate the keys and it did. And when you do it just keeps on working. You don't need to send a new identifier to whoever you're connected with. So we're gonna have lots of connections to people based on these public keys, we wanna be able to rotate keys and be able to do it. So in this diagram, Allison and Bob have exchanged DIDs and they've got their wallets here and they've put their DIDs in their wallets. They've also got these things up here called key event logs. So these are peer deads, right? This different flavors of DIDs. These are peer DIDs, meaning they're just exchanged between piers.
They are not registered on any blockchain. What they are registered in is in this key event log, think of that key event, log like a Google doc. It's a conflict free replicated data type, meaning that when Alice decides she needs to update the key that her did points to, she just does it. And Bob sees the update automatically through this conflict free replicated data type structure that that is linking them together. So this is how Allison and Bob create a connection with each other. So now that they've got a connection, you can imagine that they've both got each other's public keys, and they've also got some end points in there too. So with those public keys, they can do some interesting things. They can exchange signed messages, they can exchange encrypted messages. And this is really the heart of this talk that DIDs are more than identifiers for verifiable credentials. Exchanging DIDs creates a secure messaging channel between any parties that have exchanged DIDs. This is I think a huge concept. You can get me started on verifiable credentials. I've written blog posts about the millions of use cases that you can use for verifiable credentials, verifiable credentials are this huge space, which I think is gonna change the world did come out scales, verifiable credentials by an order of magnitude or more. It's that big? I think it's revolutionary. I think it really changes how things work.
So what can Alice do? Well, she can have a dead relationship with Bob. She can also have a dead relationship with Carol and course Bob and Carol can have a relationship. She can have peer did relationships with Bravo Corp or with a tester org or with certified Corp, right? And these peer did relationships, which I'm indicating here with the blue arrows are the ones I just described. There's no registration on a blockchain. They're just peered exchanges. And because of this, Alice can send a message to Bob, a tester, or can send a message to Alice, which is a credential, right? So when we talk about issuing credentials, that happens on top of DICOM as a protocol defined on DICOM. Okay. So there's actually a protocol defined for did for ver for credential issuance. When Alice decides that she needs to prove things to certify Corp. That's another protocol that rides on top of the messaging layer that DICOM provides. So what I'm trying to do is tease this apart for you a little bit so that you see that this credential exchange isn't this blob of code, but that in fact, it's all protocol defined on top of a secure messaging platform. And of course, because a tester org is issuing a credential, they have written a public did to a blockchain, right? So credential issuers need to write public deads almost no one else does.
So when I say did com represents a secure internet overlay? I think most of us probably understand this idea of a, of a network overlay and what that means, right? We define how things pass around the internet or, or a network. You know, PKI is an example of a network overlay, right? It's a way of hierarchically, you know, passing a tested information, but it is not a messaging protocol and therefore PKI can be used for what PKI is for, but it's hard to define other protocols on top of PKI. So, so that's one of the differences with DICOM.
So in the world we live in now we have different messaging apps. And so we have WhatsApp and we have signal and you can send WhatsApp to WhatsApp and you can say signal to signal, but you can't really send signal to WhatsApp. Even though I've heard that they actually share common underlying protocols, right? Just two different worlds in the world of did come. However, if you have intrinsic wallet, you can of course exchange messages with intrinsic wallet, but you can also do one with an ID ramp wallet or a lease wallet or an eSATA wallet or anything else. Right. I have this thing called Picos, which I spoke about this morning that are agents and you can exchange messages with them. Now notice I'm saying messages, not credentials, not credential proofs, just really any kind of message that you want.
What properties does it have it's secure and it's private, right? Those are largely because of the cryptographic properties we get from having exchanged keys, right? Interoperable, because DIDs provide us with a way of exchanging and resolving DIDs and did come is a spec specification on top of that transport agnostic doesn't really care that it's on TCP, although that's how we think of it, mostly going and it's extensible. And it's that extensibility that I think is one of the most interesting things. So one of the things you'll find if you go to the did GitHub repository is you'll find a list of protocols. And one of those is the TicTacToe protocol, which Daniel Hardman wrote, just to show how you can write a protocol definition on top of DICOM, right? And we've implemented this so that we can play T toe on top of DICOM. And I, I don't think it's gonna take the app world by storm anytime soon, but it is a great, simple example of how you can define a protocol on top of DICOM messaging.
So these are some of the ones that are very familiar, right? When we think about what we do with DIDs and self-sovereign identity as identity, we exchange DIDs, right? That's actually a protocol for, for DIDs is how they get exchanged. We issue credentials and we present proofs, like I said earlier, these are all protocols defined on top of the underlying messaging system, but there are other possible protocols and there are definitions for some of these. So delegating, commenting, notifying, buying, and selling. You wanna implement an e-commerce protocol. You could do that on top of DICOM and have all of the properties of DICOM, including security and privacy, negotiating enacting and enforcing contracts, putting things in escrow, transferring ownership, scheduling, auditing, reporting errors, almost any workflow you can imagine could be built as a protocol on top of did com and have all of the properties that did give you the privacy, the security. And of course, the ability to exchange credentials as a side protocol so that you know who you're dealing with. So, so these are all important, proper protocols that you could define on top of it. So briefly, how much time do I have left Raj
Take your time.
Well, these guys might not agree. So, so briefly I want to talk just about one possible use case that we've been exploring, and that is internet of things, right? So internet of things on top of did com. So, you know, we've now gone from the self sovereign internet to the self sovereign internet of things, which has been a bully pulpit of mine for a decade or more. So this is how things work right now, which I call the comp you serve of things, not the internet of things. And so the way it works is, you know, you, you get a coffee grinder from barista and they tell you to install an app and their app talks to an API that they administer. They give you some kind of administrative identifier and you know, the, the coffee grinder talks to barista and, and then you interact with it through an app on your phone, through the API that they provide.
Now, the problem with this of course, is that because your access to your coffee grinder is intermediated by an administrative identifier. Barraza could decide that they want to take that identifier you from you at any time, for any reason, read the terms and conditions. You have almost no rights, right? So you spend three or $400 on a coffee grinder. Barraza decides that you did something they don't like. They take your account away from you, and now you can't access your coffee grinder anymore. So that's, that's the way the internet of things works right now. And so, like I said, it's, it's more like comp you serve than the internet. So in the self sovereign internet of things, this is the diagram we had before with Alice, right? And Bob and Carol and all of these people. But now she's got a connection. A peer did connection to her coffee grinder. There's no intermediary her. She probably scanned a QR code or something when she bought the coffee grinder. And that set up a did exchange. And now she and the coffee grinder have a peer did connection, direct peer to peer private secure, and she might set up a relationship with Barraza and she might tell her coffee grinder that she wants it to set up a relationship with Barraza. Why would the coffee grinder want a relationship with Barraza?
This is just that same triangle blown up so that you can see it a little bit better. Right? Why, why would she want a relationship? Well, she might, for example, want her coffee grinder to get firmware updates. And she might want that firmware update to come over. The peer did relationship that the coffee grinder has with Barraza and because Barraza has written their public did and credential definitions to the ledger, they can automatically verify with a signature that firmware update and know that it's right. So that's one example of why a peer did relationship in the internet of things might be nice. Here's another example ownership. What if Alice, because she needs service needs to prove that she actually owns a particular coffee grinder. Well, that's easy because the coffee grinder can give her an ownership credential saying, Hey, you're my owner. And then she can use that to prove to Barraza that she actually bought one.
What else could we do customer support? I like this one, because notice that Alice isn't using her direct relationship with Barraza, she's making the coffee grinder be the intermediary and the customer customer support interaction. There's a company called hero. That's doing this. And so the point here is that the coffee grinder knows all kinds of things that Alice doesn't know. So why not have it talk to Barraza directly? And she's just using the coffee grinder as the intermediary. Of course, you know, we, we have to hope that the problem isn't that she didn't plug it in, or that the power supply's gone or something, cuz that wouldn't work. But you know, assuming it's still online and functioning, she, she could do this. So I used to have a connected car product called fuse vehicle ecosystems are rich, all kinds of connections that you can imagine in a vehicle ecosystem.
Here's one that we built for how Alice could sell Doug, her truck. Now this is a little complicated and I don't wanna take too much time going through it. But the point is notice that Alice and Doug have peer did relationships with all kinds of entities and ignoring how that sales relationship got set up because there's gotta be some method for that to happen, right? It might have happened with this fast stuff. Brokerage, for example, that she had, once Alice is set up that resales relationship, they can do all kinds of things. Alice can transfer ownership to Doug. She can notify the DMV or the insurance company that she no longer owns this truck. The truck has its own wallet down here at the bottom and it is online and functioning as a self sovereign thing. I notice that Alice has a connection to something that's a shadow truck, cuz vehicles generate all kinds of interesting information.
Alice probably doesn't want to give up all of that data, but obviously Doug wants the thing that controls the truck. She probably doesn't want Doug to know all about her trips, but she's probably happy if Doug knows about the maintenance that she's performed, cuz she can get more money for the truck, right? With, with proofs of maintenance. So what we can do is we can actually split that so that Alice gets a shadow truck that for all intents and purposes looks like her truck has all of her trip records has all of the maintenance records. Everything else that she cares about is just not connected to an actually functioning vehicle. It's no longer controlling the real truck. Doug gets the real truck and he gets any data that goes along with the real truck because all of that data is contained in the thing itself, not in some database, somewhere that four didn't happen to, you know, make available for ownership transfer. And this is, I think one of the most important things about this is that because it is based on some protocols and lots of different connections, it can be ad hoc. Allison, Doug can sell their truck one way and Bob and Carol can buy something else from each other a different way. And it's all okay. Right. It's flexible and can be used just how different parties want to use it.
So I've got things that I work on called Picos. I gave a talk earlier today, which you can find the recordings of, I think maybe yeah. If you're interested in how all of this could actually work with things, we've got quick start and stuff@peaklabs.io, you can look at these slides later and click on these links. If you want. Lots of topics that I've written about here on did com and, and the messaging spec and other things. That's my talk that I gave this morning. So you can go get that recording if you're interested in that. And that's my contact information. So please feel free to reach out to me if this is interesting or if you have questions or anything else. So thank you very much.
