 All right, let's get kicked off. We've got, I think people have got a fair number of people here. So first off, folks, I just wanted to put out a big thanks to Christine who's been taking the, running the show on trust registries for us for some time now, but she's prepared this session for it. And she and I are going to provide that. So we're going to cover off today, really trust registries going a little bit beyond the basics. And you'll understand why big picture, we're starting up the efforts of trust over IP, one of the task forces that I co-lead along with drum and read because there's been a lot of interest in that. What Christine's been working on is working with various different groups and who are curious about where trust registries fit, where they're going and she's going to open up the discussion shortly here. Christine, you want to just dive in and take it away and I'll take over at some point. Yeah, so thanks for coming everyone. So we're continuing loop. We're here just, we love to help solve complex issues. We're extremely passionate about these cutting edge technologies. And so we're just really excited to play a role in shaping the future of SSI ecosystems. And go ahead, next one. So the agenda is short, but we have a lot to cover. We're going to go over just the basics of what is a trust registry, where we are now with the trust registry protocol specification, what's next, and then some questions and answers as time allows. Next one. One quick thing, we will be sharing other recording as well as notes and then we put into the chat and stuff like that for folks later. So basically we've been talking about trust registries for a while now. We published the wallet report in 2019 and then we did a condensed version, chapter nine of the SSI book. You can see I read it a lot, have lots of notes in here. It's super helpful. It's, I mean, it looks intimidating, but it's not. It's actually really easy to read. And I've also put together an updated and condensed version on our blog. We'll link to that in the show notes as well. So next one. So really trust registries are here. Just to help us answer some of the hard questions that drive our trust decisions, especially on a technical basis, questions like is the issuer of this credential authoritative? So if we're looking at a driver's license, was it issued in my case by the Ministry of Transportation of Ontario or was it made by some tech savvy teenager trying to pass through the age of majority? And then as a holder, if I'm presenting my driver's license or my travel pass at the airport, and that includes some of my most personal information, can I trust the verifier? As we go through this, you're gonna see that there's so many more questions and answers that are needed. And the work that we're starting over at the Trust Over IP Foundation is gonna further investigate these questions. So if you're interested in joining, your participation is definitely encouraged and very welcomed. Next slide. So we're just gonna look at trust registries. Very basic right here for people not deeply entrenched in the SSI or decentralized identity space. Just talk a little bit about the trust triangle here. So the concept is that the issuer of a credential, they give something to the holder. That's me, the person. And then I'm gonna use it later with the verifier. So what happens when the issuer and the holder, we have a whole bunch of cryptographic stuff going on in the background. Daryl called it crypto voodoo magic. I like crypto stuff a little better. And so they know that I've been issued the credential. I can use it later on. It's in my wallet and not somebody else's wallet. And so when I wanna use that credential, let's say it's my travel pass. I wanna enter a particular country. In that case, the airline, they're gonna wanna know that I've met the rules and regulations for changing countries. And that could include my vaccination status or all the various visas that you might require to enter a country. So I'm gonna need to provide proof to the verifier. And with the verifier and I are gonna do on the cryptographic side of things, I'm not actually handing them a raw credential. I'm gonna be handing them cryptographic proof. So I still control that credential. It's in my wallet, I'm always the holder. The verifier, they're gonna know that the issuer, they've signed off and that I haven't tampered with the data that's in that credential. And so this lets us know that the credential I've handed you is real. It's cryptographically proven to be solid. But at that point, the verifier, they still just have to trust the issuer. In this case, the way that we build that trust is with decentralized identifiers, the DITS. And so the issuer, they have a public DIT and they've signed that credential that they've given to me. And the verifier, they can go into a registry network and verify that DIT. The key here is that there is a public DIT. It's referenceable by anyone, the verifier can confirm that. But there is a problem here. This triangle is just not enough. I mean, how does the verifier know that the issuer is authoritative? Like you have to know that the person who issued that credential, are they legit? Was it a teenager? Because we know that there are people out there crafty enough to do these things. So that's actually, that question's a lot harder to answer. And so I'm gonna throw it over to Daryl who's gonna really get into the governance side. Thanks, Christine. And folks, just to let you know, if I was in high school now, I would be the one issuing driver's license for 20 bucks a pop. So the friends would get, actually I would probably go nationwide. So my friends and family and strangers could get access to liquor, cannabis, whatever you need proof of age for. So Christine, thank you for that. Folks, you can see, Christine has been diving in pretty darn deep on this. She's been helping out in many different ways and contributing over at Trust RIP on multiple things. And she'll be with us at the Trust Nursery Task Force as well, which we'll talk about in a moment. So this trust triangle has been around for a while. We know it's not enough because that question, as Christine indicated, there's a couple of questions there. How does the verifier know that it's really the issuer that they are authoritative for that type of credential and under what auspices. But also I may need to know, depending on what we're doing, I may need to know that, should I release all of my driver's license information, all some deep health information to a verifier? In many cases, we don't really need to know, any verifier can check some stuff out. But let's talk about the decisions that need to happen. This is a concept that came out of Trust RIP. I think Charlie Walton, when he was a master card, really came up with the term and it's really a diamond. This triangle is missing a piece. It's missing the governance. And that's part of the reasons why we, and we're one of the co-founders of Trust Over IP, that the governance and linkage to the technology is really where all the magic starts to happen. That governance framework is the critical piece that brings, starts to answer the questions on a wet code, a human basis of who are the issuers, what does one need to do to become an issuer? What are the rules of issuing? Do I have to prove, if you get your driver's license, you'll know the processes are quite heavy. You have to provide a birth certificate, you have to provide a whole bunch of information, a bill from utility. They have a very rigorous process because once the issue is the driver's license, it's now in use in flight. So that governance behind knowing what's happening is really, really critical. Part of the problem is, well, how do you do that soft, that wet code, human stuff, technically? That's where this Trust Registry protocol where Trust Registries really start to come into play. Because governance is how we manage those, the inevitable complexities. The minute you have one or two people, it's relatively easy. You go to three or four, things start to get hard. And the minute you start dealing with multiple organizations, multiple people organizations, things get really complex, really fast. So we need to understand how do we handle those complexities when they pop and they pop quickly. Because governance is hard. And governance though, when it's concretely implemented is really where the value is. If I look at the day-to-day example of a credit card. Credit card, credit card networks and how they operate. Fundamentally, there's a ton of technology behind it so that the card will work at the counter. Recently in Canada, we actually had our debit system and many payment systems fall down because a single telco went down. So there's a lot of tech behind it. But fundamentally, if you look at what our Visa, MasterCard, UnionPay, AMEX, they are governance networks. Their IP, their real magic is the governance that lets a person who presents a credit card know that they have access to credit. It lets the merchant know that they will be paid, guarantee against certain rules. The person, if I have a real problem with it, I can call AMEX and say, listen, I bought something. It's not what they said it was. I want you to charge that back. And there were mechanisms that follow all of these very complex flows. But fundamentally speaking, it's a governance network. That bank issues a credit card. The card holder carries it around. The merchant knows what happens when they accept and then we have the actual card network underneath this. But fundamentally again, it's all about governance and the concrete implementation of those governance rules and regulations and processes. So we take a look at where are we with the trust registry specification. Version one has been bubbling around for about a year. It's very basic. It really does, as Christine indicated, really three things. It lets us know, is this issuer authoritative for issuing a particular credential type under a particular governance framework? So we get a governance framework for driver's licenses. We could have a governance framework for lottery tickets. We could have a governance framework for sharing information about carbon credits or clean energy, clean products. Then we would know that you are an authoritative issuer of a particular credential type because we can find you in the list. We can ask a question of the trust registry says, tell me, do you recognize this issuer for this credential type under this framework? Yes or no? Similar thing if we need to. We can ask for, is this verifier authorized for this particular presentation request? You may want to take a look at it as an example. The driver's license gets overused but because we all use it. At least two profiles of a driver's license could be in use. One is I'm old enough to do something. That's really needs to know a picture of me. They don't need to know my name. They don't need to know my date of birth. They just need to know I'm over in case if I'm in British Columbia over 19. Quebec is 18, much of the state is 21. You just need to really ask that question and get a yes or no. Law enforcement officer who pulls me over probably needs to see my full driver's license details which likely includes information that I don't actually see when I read the actual card. It's read it in my hand. There's a third question that we ask and this is more a little subtler but it is part of the, I don't know if you, Christine, we had a tweet storm a couple of weekends ago or maybe it was last weekend that really got into, why are we doing this work? And in some of the comments are, well, trust registries just centralized trust. Well, that's the nature of trust. There will be many trust registries but if you think that trust is utterly decentralized think you need to re-examine what trust looks like for different types of things. There are different trust registries. A list of driver's license issuers for North America is likely different than a list of driver's license issuers for Europe but they probably know about each other. A list of driver's licenses for North America is wildly different than someone who is tracking carbon credits in a particular province or state. They may not know about each other. They may not care about each other. The key there is there will be many. We, one of the clients that Christine has worked with, I've advised a little bit, major financial institution asked the government, how many trust registries and ecosystems do you think you're gonna be part of? And they were expecting an answer of a handful. And when the government said hundreds, it caused a pattern shift in them to realize, and then you realize the math actually about government might actually be thousands of trust registries, of ecosystems that they participate in. They're in control of some. They have some strong influence in others. Others they're just a member of. So it really comes down to as you build this out and think about your day-to-day life, all those trust things that happen, there's wildly different levels of trust and you need to be able to talk to those other trust registries. So that's really what the trust registry task force created, it fell out of the good health past work. It's been really well received but we've been getting a lot of questions at Trust Over IP. Christine has been fielding a ton of questions from various different folks ranging from financial institution, corporations to governments, both at both nation-state level as well as subsidiary levels like provinces, states, cities. The future really of what we're starting to kick off and that's one of the reasons we're doing this webinar is to help kick this effort off is at Trust Over IP, we're starting the next version. Whether that is a version 11, 1.1 or 2.0, I think it's 2.0 myself because it gets a lot bigger faster. And the reason we got this sort of virtual iceberg is there was a lot more things we'll be discussing. I'm gonna get into a bit of that right now. Some of them being schemas, what credential types, what does messaging look like? We'll get into the, what are we doing? But the key there is we're gonna start exploring in more depth. We did capture a bunch in the version one because we wanted to get something out the door because there were no answers. You'll always find that, well, this team here continuum loop, but a lot of the people at Trust Over IP, it's about getting things tested in the wild, explored in the wild and used in earnest in production to make sure we do understand the bounds and the real what's necessary for production use cases which is why we start small. Are you an authoritative issuer? Are you an authorized verifier? What other trust registries do you recognize? I wanna cover that tiny little bit as well. The one other trust registry do you recognize is a really subtle but important thing. If we go back to the work we did during Good Health Pass, what was quickly recognized? Global authorities wanted to put in an X509 type of credential network at full PKI heavyweight X509 which is a great technical solution. It's a great technical solution when you have a point of control. Passports is a good example like KO and there's a great point of control there on how passports work, how the crypto works there. You have a very limited numbers, it's actually legislated in every country and it's mandated and it's passed by UN related institutions. You have control points. What was recognized quickly that health is an area where there are no control points. There's no single control point at least. Every country has its own way of doing things. Every country has done things differently inside of itself. In Canada for example, certainly there is some federal activity but largely speaking, health is the mandate of the provinces. It's similar in the states but those two countries have different mechanism by which they can enforce or influence or guide things but they can't just drop the hammer and say thou shalt do this and there is certainly on a global level. No authority that can tell the countries what to do. There are some authorities like WHO who have a lot of influence in a lot of places. Arguably they have more influence in places where they are funding the healthcare systems but when they try to tell a country to do something they realize very, very quickly, you can't do that. It doesn't work. So imagine the following trustworthy question back to COVID in longer term. This is much more about the long term. COVID was obviously too fast, too tactical but the work it could help us discover the following. If I as a country will answer the following question. So imagine the US asks Canada, hey, do you recognize this trust registry out of the UK? Yes or no for health purposes, for your health governance. And if the Canada responded yes, that's a big signal. If they responded unknown, that's another signal. If they responded no, that's another signal that lets the US is asking the question to make decisions. That's all it is. Canada is not saying you should use them, thou shalt use them. No, it's saying, listen, I trust them or I don't know who they are. Now we can start looking, hey, maybe this is the high school kid issuing driver's license because no one knows who this issuer is because it's in a different country but you kind of get the idea. So maybe that Polish driver's license that my son managed to find somewhere really wasn't from Poland. But back into the future, where we're going, all these many, many more things, we'll cover off a few of these and what's being worked on. It's being worked on in many, many places, ranging from wildly, some groups have open sourced. There's groups have built this into their product space. TRNZIK has a version one trust registry protocol engaged in DCO is definitely working on things. You'll note, I don't know if Telegram Sam is on the call but he and I were, we're having a great discussion on Twitter. We've also had discussions on signal and stuff. We, he and I, I have a lot of respect for Sam at least. I'm not sure I'm sure Sam, I won't speak for him. But we're going into the what's necessary and how do things that really operate, especially also how do we share this type of stuff? Well, let's cover off a few of these things. So where do we need work? So a lot of questions here that relate to dids, credentials, the wallets that are in flight to prove some and go through each of these individually. But really start asking a whole bunch of questions and then there are more questions underneath this. I'm not going to go into into a detail there. That's really what the work that's being done at trust registry is, it's being done. Christine is helping some. I've been deployed on a major client project that's kind of had me focus there. It's one of the many things that's in there plan, but it's in the plans of many different groups. Let's talk with the individual questions. So what about the trust registry itself? Right now, as I mentioned, really, I can ask another trust registry about their thoughts on another trust registry. But I can't actually talk to a trust and say, hey, when were you last updated? What regulations are you listed in? What tell me the data, the metadata about the trust registry itself? So a lot of questions there. We need to figure out what does it mean to codify regulation? Can I point out, for example, the governance authority for things like BC government, which I'm living in BC now, they have the corporate registration. Where's there someone asked a long time ago? I think I was actually wondering about me. Where's your governance framework for this? And John Jordan was kind enough to say, we don't need one. It's regulated. It's in legislation. British Columbia is the authority for issuing corporate registrations for the province of British Columbia. That's in law, like perfect. But how do you ask that question technically? How do I point that and say, show me your points of reference? And also, ideally, one is that those points of reference that point back to you, the trust registry. We talked about dids. There's a lot of different questions here. For example, which did methods do you support? There are, as folks may or may not know, the W3C passed the did core specification. It went through quite a rigorous process. It was the only time there was actually, that I'm aware of, I think it might actually be the only time that there was a formal rejection of the specification by some of the big players in web two, who were saying things like there are over 100 did methods. How can you standardize on this? Like, well, how did you get to the point of all of the various different standards that became the web? You started with a lot. You had a power law that broke it down and took it what's actually being used. Same things can happen with dids. But did methods start to raise up other questions? Not just, is it in wildly using adoption or is it using .0001% of the planet and not in your country, you may not want to do the work because every did method will require work. There are slight differences between how they actually respond to different things. Some are more simple, some are more advanced. But further, if you take a look at how some of the did methods were created, the raison d'etre might be, well, I'm a blockchain and I believe in tearing down governments. Well, it would be kind of hard for a government to adopt that blockchain. There might be policy and social issues in adopting that. Regardless, they may make the decision to adopt it, but likely based on popularity, is it in use in the wild? Because you can't do everything. And frankly, some of the methods, ones are there for to prove a point, but are somewhat of a joke. I can't remember if it was snail or pigeon, whether it was a snail male or a pigeon, a passenger pigeon, a did method, which was there to explain that this is possible to do really out of band. These dids are useful offline, that kind of stuff. But also back to the dids, where do I learn about it? What's in your did docs? How do your did documents refer back to your own governance framework? Do you have other sources of truth? Can I go to DNS, DNSSEC, to find some backup, some more anchoring information about your dids? What are the ways that I can find more ways to discover and feel better about your dids and what you're doing with them? Is there a requirement for your dids to be autonomous? Or are your dids controlled and anchored to a single chain or something? Meaning you aren't actually in control of your keys, the wall that you created on the chain is in control, or do you have full control of the keys? Because that lets me decide certain things, at least understand your system. We talked about the credentials and the requests, two wildly different things, but they relate to each other very, very closely. For example, what credential types are used in your ecosystem? W3C has numerous ways of being W3C compliant. JWT, there's various different JSON-LD approaches, and there's discussion still, and there's work on the version 2.0 on where do these land? The important part for the ecosystems, not a discussion of JSON-JSON-LD, XML, CBOAR, ASN-1 encoding. The questions are, what credential types are used in the ecosystem and tell me about them? Because if I'm a verifier, I may wanna consume them. I may want to verify them. If I'm an issuer in a particular ecosystem, I need to understand, how am I encoding the data that I need to share? What is the format? What is the schema of those credential types that I'm authorized to use, and how do I encode them? That's really important for the integration, it's really important for the consumption, the issuance, and for the holder. What can they expect to see? And is their wallet capable? We'll talk about wallets in a moment. Is their wallet capable of ingesting and of storing that credential? And then later, flipping around to the other side, when I go to verify, what can I do? If you've issued me a driver's license that has no ability to do selective disclosure, I'm taking your whole driver's license. Great, am I allowed to do that? Is that a capability because there's a technical deficit or technical limit? Do I need to have a list of authorized verifiers because otherwise I'm gonna have PII in the wild? And we'll get into discussion on some of these things. Legal documents are not, in my view, in our view, a continuum loop at least. A viable thing is, well, don't do that, it's illegal. That's already been proven. Privacy laws are everywhere and it doesn't matter. You have to actually get caught. You have to be prosecuted and the prosecution has to actually find you enough to make it actually worthwhile to protect the information. So you start to wanna look at, okay, what's necessary? If I'm limited by the technology, I may say, you know what, driver's licenses? No, we don't do those. You need to issue an agent majority card. That's another ecosystem change that says, hey, agent majority card has a blurry photo and a date of birth that can be used and or it simply says over 18. This starts to answer these questions of, what do these things look like on the request basis? Initially, they were called proof requests, presentation requests. It also gets into the discussion of messaging. How am I asking for that? Not just the technicals of what does a proof request look like? What does a response to a proof request, a presentation request, the actual presentation data look like in a data format, but how did I ask for that? Who started it? Did I offer the credential to you? Did you request it of me? Which way did we start? That's where you get into what messaging formats are being used. How are we testing that? How do we get to compliance? How do we get to that real deep standardization and real interoperability? Where I do understand the semantics of your domain, you may operate in a completely different domain than I do. If an insurance company is looking for information, they are really deep and rich in their own financial institution market, specifically insurance. They know their ontologies, the dictionaries of how words are used, and now suddenly they're working in the mining environment to do some work and they're pulling in credentials. Those ontologies are wildly different. Words may be exactly the same with utterly different meanings. So I need to understand all of these things about you. Gets a little deep pretty quickly. As you can see, this is why we cut work off at those simple questions. Authorized issuer, sorry, authoritative issuer, authorized verifier, and do you trust other trust registry? Because this set of questions here is pretty big and we'll be digging into that in the task force. Another question comes up and this is being worked on by multiple projects. And while a while back, we were formally advising one of the provinces. We've been informally advising some of the provinces in Canada for some time, see for many, many years now. But one of the harder questions is, this gets into the part of the book, the WALT report. And I think we have a blog entry, Christine, if we put that into the notes at least, the Bubba's, can I trust Bubba's wallet? It was a facetious question that really asked the following. If I find in the app store a wallet that is compatible, technically compatible, it's got 4.75 stars with thousands of reviews. Everybody loves using it, the best user experience. But we find it's built by North Korea. There's nothing in the World W3C specifications. There's nothing in the Hyperledger Aries and or whichever messaging approach you wanna do for requesting. There's nothing in those that say, hey, when the information is in flight, that the North Koreans couldn't off-gas the information to them, send a copy of their way, because they're building their proof because they have access to the raw data. You need to know and ask the question, depending on what you're doing, which wallets do you support? And it's not a question people like to hear, but reality is that there are gonna be high assurance use cases where there's gonna be a real limitation on which wallets are allowed to do what. Because you're gonna need to know that someone has tested that to make sure that it's not doing something nefarious. It's not doing something that is slightly off-standard and not intentional, but could end up with dangerous results. So that's a really hard one. There's work going on, great work going on at Diff on some of the technicals behind that. Certainly the provinces in Canada that are active in SSI are diving in really hard on this one here. There's a lot more there. We're just to tell you the 35 minutes into the meeting point, and we're largely done with our discussion here unless we have some questions that are flying in. And please do ask questions. Work is starting up and Christina and I will share out in both the, well, Christina will get a blog out with this with some of the key reference points that we've got. But with pointers to the trust over IP groups where this is happening. So I chair the technical stack working group. It's paired to the governance stack, but underneath that is the trust registry task force. That's where the actual work gets done. Trust over IP is free to join. Certainly trust over IP itself is a foundation. We were one of the original funders. We're a very small shop. We're not currently funding, but we put a substantial amount of our cash into it. It does actually warrant and it is a really good place to throw, but you don't have to pay anything. You can join as an individual or you can join as a company, both free. You also though can step up to the steering member if you want. So I suggest if anybody wants to join us, please do. And again, we'll get that link shared out through the various different channels that we're putting this recording on. One of the questions that popped up came in directly from, I won't name him, but I've already named him. He's one of the topics with regards to trust registries, which is machine readable governance. It became part of a thread and I think there was a new thread on, where does machine readable governance sit? What's really cool is I think the work that's been done on machine readable governance really applies to what we're talking about here. So a lot of those questions I've been asking, that we're gonna be exploring the trustworthy task force. A lot of the thinking in machine readable governance helps answer those. A lot of it comes down to, if you followed, oh, I got to name him now. If you follow telegram Sam and I on Twitter and saw our discussion, it really comes down to not just semantics, because that's a dangerous term. It comes down to what are you doing? What's your business need? And how are you operating? And depending on how you're doing it, you may actually grab a dump of data from a particular trust registry that says, hey, here's all the information you need, take it with you, run off. The reality is that depending on where that is in my zone of control, we tend to look at three things. And when we look at, from our perspective here, is there's an immediate zone where, most of my day-to-day work is being done and I have to, no matter what, even in times of crisis, focus here. For example, police would probably always wanna have information on North American drivers licenses. Once they're all digital. They may not want to have on board, because it's an exceptional thing, things like, hey, fishing license, because they're stepping in to take care of fishing licenses, but they may want to have a cash of that, who knows. But at some point, you're gonna bump into something that you have never seen before. And you can't know all the answers and you can't say, hey, give me a list of all your dis because the first question they're gonna say is, who are you? Because you may not be allowed to have that list. You may be able to ask one at a time what those are, but it really just depends on what your needs are. We started out the trust over IP, that's sort of the trust registry task force spec started out as a RESTful API. There are many other ways to deliver this, big dumps of data, on-chain protocols, non-RESTful approaches, our GRPC, whatever it is that we need, that's what the group will get to. Christine, do you see any questions at all? I already answered one question online. Yeah, I actually had a couple come in before the webinar that were sent in to me. So the first one was trust registries will prove essential, but going one layer deeper, the next question is, who will be trusted to create, maintain, and validate entrance to the registry? A consortium in some cases, a regulatory or governmental body, the trust chain is difficult to seed. That was a comment that was sent in to me on LinkedIn. Yeah, yeah, no, and that's, that's a... Yeah. I know. So it really comes down to how formal are things. So here's a, I'll give a real crisp answer on one, but I'm gonna change the answer. So for example, there is a, I don't know if they're a trade association or what they are, but it's called AMVA. Don't even know what it stands for. AMVA is a lot of the vendors in the driver's license, hard, physical issuance cases. They're also getting involved with MDL. MDL is slightly, it doesn't not fit in this world. It's got some of its own sort of walled garden issues, but largely speaking, it's a really good source of data for mobile driver's licenses. AMVA is the logical group to say, yeah, they're an authority. I'm not sure if all of the states and provinces who participate would want to hand control over to say, yes, you are definitively the manager of the source of truth of is this issue a valid or not? The reason I say I'm not sure they're comfortable with that is there is a sovereignty issue here, not a self-sovereignty issue. It is a sovereignty of the nation state issue. It's hard for them to, and I don't know that they should hand over control to someone else to maintain that list. They may be one source of truth. So the hard answer is AMVA is a logical place, but it may not be the place. And we may end up with very informal, that people were called the beginnings of the internets. And before pre-Google days, there were the canonical list of lawyers, the canonical list of law societies and or the canonical list of whatever, you're gonna have that informal thing happen. But some point in time at some of those levels, you're gonna have informal things like, hey, this is the best curated list of folks that we follow. That'll probably always be informal. But someone's gonna create something informally, like here's a list of all of the driver's licenses issues on the planet that may formalize or may say, hey, no, there's actually AMVA is North America. Here's the EU, but you know what? That informal source may be the de facto, de facto being the informal standard for source of truth. So it really, really ranges. And this is where the incorrect assumption that trust registries centralize things, they don't. They give you a place to look to answer the questions you need to manage a particular ecosystem. If that ecosystem is by nature, utterly decentralized, guess what? We could have a Dow that does the votes that say, Christine, you are allowed to do the issuance. Oh, we voted you out, Christine, you're no longer allowed to do the issuance. Totally decentralized, if you will. It falls into part of my, and I will try not to go on a rant. The goal here is not to decentralize the world. That's a false premise because no matter how you do it, one, I'll tell you this, there will be a point of centralization that you don't recognize. Two, Christine, if people do want to chat, just allow them to do that, or maybe you can't. I'm not, I don't. Yeah, I don't know if we can do that. Yeah. And Jacques has asked you too about we can't chat whether participants. Jacques has been doing some really, really good work with DNSSEC, which depending on where you are, may be the perfect anchor point for a trust registry. If you are highly decentralized and one of your reasons for existing is you don't trust the man, they may not be. If you're a nation state managing, for example, in Canada, the GC.ca domain names, DNSSEC may be a perfect place for you. It aligns with your overall key management approach. It aligns, if it aligns with how you put the people who are authorities and how you make the business decisions, perfect, lots of different answers here. And Jacques, I think Jacques, I'll speak for him. They're doing a lot of work right now at CIRA. Can you look that up, please? Bad on me. Can the internet registrar? Authority agency? But they're basically, this is a great example of trust registry, it's informal to formal. Years and years and years ago, the .ca domains. I remember trying to get one, it was hard. .ca domains back in the day were managed for years on a spreadsheet. That was a trust registry for DNS. Obviously formalized, CIRA has actually gotten to the point where they have actually built tooling and they use that, other countries use that tooling, other top level domains use that tooling because they understand the rigor required to manage the DNS trust registry. So that's another good example of where things can be. So I think I diverged a little bit there. Thank you, Jacques. Canadian internet registration authority. I did sort of mumble through it, I think. So Carly has a question that she sent in. Good question. Do you see a model like a stock market for trust registries? One can buy stocks privately, but to trust that you were getting the correct information and buying legitimate stocks, you would need legitimate stocks. You would go to one of several stock markets with their own governance details, while also under regulation, there could exist markets of registries that are overseen by regulation and you could still have private registries. Yep, absolutely, Carly, down the road. And this was, again, we worked with a client who asked the government, how many ecosystems and trustries do you think you'll need to be in contact with? And again, they were expecting handfuls. When they heard the answer hundreds, like they're literally dropped all of them on the public, like it just, they recognized they cannot be in control. They cannot be in control of this. It gets too big, too fast. And you end up, what I would say, you kind of fall into this your own gravity well if you try to interact with all of these because that 101st one is still gonna take effort for you to integrate with because you gotta find them. You didn't know they existed. You found out about them. You gotta find the endpoint. Okay, cool. Anybody else know about these folks? It's very logical for a third party. God forbid in this decentralized world where their job is to provide kind of an aggregator function. It's all this aggregate, disaggregate. This is the nature of the internet. It combines, it blows apart. It recombines in different ways. The question would be further on that is is there liability when I am paying someone and what happens when they let that high school student in for the province of New Brunswick, for example, and New Brunswick wasn't actually issuing driver's licenses digitally. What happens when they're wrong? So we'll get into the same sort of indemnity thing which we already have structures in many, many places for but also as you look at this decentralized way, there might be a penalty. This is no, you were wrong and we just voted you down on this. There's a penalty to pay. You've staked something, you get a slash of 1%. If you screwed up this way, you get a slash of 20% if you screw up that way. So definitely I see that happening because when you get to the world where you're literally talking to thousands of trust registries, thousands of ecosystems from time to time, you need to go somewhere. That's a really great question. Yeah, good. So I have one more that was sent in to me. They would just like to know, how do trust registries verify that you're the owner of a credential? So this might be related to, there's multiple ways to prove. One of the questions that trust registry answers is, are you an authoritative issuer of this credential type? There are other ways in the SSI book that I think there's four ways. I can't remember them all. Do you may have a credential that says, I am an issuer? For example, I am a licensed professional engineer in the province of Ontario. I have literally a stamp that I, as my number on it, and I would have to sign it. There's no digital thing for this. But one could imagine me receiving a professional engineer credential that I could use later to sign something. I would hope it would actually use a did because dids are better at signing than a credential. But it would have my did in the credential that says this is Daryl's public did, publicly recognized did, intercredential that you can say, are you really a professional engineer? Yes, here's my credential. At some point though, you always walk the chain back that says, and who said that professional engineers Ontario is allowed to issue those credentials to Daryl? You always end up back at a list of dids. No matter how you look at it, depending on how many steps you go, you always end up with the, are you recognized as an authority in Canada? Licensing for professional engineers has been handed down to the provinces and territories. I believe that's actually correct. I'm not sure about the territories. There's might be some funky there. And there's legislation of which you might say, hey, yeah, these are the 10 or 13 dids that are professional engineer issuers. You're still that's of the trust registry. So would a trust registry be able to recognize a credential coming in to say, yep, here's the list, you could certainly do that. But at that point, it really is the trust registry. I'll just jump back to, it is the trust registry acting as a verifier in that state to update their own files so that the outside world sees, yes, that issuers is considered modified because there was a work, there was some business process happening behind the scenes where they actually follow through the same type of thing. Hopefully that helps answer the question. Yeah. And that was it for the ones that I had sent in. Perfect. Unless anybody else has any questions. Let's give folks a minute for any last questions. We're already at 10 minutes. We can give folks back to their day. So what can you do? I think I've duplicated slides here. Couple of things you can do. One is join that. We'll go get the link out to the task force, the trustworthy task force. If you need to join trust over IP, we'll make sure there's information on who to contact for that. But also for your projects where you're considering this, this is one of the reasons why we help different groups and Christine's been key on this. Understand what this means because things are changing. You're seeing projects, dozens of projects at government level now where they're realizing that in order for their nation's state sovereignty, they need to be in control. And they're stepping into this space and these trustees are becoming more and more important. So understanding what it means to you is really important. But if you want to start working on this, there's really a few different ways to do it. One is start diving into the actual technical discussions. The technical discussions are very, very deep down in the weeds. If you're looking for governance in business, you may have to reach out and reach out to some other leaders in the space. But also openly discuss this stuff. Get on Twitter, get into some of the discussion groups and various different fora. So you can one, learn about it. Two, share what you believe is true. Jacques, who we were talking about earlier has done some really great presentations to, I think he's done them to both IETF and may have actually done it to ICANN on where DNSSEC can play a role in this overall trust strategy space, but get public. And then lastly, where did they, is it the end of the deck? Yeah, that is. Perfect. So just, I wanted to say, I wanted to push on. One of the things I've got to rule is, sorry, I wanted to pass on a thank you to Christine to for one, stepping in here, as you can tell, Christine has been carrying a lot of the weight of what continuum loop does in this space and has been helpful, has also even done the grunt work of diving in and helping with just overall work at Trust Over IP that because I've been deployed with clients, my client project I've not been able to. But Christine, big thanks to you for stepping up and doing that. I see some questions. Okay, yeah, Jacques did. Wow, he presented to ICANN at 3 AM. So technically, that was today. Nice work, Jacques. So Jacques has presented some DNSSEC really cool ideas there to both IETF and to ICANN because DNSSEC is a really good anchor point. Marcus, Marcus Ubani has pointed out and share that link out to Christine from the chat. Yeah, I just copied it and I've saved it in my notes. So I'm going to have a look at that for sure. I'm going to share that in the chat here as well. Okay. Just that was. Can everyone see the chat? They will be able to see the chat. They won't see the. Okay, okay. I'm just putting Marcus's comment here about another resource that was not aware of that. Good. That's awesome. Thank you. There's another resource out there for a get book that's out there. And that's part of the key here is there's a lot of leaders in this space and a lot of people are playing different roles and someone who's consolidating and sharing information. I'm a huge fan. Just as folks, you know, as you explore this, you know, do your work. When you recognize there is a lot of work here, you need to make a decision if it's yours or not your work to do. There are other people in this space who can probably help you. And that's, you know, some of these things. Yeah. Jacques, the chat is disabled and we're winding up and not sure something you wanted me to share. Not sure how we even turn on chat. We'll have to, I'm going to make sure we figure that out for next time. Really sorry about that. He's probably very similar to Christine not having video in the beginning that someone, yours truly, when he set the webinar link didn't click the right buttons. Jacques is going back to bed due to after his 3 a.m. I'm sure after doing a presentation, it wasn't easy to fall asleep. So I'm sure Jacques, you're quite tired. Thank you for joining us here. Thanks everyone. Thanks a lot. Yeah. I think that's it for questions. So thank you very much folks. Again, thank you Christine for stepping up and stepping in here. It's been, it's been awesome. Thanks. Thanks everyone. Have an awesome day. Bye. Bye.