 Well, thanks for coming everyone. I'm going to get started because half an hour is not very much time Then I'm going to talk about something called did calm and the self sovereign Internet To get started I just want to make the point that When I talk about this, I'm not I don't want to debate the relative merits of different autonomic identifiers like pure dids and Kerry and ADI I think all of them can apply to what I'm going to say And if you don't know what an autonomic identifier is that's good because that's one of the things we're going to talk about today I will be Watching Or hopefully a little bit trying to watch the chat To to see if there are questions so feel free to ask if you if you have them So when This parties didn't say I have a birth certificate therefore I am We don't spring into existence because some administrative system provisions and identifier for us and no single administrative regime Be it a birth certificate or a driver's license or whatever or even a collection of them really defines us and so When I talk about self sovereign Internet what I mean by that is that sovereignty is the source of our authority to act represents a A root of trust if you will I'm going to talk in some detail about what that means because the root of trust Determines the domain and a degree of legitimacy for an identity system So when we talk about identity system architectures first of all, I want to point out my belief that identity systems don't manage identities, but rather are built to manage relationships and They provide the means necessary for us to remember recognize and rely on other parties in that relationship And to do so they use identifiers Which are handles that we use to name the thing that we're remembering recognizing and relying on So identifiers are issued to or created by a controller Who by virtue of knowing the authentication factors can make authoritative statements about the identifier for example, example when you authenticate to a website you are using A password usually to make an authoritative statement about the identifier and claim it The controller could be a person an organization of software system of some kind and it might be the subject that the identifier refers to, but that doesn't have to be the case. Okay. Identification factors can be things like passwords or key fobs or cryptographic keys or almost anything else. But really one of the things we care most about is the strength of the bindings between these three things. And The architecture of the identity system has a great deal to do with the strength of those bindings. So in an administrative identity system like the ones that we use for almost everything, some administrator is asserting the binding between an identifier and the password. And the administrator owns or verifies the identifier, even if it's your email. They're still when it's used as an identifier in their system. They are essentially asserting the binding between that. And they're assigning it to a particular controller. The only Binding that's particularly strong in this administrative setup is the one between the controller and the passwords because typically we allow the controller to generate the passwords themselves. Now in a ledger based system, Which I think of as algorithmic. We have a ledger, which is essentially registering the bindings between the identifier and the public key. And usually the identifier is derived from the public key in some way. So we get strong bindings between all of these. The binding between the controller and the identifier is strong because the identifier is derived from public keys that the controller has generated. And then finally, the primary thing we want to talk about today is this idea of autonomic identifiers. So in this case, the identifier is and the keys are self certifying and the person is their own root of trust. And I don't have time today to go into the details of why that works and why it's so we'll talk a little bit about it. But Nevertheless, the idea here is that the identifier is derived from the key, but the the source of truth about what that identifier means is held in some cryptographic structure, which I've labeled here as a key event log. So in order to use these identifiers, we have a system of wallets and agents, and I'm going to be speaking primarily from the viewpoint of hyper ledger areas, although many of these concepts can be generalized to other systems. So this is a diagram that's meant to show something on the left connecting with something on the right. And there's something on the left could be an individual or an organization or it could even be a natural thing like a cow in this picture or a man made thing like some Internet of Things device. And they do that using some system of agents and wallets. Now, from a purely to to be purely precise, we would clearly just delineate between agents and wallets and I'm going to do that in this slide. And then from the rest of the talk, I'm usually just going to say agents, and you should understand that to mean an agent and a wallet, because agents and wallets are almost always deployed in pairs. The wallet is the thing that is is essentially the distributed key man or the it's the key management system, whereas the agent is the software system that uses the keys in the wallet to do some thing and we're going to talk about what those things might be. So this diagram also distinguishes between edge agents and wallets and cloud agents and wallets, and you can see that an individual having an edge agent and another individual having an edge agent could have a direct connection save with via Bluetooth, or they could have a connection through some cloud. set of agents that may even route messages between from one agent to another. These agents are speaking a protocol called did com. That is really the basis of what we're going to talk about today is this idea of a protocol a messaging protocol called did com that a series of interoperable agents, whether they be edge agents or cloud agents can use to communicate with each other. So how does this all get started. What happens is Alice and Bob exchange dids, and you can see here that Alice has created a did 1234 a BCD and Bob has created a did which I won't read but you can see it, and they have exchanged them. And so now Alice knows the Bob the did that Bob gave or generated for her and Bob knows the did that Alice generated for him. In addition to exchanging the did which is the identifier they have also exchanged information about the public key that is associated with that did. And they are keeping track of these in key event logs. And they each have this key event log and without going into all of the details. You can think of the key event log for this particular relationship, because each relationship will have its own key event log as being a conflict free replicated data type CRD T something like a Google Doc, although much more cryptographic. And both Bob and Alice can verify that it is correct, and that the if Bob rotates his key for example, then Alice sees that key event, and the cryptographic chain informs her that this is a valid key for Bob, and that it's been signed by the previous key and so on so you know some people call these micro ledgers, because they have this kind of cryptographic property, but nevertheless the very foundation of this whole idea is that did exchange creates this did relationship. And that Alice and Bob can have a self certifying relationship between these keys, or between themselves, based on these keys and and identified by the did identifier. And this whole idea of how this works, the indirection of the did was brought home, the importance of the interaction was brought home to me. This past week, when someone sent me an email and it happened to be encrypted, and I set him back a note and I said sorry I can't read this and he says, Oh, don't you use this key anymore turns out it was a key that I had exchanged with him in 2011. Of course, I had no idea what it was didn't remember anything about it. Now, nevertheless, he still had it in his in his system. And so a better distributed key management system is clearly going to benefit a lot of people. And that's really the basis of did calm did calm is a messaging system, based on these did relationships. Alice can have as many did relationships as she want Bob can have as many as he wants, because they're based on dids and those dids are linked to public keys. They can sign messages to each other, they can encrypt messages to each other. And even if they rotate the keys because they've been lost or or or whatever the did relationship can remain. And the key event logs will sync up the keys between Alice and Bob so that they can maintain their relationship. A little bit later. So this diagram is just meant to show a number of did based relationships that Alice might have. So you can see that Alice has one with Bob like we've been talking about but she also have someone with Carol, Carol and Bob happened to have a did relationship. Alice also has a did relationship with with Bravo corp and with a tester corp and with or tester Oregon with certified corp. And you can see that in this case, a tester org has issued a credential to Alice and she has used that to present a proof to a certified corp. And that credential is not based on peer dids but rather is the root of trust for the credential is rather a public did that is written to a ledger, which allows certified corp to actually validate the credential using that public did and and the credential definition that's associated with the credential. But the idea here is that did based relationships can form a complex network and any individual can have as many of them as they want. It's important to note that Alice in this diagram has five different peer did relationships. She has created a different peer did for each one of those relationships she's not reusing the same peer did in each relationship she's using a Now, because of the secure and interoperable nature of this did calm represents a secure network overlay, very different than say TLS, which is another example of a secure network overlay, but TLS is very specific to a specific to a certain application, namely, HTTPS, whereas did calm is a general purpose messaging application. And importantly, it allows other protocols to write on top of it. And that is a very, very important feature because it creates this idea of the self sovereign Internet that I use to title this talk. So, unlike, say WhatsApp, or signal which, you know, can talk to each other but can't talk between the two platforms using wallets that speak did calm. A transit wallet can speak to another transit wallet or an ID ramp wallet, or a leasy wallet, or an isadas wallet or any other wallet that happens to be our agent rather is probably the more proper term or any other agent that happens to be interoperable with the hyper ledger Aries interoperability profile. So, we've talked about did calm is secure private interoperable transport agnostic, but the thing I want to focus on now is the idea that did calm is extensible. So, to do that we're going to talk about tick tock tow protocol, and I am going to try to share. I'm going to stop sharing. I'm going to start sharing a different window so that I can show you this. Here we go. I can find it now. Okay, so this is actually what I'm showing you on the screen right now is actually the GitHub Aries RFC protocol for tick tock tow. So this is actually a defined protocol in the Aries. RFCs that Daniel Hardman put together really just to as a simple protocol to show how protocols could be defined on top of Aries. So in my lab at BYU, Bruce Conrad who works with me put together a version of this inside our Pico system, which is a system that speaks agents. And so I have here a agent for Alice, and I have an agent for Bob. And you can see that Bob doesn't have any connections Alice has a connection to agent book for historical purposes, and we're going to create a connection between them so this is an invitation if we looked at it it would look like this kind of complicated QR code but that's not really what we're going to do we're just going to copy it. We're going to come over to Alice, and we're going to paste it in here and Alice is going to accept it. She now has a connection to Bob Bob has a connection to refresh that. Bob is going to start a tic-tac-toe game with Alice, and he's going to say I'm X and he's going to let them move first. And so now Bob is now in this game if we come over to Alice, and look at her connections with Bob you can see that she has a message from Bob says let's play tic-tac-toe I'll be X, and she could say, Okay, here we go. And she's just sending that that's just a message that she's sending Bob but she's going to come over here, and she's going to click oh, and if we go to Bob. He sees Oh, he clicks X, so on and so forth, we can see that you know he saw her her her messages, and is playing tic-tac-toe via the protocol. It's just a simple demo to show that these agents can have protocols put on top of them. It turns out that if I were to go into this we're going to Bob you would see this is a system of called Pico's KRL, not nearly any time to go into it but you can see that he has rule sets for a sovereign agent and for the did com plug in and one for tic-tac-toe. And all of these are what's allowing this game to go forward, but it's all happening over did calm using a protocol that's been defined by Bob. Let's go back to the slideshow. And you have to go in here. So in it so there are some protocols, you might if you're familiar with verifiable credential exchange inside hyper ledger areas. You might think of that as just oh something that's implemented in the code but in fact issuing a credential and presenting the proof from a credential or protocols which are defined on top of did calm. So they're not just like, you know, this kind of hard coded thing inside areas they're actually protocols, which allows credential credential issuance and proof presentation to be done in an interoperable way by anyone who can speak these protocols on top of did calm. And you could imagine there could be lots of other protocols that were defined on top of did calm you could have protocols for delegating or commenting buying and selling contracts putting things in escrow scheduling, there are almost any workflow that you want to make interoperable you could think of as being a protocol which is defined on top of did calm. Now to think about what the possibilities might be I want to talk for a minute about the Internet of Things. So this is the current model for the Internet of Things which I call the CompuServe of Things. In this case, Alice has a Baratza coffee grinder. And since it's the current model of the Internet of Things she has to download Baratza's app, and it connects to Baratza's administrative IOT system that maybe speaks to the coffee grinder through some API, and intermediates essentially Alice from her device. So imagine a different model. This is our, the diagram I showed you earlier but now Alice has this coffee grinder out to the right and if we ignore everything else we just see this so instead of Baratza intermediating Alice's relationship with her coffee grinder. Alice instead has a peer-disk relationship with her coffee grinder, and she has one with Baratza, and interestingly enough, the coffee grinder itself has a peer-disk relationship with Baratza. So what might we do with that. So one of the most obvious things that you might do with that is Baratza might issue firmware updates. The coffee grinder has a peer-disk relationship with Baratza. They can offer a firmware update over the DidCom messaging system that the peer-disk relationship gives them. And Baratza, I'm sorry, the coffee grinder can use Baratza's public did to look up the current key that Baratza is using to sign things and validate the signature of the firm. The signature of the firmware update all by itself and Alice can now be confident that she can tell her coffee grinder. Yes, as long as you can validate the firmware comes from Baratza, please go ahead and update your firmware whenever it comes along. So that's kind of the obvious kind of thing. You might imagine that Alice needs to prove ownership, maybe not of a coffee grinder, but of something, right? I just made a customer service request yesterday. I had to prove that I had bought something. So we could imagine the coffee grinder issuing an ownership credential to Alice, and Alice using that to prove to Baratza that she actually owns the coffee grinder. Of course, you could use it to prove to anyone that she owns the coffee grinder if that were important. There's all kinds of interesting sub scenarios here about what happens if Alice, you know, sells the coffee grinder, lots of interesting scenarios in this one. One of the most interesting to me is the idea that the coffee grinder itself could be at the intermediary in a customer support relationship. Alice, if the coffee grinder has some kind of problem, Alice would tell it to initiate a customer support contact, and it would connect with Baratza. And of course it knows a lot more about itself and the problems it's having than Alice does, and so it could just communicate with Baratza. Baratza knows that it is one of their products because of the, you know, the credentials that the coffee grinder might be able to prove to Baratza. So lots of interesting scenarios with that. There's a company called HERO, H-E-A-R-O, that is pursuing this actually with DidCom and verifiable credentials. One of the most interesting ecosystems is vehicles. I had a company several years ago that did, that used this exact model, not with DidCom because it didn't exist yet. But, you know, Modulo, the actual DidCom, used this exact self-sovereign model in vehicle connections. You know, vehicles have lots of relationships, owners, manufacturers, financiers, manufacturers, I mean dealers, insurance companies, other vehicles, traffic signals, lots of interesting things. So one of the scenarios we might imagine is a DidCom-based protocol for buying and selling. And this is a very interesting kind of relationship, right, because if Alice wants to sell her truck to Doug, she might list it, she might tell the truck actually itself to list itself on some brokerage. When Doug finds it, they would set up a DidCom relationship that then could be managed through some buy and sell protocol. They could each have DidCom relationships to their financing. They could have one to the DMV, to insurance companies. And, you know, then there would be a protocol for actually transferring ownership of the truck from Alice to Doug. And one of the interesting things about that, at least from a PICO standpoint, is that Alice, when she transfers the truck, the truck's going to know a lot of things about Alice. So from an information hiding perspective, she may wish to transfer the maintenance records. In fact, Doug may insist on that, but not the trips that she's taken. But she could keep all of those in a shadow truck, kind of a device shadow that would keep all of the things that Alice knew about her truck can be fully functional, at least from a data standpoint, as Alice completes this transaction. So PICO's, we're experimenting with the self sovereign internet of things, as we've seen PICO's can be agents. We recently updated the engine and, you know, Aries has gone through a lot of transitions. So the demo I showed you is actually based on the old Aries profile, not the new one. So we're working on incorporating that making DidCom the primary messaging method as opposed to HTTP, which PICO's have been around since 2008. Some transitions there. And exploring the use of DidCom protocols between PICO's for various things. So if you're interested in any of that, you can go to pico labs.io. There's code and quick starts and lessons. It's all open source. And we have some interesting projects that we would welcome people helping us with. So, I've uploaded these slides to Hyperledger so you can get them follow through all of these links if you're interested in going further. And of course I'm always available for questions a lot of the stuff that I've talked about today I've written about on my blog at windley.com. But feel free to pop me an email or, or if you have other questions that you want to ask. So that's what I had I don't see any questions, or anything in the chat so unless somebody has a question that they'd like to put forward, we're getting close to time. So, we have a question. Any SDK for DidCom. Yeah, if you go to Hyperledger Aries. Hyperledger Aries is a whole set of open source code. There is a Python version. There is a JavaScript version. Aries is a Pico version. The Python version is Akapai. We call ours Akapiko naturally because you know who wouldn't want to go to Akapiko. And there are there are other implementations of that but yeah. Yeah, Akapai is not just DidCom. It is, but it is DidCom in the sense that what it's doing is it's implementing DidCom based protocols. So, like I said credential issuance is a protocol on top of DidCom. So, so the whole Aries system is DidCom based. And I've uploaded the slides to Hyperledger. So, so that should be available on the Hyperledger system if not send me a note and I can drop you something. Yeah, so how can we use self sovereign identity on resource constrained device that's a really interesting question and that's why Pico's exist. Coffee grinder may not have all of the resources it needs to be a fully functioning system, a temperature sensor for example probably isn't going to have its own wallet and be managing keys. That's why Pico's exist. Pico's are device shadows that can that can work with resource constrained devices to offer them these kind of agent services. So that's that's exactly what Pico's are designed to do is to use this. Any alternative to Aries. Well, I'm probably not the best person to answer that question what I would say is the Aries is a set of specifications. There are Aries code implements all of this but for example, the Pico stuff is not part of the Aries project it just uses the Aries specifications to be interoperable. And yes, Pico's are all open source. So where are at time, I probably ought to end so that you can get to the next session but I appreciate your time today please feel free to ask additional questions by sending me an email or on Twitter or whatever so thanks a lot guys.