 All right, folks, let's get started here. I'm going to start ripping through things. We're here today, just quick look at the agenda. All he's gonna give us an intro to kick us off and then I'm gonna dive into some basics on what is a trust registry? What's wrong with the trust triangle? That's kind of a backup into the decentralized identity SSI world of some background information you'll need. Talk a little bit about some examples of trust registries that are in the wild or being built out that are solving real problems. And then at the end, we're gonna talk about, where are we now? Trust registries are kind of a newish concept, but not. There are twists and turns when we get into a more decentralized, more distributed world. But we don't understand, what do we really know? What are we fairly certain about? As well as what's next? What are we not as certain about? But we know we're heading in the right direction. What needs to be done? And then we'll slide into Q&A. As we go through the presentation, please feel free to use the webinar Q&A feature. If you need to use the chat, if the Q&A feature is not functioning on your device, Ollie's gonna help run that off. But Ollie, why don't you give us a quick intro? Sure, well, first of all, thank you so much guys for joining us. So it's our first webinar of the year. We're trying to do this on a monthly basis. So this one is about trust registries. So we are recording this session, by the way. So if you want to get the recorded version, we're gonna post it on our website. I'm gonna put everything in the chat. So our website, continualloop.com. We're gonna create the YouTube channel as well as shortly after this. So just make sure to comment it, share it, put a thumbs up as well for your colleagues that missed the opportunity to be here today. So a little background. So I was lucky enough to meet some of you already in meetings with Darryl. For those of you who don't know me, my name is Olivier Dubot. You can call me Ollie Oliver. Or if you want to practice your French, you can call me Olivier. So I'm the new business development director for continualloop. So we are a boutique SSI digital identity consultancy firm based in Ottawa in Canada. We work with small, medium, large organizations all across the globe. And so I've been working with Darryl for quite some time now on other ventures. And a couple of months ago, he asked me to join him in this SSI journey. So my main role with this company is mostly connect with you guys, develop strong relationships, partnerships with any business leaders, whether you're a bank or SSI startup in the fit and tech world, educational space. We just wanna make sure that you have all the tools and knowledge to complete or to start an SSI or digital entity project. We have a lot of relationships in this space, especially Darryl. So he spent hours, 100 and 1000 of hours to develop the rules, the framework, the ecosystem on his trust over IP foundation. And it's a space that in the most four years is gonna probably grow 1000%. So we need to make sure that we have everything possible to help you guys to complete the project that you guys wanna do. And it's on the business leaders and governments to take the lead and try to implement this technology and rule out the other less secure and easier to implement alternative. So we're here to do that. So without any further delay, I'll add it to it, Darryl. There you go. Thanks for the time, Ollie, much appreciated. So we're gonna dive in folks on a few different things. Quickly, Ollie already indicated kind of who we are. We're a boutique consultancy, small shop. We are based in Ottawa, Canada, but we do operate pretty much globally. It's actually kind of strange when we see substantial activity, which we are right now in our own home country of Canada. Background, we've been developing systems for over 20 years, not necessarily as continuing loop, but as companies that I've been involved with founding multiple startups, some were acquired. It was nice, some burned out, wasn't so nice. But we were building mission and lay critical systems for search and rescue, combat search and rescue. We've worked in the payment space, crisis information sharing. So various different spaces where time reliability was absolutely critical. Now we are a consultant advisor for organizations of various sizes from the tiniest of startups. Many of you would know me for many of these sessions. We provide hours and hours of pro bono advice and help people make sure they're heading on the right path, but all the way up to largest corporations, governments, militaries. And we work in really three different ways. One of which is peer advisory and guidance where we come in basically and help your team mentor. We mentor your team, help them make the decisions that are needed. At times we also embed as an executive. I'll speak to one project where that was the case. And at other times we will actually go out and build out the team, partner with the folks that we know who are global leaders and help you execute on projects. Just one of the things I do is I sit on, and at times we wonder if it's too many, but I sit on various different groups, IEEE, blockchain group. We're one of the co-founders and funders of trust, the trust over IP foundation, sit as a steering, I sit as a member of the steering committee. I'm co-chair of the identity for all council along with Nikki Hickman. That's hosted at the sovereign foundation right now. We've been involved heavily and I'm gonna speak to the Good Health Pass collaborative work. We actually led the trust registry work that was there. I've been past chair of standards at Oasis, various of another standards and interoperability groups that are really key. We're actually doing a discussion at some point the next month or two on interoperability, but today let's talk a little bit about trust registries. Trust registries, the term has been around for a little bit, which was actually certainly in the wallet report, which we created back in 2019, which is still actually quite a relevant documents, a little heavy, a little thick. We actually condensed it down as part of the chapter on wallets and agents in Drummond and Alex's book, self-sovereign identity, if you do wanna take a look at that, that might be relevant for you. It's actually a little more condensed version. But the important part of that was with regards to trust registries, answering really the questions. How do I know, particularly how does a wallet know that it can trust the parties at the other end, those issuers and verifiers who were there and how they got their authority? Is it legislative? Is it a community-based authority? Is it really informal? And how does this evolve over time? But part of that report that most folks don't know about, many people have looked at that report, is there actually were two reports? Just one sec, my mouse, there we go. The first one was the public one, which everyone has seen. The other one was more of a private wallet strategy, which the project partners that we worked with are still executing on. This really got into the, what does it mean to your business? Where is it gonna be? Where are things gonna be in three, five, 10 years from now? What does it matter? And we looked at two different types of trust registries, both an issuer registry, a credential registry, things have evolved, as you'll see here a little bit later. I just wanted to be clear on one thing. One of the things you will not find in the list of stuff we do is reports. We don't typically produce reports. This one was done under duress and the people involved would know it was kind of done under basis of temper tantrums. I do not like writing reports. I actually physically detest it. What we've learned in the past over this period now is we do have access to some of the best researchers and report writers out there. And next time, if we ever have to do a report or participate in a report, we will help guide it and not do it ourselves. So let's back up and say, what is a trust rich? Then I'm actually gonna back up even further and kind of show to you, prove to you why it even matters. So at the fundamental basics, a trust registry is there to answer some of the hard questions that really just drive our trust decisions, especially on a technical basis. For example, one of the hardest questions and most important questions is, is the issuer of this credential authoritative? If you have a driver's license credential, is it truly from the province of Ontario where I live? Or is it some high school kid? There you go, Sankershan. I see you in the audience. Is it some high school kid pretending to be from the province of Ontario so that the people he sells fake driver's licenses to can get into a bar? Additionally, as a holder, if I'm carrying my driver's license around or I'm carrying a travel pass, which includes some of my personal health information, can I trust the verifier? Do I know that they're gonna operate under the rules of a particular governance framework? Are they authorized to see that information? And are they responsible when they receive it? There's a lot of other questions that come up. We'll deal with some of them right now, but this is a high level discussion on trust registries. What I just wanna stress as we go through here is that there are more questions, there are more answers needed, but we already know the general path we're heading on. So let's back up just a little bit. So I'm gonna talk a little bit, just for those who are not deeply entrenched in the SSID central identity space, we'll talk a little bit about the trust triangle. This is the issue of a credential gives something to a holder, that's me, the person, and then I use it later with the verifier. So what happens here is the issue where in the holder have a whole bunch of crypto magic stuff, that's my technical term, crypto magic, where they know that they've issued a credential to me, it's in my wallet, it's not in someone else's wallet, that I can use then later. Later on, I want to use that credential, let's say it's my travel pass, I want to enter the country, the airline wants to know that I largely speaking have met the rules and regulations of changing countries, whether that be vaccination, various different visas, et cetera, but I'm gonna provide proof to the verifier. What the verifier and I are gonna do is the cryptographic side of things. I'm gonna say, hey, here's not the credential, I'm not handing you the raw credential, I'm handing you a cryptographic proof that I still control that credential, it's in my wallet, I'm the holder and the verifier is gonna know that the issuer signed off and I have not tampered with the data inside that credential. That lets me know that the thing I handed you is real, it is cryptographically proven to be solid, but the verifier at that point has to trust the issuer. And in this case, what we have are decentralized identifiers, DIDS, and the issuer has a public DID that they have signed that with that the verifier can go to a registry. We, I sit on the board as an ex-officio trustee for sovereigns, a lot of folks are anchoring down to sovereign, there's tons of other networks out there, but the key there is there's a public DID that is referenceable by anybody and the verifier can confirm that, but there's a problem. This triangle is not enough. Business question, there's two of them that get asked is one, how do I know that that's actually the verifier? If we take these public permission networks, I can put a public DID and claim to be anybody. It's a cryptographic crazy looking string of text and numbers. It's not humanly consumable. I don't know what it is. I'd have no way of saying, oh yeah, definitely that did, unless I've gone and done the homework and contacted the province of Ontario and said, hey, you're issuing a digital driver's license as a verifiable credential using this DID. Okay, great, cool. So I don't have an answer for that question. And additionally, as a holder of my driver's license, as a holder of a travel pass, as a holder of a diploma, electronic health records, I don't know if I can trust the verifier. That verifier could be a very well-meaning but poorly implemented system. It could be a nefarious system. It could be the perfect system. I just have no idea how to do this. So we have a solution to this where this triangle kind of falls down and really it's been called in the term that was actually Charlie Walton when he was at MasterCard, started calling it the trust diamond, which we look at the same pattern. We have the issuer giving a credential to a holder, presents that to a verifier later, but the verifier is able to answer or ask a couple of questions because there's a governance authority in charge of things. The governance authority manages who the issuers are. It manages who the verifiers are. And it does this by publishing a governance framework and effectively running something that lets me ask the question, how does this verifier trust the issuer? How does the holder trust the verifier? This critical piece of the governance framework is absolutely, totally critical. Governance itself really is how do you manage the complexities? If it's just you and I in the world, it's relatively easy. That's actually complicated enough. But when we start adding in people in a larger circle, we start adding organizations in that we do not know. They all have different needs and there are different incentives for having their behavior. So the governance is really needed and it's hard. But the governance and that concrete implementation of a governance is really where all the value is. I wanna give you a day-to-day example of a credit card network. I can go to a store, pull out a card, doing a drumming here, pull out a card and walk into a store and use it because a bank has issued me, I'm the card holder. They've issued me a credit card and I then present it later to a merchant. And they know through the governance of this network, whether that be this network that they're gonna get paid, I know that I'm gonna be charged. I also know I have some protections that are due to the governance of the network that maybe if this thing breaks and or is not what I thought it was, there might be ways that I can actually get my cash back. But this is why we trust MasterCard, Visa, AmEx, Discover and lots of other cards because of this credit card network, it's the governance behind it. Yes, there's deeply technical stuff that wires this thing up, but without the governance, the whole system falls down. We have a good question, Darvel. Yes. How does the user know about the governance framework and more importantly understand if they manage to obtain it and finally which users can be bothered to do it? Yes. So this is where we're in the early days. If I take a look at the systems that are out there right now that are using decentralized SSI based patterns, they are in discrete ecosystems and they code that into the wallet itself. So the user has no knowledge that, oh, here's the governance authority that I'm operating under because it's part of it. And I'll speak to one example, which is MemberPass. But as we get better and as things grow, it becomes these trust registries where the wallets can make decisions, where we have software agents that can make those decisions, but that's a little bit down the road. I'll get, and I'll cover off parts of that. That's for David Chadwick. Governance back to it, it's hard. It's a human construct. What Nick Zabel calls it's wet code. It's stuff up here. It's stuff on legal contracts that really is hard to execute on, but it's human. This is how we operate, how we always have operated. The hard part is where's the dry code? Where's the actual stuff that systems, architects, developers can get answers to the question like, hey, where's the list of public dids that are definitive for Canada issuing driver's licenses? They need to answer that question. They need to answer, and I'll get into more detailed questions in a little bit. And that's right away, I'll get into those. And tying governance to technology, I'm gonna jump in here, I backed up my slides here, to talk a little bit about why this is really important, how we're separating governance and technology. And this is one of the reasons why we as a very small company helped co-found, drive the need to create the Trust Over IP Foundation was because of two things. It was this separation of the trust and governance which was always being blurred, but as well as the layering of the solution that we were looking at, which became what we call the four layer model for Trust Over IP. This starts to help us understand the difference, especially the governance at the top level or at any level of the stack. What's the governance side? And then what are the key technology pieces that help us get there? We'll see the term member directory, provincial registry, these really are what now I'm calling the trust registries of the world. So here's what the questions we need to basically start asking ourselves at the most basic of levels. This is, I need to know, is the issuer authoritative? And to answer, to put some qualifiers on that from David is says who? More particular, is the issuer authoritative? And I'll get into the detail on that under what rock conditions. But additionally, is the verifier authorized if you're asking for that to happen? You don't need to. You don't have to have a verifier listing, but you may want one depending on what it is the usage. But as well as, as we grow, and I'll speak to where this becomes more important as a decentralized community. And how do we start taking multiple trust registries and chain those together? So David, you get an answer of, well, if 25 different country level organizations trust this 26 one, that's probably good enough for me until it isn't. And then we get into the signals that are being shared. This is down the road type of stuff. So here's the detailed questions that we actually have already started asking, particularly under good health pass, but this has now been moved in the trust over IP trust registry task force is specifically this, is this issuer authorized to issue this credential type under this governance framework? This lets me know, is say the province of Ontario authorized to issue a driver's license under the rules of Canada? This lets me know if you're really an authoritative issuer. Similarly, is this lab authorized to issue a PCR test for COVID-19 as authorized by the province of Ontario, the country of Canada, or some other national body, which may have sub national groups inside of it. We'll get into that in a little bit. Similarly, is this verifier authorized to request this proof type under this governance framework? So this is a good example of the nightmare scenario for most SSI de-central identity folks is the, I want to use my driver's license at the bar to prove I'm an age majority. There's actually a really, the reason it keeps popping up is it's a really good example. Well, one can imagine a driver's license has different ways of being requested. And this is actually under the MDL, kind of old school standard with ISO. You can ask multiple profiles of driver's license. I'll use two examples. A law enforcement officer who pulls me over probably wants my full driver's license information and I probably should provide it to them. So my wallet may want to say, hey, we've already checked them out. They're a law enforcement officer. We recommend you share that driver's license fully. Go for it, press a button, off we go. Then I, you know, continue on my trip and I walk into a pub and they say, I need to prove your age majority must be in some place where they, you know, they're not checking out my gray hair or anything. And it says, yeah, this is a pub age majority request. It gives me kind of a dumb down picture of me enough for them to identify me but biometrically safe. And it has a check mark over 18, 19, 21, whatever that jurisdictional rule is you need. That's perfect. But then I go to another restaurant. This actually is happening in many places in Canada where they scan the driver's license and they asked for my full driver's license for information at a pub or at a restaurant. This is bad. This is a, you are asking for far too much information. And under the privacy laws of Ontario and the very super promises we have, it's likely illegal and may need to be reported. This gives you an idea of some of those trust questions we're asking. I'm going to get into the trust registry as well. Like for example, is that this particular trust registry understood think countries and COVID-19 and vaccination and travel passes, authorized, recognized for a particular type of credential under a governance framework that I recognized. This is where you can have signaling of countries trusting each other. There are a couple of interesting questions that might fit this slide. Well, let me take a look here. How is an issuer a verifier on boarded in the first place? Yeah. I'm going to get into that in a moment. Keep that in mind, Ollie, because I'm going to discuss with the internal, how do you run inside your place, the trust versus what does the outside world need? We'll talk about that in just a little bit, if you don't mind. Okay, and Sean, we'll take a look at your questions in a little bit if you don't mind. Thanks, Ollie. So what actually happens with the governance side and the trustworthy, this is where the governance and the tech kind of meet because I have to look at the situation. And depending on the ecosystem I'm operating in, I'm going to have the public dids of issuers. I may have a private did of a verifier because it doesn't have to be necessarily on a ledger listed in a trust registry, depending on what it is that I need. Later on, the verifier will want to confirm, hey, I have Daryl's credential here. He provided to me as the holder, but are you really the province of Ontario? Are you really the lab issuing a vaccination credential? So they want to confirm against trust registry is the issuer authoritative for that particular credential type? Similarly, the holder may say, hey, listen, I want to check out this verifier. Are they allowed to ask for, should they be asking for my stuff? If we take a look at vaccination passports with smart health card, they're closed systems right now. You have the card and you have typically a province or state issuing, here's our verification tool because they don't want to share necessarily the keys that are out there. So they can't operate in a larger spectrum. And here's what we're gonna do the internal and external. So the internals of a trust registry really about the, how do we onboard an issuer? That from the external world isn't relevant. It's extremely important to know that, the United States state of Virginia has vouched for a lab that is issuing COVID-19 PCR tests because of their legislative process. That's the body who is in charge of that lab. They will go through various different rigmarole, various different rules to say, yes, this is a bonafide authoritative issuer. Boom, they get added, they manage, they do the create retrieve update, delete of their own business life cycle to maintain that lab. They have to revoke it later if they need to. That's the important part for them managing their own stuff. Another example, I am a professional engineer in the province of Ontario. There are various different regulatory and technical things I have to do to maintain my license. Professional engineers Ontario is the body who is in charge of my license. In different provinces, they have different names, but this is all legislative. How they do might be slightly different rules province to province. The key thing there is at the end of the day, they are the authoritative body, the governance authority, who is operating under their own governance framework and they maintain a list of those issuers, people who are allowed to sign as a professional engineer in the province of Ontario or the province of Quebec or down the states. It's a PE, everybody has their own. So they manage that membership. They also manage what types of credentials they're using, well, how those credentials should be used in the wild. The external world is where we're concerned about, you know, what governance frameworks does a trust or agency operate under. The professional engineers one may not be of interest to many, for those in the insurance world who are making sure that, you know, but buildings are being built correctly, that nuclear capacity is being addressed. It becomes very important for the average person on the street, not relevant at all. So depending on what you need, it's a different governance framework, but we wanna know about those issuers, those verifiers and trust strategies that are known. We'll talk more about what are those credential schema and definition as well as presentation requests that drive the usage of these. Just looking through the questions. Wow, we got lots. I think some of them are gonna need to wait a little bit. Yeah, I think you just answered one of them. I wanna give you two examples of trust registries. One of them is in the wild and the other ones are being developed. Member Pass was a CU ledger now called Bonify. I was the contract CTO for it for a few years because it was really the first operational production use case of SSI, certainly anchored to the sovereign network, but arguably potentially one of the more powerful ones. What it does is it helps credit unions in the States. It's actually got a global mandate, which is important for trust registries. To solve a problem, how do I know you're really a member of this credit union when you phone in, when you walk in and when you log in? They have different technology providers, so they have no control and finding out which is really you. If you wanted to phone in and get your bank balance, you're likely two to three minutes before I can even ask, you can ask the question, what is my bank balance? Cause I really need to know it's really you. You're not trying to scam your aunts. You're not trying to scam some stranger or take over someone's identity. But the key there is that the trust registry evolved. We didn't need it in the beginning. In the beginning, it was the investors of Member Pass of Bonify. The board of directors were really the credit unions who were participating. Everyone knew everybody. So everyone was able to say, yeah, yeah, here's the list of digs. It's just a config file, go for it. But then we started getting smaller credit unions who actually have more of a digital identity problem because they have a fractured set of tools and systems they're using. And we started to get questions from other credit unions, the larger one saying, oh, who are they? We realized that we didn't have a list of those Member Pass issuers that was being maintained. So we started to do so. The principal use case for Member Pass really are two-fold right now. One is inside a credit union, is this credential, do they hold a credential? I issued them, which is not important to know other people's issuing dates. It's just not important at that point. But then the next business case becomes, well, how do I know and prove that I can now take funds out of a different credit union from my own account? That's when we started to get really concerned and wanna make sure that this is an official member of the Member Pass network, that their did is registered, which is anchored to sovereign, but it is in the Member Pass trust registry because it's a very strong authentication signal, a very high level of assurance that if I walk in with that Member Pass from credit union X into credit union Y to take funds out, it's harder for them to get a Member Pass and it is to get a fake driver's license and spoof me, which is a very well-known attack factor right now. So this one's been deployed for, well, year, year and a half. And again, it's focused really on the US credit unions, but Boniface mandate is global. It's also beyond just credit unions, it's community banks. So they start to get different communities. So the Member Pass becomes that anchor and that trust registry is the source of truth. Just taking a quick look at the, yeah, we'll get into some of these questions. I love these questions, but I think it's probably better to go in and the mentions of PKI especially, because yeah, we'll get into that in a little bit folks who are diving in on that. Sean, yeah, governance authority and trust registries are different entities. Yes, let me deal with that when we get back to one of the diagrams, but the trust registry is a concrete implementation that serves a governance authority, particularly serves a governance framework of a governance authority. It is the concrete instantiation. It's the thing I can talk to digitally, but further, we certainly are planning and anticipating that a trust registry may serve multiple governance authorities. Not everybody wants to stand this kind of thing up. It just doesn't make sense where it's all to stand up a full server system when I can just say, yeah, yeah. I'm a, you know, the professional engineers in Canada, they're all served out by one particular trust registry because it's just, you know, cost savings type of thing. Want to dive into quickly, the good health pass collaborative work, the blueprint and again, we led the trust registries segment theme. I don't know what we called them at the end of the day. Before we go in this, when you go back to member pass and there's a question from Alex saying, why do you need sovereign? And when could you just have the, oh, just let me just go up. There was another question, sorry. So why do you need sovereign? And when could just have the public this anchored in the member pass itself? Yep. Whoops, there we go. Yeah, so sovereign. So one of the points that we have to do here is if I take a look at the overall, how do I present a credential? A proof of a credential. So imagine I'm sitting here at Unify out of California. They've issued me a Unify credit union member pass. I walk into desert financial in Arizona. They wanna do a couple of things. One, am I the holder cryptographically speaking of this credential? Do I still control my side of it? Then they wanna do the crypto check to make sure one, I haven't tampered with it, but two, that it was signed by a did by the credit union. The only information we have in a credential is the did itself. It's an identifier, the decentralized identifier. What I need to do when I want to do is go to a public reference point, an anchor, which in this case is sovereign, to say, hey, I just got this information about this, did. What is the public key as anchored to this third, this reference source, which is the decentralized ledger that I then compare that against how the credential was signed? So I'm not saying to member pass, hey, give me mine. This is a closed PKI system. We'll say, yeah, here's a list of all the public keys you need to worry about. But we'll talk a little bit about why we're not doing a centralized PKI system because there are many, many of these things and we can't all be doing the same PKI because someone's gonna be in charge of that who doesn't make any damn sense for us. So I need to use sovereign for that particular anchoring. Member pass certainly could have created its own ledger. That's one of the first things that we looked at doing. Business wise, we looked at what is the business problem we are trying to solve? We're having difficulty in this case with trust internally of our own systems because they're run by many vendors and we've lost control of things. And it made sense, we did the analysis that it needed to be a ledger or utility, could have been a database that is accessible by everybody, but not controlled and owned by any one particular entity, which sovereign in that case fit the bill. It's a public permission network and get into the whole stuff behind it. And again, I am an ex just for disclosure I am an ex officio trustee because I am co-chair of the Identity for All Council. So I mean, it was a business decision which a lot of different groups start with, no, I need to control this myself always almost always ended up with, oh yeah, I don't wanna control that. That's just too much right now. So that's why it's sitting on sovereign. Thanks, Ollie. So backing up to good health pass, good health pass was created to, in Charlie Walton at the time at MasterCard he's now at a vast, was basically trying to answer the following question. How do we show the world what good is not perfect, good. What's good enough to start opening our borders because international travel is cripplingly. It's crippled right now due to the manual and paper-based processes and inability to understand different travel corridors and all the intricacies that are already there. How do we start to use that information to open up in, in New York, they have a single system, IBM has deployed it for the state. It's called Excelsior, which allows me to show my vaccination information if I'm in the state and recognize in a privacy respecting way that at a restaurant, the problem is if I'm from New Jersey or Canada, my daughter was just down in New York, what did they do? It doesn't work because it's a closed type of system. Really wanna answer a couple of questions. Is this health pass authentic? Is the traveler, the authentic holder of that health pass, meaning I'm not using all these Quebec-based vaccination credential, which would be quite easy for me to do, other than there's a little bit of naming, but that crypto's already been broken. And does the data on the health pass satisfy the travel rules? Travel rules get really complicated really quickly. If you take the Canadians who have a mix of Pfizer and Moderna, the states doesn't recognize that. So there's a whole bunch of these different rules that kind of get ties and knots, but we tried to solve the problem. And the way we did it was, we looked at the who are the issuers? There's various types of issuers. And this again is why you can't get a single PKI solution involved. It's just, it's not possible. When you have test administration being run in every country on the planet, may or may not be managed at the national level, could easily be regional. You have testing devices themselves that need to be brought in potentially. You have healthcare providers with their own privacy regimes, which are usually quite stringent. Each managed at potentially a national or subnational level. And don't kid yourself that WHO is not a standard. It is a body that kind of advises and pokes at health authorities. You have national and regional health systems. And you have a ton of other information, issuers of the identity data. So you have a ton of different types of issuers issuing information to us, the traveler, the holder. And then the actual travel groups, whether that be a government border, an airline wanting to make sure that from what I can tell right now, you're going to be accepted into the country. Cause if you're not, it's on the airline to get you back to your home country. Various different secure areas, airline boarding systems. And then you step into the ancillary, the next level of the hotels, the various different conference entertainment venues that may want to know, are you vaccinated? Did you get into the country by those rules? That's good enough for me. Welcome, Mr. O'Donnell. Please take your seat at the restaurant. So then we looked at, okay, where's the trust registry fit? Well, the issuers are listed in A trust registry. This is going to be key, A trust registry, or many depending on who they are. The verifiers may be listed in those as well, because depending on the regime or the governance framework, the ecosystem governance framework we're operating under, I may have to hive, have what's called verified verifiers in that you don't get to ask, you're not allowed to or we don't recommend you answer the question from a unknown verifier who's about to slurp down your private information. All of these things, the holders use the trust registry to know that's a good verifier. The verifiers use the trust registry to know that's a good issuer. All of this is done under the governance authority that manages that particular trust registry or its portion of that trust registry according to their own governance framework. This is a more technical diagram. I'm going to jump past it. The key part I want you to see is, here is a jurisdiction. When I say a jurisdiction, that could be a country. It could be a state. It could be a city. It could be a region. Who knows, but they've got their own rules, their credentials, their passes and the trust rich and governing authority. The reality is this is where the PKI falls down dead is in my world of just travel, there are dozens and dozens and if not hundreds of governance authorities who are needing to share this type of information. And they are the ones in charge. You can't say, hey, we're going to go use the WHO, which didn't actually, I don't think it actually landed PKI because they don't have the authority from the state of Virginia to go into the WHO because that's nation state only. There is no answer there unless you go to a, call it distributed, call it decentralized, and that's where PKI starts to fall down. Effectively, what we're talking about is distributed PKI. That's all. It's not anything magically wildly different. It's just, there's no root of all roots that we're talking to. So let's back up to what do we know? And this gets into the, what do we know we absolutely need to do and we're doing? We need to know who the authoritative issues are, who the authorized verifiers are and who are, where are the recognized trust registries because we have this distributed ad hoc systems being stood up all over the place. That's a freaking disaster when you try to do it on paper. It's hard enough to do digitally, but I need to answer these questions quickly. So what we've done so far, we took the good health pass collaborative work, the good health pass blueprint, have moved to continue the work over at trust over IP, the trust versus protocol. Two things that are there, very short document, the version one specification, which answers those questions, are you an authoritative issuer of this credential type under government's framework? Are you an authorized verifier? Same rules. And are you a recognized trust authority? Any one of those questions, you can answer all of them or just one. You can follow the specification working draft and the open API SPAC is in GitHub. We'll share a follow-up email pointing you folks at this, just don't wanna jump into a browser and jump into GitHub and just cause everyone to just slam into a coma. So I would do wanna raise up, where do we know we need to do work, but we don't have all the answers right now. We're fairly happy that we know the answers here. We're actually moving the spec out to more of a community draft to get some more input. We're not seeing a lot of churn. We think we've got it going pretty good. Drum and Rita from Evernim and I lead that particular effort. So we know on what needs work is in a particular ecosystem, what credential types are used. If it's a driver's license regime, perfect. Driver's licenses are the credential type. In a good health pass type of system, we have many different things. Proof of immunity, proof of vaccination, diving into electronic health records that provide that proof of vaccination or the immunization system that drives in. So a whole bunch of different data types as well as the travel linkages. How do I link your vaccination credential to some sort of identity proofing if that is necessary for a high assurance credential? One that's kind of got people wrapped around the gears a little bit, no one's thinking too hard on this. One is what wallets are approved for use in this ecosystem? Governments are very concerned about this. In the wallet report, and since then and even before then, I've jokingly asked the question, can I trust Bubba's wallet? Imagine Bubba's wallet shows up in the app store. It's got 555 star reviews. It's got the best user experience and it makes my digital life awesome. I don't have to worry about anything. Problem is it was written by North Korea. We've got a serious problem if we don't know how to accredit and certify the wallets that are used in a particular ecosystem if and when there are sensitive data. If it's completely non-sensitive data, maybe it doesn't matter at all. But also what uses of the credentials are normal and abnormal. So as I give you that example, again, if someone from a restaurant asks me for my full driver's license information, even the data I can't see on the driver's license itself in the physical world, what do I do? That might be an abnormal use, but what would be normal? Well, the pub asking for age and majority, totally normal. My wallet just may simply either, hey, we recommend you to hit the green, yep, share it, or might even just go as far as just share the damn thing. I don't want to be bothered by that. It's a routine thing, just make it happen. That gets to me in my choice, helps my wallet and the agents that are working for me to do that. Additionally, we're doing this right now about trust registries. What information can trust registries tell each other? What are the signals we can give that help us understand that 25 countries trust this one particular trust registry, your country 27, you want to commit and say, yeah, that's good enough for me. Hey, perfect, awesome. Or hey, we've had privacy, we've had faults reported in the trust registry of somebody who has done abnormal use of credentials as a verifier. The trust registry signals may want to say, hang on, that's the 33rd report we've had in the day, shut them down. All these things kind of need to be thought about. What else is out there? We talked a little bit about the pieces of the credentials being shared, running out of time, I'm gonna jump into some questions here. How do I use those, those presentation profiles? Additionally, what ledgers and did methods as a particular governance framework support? There's gonna be, I think right now there were 50 plus did methods, are they all gonna survive? Probably not. Are they all gonna be relevant under various different situations? Probably not. But I need to understand, hey, listen, if I'm doing professional engineering credentials under a particular framework, do I anchor to Ethereum? Do I anchor to sovereign as an indie method? Do I anchor to Bitcoin? I need to know business answers because I'm gonna get someone who's anchoring to something I'm gonna say, sorry, I don't do that one because we can't do everything. As well as we get into more of the interactions amongst the whole system. A part of the question I've got for folks here is people are asking, where do we need to do more? A lot of it comes down to helping out in the open source world. For example, Medcredge is a project I've advised on a pro bono basis, the proof market team behind that. It's got a really good trust strategy for someone who needs to stand up, labs, doctor's offices for issuing credentials, but it hasn't done the trust for protocol yet, needs probably a week or two of development for someone to help work on. Start thinking about the schema, the cred deaths and the presentation requests in your own ecosystem. But also what can you do? Part of this comes down to if you're doing something internal and private, perfect. Still get your teams participating because they need to start learning on this stuff. For critical projects, I would say start learning now. We deal with our clients really have two different things that they want. One is help their teams learn because they want to build the capacity and capabilities inside the house. So we come in and we help with them. They engage leaders that either on our team, ones that we recommend, as well as get open up your discussions for your projects. If it needs to be private, great. If it can be public, you'll probably get even more interest from the open community. But those critical projects, and we've worked on projects that range from wildly open to extremely closed, highly classified. So it depends on your business needs. One rule I want to just point out to people is what you're going to find as you dive into this open world is the 1% rule, where there are tons of people in trust over IP who are doing great work. Some of them are contributing pretty heavily. A lot of them are watching. Call them lurkers. They're watching and learning a bit because they're not necessarily doing they may not be learning quite as much. But then you look at the who are the hardcore creators who are driving things. And we can encourage you to join in as creators or contributors or if it serves your business purpose, start watching what's going on in particular area. As a follow-up and I'll dive into questions real quick. Actually, let's dive into questions right now, Ollie. Just looking at where we're okay. That was one. So how is an issuer verified on board in the first place? You talked about that. Governance. So can you elaborate on that? I didn't like to dive in on Sean's question. The first one? Yeah. So Sean and I know each other from the past. But part of this decentralizes the world, SSI decentralize Danny is I don't trust corporations and organizations. Hey, great, cool. You at some point need to decide are you going to maintain a list of all the issuers on the planet that you trust? That's totally fine. At some point you're going to reach a particular level of a trust reserve. You say, that one's good enough for me. It's going to start because it does, you can trust the math or the legal authority. Or once you stop trusting them, yank them, pull that trust registry from your good list, or go through their list and say, yeah, that's great, but 10% of them I don't trust anyways because it's my decision. There's a country tied to this particular country that breaks my rules, great, toss them out. But it's the trust registries that allow me to know that these are the groups that I can trust that one list. And whether that be issued by a country or by a bunch of, I'll use the story for the phrase, crypto anarchists are maintaining it, beautiful. There's a community-based trust registry that I can point at and believe in because of my rules and I don't trust the corpse or the individuals behind the other ones. Nothing wrong with that. If you had to be part of a PKI regime, you can't even answer that question. As an issue where you need to trade the DIDS, create a relationship first, will he be phoning home? Yeah, no, when we do the relationship between a holder and the issuer, the relationship there is off-chain. It is completely private. And this is another reason why we don't just ask member pass for the DIDS. That verifier doesn't want member pass knowing that it's checking against a particular authority because now you can get correlation in bulk. I want to go out of band on my own and just simply look at this ledger and say, yep, that's in the list. That works out the key matches and you don't have to call the trust registry every time. You just do it when things change. Okay, onboarded. That was answered. And Sean, yeah, this has become a new set of terms of service that users don't need. Certainly some of the governance frameworks may have terms of service over time. That's an area we're gonna need research in. We should note that, what's a normal term of service? What's a weird trust registry? What's a, if I enter a particular governance framework, what are the rules of engagement? Some of those ecosystems will be very rigid as they should be. If I take a look at, it's PKI based, but if I take a look at the passports, yes, I can now decode some of the information in the wild from my passport. But if I want the key information, that critical confidential information, I need to join a very rigid system run, I think by IKO. So depending on what the needs are, it could be completely loosey-goosey all the way up to, used only on closed classified networks. The terms of service would hopefully be a little normal. This is more just what data am I sharing? What else do we have here? Where are the holders authorized? Do I need a personal trust registry? You might, Sean. Really depends on when it comes down to holders. I would think registering holders would be probably draconian, but maybe there are use cases where that does make sense. I'd be more concerned about registering the wallets that holders are allowed to use because we don't want the system we've defined. It doesn't call home. It's privacy-respecting. It doesn't correlate. But if I have a wallet that is calling home, correlating and sending information off and off-gassing to somebody who is nefarious and wants to do surveillance-based economics, I have a problem there. I can't, one of my old developers had a T-shirt. I loved it. Spellcheck doesn't fix stupid. The approaches we're using can be used inappropriately and or circumvented. I want to make sure that when I use a wallet for serious use, carrying a vaccination credential around making it easier than pulling out paper, which I just did. I went to Quebec. I'm not from Quebec. I had to have my vaccination, which I was smart enough to highlight. You have received two doses and it has, that was my wife's name, but if I just want to get into a restaurant, I'm not as fussed. If I know that there are privacy concerns or relatively dealt with, the wallets are the key thing. Holders, you might need to be registered. Who knows? We've got good questions in the chat, Darryl. So one for Karen. Is there a way in Canada in the specific provinces to leverage the digital identity systems being launched or in use for startups in other sectors? And is this important? Where did you see that one? It's in the chat and not in the Q&A. So is there a way in Canada to in the specific provinces to leverage the digital identity system for startup in other sectors? Yeah. So right now there are some initiatives in Canada that I can't get into too much detail on. But there is an overall goal. BC government has done this for corporate registrations. The goal there is give those corporate registrations to two different parties. One is the general public who have a right to see it by law, corporate registrations. These are the list of companies that are listed or registered, but also to the companies themselves for various different purposes so that I can tie, for example, an insurance certificate to a corporation and see, oh, yeah, that contractor I'm bringing into my house is insured as opposed to them wagging a piece of paper in front of me. That's already underway in the government of British Columbia. And if a startup finds a reason to use it, yes, it's totally open. They're based on particular hyper ledger areas, implementation, working hard on creating interoperability test suites, both between trust over IP, hyper ledger and Diff, the essential identity foundation. When you get into the actual identity documents themselves, so identity credential, like a driver's license, like a health card, a government identity, it gets a little tougher because there's no examples in the wild that are real. But once there are, it's the same interaction as if I was asking for a corporate registration, I'm just saying, hey, I need to know, hey, Darrell, can you share your government issued driver's license number? Because I needed to rent my car or something. It makes it just easier for me to check in, hey, perfect. But yes, startups can certainly do that when those are in the wild. And if they pay attention to the news, I would think over the next few, three, six, nine, 12 months, they'll see more and more examples of exactly that. It's the same type of question Darrell. So can you talk a bit about the role of the government in all this? They are the issuer of the foundational identities. Do they not have a role to play in defining the governance framework, the standards for the wallet, et cetera, et cetera? Oh, 100%. And the government, the government, this is something where I'm proud that, you know, the Canadian government at multiple levels, federal, provincial, territorial, and even municipal, have been doing the hard thinking of what is the role? If you take a look at who would I like to receive a digital identity document from, I would pick the government every time if I can share it in a privacy-respecting way, as opposed to a third party who is taking a picture, I'm doing a selfie, it looks okay. Yeah, that's good enough. I'll take the assurance level that the government has with the processes that are in place every single time. Further, I want the government to play a role, not run it, but play a role in defining the rules of the road. What wallet is authorized? What wallets are authorized is a key one because I want to know that there's a protection for that they're following privacy expectations of Canada, that there are groups who are monitoring the usage in a privacy-respecting way. What's interesting is governments, when they first touch digital identity, learn quickly that there are things that could be done that could be badly used. I've talked to one government official was like, you know what, they love the idea of every time I use my government digital credential, they would know. But then they realize quickly, we don't ever want that information because the minute you start monitoring my activity that I use my driver's license to prove my age at a casino, to prove something at a particular bank, the government knows way too much about me and that violates Canada's privacy laws. The good thinking has been done. The actual, if I take a look at the public sector, pan Canadian trust framework, which drove some of the activity at the Canada's CIO strategy council. I'm vice chair of one of their tech groups. That's a standard now for the government, for Canada, not just for government, but for business. And it is considering all of those things that a lot of that deep thinking came out of the government whose role is on policy, not really on running stuff. And hopefully that gives a quick answer. Another on privacy, it's a good one too. So if I have a trust registry and lying on someone else's trust registry, can a third party discover who is in that list or find out who I trust? Yeah, liar, the only way they could do that is to ask you and you would have to answer because you're getting a signal back that's private to you. You're talking to trust registry and all you're asking is, hey, can this did issue a COVID-19 PCR test under this governance framework? Yes or no? If you want to broadcast that to the world, say, hey, listen, I trust lab X, hey, go for it. But the trust registry is not gonna be telling anybody that you've done that. Now, down the road, the deeper thinking that two, three, five, 10 year horizon, you may want to signal to the outside world, this is something I trust, much like I like a post or I may wanna put, I believe this post, I will sanction, not sanction, I will vouch for this particular post, you may wanna send a signal so that those of us who don't wanna use formal trust registries can derive data that say, hey, the math says, there's no way that 37,500 people trust this one and it's not trustworthy. They gain the system, there's no way they can get to that level of trust. I'm just gonna trust them. Another one, how will an interrupt be endowed across trust registries? Yeah, so that's one of the reasons why we have the trust registry protocol, which is focused again right now, laser focused on only answering three questions. Is this issue authorized to issue this credential type under this framework? Is this verifier authorized to use this credential presentation under this framework? And is this trust registry trusted? We're looking at the, how do you share information? And we did this back in the 90s with geospatial so that I can hit a trust registry that is informally managed, but it actually is aggregating for 2,500 different trusters that I don't ever wanna know about. I can relay information, I could synchronize. That's down the road though. So we're not there yet, but hopefully that gives a quick answer. I think we're running out of time here, Ollie. I need to jump onto a board call. Just real quick folks, I do need to close this up. We'll do our best to send out an email with answers to the questions that are in the, that have remained unanswered. These projects, as you probably guess, we've been in it for a long time, we can say with pretty high confidence that some of the projects are really daunting. They seem daunting. If you don't have the right perspective coming out of the gate, you may not even decide to start. We've helped dozens and dozens of organizations and we love helping projects get started in the right direction. If you have questions, reach out. Ollie, can you share in the chat? So if you haven't already, the links that we've got here, especially the link to the Contact Us, just hit our website. If you don't just hit our website, see the Contact Us, click it. Reach out to me on Twitter, reach out to Ollie and I on LinkedIn. That should be able to get you a little bit of information. We'd love to help a little bit. Make sure you're understanding one, what are the right questions to ask, as well as what's the direction you probably want to head in. With that, I think we need to run. Lawrence Ma, you've asked some questions, I would say are not in scope for this. Please reach out to me on Twitter or LinkedIn or directly through email to ask those and I'd be happy to point you in the right direction. That's about it, folks. Thank you very much. Again, we'll have a recording of this. We'll make that available, probably by hopefully late tonight. And I thank you and don't be afraid to reach out. Have an awesome one. Thank you, have a good day, guys. Bye.