 Welcome to this session. This is an Ask the Experts. So we're certainly hoping people are coming in with questions. Practical hyperledger areas, deployments and enterprise and government environments. John and I have been working in this in the hyperledger Indy and Aries environments for about four years. John, you want to introduce yourself? Sure. Hi, everyone. The executive director of BC government's digital trust service. And as Stephen said, we've been working in this space for four or so years and I've been working in identity space for maybe 15 years and really happy to be here. Right. My name is Steve Curran. As I say, working with John consultant. I sort of ride the line between technical and business leave John to deal with the government things and work on work on the technical side helping the technical team moving forward and so on. We've had a lot of good stuff come out of the project and we're pretty excited about it. The way this session is going to work whoops is this. We're going to do a brief introduction on the use of Aries at BT gov. And then we're just going to loop with hopefully hearing questions in and go into some discussion and if there's just awkward silence will move on to some new slides so we'll see how this goes. I'm just going to leave the chat up. I'd say suggest using the chat for questions and and I'll drive off that so I just have the one thing open. So that's what we're doing. Okay. Whoops. I'm on to screen so I got to make sure I'm at the right one. I'm coming into this we sort of have an assumption of what knowledge people are coming with. So we'll see how that goes. One, the trust trust over IP triangle the idea of verifiable credentials that an issuer will issue credentials to a holder an issuer might be the government a holder might be a citizen with identity data might be an organization with corporate papers. The holder when necessary can present those credentials to a verifier and they'll do that with verifiable credentials the same way they would do with paper credentials which is they would do it as an independent transaction entirely with the issuer entirely out of the picture just between the holder and prover the verifier would decide if they trust the issuer they would know who the issuer was they would decide if they trust it and all of this is underlying foundationally under underpinned with blockchain that's what I'm trying to get to. So cryptography is involved in being able to issue the credential in a way that the holder can prove who they are get better can prove the information the credential who issued it that it's not been tampered with. And the verifier uses data public keys primarily cryptographic information they get from from the blockchain to be able to verify that data. All of that is embedded in Aries Aries are the agents that allow the operation of the software for issuers for holders and for verifiers. On the other side of it is while Aries represents a technology piece. The trust over IP stack is is presenting it provides two sides of the piece technology on one side and and all of the pieces that I kind of deal with and governance on the other side which is how do you know you can trust the utility where the keys reside. How do you how are the protocols defined that allow the Aries agents to talk back and forth what are the credential formats that are used what are the governance around the meaning of the credentials at the fourth layer so a four layer stack and this is all embedded in the trust over IP foundation which of which john is the executive director. So, with that, we'll get started on a bit of sort of what we've done at BC gov first of all and then a bit of the tips and tricks we've learned along the way so use cases that we've done at BC I won't go through all of these but but the idea here is I mentioned even a couple already or book BC is the one that that is the largest one that we've worked with which is the idea that we would have a community wallet as a verifiable credentials about organizations about using public data that we could put out and make available to citizens and organizations to use and and underpin it again with verifiable credentials so the data could be verified that not only does or book BC hold it, but it was issued by the mentor of credentials about organizations which is BC registries. We've had various permits and licenses related to that one of the projects was cannabis licensing so when cannabis became legal in Canada there was all sorts of regulation put around it and so lots of permits and licenses involved. BC gov has done a pile of work in areas itself and enabling deployment enterprise deployment and things like that, and then use that for a bunch of use cases such as lawyers, essential service workers credentials for organizations. And then the thing one of the things we're working on now and that's kind of interesting is a business partner agent. It's called which is SSI agents for organizations where we would actually have organizations having their own wallets and being able to receive credentials from places like the government and be able to share those credentials with other organizations and as well request credentials from other organizations so those are the types of projects we're working. So at this point, we're going to shift into getting into tactics that we have used in in getting started with self sovereign identity with trust over IP, and things we found successful. The first one be controlling. So if you're starting a project if you're getting started in this area and in an enterprise. You want to control as much as you can in order to be able to get started. We're really building a two sided market. And actually, because it's a triangle at three sided market we have issuers holders and verifiers and we've got to convince show the value for all three of those parts of the market. So being able to control both sides of say the issuer and the verifier really helps with a workbook. We actually control all three sides of it. We made our book itself is the holder registry started out as the first issuer and then we had additional issuers come along and verifiers are just people who are kind of interested in seeing that the verification process. They want to be able to look at various companies and make sure that they have accurate information about them. We had another project where we got involved with the law society here in British Columbia they are the people that say who is a lawyer and the idea there was Ministry of Justice in British Columbia needed to know who a lawyer was to allow them to access a system. We started with a small case but the law society and Ministry of Justice are very well known to one another. And the idea was that the law society would be the issuer Ministry of Justice would be the first verifier and lawyers would be the holder of the credentials and having Ministry of Justice as a first verifier opens the door for other verifiers to follow. So we controlled the issuer verifier piece of it the law society has a fairly good relationship with lawyers since they provide provide services for them and and and and maintain the membership of who is a lawyer. And so a lot of control over it so that's the first piece of advice be controlling John you want to take the next one. Sure. The other tactic that we like to use is what I call clicky things. So that essentially means demos and working demos working proofs of concepts because some of these concepts are new and difficult for people to sort of get their minds around. So you want to create working examples that they can relate to. And we did this in a number of different ways of course Stephen has mentioned org book already we before that went live we had lots of working examples again using the sort of agile technique minimum viable product making sure we have all that continuously. And then we had various proofs of concepts that we did at for things like the Internet identity workshop, we created a thing called conference book, people could practice using credentials, and a number of other examples that we used a mail verification was another one here. Stephen mentions, or people could use the standard sort of verify this is your email that you're in control of your email address, then use that date to get a email credential. So clicky things are important gives people confidence allows them to try it out for themselves. All right, we had kind of expected this would actually be a more verbal back and forth and people would be asking questions as we go so I know it's nobody's asked any questions yet in the chat or in the Q&A so this is supposed to be an ask me anything session. So we are hoping that questions will come out as we go through this so we're about to hit our first break where we're answering questions before moving on so hopefully some questions come out about, you know how you're trying to use this technology and, and what you're able to do as far as I know we can't turn on the audio good question. But I don't know I'm new to this platform. Oops. Okay. The next one is kind of obvious for those who have done things in enterprise and those who have started something new and started to build things out. Mitigate your risk in what what the use case is that you're picking to begin with in government politics very much plays a role in it. You don't want to do things that are high controversy in an environment enterprise similar you don't want to mess with. You know, say privacy concerns or, you know, distributing out data on on this new mechanism that you haven't used before for security. Many participants, you know, if you've got many participants and stakeholders involved that's all the more people you have to report to and and keep in the loop as to what's happening with the deployment. So it makes it harder. You spend less time focused on trying to get pieces put together get change management done get things rolled out and more time dealing with all of the participants that want to see their needs met so you try to keep the cases contained. We've mentioned this before when we started org book organizational data is public data in British Columbia so anything about a or most of the data about an organization is public and more so each day it turns out. So we were able to use organizational data to do lots of things because it's already public, even as if we screwed it up and and how to breach or whatever the data is public anyway. Once you understand that really begin to push the envelope and that's we can get into a few things we're doing more now as we get into citizens and and using health data, for example, of the project projects you've undertaken in BC has adoption been smooth. John you want to take that one that's a question we've had. Okay, I didn't even see the question I'm having has adoption been smooth. Well right now like so for example, or because our longest running project we haven't, and an adoption is slow, I would say to be honest. It's, it's a we've had a number of permits and licenses like three or three or three or four so far other than registries. And it takes time for people to understand what you're doing and I would say another, another tip is that I guess we although we partnered with the business like the BC registry since the beginning. And we really aim to show the business value of what we're doing. I think we need to do a better job at explaining why this is different and how it's important and what pain points it it solves for people so that they have a more compelling reason to adopt. So for example, one of the things we're learning is, there's many, many services and government that serve businesses, and they've all, they've all got a challenge that sometimes they don't even know which is the business name the legal name of the business that they're serving that they need to know is often wrong. It's not the right set of characters it has to be to be the legal name it has to be exactly the characters in the registry, but so for so far they haven't had access to that. And so they've done typey typey, and often that's wrong and so they don't actually have the legal name, which means they can't prosecute that that business if they violate the regulations and there's actual legal precedent for that. And so, when people become aware of this and they realize they can use your book API to do auto complete, they've done in very short time like days integrations with their applications and stepped up their data integrity quite a bit. So that's something we need to talk about more. And another feature we just added is an API where you can take your not so good data. You can use a fuzzy search API and get back good data. So, I would say that once people see that, like, once a team sees how easy it is they love it. But we haven't done a good enough job yet at showing how easy it is, what the value is to them, and then, and then they can adopt it. John, I'm going to answer the next question. Leave you to think about this so you can come back with this one. I just didn't want to see more questions. Yeah, yeah, you mentioned citizen pain points. So I want to come back after I answer the next question to that for you. Does our book have any requirements about removing data e.g. right to be forgotten to stop it? Two things. One is, or book is not a blockchain itself or book uses blockchain for the keys, but that all of the data are credentials which are put into a wallet and in general this technology is like that that the right to be forgotten. Generally is not an issue, even though it's blockchain because what goes on the blockchain is just cryptographic data published by the issuer that are used by the other parties. The data itself, the credentials themselves are only shared by the issuer to the holder and from the holder to the verifier. So there really is not an issue with needing to be forgotten or anything like that. It's just like the government giving you your driver's license and you can do what you want with it if you want it to be forgotten, you rip it up. In our book, we are, we actually update all of the credentials, we do that by revoking the credentials and then issuing a new one. John, you want to go to that. What are the citizen pain points and the reason that that that's being done. You mentioned that in passing and I thought it was one to highlight. Okay, I also have a couple of other questions that have shown up on my. Okay. So maybe I'll answer those. I see a question here. Yeah, when you created credential definitions. Is there such a thing as industry standards for local governments for those use cases. So that the credentials are interoperable across jurisdictions. That's a great question. Excellent. Yeah, that's a great question. I think that really industry standards per se, there's, there's sources like schema dot org and so forth, but what we did in Canada is we have a, you know, we have a federal provincial territorial tables or committees and, and we collaborate through those mechanisms. For example, when we did org book and we collaborated with the government of Canada and the government of Ontario. Basically, we got together and said, here's what we think it's schema should be. And we, we work that out together. And we tried it out and we discovered it didn't work quite right for some of the use cases Ontario wanted. So we changed it. And then we made a couple of revisions. And when we finished, Ontario had issued like 10 million business credentials. We'd issued 3 million. Canada had a quarter million or so. And it worked for all of those legal entity types. So that was a really great example of how we could work together on the schema. It's a, it's a definitely a challenge going forward. When you look at global interoperability. And we can see that with the vaccination credential use cases and so forth. So hopefully that's helpful for that question. The other question I have here Stephen is, when someone is using his mobilization, how to guarantee ownership. Yeah, and someone just use someone else's phone to prove, for example, vaccination status. That's, that's a really interesting one and one that will evolve over time. In, in the case, generally, the answer is, it's difficult as you start up, as things become more as as wallets become more valuable, it becomes less of an issue, someone is not going to quickly share if they have a number of credentials in their wallet. That's one, two is wallets can become a way to guarantee to tightly tie, say a foundational credential like an identity credential to the person who's holding it so that is another evolution that could happen. What's happening with vaccination status is generally that enough information is put into the credential to allow correlation with some other document with it that the person is also presenting. So you're basically, as, as a verifier, you're going to mitigate your risk by requiring more information that you can correlate with other information you have about the passenger say on a, on a flight, and that would prevent that. Ultimately, we'd like to get it that we're minimizing the amount of data being shared, and, and that will just come over time each, you know, with she, with each use case coming out that verifiers, the issuers and the verifiers have to think of how do they mitigate their risk for using this, this type of technology. So that's, that's a rough answer. It's not a perfect answer as yet, but it's definitely going in the right direction. Yeah, I mean, the general thing we call that the lending problem. You know, it's, it is a risk, but as Steven said, I think the, the other two, just to summarize like the two mitigations for that are one is, are you really going to lend somebody your phone when it and give the give them access via say the passcode to your visa card on there and all the various other things. You know, plus, when you go to the in person event to say like a plane, like getting on a plane, I mean, if you've lent your vaccination status and they double check it, it's, that's a problem. And then the other is trying to get some sort of biometric tie in to the wallet, you know, itself and there's, there's people experimenting with that idea. Any other questions that we missed or I only see two. There's a good one here, John, and I want you to answer that one. What is the biggest hurdle to overcome to get other governments to use a system like British Columbia for issue and digital credentials where are who to talk to if you want to make those changes in your local city county state. Right. That's another great question. I think I don't have any special magic answer to that. I think we're trying really hard to make it easy to adopt from a technology point of view. So it's, it's not ripping up and replacing things. It's adding to things. So I often describe it as like adding a print driver to your service. So if your service already issues something which pretty much all government services do because their goal is to provide you with something that empowers you to do like to open your business with certain licenses, or to get a renovation to your home or whatever it is, or, or the really foundational stuff like provide you with your personal identity attributes so you can go about proving who you are. It's it's a very natural fit for government. We're really trying to find a group that is open to change and innovation. And again, going back to our tips, trying to find a use case that is got a contained audience that has a clear value. I really like the business side of things because again, as Steven says that, you know, our strategy was to use data that isn't subject to privacy laws, you mean still treat it with care. And it is ultimately the same kind of data names and attributes. It allows you to experiment and do something that is lower risk. So I think that's another tip. Another question here, Steven, I don't know if you have another one. Yeah, I see one there. And the questions are coming nicely between technical and business so we're balancing them. So I get this one. With regards to wallets and agents, where does the burden of managing dids to identity owner mapping fly in in the Aries use case that we're talking about. The wallets sort of hide all those details. We were once at a conference where somebody said to us if if the end user ever sees a did we failed because the UX just is not appropriate. We generally keep it that way. Enterprise, you know, with with Aries basically it's only the issuers that have public dids that they need to share all of the rest are dids that are peer to peer and that are sort of under the covers that are allowing connections. And what it looks like in your wallet is much more like, you know, a telegram app or a signal app where you have connections of people or entities that you that you communicate with that you message with. And the verifiable credentials themselves are all are all business objects, if you will things that people recognize. We do have underscores and things in the name still and we're trying to figure out ways to get rid of those but we're generally not showing dids to anyone. The one thing though that does come into play is when it comes to backing up a wallet and things like that there is sort of this need for the security and the cryptographic safety of making sure that you've got a good passphrase involved and that you're that the backup of the wallet is is can be safely can is safe and therefore that falls right now falls on the burden of the wallet holder. What do we got next that actually was the question was, how difficult is it to switch wallets for regular users is backup restore across wallets agent mature enough to support this scenario. So there are wallets that have that. But it's so so there is a number of wallets the transit e-satis and lissy wallets can all be sort of saved off exported and then imported into the other and they will operate. That's not something that we've gone that far with an interoperability it's not included for instance in the Aries interoperability interoperability process but it's one we want to get to. I did have another tip for the helping with the adoption of government. If you are, you know, a technology provider something one thing you might be able to do is use the tools that are available. So come to the hyper ledger Aries forums and ask us about it. Yeah, but you could take open data often governments have published open data. For example, business data, and you might be able to do a nice demo that, you know, for example, do an org book for that jurisdiction or do do some sort of demo that allows people to see what's going on and give confidence that it's working. It's fairly straightforward to do with with not a lot of investments so that might be another adoption trick. We have one more minute left Stephen. I know time. Let's see this last question. There's a series of questions. Are you there. Yeah, I'm reading the question. What do you think about an application that supports a business process and use verifier for process events to make them auditable. This is one where we're definitely building up to the idea of supply chain. There are things like you want to prove responsible sourcing of materials so an organization a has a exist as an entity and it has a certificate to say it has an it has it exists. It has a permit to do something like mining in British Columbia for example. It has an ISO audit from some organization that says it follows through on a mining standard as it produces material that produces a verifiable credential to go on along with those materials that ties back to the source of those materials. And that process can allow querying and auditing where necessary to find out the full course that the products traveled along the supply chain but also what standards were used what what compliance reports are available and so on about the about the material. So that's one of the areas that we're busy gov is working in that's fascinating and. And so if you have other questions about that glad to take those that offline or another time. Yeah, if you're interested in that you can check out the business partner agent in the hyperledger labs. There's weekly calls with with the busy government and posh as one of the lead developers. Yeah, I guess we're out of time so thanks for the questions that was great. We really appreciate it and hopefully you got some of those and we're glad to help more we will post the slides it's got links and things in it but I guess on to the next session. Thanks for coming.