 to record. All right, awesome. Well, welcome everybody to the Identity Influencer's Working Group call. My name is Tim. I'm Sharers kind of co-administer of this group, and it's my first time presenting. So we'll, or not presenting, but you know, leaving it. So we'll see how that goes. Very exciting. First off, just wanted to remind everyone that we are operating under the hyper-religion anti-trust policy. So, you know, don't say anything that you don't want out there that's private or, you know, any of that stuff. So I know usually... I think I'll ask you, Tim, for a minute. Or maybe it's just me. You're working for me. Working for me, Shar. All right. Well, it was, it wasn't super important. It was the anti-trust, I guess it is super important. The anti-trust policy, Shar. So don't say anything, you know, that's private. So, yeah, I figured without further ado, we can kind of jump right into the Working Group Reports and Release Plan. So the, looks like the main Identity Working Group hasn't met recently. There was a hyper-religion indie contributors working group on the 21st. Did anyone attend that? Yes. We talked about moving forward with the release of, we now have release candidates for Hyperledger Indy for Ubuntu 20.04, which is huge. And then working on getting that available for the various downstream projects, upstream projects, downstream projects that use Indy. So we're getting there. All right. Very cool. Thank you. Still have a concern with the mixed-node issue, but it's not as clear. It's a serious problem. Mixed-node issue is a network that's running 16.04 nodes and you introduce a 20.04 node to it. And there seemed to be early on a problem with that. We've done some upgrades of various things and maybe that solved it. But anyway, we're still trying to figure out if that's a real problem or not, which is annoying because it's intermittent. All right. Well, good to know. Thank you for sharing. All right. Moving on, the Aries Working Group met on the 29th yesterday. Was anyone able to attend that call? Yeah. We had some good conversations led by Mr. Curran here, the other one, about proxy ledger access as well as the overlay capture architecture as applied to Aries. It was very good. And recording's posted. All right. Sounds good. Looks like Byfold hasn't met recently. Was anyone able to make the Aries Agents Working Group call? Akapag, we're getting a new release today. O7-4 will be officially released today. The final things came together yesterday. So looking forward to having that officially released. And we're here to go. And then we started talking about what will be the final 1.00 release. All right. That's super exciting. Had some discussion on DidCom 2.0 as well. Didn't go as far as I would have hoped. And so we'll see how that goes. I'm looking forward to having some conversations about where that fits. But I think it's still down the line a bit. Was that just implementation questions, Steven? What's that? Was that just like when to get it in the timeline? Yeah. Yeah. If there's things that come up that are particularly painful there, like just unknown things, will you raise those back to me? Like it's not clear how you do X and Y at the same time or something? Yeah. Yeah. Thanks. Steven, was there any highlights for the .74 release? The biggest thing, I'm actually thinking about that for the final release notes. I've been doing release notes all along. We've done five release candidates over this. And I've had release notes put out. I think the biggest thing is a lot of performance work done where a lot of stability was put in by people both doing scale testing, load testing, including the creation of a load testing repository, and then corrections based on what was discovered, and then analysis to show how performant the ASCAR implementation is. The next generation from the ND SDK, how solid that is compared to the ND SDK. So that's one. Endorser work. That was a big part of this. We now have sort of full indie endorser capabilities for both an author and an endorser. And then the third part was a lot of work on revocation and some a little bit painful, but not into the world discoveries on handling revocation. And again, all related to sort of productizing and making more robust the platform. And of course, there's a pile of other enhancements and a pile of bug fixes related to the product. And it was really a stabilization release, I think, more than anything. Improving its use in production scenarios. Great. Thanks. All right. Awesome. Yeah, thank you so much for sharing. Next up, we have the Aries Framework JavaScript meeting. Was anyone able to attend this one? Anyone go this morning? It was just an hour ago. I know they're making huge process. The O2 release is, I believe, out, which has a pile of AIP2 things in it, including issue potential. And they're working on O3 already, which is going to have the present proof V2 in it. So moving forward on that. So good progress and tons of progress then gets carried over into bifold and that work. All right. Very cool. Looks like these haven't met. I think this trust will repeat all members meeting. Was anyone able to go to this? I think that was our most recent. I did attend the IAM SSI. It was very interesting, actually. All right. Could you tell us a little bit about that? I'm still trying to digest it myself. It's an interesting concept where its identity access management, I believe, is what it stands for. And so it's how we, you know, IAM, I think of as what we do today to log into websites and then the SSI and how we have to like migrate from the old world to the new world and use a combination in a lot of cases. So there was good concepts talked about. All right. Well, it looks like they do have the recording as well. If anybody wants to review that one. Oh, just on the governance stack working group, there is no meeting today. If anybody was planning on going, there was a note in Slack that because Drummond and Scott are both the way they're going to cancel. All right. That's good to know. Was anyone able to make this technology stack working group meeting? It looks like a few days ago here on the 27th. All right. Well, it looks like you can read their charter and special presentation if you want to catch up with them. Was anyone able to make this ecosystem foundry meeting on the 23rd? It looks like they were talking about community topics, government across layers. It's coming up or governance. Sorry. Diff did come working group. It looks like they've been on the 27th. Was anyone able to attend this? Yep. We are in a good place from the spec perspective. We have received no negative feedback from the either the technical steering committee or the steering committee. So we anticipate ratification of V2 within a couple of weeks. And then our discussions have centered around extensions, how transport extensions are defined for the transport is not in the core spec, and stuff like that. So good ongoing conversation. All right. Awesome. I think I saw a recent un-sync meeting. Was anyone able to go to that? Yeah. Well, Stephen and I did. There is there is good conversation kind of around the direction, how we encourage adoption of did convie to other stuff like that. So the nice part about that is the meeting notes are the chat. So you can just go in the group and kind of see what happened. And so that's convenient. But yeah. All right. Sounds good. Thank you. It looks like the interoperability group also met on the 15th. Nope. They canceled. Oh, they canceled. All right. That's good to know as well. Sovereign foundation, nothing. And then W3C looks like the community credentials group was meeting a couple of days ago on the 28th. Was anyone able to make that one? I mean, the big thing out of W3C is that they've got the VC 2.0 working group started. They got their charter and started. Did working group is still waiting on W3C to decide? Okay. Well, I think that is everything, team. Thank you, everyone who shared and went to all these meetings and could bring back that info for us. The next thing on our agenda is a presentation on machine-readable governments from Mike Ebert and Simon as a Renko. I hope I said that right. If one of you guys wants to screen share, let me make sure that you'll be able to. Nope. Yeah. Looks like you can go ahead and do that. Okey-dokey. We're gonna find the right thing. All right. Can everybody see some gray slides? Yes. Awesome. All right. So most of the people on this call already kind of know what machine-readable governance is, but we have people who watch the recording and some people who haven't. So we're gonna go through some basics, a little bit of code, and do just some unforeseen circumstances. We'll see if Simon is able to get the demo ready, little demo to show you today. All right. So I'm gonna have to kind of fly through these to fit them in the allotted time. It's kind of a lot of material. So please interrupt if I completely blast through a concept that is confusing or if you have a question. So kind of a quick introduction to machine-readable governance. We're gonna go over what is it, what can you do with it, and then a little bit of a code overview. A lot of the work that I've done on machine-readable governance has been inspired by a proposal RFC by Daniel Hardman. And he said that a governance framework, or is sometimes called a trust framework, is a set of rules that establish trust about processes and indirectly about outcomes in a given context. So if that's what a governance framework is, then machine-readable governance would be governance frameworks embodied in formal data structures. So it's possible to react to them with software, not just with human intelligence. So we're talking about ways to take the rules and conventions and standards for an ecosystem and apply them in machine-readable code. Our approach has been to create governance framework files. And these are neat because each particular jurisdiction can publish their own and organize their own ecosystem. And then as ecosystems proliferate, it provides a format that allows them to share without having to have centralized servers that decide who is in or who is out of a particular list of trust. So files are cool because they're available to anybody who can resolve the URL or location where they're published. And everyone can look at how things are supposed to go, what the procedures are supposed to be, and the rules are ahead of time. And it allows your, if you have a holder agent that understands a machine-readable governance framework file, the agent can use that file to assist the users to make good decisions. Files also support offline interactions. They're relatively easy to cache. And so if you are in service and can download the governance framework file and store it on your device or agent, then if you end up out of service, some interactions can still proceed. And avoids the phone home or call to a centralized location, you know, single point of failure kind of problem as well. One of my favorite benefits to a governance framework file is some of the governance framework files that we've written allow you to decouple your business logic from your code. One of the sections is a place where you can specify the actions that can be taken or that are expected to be taken in your ecosystem. And so if you have the actions and the procedures described there, then, you know, those workflows can allow, you know, if an agent can interpret a generic file format that describes workflows, then you can change your workflow if you need to without having to go into hard-coded agents to change the code that says what they're supposed to do. So the way we've done governance framework files, we have some sections that are about establishing the roots of trust. We define some roles and permissions for those roles. And then we've specified some workflows. So we're going to go over the pieces of code and the file format that describe each of these. Any general questions about governance and machine-readable governance frameworks or governance frameworks and machine-readable governance files before we dive into specifics? Mike, just a quick question. What's the recommended storage location for machine-readable governance files? And one of the thoughts there is, is it with the human-readable governance documents? So we're still working on what the recommended way would be, but there are a couple of ways that have been talked about already. The route we took in the interest of getting something working as quickly as we could was to publish the governance framework files on a known domain. So just with a URL and a domain that people kind of trusted already, you could also use, publish them in a way such that they have a did for a did document and use a did web or a did key method of kind of signing and making sure that those are trustworthy. Maybe Sam has some more forward-looking comments on good ways to publish these. Not many. The point is that they should be published by whatever authority is publishing them. So if you have like an organization website or a company or whatever else, then hosting it on those domains is probably the most sensible place to put it from now and maybe forever, but at least for now. Can you be a little more concrete as to what you see as the scope of a governance framework document? Like would it be an issuer? Would it be a verifier? Would it be a group of those? We've written them to kind of live at the ecosystem level. So you have, so for example, let's say you have an employer and they are going to be using verifiable credentials internally and so they have a couple different machines that are issuers. Let's say one is for the security group and one is for human resources and they're going to have a number of maybe a single application or a number of applications that are trusted to be holders and then they'll have various verifiers that are within their their little company ecosystem. So you could have verifiers that say here's the key access code, here's the login system for the servers that we run, a different one would be here's how you present that you're an employee so you can collect pay stubs and information about your benefits or something like that. Or another example of an ecosystem is we ran this as a trial with the government of Aruba and so they had partnered with particular health information providers that they knew would be that they would understand the information coming from them and so they made a list of those issuers even though they didn't control the health systems they said we have gone through the process of trusting these particular issuers. Here's the government agent that will verify health information and travel information and then issue a trusted traveler a clearance to enter the country and then here are known verifiers who are allowed to look at that trusted traveler so that you can at several different levels such as the airport which would have access to all of the information the government wanted to provide or a venue like the casino on the island or a hotel or a restaurant who would be allowed to see that the government had deemed them healthy and able to travel but wouldn't have access to most of the information on that credential so it's kind of a collection of the issuers and the verifiers and the rules they follow for a particular collection of entities and services. So maybe a more formal definition there is that it's a it's one or more issuers and zero or more verifiers you can also have trusted verifiers in the system that are issuing credentials that all have this roughly the same semantic meaning so an industry association one is a decent one I know you've got some use case going on with lawyers for example and so if you had more than one issuer or one or more issuers that issue credentials relevant to lawyers then all of those would be trusted issuers for the for the schema if you if you will and then and that alone makes a useful governance file because now when someone presents you a credential you actually can decide or use that file to decide whether it's a trusted issuer or not. There's there's two ways Michael's talking about direct listing of issuers there's there's another way that we've imagined that that we have not yet put in the file which is the governance file can say people are a trusted issuer if they have can themselves present a credential from an authority listed here and that way there's like a there's like a better way of scaling that without listing everyone that's another way but we haven't yet had a customer with that thing that hasn't motivated developing it yet okay cool yeah it's the scale thing that if I have a more or less generic wallet how do I know when to pick up a governance file why to trust it and so on and I think I agree with okay sounds good I think we know this issue so it's it's interesting good thanks. Yeah well we're exploring the ways to sign a document and so that you can trust the file or where to publish it and then I think that as an identity community it would be a good idea to look at you know how to tell Mr. Generic Holder that he should pick up a governance file and use it one interesting thing is that they're still useful even if the often even if the holder doesn't know anything about the ecosystem underneath but yeah so there's there's all sorts of nuance there so and good comments thank you okay so so far we have some sample code that would be interesting to describe things about the ecosystem we're using presentation different definitions as defined by the diff and then we have a section for actions which is workflows that are kind of extend what you can do with your establishment of the roots of trust okay so we're using governance files as the blue to hold all of our machine readable governance together and there's a metadata section this is not a locked down standard by any means so we've just got some sample ideas here so you could provide a context you could name your governance files in a human friendly way so people could look at which one is being used maybe make decisions based on that you could version this particular governance file to say we've updated our governance you could use different formats so we're working with the diff to try and come up with a standard for this so you could say format one from the diff or format 1.1 or 1.2 or whatever it would be good to include a unique ID could be a uuid or a did or something like that this is not written in stone yet this description could go with this human friendly name to say this is what this governance file is for you could include a last updated date you could link to resources such as the human readable governance that goes with this machine readable governance and then these ideas are you know a little more borderline but you could perhaps tag your document for search and discovery purposes you could describe the jurisdictions and the geographic areas that are involved here so this is just a sample of some ideas there my sample did not include network alleged information you could put that in there you could provide a mediator an invitation to a mediator and maybe something about recourse in case one of the agents listed in the framework or in the file doesn't behave the way they're supposed to we include a list of schemas so like sam was saying you have a collection of schemas that are semantically related or similar so in our coven use case we had all the things related to health and travel for aruba when they were using when they needed to check health status so you have lab orders results vaccines exemptions and a trusted traveler which is how the government said you're good to come to the country the participant section is the sam was saying this is the place where you would if you're hard coding the agents that you trust if you're hand or you know managing a list then that's where you would put these so the most important part is this did the other items are optional we used them to be able to provide some interesting information about the agents without having to stand up additional components in the ecosystem to issue credentials or to provide information about the dits so we just put a little bit in here the did would be mandatory the other sections could be optional and you know if they're provided and you understand them and you trust them go ahead and use them but if you if they're not provided or they're provided and you don't trust them or you don't understand them then then use the did to look up something or ignore that so in this case we had you know the simplest possible file for aruba was the government a health issuer and a single venue we did more than this but just to kind of illustrate the participant section here that's kind of what we can show there and then roles can be used to categorize participants in an ecosystem and help others to understand what those participants are supposed to be doing and if necessary you can assign multiple roles this is one of the sections it's most likely to be reworked as we work with the diff and other organizations and just you know investigate their needs but the concepts are pretty similar no matter what we tweak here so we've listed some roles for this particular use case a jurisdiction could describe their own these could also be so you could create your own or you could agree on them a broader scope say across an industry or you know a government or other jurisdiction and then you can map those roles to the participants that you have a notion of permissions so you could say we're going to create a list of health issuers and one of them could be a hospital one of them could be a lab or you could say we're going to have a list of you know if you're doing industry standards for you know certifications you could say here are the different providers of training or review boards or things like that and list those in the aruba case there was a travel issuer so the government said we're in charge of issuing travel related credentials and we're the ones who are going to do the verification in this case you could have you know as an example you could have your security verifier and you could have instead of travel verification you could have the hr verifier example that I kind of mentioned earlier and you'll notice the government shows up in two places that's an example of multiple roles so that's kind of a permission section and Mike yes just back to that would you consider that concept here the role mapping to specific dids to be you know we've called it a trust registry maybe in the past is that kind of what this would be this is extremely similar to a trust registry I have looked into the trust over IP trust registry spec the version that they just recently published to their github and the the the basic idea of what you're storing the ideas are kind of the same but the the implementations are a little bit different so this is included in a file that you can download and parse and theirs is api centric they want people to make api calls to their central server to retrieve information about a particular did and so if you were if you wanted all of the information about who is going to be doing what then you'd have to query for every did okay potentially so maybe I've got a hole in my understanding there but so the approach this is a very similar concept the approach for delivering it to people is just a little different okay right yeah so once you have the participants and what they're expected to be doing we've actually done some work to describe what those actions are and then to link them together into you know potentially link them in together you don't have to link them but you can to link them into workflows so we took some inspiration from Keith Smith I like to give him credit he shared a presentation on interaction documents and so some of his ideas made it into here so I just I like to include that reference for him okay so here is an action section that describes the the workflow in aruba was a very you know it was one of the more complicated ones we've done so far as far as describing all of the different steps and having a number of different things to do so a quick overview of that sample workflow you would go and connect to a provider of health information and then prove who you were then collect your health information then connect to the government prove who you were there share your health information go through a flow to establish that you were you know you've met the other travel requirements receive a trusted traveler and then go and get verified at various locations with that trusted traveler to enable you to do different things and so this these actions kind of describe what some of those steps are so this very first one on here is to say if you're going to connect to a connect the holder to a health issuer if you're the health issuer then you are going to be using an action that is of the type protocol there are some other action types as well that we'll talk about in a minute and then for that action type you can use use a specify we're using dig conversion one and we're going to start with an invitation if you have success with this protocol proceed to the demographic step and if things if there's an error then you could include an error handler we've since in our code we've actually written the error handling it's typically a basic message that tells the user what happened let's see here so this is an example of a protocol that's a question answer so after you connect to the health issuer the health issuer is going to ask the holder if you received a medical release credential from the health lab before meaning are you going to authorize us to release your health information and you know you can answer I need a new credential or I already have one and then if the protocol executes successfully then the next step would be to make a decision based on the response from this question and so you know it's it's information about how to execute this step of or this action and then optionally you can follow the steps that you know for success or for errors and they're all just kind of changed together like that some other interesting features here some of these include let's see let's find an example here okay so if you're issuing a credential you could link to the schema that you're using and if you're doing a verification this is where the presentation definitions are linked and a presentation definition you know uses the presentation exchange format from the decentralized identity foundation and describes how a presentation is supposed to take place so which which schema or schemas are supposed to be checked which attributes are being asked for what are some of the formats for those fields and and what's interesting is you could have multiple actions so let's see so to go back to the trust to traveler use case you could say the there's an action for verifying the full travel document and that's assigned to roles that are such as the airport or border control who need to see all of the information we have a different action for verifying basically a simple thumbs up or thumbs down do you have one so that the restaurant or the venue would know to let you in but without exposing any other sensitive information the other action types besides the you know ones based on did come protocols we've written what's called a decision action which allows you to feed in a value and then make a decision based on it let's see if I have an example in here okay here we go so based on choosing which health credential you're going to use to present you could say if the person chose a lab result then the next step would be validate the lab result they chose a vaccine exemption and we're going to back validate the exemption so you know you could interact with the the user and then based on their choice take another action and then the final action type that we've not actually implemented yet but have considered would be like an api action where in the the flow of all of this you could ask your agent to communicate with an external or in another api somewhere kind of send information or trigger something else that's not perhaps directly related to the agents involved okay that's a lot of talking really quick our actions you know is that starting to describe what these do or is that completely clear as mud the the interesting thing for me is this seems to be a a way to script a controller so it it it looks to me like you've got the architecture here is you've got a aries framework which executes protocols and and reports back progress and webhooks and so on and and with that you have a controller and then what you've done here is sort of created a script their controller with use you manage itself which is less about governance I think I don't know but that's and more about business process and business flow and and so I'm wondering if you have two concepts here that that don't necessarily have to mix they don't have to mix but there's there's there's good reasons why governance and process do mix and the key smith's example that he always gave was that if you get pulled over by a cop you you you should have the right to verify that they're actually a cop before you present them anything and so having a process defined in governance says hey you're allowed to ask the cop for proof that they're a cop prior to you releasing this information and then here's the information that the law requires and so having that kind of interaction there allows for the the the the combination of the two so you're totally right and it has to be all the time right so the vision there would be any wallet would have would would have this capability of executing actions and they would have a series of actions in the wallet that they could invoke at some point and that invocation would do a bunch of things that are specified in an action file but that but that the user wouldn't have to carry out each one is that kind of what yes so far we've used this mostly on the back end so no i get that but i could be an example yeah yeah but yeah okay you've got hands up oh uh i'm not seeing the participants first okay simon go ahead um yeah just a quick comment to student currents uh question uh so the idea about the governance file uh is that it's going to be used optionally and it's going to be you it's it there's a possibility to use it only partially for example an agent that will want to know only about the participant's section of the governance file and then it will just care about knowing the trusted trusted participant in this ecosystem and don't care about following the action section of the business logic in the other case you might that agent might want to say hey i don't really care about the participant section i can take any credentials from anyone or verify it from you know verify any credential but i do care about the business flow or in the other case you can say i would like to have both or in the fourth case you can say i don't really care about the governance at all and i will do whatever i want so the idea is to make it flexible enough to meet every single scenario whether the agent specifications want to follow all some or none and that applies particularly to the holders where they have the option to do whatever they feel like doing uh it's with uh when you're trying to establish expectations then uh if a an issuer or a verifier goes off the rails and is doing wacky things then that is sometimes cause for serious concern in particular workflows or ecosystems but yeah so you know it's it's not shouldn't be mandated for the agents to be able to function as agents but could be problematic if you're doing something sensitive or where you're trying to to meet a certain expectation but good comment Simon uh Kyle yeah um this is really good and and i just wanted to address Steven Curran's comment that i think this is some governance this is some level of governance um maybe it's like ecosystem level um because it covers off some of the requirements that potentially would be there for the transactions between two agents that you want to essentially govern and you know for sam's example of the you know the policemen you know that that ecosystem has that you know sort of business process you know governed you know uh for you know the the person in the car wanting to verify first that they are a police officer that you know we can say that that is governed and so that you know business process or transaction you know follows that um my other comment or question on this is because these are all essentially at the end of the day peer to peer transactions when we talk about this as a controller who is controlling the transaction um and and what might happen if you know there's different sets of actions on each of the agents that are doing the you know the exchanges so so far it's typically driven by uh whichever agent is the uh usually a the server based agent right now um or you know so usually the issuer or the verifier that has a particular workflow they're trying to enforce um if you were to have differences um it's possible that you could have you know if you had one agent using one governance file and a different one using a different governance file or a different set of actions that you could get into some funny uh edge cases or loops where one agent responds in a particular way and then throws the other agent you know it responds and finds itself in a state that it hadn't anticipated or was missing requirements or something like that uh so typically it would be better if they would uh you know we're agreeing on or using the same same governance files that they could both know that we're we're doing this dance you know or one you don't want one doing the cha cha and the other doing the waltz right um and so what we need is a little music that cues people into uh which one they're using but yeah right now it's typically driven by uh the agents that would be constrained more constrained to a particular workflow an expectation that your issuer or verifier is going to behave a certain way and the holders are the way we've used it so far is to help them understand what's going to happen and what the expectations are so they could flag behavior that's um inconsistent or problematic um are the actions going beyond just saying initiate this protocol because the once you initiate a protocol both sides kind of know what the dance is it's it's the question of who initiates the protocol i i would think that the actions would not contain a lot of detail of of trying to manage the protocol once it's initiated right so the the the yeah protocols kind of have their own flow and state machine right right so these these actions are meant to be uh at a meta level so to say um we're gonna kick off this particular protocol and then when that protocol uh is all complete then um based on you know the the results of how that interaction went then we'll look at what the next action should be so you have kind of a state machine that is on top of or above um the the state machines that the agents already know how to to run themselves yeah okay good yeah and steven some of the you know talk about the dance is you know even if we just look at this example right here where you want to verify some but if they do a verification after an invitation um is done um if you have both agents you know doing that you know they will both want to you know check who the other person is how does that work um do you know what I mean yeah i might might maybe you have an answer for if you have two agents both running this thing and they get an invitation and they both want to verify each other so the what you could do with with a workflow like this is described to say you know what it generally would be smart if the the issuer or the verifier identified themselves first and then the uh after they you know those agents had to identify themselves then the holder would present the information that that was needed or requested to identify themselves second or if it needs to be the other way around you could list it that way and then then both agents would know okay when we go through this workflow I know to expect that the issuer is going to identify itself first or that the holder is going to request that proof first and so that they don't end up with the collision of who are you know who are you you know you first know you first in most of those race condition scenarios there's one party that doesn't care for example if if you are the dmv or something you're just going to volunteer your information without caring what you receive first um and the the only time you really get into the race condition is when you have two typically individuals and in that case what I suspect will evolve as an industry is more of an escalation thing where there's some information you're willing to share all the time and then you know further permission will be required to elevate that all right uh let's see here we already covered that it's a state machine we have some emitters and listeners so we wrote some custom controller code that could process a governance file we're working on standardizing the governance files and making the controller code it's written for akapai working on making that um fully open source so people can look at it and use it um i'm not going to go over presentation definitions a ton because we can go look at the this information from the diff and we're rapidly running out of time uh let's see here all right we already talked about okay some interesting concepts for the future uh we may be able to do some inheritance or copying from one governance file to another and or or perhaps just directly referencing sections and other governance files so for example uh you like someone else's trust list um but you want to implement different actions or you like someone else's actions but you have your own list of agents you could kind of put things together that way discoverability could be interesting so once these start getting published then it might be useful to have ways to find them or search for them or rate them um and then we've talked about uh you know how does an agent know what governance is in use and so we have to talk about how to surface that um you know where it so that everybody's aware of what's available um let's provide the link to this presentation in the chat so that everybody can refer to the full governance file sample there's also a presentation definition sample and uh we've done a whole bunch of questions already um Simon were you able to find one of our demos that's currently up and running at the moment I know that I asked you at the very last second to prepare that yeah no worries I was able to get my local environment so okay so I'm gonna stop sharing while Simon brings that up and then Steven current your hands up um I can wait till after the demo I don't want to pull that up okay or if it'll take time to get the demo going no looks like it's going good all right so Simon's showing us the uh there's open source code in the cardia project that includes um some of the governance um so that is a code base you can go look at and dig through uh we're still working out you know it's not perfect yet but um it's at least in some fashion of usability there and uh it's a code base that we can share with everybody so all right Simon so what are you showing us here right now right um so just just a quick note that uh we are the point where we can actually choose uh which governments govern men governance file we would like to use so uh we have a little section in our settings tab which allows us to add a governance uh file by providing the url and then it's going to be available in this drop down menu and you can just swap between the governance in the real time and it will change the behavior of your agent so uh here we're using the atomic actions that we've used for the inter-opathon the difference between the actions atomic actions and the regular governance file is that uh we are not enforcing the participant so any role would do in this case you can see that we established an active connection but our holder is uh just waiting for the next step and I can just go and uh send the basic message and it's gonna this basic message is going to be executed by our governance actions um where we just go we send a specific uh flag to the action processor and it's going to go and fetch the governance file and it's going to loop through and see which one uses the basic message protocol and it will uh grab the message from there in this case it's the this is a basic message in the content of the action and it's going to be yep I'm going to interrupt here um so where we if you break down the governance file to any role and the actions aren't linked together into a workflow that ends up being the exact same as a normal agent could you potentially switch on the other governance file and show even just two or three steps of the workflow maybe not the whole thing but we're pretty much out of time and I could I did not anchor my did that could cause uh so uh I think that we can get as far as well you can demonstrate the connection and the question uh before you is it is it gonna let you do that um it's not all right I mean if you incur and wants to ask a question it's gonna take me maybe a minute to anchor the did so it's not going to take too much time so um all right give it a try go quick and then we'll talk to Steven for a minute and try and end as soon as as soon as we can about Steven um just a quick comment having spent a pile of time in um multilingual and and overlays capture and and making that um I would highly recommend making sure you've got a mechanism that isolates all the phrases in a governance file so that you can make it multilingual um so it's easy for someone to know okay here is the full set of things that I've got to translate when I want to have five languages supported in this governance file so that was the comment I had to make that's an excellent comment and after watching your overlay capture architecture presentation yesterday it's like oh I really okay it's time to look into it it's it's uh ready for you know implementation and I should know better so yeah um yeah I'm not sure overlay is the solution for because your your data structures are so complex um so I'm not sure that's the right one but but that's something like multilingual absolutely is is fundamental and and needs to be addressed earlier the better absolutely ooh time to take a note all right where are my notes there they are yeah I appreciate the feedback um I gave a couple presentations uh about a year ago and a lot of people were like you know crickets when I shared any of this and I don't know what the deal was but on the last you know since this last IW I had a lot of good constructive feedback so it's helping I just wish I could go faster I know the feeling okay I think we're all up okay let me okay yeah there's one step that I keep forgetting every time so once the change was made um our agent will keep the local version of this governance file and so you you need to go and fetch that again and then you can go and decide select that so yeah it's not it's a little confusing but let me get rid of those and boom we are able to get the invitation so I can scan it and we got an active connection and boom here's the question answer that goes through the uh automated automated flow how far would you like me to go with that Mike uh another step or two so um this doesn't look a whole lot different than you know your typical demo but it's really interesting to note that the actions that are being taken by this enterprise or server-based agent you know this controller on top of ACAPI um those are running through the actions workflow you know the kind of the scripted deal to create those that are not hard coded in our controller code not being attention to the values here so I mean did the wrong date there uh no we're fine all right so we got a medical release credential offered to us and we fetched the demographics information from the self-attested and send it back so there's a medical release knowledge so if I go ahead and connect again I should be able to present that and this shows that decision action in action here where they answered the question and then we went down a different path based on what the user chose so the first path was we're going to go through a workflow to create your medical release and then the second workflow was I've already got one so we don't need to recreate that process that's a pretty good uh demo at the moment Simon we're out of time but it shows that you know the actions were scripted there showed a little bit about how to load one a little bit about the ecosystem so thank you very much I guess we'll turn the time back over to Tim all right yes thank you guys so much for presenting that was awesome and thank you everyone for coming we are unfortunately a few minutes over so I apologize for that but the recording will be posted and we hope to see you all again in a couple weeks have a good one thanks Tim thank you thank you thanks Mike thanks Tim thanks Simon