 Great, thanks, Sean. Welcome everyone to the Hyperledger Identity Special Interest Group for November 16th. Got it. Thanks. Thank you for joining us today. I'm Shar Haaland and I'm a co-moderator of this group with Vipin Barthon and Tim Spring. Today we will spend a few minutes at the top of the call going over working group status updates and then we'll hear a presentation from Trevor Butterworth and Simon Nazarenko of Indicio on Simplifying Decentralized Identity Governance. So looking forward to that. Since this is a Linux Foundation call, we are following the Linux Foundation antitrust policy. Since this is a Hyperledger call, we are following the Hyperledger code of conduct, both of which are linked here. This call is being recorded and live streamed and we'll post the link to the recording right here later today when that is available. Let's see. I'll send out the Wiki link into the chat if you'd like to follow along and if you'd like to put your name under the attendees list, that would be wonderful. Would anyone like to take a moment to introduce yourselves? You can just say a few words about what you're interested in or doing in this space. Trevor and Simon, feel free to introduce yourself now or when you start the presentation, either is great. I'll do it when I start the presentation. Sounds great. Same here. Great. Would anyone else on the call like to introduce themselves? Yes, I can. My name is Philippe Bourque. I'm working for the Quebec government and I'm working on the digital governance of the digital identity and credential program. So I'm here to learn about simplifying the digital governance in this unthreatized solution. Great. Yeah, absolutely. We're glad you're here, Phillip. Thanks for joining. Thank you. I'm Kyle Robinson, working with the government of British Columbia, spending a lot of time working on governance. And so interest in this topic as well. Great. Thanks for joining Kyle. Glad to have you here. All right. Yeah, if anyone would like to put their name under the attendees list, that would be great. In terms of announcements, this group will take a short hiatus in December. And so we won't have a meeting on the 14th or the 28th, but we'll get back to things on January 11th. Are there any other announcements that anyone would like to make before we jump into. I will show our thank you. My name is Sean Bohan. I am a part of the Hyperledger staff. We have not formally announced this yet. We're going to start doing the promotion for in December, but in late January early February, we're going to have a workshop brought to you by DSR who are fantastic members of the community. It's going to be about identity and interop. So how Aries and Cardano and Bezu along with other Hyperledger and non Hyperledger projects can work together. I believe in on credits involved as well. There's going to be more details coming out probably after in early December, after the Thanksgiving holiday, but we want to let folks know and we're going to include that in the wiki for the identity special interest group. Once we make the formal announcement. So thanks y'all. Great. Yeah, absolutely. We'll look at more information on that. Thanks for that update. Any other announcements that anyone would like to make. All right, moving on to working group status updates. So we have plenty of time for the presentation. I'll just give quick highlights overview, but once I'm finished with that, feel free to speak up in more depth about any topics or working groups that you're involved in would like to talk about. Let's see, on the Indie contributors call. We have been hearing about progress on upgrades and as well we're not a DSR gave a presentation on the progress related to the Indie Bezu proof of concept. It's really interesting to hear about. Let's see, in the areas working group, they've been working on the occupy plug-in repo that please act protocol and long term support policy unqualified did. It looks like areas by fold is still on a bit of a hiatus. I don't think they've they've had more recent meetings than us. We've been talking about the latest release. The Anon creds RS branch, you know, the load generator project as well, the BCGF code with us. Anon creds in W3C format and then we had a demo as well on the traction sandbox. So that was really cool to see. In the maintainers meeting, this is a meeting that's separate from the user group that is particularly focused on on getting PRs merged in. So that as well has been focused on that newest 010 release. On hyper ledger, let's see areas framework JavaScript. They've been talking about the absa wallets how actually reduced thousands of lines of code and then as well they move to the open wallet foundation of that code base. Let's see on the hyper ledger. Anon creds project. They've been working on PRs to the Anon cred specification. Anon creds the 1.0 in the W3C verifiable credential data model standard format and as well discussing the Anon creds version 2.0 work. Let's see so that's a super quick overview of the hyper ledger working groups. Any update any other more in depth updates that anyone would like to give. All right. In the transfer IP foundation. Yesterday they had an all members meeting. Looks like what they mainly talked about were the task force updates, which are all listed below. The communications committee, there are a lot of blogs being worked on a trust registries, a CDC. Lots going on there in terms of blogs coming out. Let's see in the governance stack working group. Don't believe they've met more recently than us, but please correct me if I'm wrong about that. Technology stack working group. They had a lot of a lot of new updates for the all members meeting. Many, many task forces there. And the technology architecture task force. They've been working on the technology architecture specification. The one sounds like that is coming along well. The trust registry task force has these deliverables planned. The trust spanning protocol task force is working on their specification. Let's see won't go into too much detail on these unless anybody else wants to. Jump in with more info that would be that would be very welcome. The, if you did the task force AI and the metaverse credential exchange protocols task force did web s task force. But you'll feel free to jump in if you'd like to talk about your work on any of those. Let's see ecosystem foundry working group. Don't think they've met as recently, but the concepts and terminology working group met last week. They have been working on the terminology engine V2 they've got a glossary with over 350 terms defined. Yeah, lots happening there. Anybody who's involved in any of these TIP working groups or task forces. Would you like to give any more updates or in depth, in depth overview. The only thing that maybe point out is in both the technical technology stack and on the governance architecture task force. We're working on a new stack diagram, essentially a new way of talking about the stack, which is more inclusive of the trust spanning protocol. So that's just in the works right now. And there's a bunch of effort going on with that. I see. Great. Thank you for that update. Which task force is that happening in is that in the I'm, I'm attending with the governance architecture task force. Okay. Yeah, it's under the governance stack. Okay, the task force at the bottom governance architecture. That one. Great. Thank you so much for that update. All right. Anything else. I'd like to talk about related to trust of IP. All right. In the decentralized identity foundation, the outcome spec working group they made on the first Monday of the month. So their last meeting was on the sixth couple of weeks ago, they talked about protected cloud storage and did come at the itf. Let's see. I had some trouble finding notes on the to come users group meeting. If I can call on Sam. I see you turn the call if you're willing to give updates about either both of these groups and the recent happenings. I can so the users group, we know that we're bad at notes by the way. There's there's some there's some plans underway to be less bad at notes but it's from polygon ID who has developed a set of protocols on top of did come in order to enact their interactions. So it's still did come underneath, but they have some heads of specific needs for their credential types and the protocols designed to use those and so they developed it com protocol on top of them so we had a cool presentation from them. And then that was that was the majority of that particular meeting. The spec working group you already the biggest item there was discussing the, the potential to, you know, seek work on the on did come in the future at the itf so that will be a little bit of a slow burn project. The process of, you know, creating a draft and some other things on the way there and seeking for working group but those are that's probably the most important thing we discussed. Yeah, absolutely. Very exciting. Thank you for those updates. All right, let's see. I've not been aware of recent meetings for the different interoperability group. They just look like the IOT special interest group has been meeting and they've been talking mainly about potential potential items that their group could work on. Let's see in the W3C standard. I wasn't able to find too much on the did working group but community credentials group has been meeting they've had their regular CCG traceability calls and VC for education task force calls. Any any updates related to these last few groups or any that we talked about today that anybody would like to go into more depth with. With that, I will pass it over to Trevor and Simon for our presentation today. Thank you. So, just let me share my screen and then get into the introductions. So, my name is Trevor Butterworth. I'm co founder of in DC and VP for communications and governance. And I'm going to let Simon introduce himself because I'm going to come back to set a little bit of context for what you're about to see based on in part who I am so Simon if you'd like to introduce yourself. Hello, everybody. My name is Vyacheslav Nazaryanka. I go by Simon. I'm a software engineer at DCO and part of my work is implementation of decentralized ecosystem governance. That's what I do. Thank you. I came to in DCO I'd worked as a consultant to the sovereign foundation. But I came not as a technologist or an engineer or a computer scientist, but as somebody who has been heavily involved in communications and specifically how to communicate complex information started out as a journalist. This journey started out in journalism. It involved working at a think tank, which focused on explaining or analyzing how statistics were used in the news. It then led to the creation of sense about science USA, which was focused on science communication. We had a partnership with the American statistical association. I'm probably the only person with an art history degree who's published in the annals of internal medicine. So I happened to work on a project with the annals and with Acura, which is one of the world's leading data visualization companies to try and design a better way for clinicians to understand what to do if they have missing data in a clinical trial. And that problem was the result of them refusing to read all the excellent documentation that has been put out by the National Research Council and other bodies. Could we do that with visualization? Could we get them to focus? I also worked on the flagship project for the Sustainable Development Goal to End Hunger, which involved natural language processing to analyze the entire corpus of agricultural research for policy related material. Bill Gates described it as one of the biggest breakthroughs in agricultural research in decades. My job was not to code or to do the science, but to try and explain it to the stakeholders so my boss could get money. So when I approach decentralized identity governance, I'm looking at it as both a communications problem and then also from the perspective of Indecio an implementation problem. Because our customers, you know, they want to implement solutions and governance instead of helping them do that can often be at least perceived as a problem, a digestive problem. So this says this is this says it all from my perspective. We are forcing people to eat raw kale and raw kale is pretty difficult to process. We need and that manifests in a diagram that you're all probably very familiar with the TOIP technology stack and the TOIP governance stack. How do you consume this in order to get an implementation up and running and quickly? The problem with that the that stack is that it makes governance look like it's a bigger problem than the actual solution you're trying to implement. One of the areas of confusion is that it seems to suggest there are four different governance authorities governing each element of the stack. And in part, I would say this is something that is a legacy problem from the stack being created before there were really implementations. But in part we are telling people this technology is really simple and simplifies things and it does. But then they when they go to think, well, we've got a structure it that confronted with something that seems almost more trouble than it's worth. Now, just to stand back a little bit. One of the underlying problems here is which is brilliantly put in a book that I recommend you all read it's very entertaining. One of the heroes in it is Raymond Louis, who is one of the one might say one of the key designers of the 20th century. He did the logo for Shell and the US post office. And he had, you know, came up with the Maya acronym most advanced yet acceptable. How do you plug somebody into something so that the reasonably familiar enough in not to experience cognitive overload. And the field of metacognition posits that when, you know, something very obvious we prefer fluent thinking. That is, we don't like trying to process complexity complexity. Now, one of the related problems with that is that consumer research, how I'm going to say caveat on all consumer research in terms of study quality, but consumer research shows something that at least feels intuitively correct. That is, when we struggle to process information and hold multiple things in our brain at once we quickly exhaust our working memory. And the actual experience of thinking is unpleasant. And that unpleasantness then is transferred over to the product. So when you people try and look at the this diagram which is kind of central to, you know, our understanding of decentralized identity governance. You might ask, well, how many concepts or operations or processes or things do they need to hold in their brain at once in order to understand what's going on. And a conservative reading of this diagram is 52 elements. And that's a disaster. That is, it's just not you cannot, unless you already know what that diagram is telling you. It is incredible. It's it's it's incredibly hard to figure out what it means and where you go from it. And this is why we need to make decentralized identity governance easy to digest. Again, the focus is implementation. So, and by no means, you know simplification is a work in progress, just as all writing is rewriting. The more you do it, the better you get at it and the more you reduce the elements. So this is not something I'm not proposing. We're not proposing something here that's written in stone, but as a way, but as a heuristic that helps people to actually implement solutions. And we'll stick with the we'll stick with the botanical theme. And obviously being Irish, I couldn't resist using a shamrock. But we could think of governance better or more easily if we see the three main domains. Ecosystem governance, which is all about the issues holders and verifiers. Machine readable governance, which is the implementation of the rules for those participants in an ecosystem and the network governance, which interacts with the other the ecosystem governance largely in terms of of rules or sorry legal agreements. And so here you can see reducing it even further to two domains of human activity. So the key governance issues for ecosystem governance identity assurance credential issuers credential types, etc, etc. The key governance issues for network governance are the governance structure of the network, the business policies, the technical policies, etc, etc. And then the legal agreements that when you need to write to a ledger essentially boiled down to don't write personal information on the ledger. And additionally, if you're going to be marketing products or services to the European Union or European Union citizens, you need to have data processing agreements to comply with GDPR. So, in a sense, we're dealing with two, you know, two elements of the one thing, the relationship between ecosystem governance and machine readable governance. And so machine readable governance as it is currently developed as in its current state looks at the schemas being used, the agents that can be trusted, the roles these agents play, and the actions these agents can take. And of course, Simon will explain more of this visually. And the so so essentially it's a subset of ecosystem governance. Now, so you've if you we reduced and simplify these areas, we need to then think about what are the decisions that need to be made. And the reality of implementation is that most people are not the certainly not coming to us and saying we want to create a network. I mean, the that's a minority of people given the task that's in it. That may well change. I mean, one of the things we have developed is a simplified way to spin up a node. So I think as this technology progresses, that will become a bigger thing. But right now, people either want to create ecosystems, or they just want to issue credentials or verify credentials. So, figuring out, you need to figure out what kind of governance you need. And that starts with your goal. If you want to create a full ecosystem, then you are the governance authority. And if you just want to issue credentials, you need to join an ecosystem. Once you've decided that you either have two choices, I have to create a network or I have to join a network. And that involves a certain amount of evaluating network policies. So what are the essential questions then that you need to ask of ecosystem governance? Let's start from the top. I'm not going to read through all of these. You can look at them at your leisure. I'm conscious of the time and getting Simon to demonstrate. But essentially, we need to determine the identity assurance policies for credential issuance. And they vary somewhat between whether your ecosystem is for people, organizations, or things. And then you need to determine what credential type you should use for people. So for instance, if you need selective disclosure, your answer is, and yes, you do. Then you can use an on creds, et cetera, et cetera. If you use an on creds, that requires you using did indeed. For instance, are you integrating with partners that don't have full decentralized identity capability, that is, they are issuing paper documents. Then you might consider using a proxy issuer that verifies credentials and reissues them as verifiable credentials. And then finally, on times of the questions we put together, is it necessary or convenient for the credential to be presented by someone who is not the subject of the credential? And then if that's the case, then you can use SDJARTS or JSONLD. So that's the kind of decision making we want to get people very quickly to hone in on what they need to get up and running and be successful. And so these questions continue. Will there be multiple credential issuers in your ecosystem? So if it's yes, then you need to create governance for issuer onboarding, a legal agreement and audit. And then once issuers are onboarded, you can add it to a machine readable governance, governance file. And this, so this, why I've, at various points, we've color coded the step towards machine readable governance. And you can, I guess, guess that what we ultimately want to be able to do is to automate this so that when you, you know, you're making these decisions, you're able to ideally launch yourself into the governance editor and literally start creating with whatever pull down menus and do dads that are necessary, create that file. You know, the virtue of this technology and implementation is speed. We should maximize the speed at which we can create the governance to make it work. Pretty much that's the pretty much the goal here or at least the goal in this thinking. Will there be multiple credential types in your ecosystem? And again, yes or no. And then depending on what you have to do there, you work your way down to create a schema for credential. And then again, we hope to put in the next, you know, that you will be able to simply leap into your governance editor and write, create a credential, a schema for a credential. Which did methods should you use? Well, we recommend using a did method that allows for communication endpoints, even if you don't plan on using them now. Mainly because this will provide flexibility for future growth. Our perspective is that, you know, the technology is evolving, build for the future, not build according to just what's possible today. I'm going to speed on through some of these. What did method, so this is a continuation, how much durability do you need in your ecosystem? Load your ability, then use did web or did web variants. If you want high durability, use did indie design. Again, we have a design recommendation, secure bi-directional communication design with future capacity in mind. What protocols do you need? Again, the kind of fundamental questions, what device capabilities will participants have? Do you just need credential issue and some verification? So for instance, if you need secure protocols for notification and confirmation, OIDC is not sufficient right now. How will you manage cryptographic keys? This is an area that's evolving. So ultimately, you know, as we revise this sort of approach, we will contain, you know, we will provide more and more options and detail. So that really you're not left guessing as to what you need to do. Again, you know, what you what are your wallet options and requirements, etc, etc. So I'm going to skip over this. This is if you have to evaluate a network and this stuff is, you know, this stuff is familiar from if you look at TOIP. But these are the essential questions you need to ask. And if you just want to issue a verified credentials, you have to understand that the importance of governance to actually making credentials work. So there's just a little bit of information there. And then we were on to machine readable governance. So a quick overview, you may already be familiar with this. Essentially, this is the what this does and this came out of our work with the government of Aruba who wanted absolute control over the information that was presented in a credential that they they needed to be accountable. At the time, the good health pass was proposing, you know, a sort of supranational nonprofit to kind of rule on which credential, you know, how these credentials should be should what they should contain and how they should be structured, etc, etc. What we found is that government wants to govern and that principle applies. If you're a government or if you're, you know, a membership organization or a company or whoever is the responsible for the the the ecosystem, they should be able to implement governance as quickly as possible. So the other advantage of this is that if you cash a machine readable governance file, you have a pathway to offline verification. And I think that's a particularly important point. So just to revisit the key elements that we're going to be talking about here. And the benefits. So again, the relevant ecosystem authority is directly accountable for governance. There is no time lag. Rules can be changed really quickly, and you don't have to ping an independent trust registry in order to have an issue verified. You can choreograph quite complex rules and make them frictionless. You can combine hierarchical rules so particularly relevant for say managing drone flights across different kinds of airspace. There's offline functionality, as I mentioned, and then significantly, if you are making by making a trustless portable, you rule out the possibility that an independent or third party trust registry could enact a toll. And we think tolls on verification could be highly could be seriously dissuade use of the technology. And we also tend to think that where there's an opportunity to seek rent, rent will be sought. So I'm going to switch over to I'm going to let Simon do his thing. I'm going to stop sharing. Simon, are you ready? Have I prepped you enough? Do you want me to talk a bit more? No, you did great. Thank you so much, Trevor. So I just want to start with sharing this little information in a chat. The governance work that me and Mike Ebert and Sam are doing is done under the umbrella of decentralized identity foundation. There's a workgroup that is happening each Monday from 11 to 11.45 a.m. mountain time. There's a Zoom link I shared just in case you want to join, see what's going on, what we're talking about, and what it possibly participate. And I'm going to share my screen right now so we can get to the demo. All right. So for our presentation, we're going to use an proven agent, which is in DCS product. Proven agent can act as an issuer, verifier, or holder. So we're going to use that today for presentation. I'm just going to log into the system. We'll need a little bit of logs. This is a development environment, so you will see some logs over there. So don't mind. And we'll start with the issuance workflow where I... No, never mind. Sorry. Let's talk about governance. Sorry. I'm running behind myself. So this is the file that I pre-made for this presentation. I didn't want to spend too much time on actually going through the governance editor, but I just wanted to show you the final example of the produced draft of the governance file. You can see that it consists of the metadata about the file itself, and it has the schemas section, which describes the schemas that are part of this ecosystem. We have a participant section that describes trusted entities, and you can see that it describes entities by schemas and by description. And then we have role section, which basically describes which action can be taken for each schema, and then we assign the role to a specific participant to allow that action to happen. So right now we have the did that represents my agent, and we assign the role one, which is issu, driver's license schema. And let me go into my governance editor, and I'm going to upload the file, which is just sitting in my file system. And we are going to publish our governance file to an S3 bucket, and I will talk about the publishing in a couple of minutes, but we can just confirm that it was published, and I will go over this piece later on. So right now we have a governance file that was published. We can go to the governance files component of our proven agent, which acts as an interpreter piece. So I can grab the URL to the S3 bucket, and I can import that governance file to our ecosystem, and I can activate that. So right now, our agent will check with the file, with the diga file to see whether the participants are allowed to perform a specific action. So in our case, we will attempt to issue a credential, and we have a role for that. So right now, sorry, I'm going to start this workflow by generating an invitation URL, and I'm going to grab that URL here, and we will be using our APIs to accept the connection. So basically, for the sake of the demo purposes, I'm connecting to myself. So I'm connecting this agent to this agent. So we are going to select one of those options for the demo, and I will issue a credential. So as you can see, it's on the way. It's a happy message. We can go and go to contacts and see connection. The contact, we can see that the driver's license was issued, and we can check the health credentials, and we can see that it was acknowledged as well. So that's all amazing. Now, since we connected to ourselves, we can go ahead and use that same connection to verify the credential that we just issued. And I'm going to go here and we will choose partial disclosure, and so I'm just scared about driver's biometric information, and I will send the presentation request to that connection. But we are being told that we're not allowed to verify based on the governance file. Again, I'm just going to click that again so you can see the message. So to be able to fix that, we need to make changes to our governance file. And I can do that really easily. Again, I can use the governance editor here. Let me just refresh the page so we can see how it works better. Okay, so in my governance editor, I don't have any files selected. And I can just grab this file that I've published earlier and I will upload. And we got that and I will just go through the governance editor piece really quickly. So this part is the metadata that we can edit. If needed, we can also create a new one from scratch just by clicking the create button. We can go to schemas where we can add new schemas to be part of this ecosystem. We can edit them as well. So right now, when I clicked on the driver's license schema, you can see that we have a list of issuers as part of our ecosystem trusted issuers. And they are allowed to issue the credential. So this is only authorized to issue. So now I can just go to this little section that allows us to manipulate roles. And I will say that this issuer is also allowed to verify driver's license. And I'm going to add that role. Now we can go back to governance editor and I can publish that again to our S3 bucket. All right, so that was published. Now I can go to our governance editor, sorry, governance interpreter section, and I'm going to use our versioning, which is a new piece that you probably haven't seen before. It's in development right now and I'm going to click refresh. And our governance file was updated to the latest version that was published, according to the information on the current version of this file that we are using. And so right now I don't even have to refresh anything. I can go here and I can request the verification of this credential again. Not from here, sorry. From here. And as you can see, credential request went through and the status done indicates that the credential was indeed verified. So, a couple of things I wanted to touch on is that our current version of governance diguff supports publishing and versioning. So, if I go to governance editor right now and I will download this file and let's just call it final two. Let me go ahead and open that really quick. You can see that in our draft version of the file that we can create using the governance editor. If you just save it to a local file system, it will be in a draft state, meaning that it does not assign a version or a URI or the current version or any previous versions. So in our published governance file, it assigns the version which is the timestamp of the publishing. It also assigns the URI of the generic URL to a governance on our S3 bucket that we can always access and which we use to check against the most current version. And then the current version specifies the unique path to the file that was also published. And there is a set of previous versions over there. So, this is very helpful and handy. And it is still working progress. Again, if you would like to contribute or just look at what we're doing, you can come on Monday and be part of the deep governance work rule. But I believe that concludes my demo. And as a summary, I can say that decentralized ecosystem governance is a tool that is designed to translate human governance decisions into machine readable formats, enabling our software to make accurate decisions. Thanks. Now I believe that's the question time. Quick question, Simon. What are the next steps with the development of DGov? What's on the roadmap? So, one part is the trust establishment, another part is the credential trust establishment. Now, if I show my file again, you can see that we rely on named participants only. So, you have a set of trusted participants that are described in the file and you have roles assigned to those, right? So, in our case, we assigned role one in the first round of test or demo and then we assigned the second role to verify our driver's license as a second part of our demo. Now, credential trust establishment allows you to issue some sort of the organization schema to participant, but participant does not have to be part or listed in the ecosystem. And basically, it means that as long as you as an issuer hold this specific credential, according to the ecosystem, you will be granted a role to make a specific action. And this is the credential trust establishment is one part of our decentralized data foundation work and there is also a bunch of other cool stuff that we're working on, but they're in earlier stages. Can I add a few things, Simon? Go ahead. So, Sam, I work with Simon in that group. He mentioned versioning was under development and versioning we've been we've been proving out the concept but that will make it into the spec relatively soon. Also, under discussion is the ability to apply time ranges to authorized roles. And that allows for a participant that has been authorized but isn't in the future to still recognize the previously issued credentials. This is not uncommon, for example, what an educational institution loses their accreditation. But, but they, of course, the credentials they issued while they were approved still count. And so those are a couple more features that that are coming up on the roadmap. Thank you, Sam. All right. So it looks like we have about 10 minutes. Does anyone have any questions about what Trevor said in his slide that we're going through the slide that or questions for me about my demo. Philip has a question. Yes. Hello, Simon. Thank you for the presentation. Very interesting. I have a question about the governance of the governance editor tool. So in your demo you changed the governance live and you were you were alone to decide to update the file. Is there any consideration about having some kind of maintainer voting system for to be sure that nobody changed the or break the governance live on the system or some recommendation about that. So, obviously, the ability to to edit or generate the governance file is not going to be accessible to everybody. Even if you have an ability to create or edit an existing governance file. You won't be able to publish that to the same source where you got it from. So let's say let's just take a scenario right now. And I believe you're still seeing my screen right. This governance file was published to an S3 bucket and let's say I'm the governance government of Ukraine. I'm Ukrainian by nationality and so I created the governance file for whatever ecosystem I'm using and I published that to an S3 bucket as a source of truth. I am using a did to sign my file as a JWT and to be able to. So when it's posted when it's published it is in the science version it's in the science state. So there is no way to temper with the file without being noticed that it's it's it's broken right because it will not be verified. The signature will not be verified. The interpreter is able to grab the file from whatever source and even if it's JWT signed it has an ability to resolve did to be able to actually see whether the file isn't a perfect and pristine state and wasn't tempered before. Does that answer your question. Yes, mostly, but just maybe the part that when when you publish the file. Is there a way or consideration about not allow it to one person so you publish your date but unique signature from maybe a group of person some trustees or something like that before making the change to avoid some some some people that that would make bad decision or Yeah, I don't think we thought that through yet. But maybe some, some current has any comments on that I don't think I have any. Any answers to that question unfortunately I don't think we've thought through that far. I apologize I missed the question could you ask that again. Yeah, sure. So we see. We've seen in the live demo that we update the governance file live and this changed the real live and the system. I was asking about is there any consideration about using some kind of trust these signature before doing the change to to be sure that not only one person have the other authorization. So to make some change in the governance file. So at this point the governance file is signed when it's published by a single organization. So typically a key assigned with an organization's did the organization has the opportunity of course to restrict and apply their own rules about who within the organization is allowed to edit that file before the organization signature will be applied. So that isn't something that's managed by the spec itself, but rather left up to the administration of the organizational keys used to sign the file. So that can certainly be put in place, but it's not something that that is specified in the spec itself. Perhaps some non normative advice could be applied there to make that happen. The other thing that's worth noting and we say the word edit. We're going to move that we're going to start with the existing file and make a change. There's there's no actual editing there's only publishing a new version. So when every time you you publish it a new version gets published and it's actually the opportunity of anyone consuming the file to not update to the newest version if they would like if they don't like one of the changes made. And they decided that they want to individually vet the versions. They're also capable of doing so because of the architecture of how it's done. But and then others that they have decided to trust the publisher of the governance, and whatever they say goes which honestly is like a really common thing in our current world. Then, then they can just say hey use the latest version, no matter what the changes are right. And so that's, that's an option there. So, so yes, I, does that answer your question. Yeah absolutely thank you. Are there any more questions for anybody. There was a question from Silana about sharing the slides Trevor I believe those are the slides that are in your position you can share them with the public. I'll pass them on to shark or shark and has access to them so. Sounds great. Simon is there a meeting page for the decentralized ecosystem governance working group. There probably is, but I might take me a minute to find it. No worries. No worries. Great. Are there any other questions we've got just a few minutes left if there are. Great well thank you so much. Trevor or Simon did either of you have any final words for your presentation that you'd like to leave us with. Well, I think so. I think what we want to do is to get people into the position of thinking about what they need to do. Rather than giving them overviews descriptions of rules that they, they, they don't necessarily know how to process. So I think that's a key aspect and then joining that up to machine readable governance in a way that seamless would be the goal. But anyway, this is an alternative approach. One that's kind of born of the experience with customers who, who are kind of terrified about the whole governance thing and to get them to, to get them to a place of comfort, where they can process things discreetly and easily without freaking out. The question of the, what is the link to the spec this is based on from Kyle question in the chat. I can provide that just give me a moment. So the trust establishment is going to be one. And let me get you a second one. Great. Thanks for sending that Simon. All right, any, any last questions or words. Awesome. Thank you so much Trevor and Simon for a fantastic presentation and thanks to everyone for giving working group status updates. Really appreciate everyone joining and we'll see you all into weeks. Thank you. Thank you.