 Welcome to the July 26 2023 errors working group call. A few things. Topics on the agenda, marketing update, endorser service. And RFC pull requests and notably the one involving community toward it updates around unqualified dids. We are recording. So we'll be posting recording afterwards reminder. This is a Linux foundation hyper ledger foundation meeting. So the Linux foundation. Any trust policy is in effect. As is the hyper ledger code of conduct. Anyone new to the meeting that would like to introduce themselves say hi or talk about what they're doing in the community. Feel free to do so now, or if anyone has any announcements, please grab the mic. Any topics to add to the agenda. All right. I'll start with release status updates. Notably released 090 of acupy has been released with the new credits implementation of an on credits so the removal of the credits. Dependency and series of performance improvements and fixes. In the CL signatures implementation. So for a non credits. So that's in place. And the release was completed earlier this week. I actually haven't sent out a full announcement yet. But it is on my list for today. To let everyone in the community know. If you guys have any announcements from the various projects. Stephen I was at the AFJ call last week. And had shared the information from this call previously about wanting to deprecate. Did the indie SDK. Yeah. And so there was the fair amount of discussion about that. And so what I wanted to do was to get in touch with you to make sure that. All the. He understood everything that was going to need to happen and everybody was in sync. Okay. I have not yet heard from him, but hopefully will. I've sent him a few notes this morning about. Other upgrades. So hopefully that'll. That'll come out as well. Thank you for that. I'm going to go ahead and get back to you. I'm going to speak with. The areas VCX crew who are on C on the call today as well. And. They're. Doing their work on that. And wanted some other updates and. Information about using. In particular the. And now in credits rust implementation. So. That too was moving forward in the areas VCX community. Okay. So I'm going to go ahead and get back to you. I'm going to talk a little bit about the topics. Helen. I see you are here. And Alex as well. But can you talk to us about the marketing update? And do you want to share. Nothing to share today. But yeah, happy to give an update. We met yesterday with the Aries marketing working group. It had a few folks join us, which is great to have. The, the survey that we had presented at the last meeting here. That Alex presented. And so we've got some really great feedback from others in the community who had. Just some help rounded out that the survey results, which was great. So our next step is that we've identified is to now reach out to the. And then we're going to go ahead and talk to the foundation staff. And talk with them about updating the, the website there in the process of updating the entire hyper ledger website. So we're trying to figure out how to get in there. Kind of their workflow to get some of that information updated. And then we'll move towards making sure that we are in alignment with the layout. Kind of the prescribed layout that is already there for projects and the wiki as well. And then we're going to go ahead and talk to the foundation staff. And then we're going to go ahead and talk to the foundation staff. A lot of the conversation yesterday was talking about how high level to start. Some of the messaging and communications and kind of overview. And then how to. Kind of lower the barrier of entry. For use adoption, contributions, involvement in the community for developers as well. So kind of how to describe. And then how to direct the developers where to go as well. So I'm really excited for the progress in the kind of maturity of what we're talking about and what the direction we're going. And now it's all about finding the right way to implement it across the kind of various touch points that folks reach when they are heading towards areas. So stay tuned for, for those updates between now and probably our next meeting. Cool. We're having an internal workshop at BC gov Helen that. We hope it will be a. The start of a series of workshops that. Simplify the ramp up for developers. And that, that can be used, you know, repeatedly within our organization, so that we'll apply outside and so make it. That, that initial climb much, much easier than it's been in the past. That sounds awesome. Yeah. I know a lot of organizations are really trying to crack that net in terms of trying to. Yeah. Just increase adoption. Reduce time to adoption, et cetera. We at a DCO just put out a short kind of beginner's guide yesterday that we're circulating. Yeah. Yeah. I think it's more of more geared towards the business audience, really explaining what. What verifiable credentials do what, I mean, very, very kind of a very high level. But I think it's, it's that sort of essential guide that I think a lot of people, especially business decision makers, kind of need early on in their, their process. So yeah, I'm happy to post that somewhere if folks are interested. Yeah, very cool. I would be interested in that as well. Cool. Maybe I'll just put it on the discord link or something. So cool. Okay. We're also seeing, by the way, for developers that I'm, I'm helping or working with a person who's new to the community and every turn they hit M1 problems on a Mac. So we do have to figure out how to deal with that. We're almost there. We've got lots of fixes, but not quite everywhere. So one thing that I would suggest the different projects do is, is make sure that somebody is trying these on a, on a plain M1 Mac and seeing how they go and because that's super frustrating when you're just trying to try out the tools and even the demos don't work because of issues like that. Okay. So, and just one last thing is that our next hyper ledger Aries marketing committee. Work meeting is it's last Tuesday of the month, so there'll be one in our next ones in August. And again, even if you're not a marketer, you're not necessarily interested in marketing per se, but you do have opinions about what is useful information for different audiences. Please, please, please join us. That's the best. Some of the best conversation yesterday happened from folks that aren't necessarily in, in the marketing realm, but definitely have opinions and ideas about kind of Aries communication and we will be extending a special invitation to Steven and Sam to join us because we have some questions that we'd like to pick your brain about. So hopefully you guys can join us as well at the end of August. So I'll try to get that on your calendars. One other thing to point out to everyone is that I believe there is said quarter three is identity themed. Yes. So basically anyone that wants to, you know, do some promotion or have hyper ledger promote what they're doing in the community, what they're doing, what their product does and things like that. That's a great opportunity to use hyper ledger to do that. And, and we encourage that. So definitely keep that in mind. Yeah. And if you have any questions, please feel free to direct your market, marketer folks, marketing team folks on your teams to me and I'm happy to answer any questions or to Ben, you know, the hyper ledger staff, they've been putting out. Yeah, lots of messages about it. So if you have questions or need, need further information, please, yeah, don't hesitate to reach out. Awesome. Thanks. No problem. Okay. Thank you. Aries endorser service. We're doing some work in BC gov. So we thought we would. Share this presentation and sort of set the scene and then talk about what we're doing. So Aries endorser service for those not aware. Aries endorser service is a. Aries endorser service for those not aware. So it's a version of acopie. To act as an endorser. So the idea there is that in your own. Enterprise and your own environment, you can spin up an Aries endorser service. And then point your Aries agents to use that when necessary. So this, this presentation is about going beyond rejecting or accepting everything, which is where we're at today with the Aries endorser service. A reminder of what the Aries endorser services originally implemented to support the hyper ledger Indie endorser model. So on Indie. An endorser is allowed. An endorser is a role. That is given to a dead and an endorser is allowed to write transactions and allow to endorse transactions for others. So basically. Aries endorser uses their dead and verification key from their dead on the Indie network. When writing transactions to the network for themselves. But they are also used that to endorse transactions for others. And so the common pattern. Is for an organization to have a single endorser. And for any other. Services within the enterprise. So basically, it would not be an endorser, but rather be an author. An author is not allowed to write transactions unless they are endorsed means signed by an endorser. So basically all of the other issuers within an entity. Would send a note to an endorser saying, Hey, here's this transaction. I want to write, can you endorse it for me? The endorser signs it. And either. The endorser, you know, submits the transaction for writing or sends it back to the author and the author submits it for writing, either works as long as the signatures are in place. The author must have constructed the transaction. The endorser must have signed it. And then after that, whoever submits it. Is able to do so. And then on a public indie ledgers endorsers are able to write. As long as they are not responsible for, for paying a trend, paying for a transaction that they write and that they endorse. So the ledger itself doesn't care what transactions they write as long as they're properly signed by the author. And if necessary, an endorser. And then that the endorser would then be charged for them. So. The endorser would then be charged for them. And then the endorser would then be charged for them. Endorsing. Service within an enterprise may be useful on other verifiable data registries. So as we start to think about using other services, the enterprise might want to have control over who's allowed to write. So an example is in BC gov. We have a central digital trust. And I think I've got that in here. Maybe I don't. I think we have a digital trust group. And that digital trust group is. Charged with making sure that. Other groups follow the. Policies and regulations for using for issuing credentials. And for using common schemas and, and doing things in a collaborative way. And so. We have a digital trust group is basically the endorser. And so even, you know, even if we weren't using India, we would still want that control to make sure that. Organizations within BC gov are not. Issuing credentials, for example, that they're not authorized to issue. They're not the actual authority over. We don't want. We don't want them to issue credentials. We don't want them to issue credentials. We don't want them to issue credentials if you will. Issuing credentials that they shouldn't be issuing on behalf of the BC gov. Okay. So basically within acupy, at least, and certainly with the endorser service. There's two roles, the author role and the endorser role. The author simply has to know who is my endorser. And the endorser role is to a single ledger. So we in BC gov, for example, we write to multiple ledgers. There's an endorser for each of those ledgers and author needs to know, Hey, which ledger do I write to and therefore which endorser do I use. Basically the author, the author is handed a. Did for the endorser and they can establish a connection with that endorser and then. The endorser needs to know it's endorser did. Whether it should auto accept a connection request, should I just accept a connection from anyone that sends them, should I auto endorse request every time an endorser sends or an author sends a request, should I endorse it. And. The endorser service doesn't have a controller right now, so it isn't built in. You don't have to build your own it with the Aries endorser service. So as a result of it, if there is no controller that you've implemented no business rules that you've implemented. It's an auto reject service and that's the why I had that in the title. Right now the Aries endorser service that exists either auto endorses everything because you've told it to or rejects everything because there's no controller to override. So there's no controller to do anything that you've told it to or reject everything that requests. There is a configuration on writing. You know the. Sorry, that the first sentence in this is wrong. This would say the author must write the transaction to create. Oh, sorry. No, this is right. When using this. For rights to actual to Indy. The endorser must write the transaction to create the transaction to create the transaction. And the author must also write the transaction. Writing the transaction that creates the authors did. The author sends the did over not the transactions, but rather the did and the very key. And then the endorser writes the transaction and submits it to the ledger. For all other transactions that the author wants to create to create a schema, credit, def revocation registries and so on. The endorser may execute the sign transaction or the endorser may pass it back to the author to submit. So either of those work, it doesn't really matter to Indy who who submits it as long as the correct signatures are on the transaction. The author has to be the author of the, and the endorser has to endorse it. So that's basically the roles and and functionality of the of the endorser service. So, preliminary ideas we had for for what the what a finer grained controller might have a finer implementation. So authors might be authenticated somehow and authors would have all or nothing privileges in other words if an author was allowed to use an endorser, then that auto correct would work the author could write whatever it wanted. So a way we can enforce control over the in the endorser would be to create some sort of allow list a list of dids allowed to be endorsed. It's a bit tricky because the author did is not known until the first time they request there did be created. So it would submit a request and then it would be held until it would either be rejected right off or held until their did was allowed, put into an allow list. And so then we thought well we need a UI for managing the allow list we need, we need a way for people to add and remove dids from it. So that's hard to do, you know if you're having a generic service, how do you create a UI that will fit everyone's use that's, that's pretty tricky. Oops. This touches back on the BC government requirements but a little bit more we have that I mentioned the digital identity and trust group approve rights to the ledger. We wanted BC gov wanted finer grain controls they actually wanted permission not over just whether a an author is allowed to write transactions but rather every specific transaction be approved so in other words, if an author wants to write a particular schema, we would want the digital identity and trust group to look over that schema review the schema agree it is necessary agree that it's appropriate that this group use this schema and not use one that already exists. If, if the schema should be one that already exists, the, you know, the request to write a schema would be rejected. Similarly, you know, a credential definition and so on. So basically we wanted control not just over who the authors were, but actually each transaction that the author wants to write. So that, that creates a logistics problem how do we implement such a thing. Without that, and with that, I'm going to turn it over to a miliano soon a who is working on ideas for for implementing such a thing so I'll stop sharing and pass it to you a million. Thanks even. I'll put a link in the chat in the meantime, because it's what I'm going to be sharing for the most part. I figured out how to share the screen that would be great. There's a button called share screen. You know it's early for me. You're welcome. All right. I think you can see my screen right. Yep. So this is the, an issue that I've logged. And we have been having a conversation on in the ears endorser service repository in GitHub, and they should describes a little less in detail, but Steven just exposed so sort of like the requirements were looking at implementing and provides a suggestion or initial starting point at how to implement the access control this endorsement more granular controls and configurations and the idea was to keep it as simple as possible. At least for the first cut, as Steven mentioned, it's hard to come up with like a UX that works for everybody. And especially if you're looking at at the UI controls. So we try to put together something that should work in most cases and should be extensible in the future without too many issues. I'll just skim skip to the bottom. A recommendation just to give an overview and then we can open the conversation if you want. The idea would be to have a few different levels of authorization that are stored in the endorser service as a permission matrix or allow list. We have at the very as an initial step and allow list to determine who is in the first place allowed to get a connection to the endorser and even have the opportunity to request any type of endorsement transaction. So this can be just like a simple table that includes the did of the requester or in case of multi-tenant instances, we're working quite a bit with multi-tenant stack up high, in particular with traction, we're trying to get that to be our default way to go to a new agent for a government business unit that requires one. So in that case, I think we might just want to match on the public URL for the agent, since it's going to be the same for all of the tenants. And these will allow the items in the allow list to establish a connection with the endorser, nothing more. The next step would be to have a permission matrix that finds each did to the operations that they can perform. They can publish their own did, they're public did on the ledger, they can publish schemas, credits, and while publishing the did is only a true false flag, schemas and credits would have three different states that could be applied, these are reported up here that are auto, manual and deny. This comes from a suggestion from Wade Barnes. These are basically the, what would we envision seeing like the three paths that could happen. If a request comes in, it could be automatically approved for a schema, if more on that in a second, but the endorser could work automatically on that request. It could require input from an administrator. This is what happens nowadays. We need to basically accept the endorsement request via API, or we could add a denying case. I don't know that that particular author has been misbehaving and is not allowed to request endorsement anymore. This permission matrix would be a top level type of permission to explicitly set what each did is allowed to do and how everything is treated. And there would be two additional allow lists that depend on that. So there would be sort of like a foreign key relationship on the dids in these table and these two tables. One would be an allow list for schemas and would specify a schema name and schema version that can be published. This goes back to what Stephen mentioned. Determine whether the author should be allowed to publish that schema or it would be better for them to reuse a schema that's already published. Some ID documents might follow the pattern where a higher entity organization publishes the schema and then, in Canada as an example, it could be a federal government publishing like an ID document schema and the provincial government having their own credential definition. As you can see, there's a possibility of adding wildcards in case it was determined that a specific schema name is okay and further versions can be updated automatically. And the same thing, so to speak, would happen for the credential definitions that tie any insurance schema. I see Stephen, you have your hand up. Just a quick confirmation. When you say manual on the permission matrix manual implies go to the allow list to check versus allow or whatever it was called where you don't even need to check the allow list it's just they can do, they can do any creating schema. Right. Manual would just mean the request gets to the endorser and stops and then something needs to happen for it to go through. It could be updating the allow list and kicking off the process again if that specific entry can be approved or it could be a one off and admin goes to the API for the endorser and manually approve that transaction and move it forward. That would be basically a way to handle exceptions. But the problem with that is that implies that the areas endorser service will have a UI and I think that's probably a bad idea. You can call the API is there exposed right now just using postman or something else right like that that's really like a edge case scenario that could happen. It's there's no really way to prevent it, in my opinion, and depending on who's running the endorser service they may or may not they may decide to do it that way or not like that. But what would happen right now like right now, if there's nothing in place so if you send a send an endorsement request to the endorser, the transaction would just either be approved automatically which is definitely what wouldn't not what we want, or sit there until an administrator goes to the API and calls the API for the agent to approve the endorsement request. What I'm suggesting is that that that hang option not be an option that basically the not be possible at all basically possible at all they'll either get accepted or rejected and and therefore either you know it's either if it's manual and it's on the list it would be accepted but if it's manual and not on the allow list it would get rejected and and it would be the responsibility of the caller to decide if they are what to do about retrying. Gotcha. Steven the system challenges in manual workflows, because then you end up having to pull the, pull the endorser service for exception right. Yes, yes, but the benefit of that is the endorser service is has no interface no user interface and no need to hang on to things otherwise you're basically just hung there. If you reject it at least you can have some. So, my thought is presumably the organization that knows how endorsement happens. You know how approval happens such that they get on the allow list so they could decide what their retry strategy would be. This this endorser service then won't have any API is to do manual processing that it does. That's why the manual step was set there. I just want to I just want to throw in my two bits I the manual the manual approval is already an existing workflow within the endorser service I think it should be left there and it should be left as an option simply because somebody. Somebody might decide to, you know, build out a UI around the endorser service and I don't think we want to stop them from being able to do that. The manual process in my opinion would be if you had a UI basically what would happen let's say somebody requested a endorsement of a particular schema. If you built in, you know, if you built a UI and notification system around that if you decided to, you would end up having notification that a request has come in that would be queued for a review that you could go in review the request review the schema and then, you know, approve that through UI. I don't think we want to, you know, preclude people from being able to, you know, do enhancements like that. This is Tim and yeah in Ontario that would break our complete automation if we didn't have that ability. So we use pipelines to approve. And the endorsers don't know anything about the dids really that much of what they do but they get requested by a ticket. And then they go in and they use pipelines to approve against the API is. Yeah, there's a chicken egg problem I think other way around in terms of process. I'm not so sure you can always pre configured the allow lists before the requests are made. I'm not so sure that's the right necessarily the right process it might be but I think this the reverse of having requests come in and then be approved makes a lot of sense and certain flows especially if you're using a ticketing system, or an enterprise request of a service to request approvals for things external to this. Anyway, that's the way we're doing it so yeah I just yeah breaking that that that pattern would break our entire deployment. So total now a total agreement but now I think it just means that there should be a fourth one, which is allow list. So that you get so that it can be that you get approval or rejection based on whether it's in the allow list or not. I think that's where auto comes in auto would just default to the allow list and then no process the rules there and then do the allow list says so that's what auto is to me. Oh, that's right auto meant. Yeah, whatever they want. So they would be endorsed if it came from a certain did then it would be endorsed and I think that is also another policy should that should be there so that's why I would say there should be a fourth one. Well that that that would be you would have auto at the did permission matrix and then you would have the did listed in the allow list for schemas with with name and version as wild cards and in the credential definition allow list with wild cards I mean, maybe I should try basically auto endorse anything. I mean running through an example here of how we're, how the things were were thought through or or not through thought to some extent to just try and clarify. One note is noted up here I kind of like skipped over it because I kind of assumed that I was known, keep in mind that there's flags that can be set at the agent level to fully automate certain types of actions as an example connections you might set the endorser to always accept connections from everybody but not process any request until further rules or input are are in place. Anyway, if you do just just run through an example that might help clarifying what I meant. Some tenant from a multi tenant service with the did you I whatever is asking to connect for the endorser. If these are the base URL the connection would happen automatically, but until something else is set in the permission matrix and allow list. No operations would be automatically endorsed. Somebody would go in the configure the permission matrix to include the did and set these flags, the way that they wanted so did public true means like these did will be able to request the endorser to publish the data to the ledger and endorser will accept the transaction and will do it. That's sort of like the only way to do it is based on what the presentation that's even gave before and explains and then based on these flags as Wade was explaining say like schema endorsement if these were set to deny the transaction request would be rejected. Clear clear and loud. If it is set to manual the transfer the transaction is not rejected or accepted it sits there and goes in a queue for an administrator or some kind of process and administrator could be a theoretically like an automated process to review it and act on it. If it is set to auto, then it would drill down and look into the allow list for the specific item. Let's say it is the schema and check if there is a did registered for that matches the one that is making the request. If the schema that is being requested endorsement for is in the allow list. And if the version for that schema isn't the allow list keep in mind that could be wildcard so in theory if I really wanted to have something super open. Don't know the reason why I could put wildcards in both columns. In that case, if the allow list has an auto flag, and there is a match in the allow in the allow list, then the operation is completed otherwise it would fall back on to the previous state sort of like hierarchically which is manual, and it would just like sit there and wait for somebody to to act on it. We could change the default behavior to be to deny it. That's something we can discuss based on or we could make it configurable but that's kind of like how the workflow would go through. I see Warren has his hand up. Yeah, another possible use case for this is something where let's say you're a software as a service operator, and you're running a multi tenant occupy on behalf of a whole bunch of other providers and verifiers, and you want to be able to have them be able to publish their, their schemas and their credits and the like without them having to be in a list but you're controlling access to the endorser through your, you know your network policies and whatever authentication mechanism. You don't necessarily want to be updating the endorser's lists to allow those those functions so this is creating an overhead for that kind of deployment if I understand this correctly. I mean, there would be a small overhead, because the list would have to be maintained, but again you could use wildcards for most of the well most the schemas and credential definition, the permission matrix would be set explicitly to sort of like there's a record that the agency or an endorsement company accepted to endorse transactions for that specific did and I believe that could also be automated I'll just give a big step forward tiny bit to explain that the idea, at least initially to make things simple and also tied into what we as we see gov think we might be using is to have these tables in the endorser service match one to one CSV files that can be maintained by the business user, rather than having a developer having to go in and and changing the database or having a specific UI, the CSV files can be stored somewhere in our case, it might be a get a repository as an example, and maintained via pull request that provides the benefit of being able to run this on the state at different moments in time and see the diffs when you when a request for update is being submitted, and then the endorser would just expose some API endpoints to load those files or it's going to take a week, and the load process would be a fairly simple, whatever you're giving me is the snapshot of what I'm going to be using there's not going to be update or merging of of records is going to be, I don't know I just pushing the credential definition law list. This is the new one everything that is there will be replaced and because it would be iterative that should not be a big problem in Yeah, two things I think warrants question answered actually by ready to talk to your screen what connections are allowed so connection is allowed from your multi tenant occupies, you could then say, the global auto endorse so only connections from here would be created but you auto endorse everything else I think that covers your case. You still might want the overhead of adding an addition just in case, you know, in a zero trust idea, you might want to use a little bit more but but that's a possibility. I cover it. I, and then back to, to my point after your description I still think the extra overhead of having the allow lists beyond the permission matrix is unnecessary if we add a fourth option of auto actually meaning auto everything for a given did versus directly allow list for a given did. So I think it would be worth having a fourth but I'm, you know, not a hill to die on but just that would be my thought is it's worth that fourth option. Just looking at the chapter meantime because I noticed there's a couple messages. I mentioned that while you're doing that that that is the model we're thinking of doing that Emiliano handed out which is that, since it's largely business users that are going to approve these will probably do something like use pull requests as the actual mechanism for use in GitHub, and then the pull request will in turn generate these allow lists, they'll be loaded into the endorser service and that's how they'll be maintained is more that way. And then my assumption would be we mostly use, you know, have rejection on the other side but but it's possible the other way that they just hang there. If I just don't know what would happen if they're not in the allow list. If they actually hang, hang there, or do we send back a rejection if they're not in the allow list and then assume that they'll retry after some time but but our something like GitHub is the actual human approval part, and this will be this service will all be just an automated process. These tied into the question in the chat from Colton about the manual step, like, basically his question like, if we have these automatic configuration, why do we need manual. And I think the series of one is just to provide flexibility, you may want to go a certain level of configuration and then just like keep track of who you're endorsing for and do everything manually or with another process that is not resulting into the endorser. The other one could be the series just described Steven where somebody from just going back to the multi tenant agency, multi tenant agency. It's allowed to connect connects with the endorser and submit an endorsement request before the permission matrix and the allow list and credential definition allow list are updated these could happen since the tenant might be generated and you may not know the did ahead of time, what would happen here is like, you might have the transactions just sit there in and wait for manual approval with the API, approve those manually and then update the permission matrix and allow list to match what you just did, you know, in order to like, not have them have to retry that could be an option. Oh, I must have then misinterpreted the question sorry Colton. But yeah the overall idea is to get something that is like flexible enough to cater to most not all use cases with some degree of configuration. What are these is right or not I think this is to be debated and decided. Another question I had. Is it. Do we think it's necessary that in addition to my schema and version that the endorser service actually check that the attributes in the list are the same as what was approved. So my thought there was, we could add to the schema allow list and extra field that says here's a, here's a CSV list of the attributes and then that the endorser service could actually check that the the writer is adhering not only to the name and version but also the actual attributes. Again, that might be going too far but we could always leave it as an open option in the future. Yeah, I honestly had not thought about that. It could be something that we could potentially add as a new column and have wildcards. I'm wondering how complicated it might become. If I'm, if I'm not wrong, I've heard some something about schemas becoming a little more descriptive than they are right now than just a list of attributes and at that point. If we're just like shooting ourselves in the in the foot by adding too much granularity but I need to think about it a little bit. That's a good point. And then the other point I was going to mention about the you get hub is one of the other reasons for using get hub as well as it being relatively easy for anyone to use for for this type of approval process, but we could also use it to generate a static human consumable human friendly website that says here are all the schemas that exist in our ecosystem and here are all the and the credentials they issue that exist in our ecosystem so that we not only provide fodder for the allow lists but we also put out a human thing that says oh the person potential is this, you know, is has a human description to it and so on. One thing that is missing from this list. And I was forgetting there's a longer thread down here you guys can go in and check out separately is whether we want to get the granular control down to the revocation registry and revocation registry entry as well. Or do you want to set it explicitly what what's going to happen. I personally had don't have previous 100 what 100 and clear on what should be allowed or not allowed or which do but just mentioning that there's that possible that that level granularity as well that is being discussed. That's the link to the schema for verification. Yeah, this is talking to the, what Stephen was talking about but adding the attributes and stuff like that. I just wanted to mention to the group. One of the things that I was thinking about as far as the allow lists and permission matrix goes is that it should be completely explicit as to what's going on rather than leaving things implicitly working on on something so in the comments. I'm really a proponent of, of having the reg red, red, red, red def and entries being included in the allow list in the permissions matrix as far as how those are to be processed as well. It's simply because if they're not there and you don't explicitly define what they are then what ends up happening in the endorser services you end up coding, hard coding business logic around how to deal with those two objects based on what you're doing with either the schema or the more specifically the credential definition associated to those to those objects. So that whatever you code is going to be one interpretation of what should actually be happening with those objects where, and that's not going to work for all situations. If it's actually explicitly defined in the permissions matrix then you can let whoever is implementing this decide how they want to deal with those objects. It's down all the way to the credential definition list or right because each credential definition is going to have their own revered right but not that that you can imply safely, because, because of there is that one to one between the red forever and the red, the red and the revered entries and you're going to have, you know, it's, it's a one to many for the deaths and the entries but that that you can, you know, imply not imply but you know figure out. What I meant is like, you know, in a situation like this one where the say that the same did with two credit deaths. This is not the case but whatever. The same did with two credits if we only have flags at the top here at the top level of the permission matrix then I wouldn't whether this is desirable or not. I don't know, but like we wouldn't be able to say, Oh, for this first credit death, don't allow more revocation registry entries to be published but still allow it for the second one. That's what I was going with. Yeah, okay, I get where you're going with that. We're getting to the point where we seem to be wanting to like do a very like point to point granular control and at that point we would need it at this level. Yeah, but I mean it there might be a case where, you know, somebody decides okay we're going to, you know, we're not going to let this particular issue or, you know, issue any more credentials against, you know, any more credentials against this particular schema. And the only way you can really do that is to, you know, stop them from creating red red definitions, you know, additional revered definitions. I see Colton Colton's comments in the chat. Yeah, the wild card could be used at this level, similar to what was envisioned above, because at that point you have the extra two columns here for the revered and revered entry. And you could just have it populated by default with wild cards. To me, there's a one to many credential definition to revered definition and one to many revered definition to entries so that if you have permission to for writing a correct F it implies you have permission to write any revered credentials associated. And if you ever wanted to cut off somebody from doing updates to, you know, adding more definitions for updating the state you just remove their allow list entry for the cred def, and that would be good enough. Just because they're, they're all linked together. And so that would give you the control that you're looking for Wade but Yeah, and that's that's I think that's where we also differ on, you know, a little bit on an opinion with that, like, I think once something's in the allow list. I don't think it should be removed to indicate that it's no longer allowed. And that causes operational confusion later on because you end up going okay well, you know, this person is, you know, this, this credential definition is not in this list yet it's on the red, you know, on the on the ledger and there's been an issue against it. And then you have to go back in the history of the, you know, of the allow list to figure out okay yeah, we did, you know, we were endorsing this at one point in time and it disappeared at this other time, where if it's explicitly denied from the permissions and left in the allow list, it, it is very clear from at a glance that, you know, we no longer endorse this, you know, this credential definition. And then the only thing you need to do is go back in the history and go okay well when did we make that decision. I think that's getting pretty subtle. Yeah, one thing to say is like if we add the extra controls at this level, either pattern would work because you could leave leave the record and kind of change the permissions or deleted completely and the results should be the same. But either way you have to change the record. You have to change something. Yes. Yeah, something needs to change for sure. All right. Well, that was all I'll stop hearing a lot. Definitely. So we're going to start implementing something along this at some point, and so we'll finalize what what we plan to implement welcome input from anyone based on these questions obviously we're, we're still debating it. I'm hoping to have that and and if any others want to use this. Let us know what your thoughts are and how you would like to see it done because we'll see if we can build that in. And with that we ran out of time so there won't be any other topics and Sam will be back next week so it'll all be better. Thanks all. Thanks everyone.