Stephen Curran: Welcome to the July 2620 23 years. Working group. Call
Stephen Curran: a few things topics on the agenda marketing Update endorser service and Rfc, pull request, and notably the one involving community ported updates around
Stephen Curran: unqualified dids.
Stephen Curran: we are recording. So we'll be posting a recording afterwards reminder. This is a Linux Foundation Hyper Ledger Foundation meeting. So the Linux Foundation Co. any trust policy is in effect.
Stephen Curran: as is the Hyper Ledger code of conduct.
Stephen Curran: Anyone new to the meeting that would like to introduce themselves, say I, or talk about what they're doing in the community.
Stephen Curran: Feel free to do so now, or if anyone has any announcements, please grab the mic
Stephen Curran: any topics to add to the agenda.
Stephen Curran: All right.
Stephen Curran: I'll start with release status updates, notably. release 0 9 0 of acupy has been released with the new credits implementation of it on credit. So the removal of the dependency and a series of performance improvements and fixes
Stephen Curran: in the Cl signatures implementation. So for a non-cred. So that's in place, and the release was completed earlier this week. I actually haven't sent out the full announcement yet
Stephen Curran: is on my list for today to let everyone in the community know anyone else have any announcements from the various projects
Warren Gallagher: Steven. I was at the Afgh call last week, and had shared the information from this call for previously about wanting to deprecate
Warren Gallagher: did the Indie SDK and so there was a fair amount of discussion about that, and Timo was to get in touch with you, to make sure that
Warren Gallagher: all the he he understood everything that was going to need to happen, and everybody was in sync.
Stephen Curran: Okay.
Stephen Curran: I have not yet heard from him, but hopefully, will I send him a few notes this morning about other upgrades so hopefully that'll come out as well.
Stephen Curran: Thank you for that.
Stephen Curran: And we did meet with the Aries Vcx crew, who are, I see, on the call today as well. And they're
Stephen Curran: doing their work on that. And wanted some other updates and information about using in particular, the and on credits rust implementation. So
Stephen Curran: that, too, is moving forward to the
Stephen Curran: okay.
Stephen Curran: let's get into our main topics. Helen, I see you are here, and Alex as well. But can you talk to us about the marketing update? Or do you want to share?
Helen Garneau: nothing to share today? but yeah, happy to give an update We met yesterday with the Aries marketing working group and had, a few folks join us, which is great to have further feedback. on the results of the the survey that we had presented. at the last meeting here. that Alex presented and so got got some really great feedback from others in the community who had
Helen Garneau: just some the help rounded out that the the survey results, which is great. So our next step is that we've identified is to now reach out to the Hyper Ledger Foundation staff and talk with them about updating the the website. they're in the process of updating the the entire hyper ledger website. So we're we're trying to figure out how to get in there
Helen Garneau: 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 the layout. kind of the prescribed layout that is already there for projects, and the wiki as well. So a lot of the conversation yesterday was talking about
Helen Garneau: 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 what the say business decision maker needs to see wants to see. We want them to see, 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
Helen Garneau: of what we're talking about and 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 Aries. So
Helen Garneau: stay tuned for for those updates. between now, and probably our next meeting.
Stephen Curran: Cool.
Stephen Curran: we're having an internal workshop at BC, Gov. Helen, that. We hope it will be a
Stephen Curran: 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, but also will apply outside and so make it that that an initial client much much easier than it's been in the past.
Helen Garneau: That sounds awesome. Yeah, I know a lot of organizations are really trying to correct that net in terms of trying to.
Helen Garneau: Yeah, it just increase adoption, reduce time to adoption, etc. we at a DC just put out a a short kind of beginner's guide yesterday. that we're circulating. Yeah, that's more more geared towards the business audience, really explaining what?
Helen Garneau: 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 I I'm happy to post that somewhere. If if folks are interested
Warren Gallagher: I would be interested in that as well.
Helen Garneau: Oh, cool. Maybe I'll just put it on the discord. A a link or something so cool. Okay.
Stephen Curran: 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, and one problems on a Mac. so we do have to figure out how to deal with that.
Stephen Curran: 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
Stephen Curran: somebody is trying these on a on a plane, M. One Mac, and seeing how they go and cause that's super frustrating when you're just trying to try out the tools. And even the Demos don't work because of of issues like that.
Stephen Curran: Okay?
Helen Garneau: Oh, and just one last thing is that our next Hyper Ledger Ares marketing committee works meeting is. It's last Tuesday, 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 happen from folks that aren't necessarily in in the marketing realm. But
Helen Garneau: 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 in August. So I'll try to get that on your calendars.
Stephen Curran: one of the thing to point out to everyone is that I believe Hyper Ledger is said quarter-three is identity
Stephen Curran: themed. So basically, anyone that wants to, you know, do some promotion, or 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
Stephen Curran: and and we encourage that. So definitely, keep that in mind.
Helen Garneau: 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 been. 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.
Stephen Curran: Awesome. Excellent.
Helen Garneau: No problem.
Stephen Curran: Okay. Aries in Dorser service.
Stephen Curran: we're doing some work in BC, go. So I we thought we would
Stephen Curran: share this presentation and sort of set the seat and then talk about what we're doing. So Aries endorse our service for those not aware areas in Dorset service. is a
Stephen Curran: Aries repo that contains a pre-configured version of occupy
Stephen Curran: to act as an endorser. So the idea there is that in your own enterprise and your own environment you can spin up and Aries endorse or service
Stephen Curran: and then point your Aries agents to use that when necessary.
Stephen Curran: so this this presentation is about going beyond rejecting or accepting everything which is where we're at today with the areas endorse or service. So a reminder of what the Aries endorse or services originally implemented to support the Hyper Ledger Indian Dorser model. So on in the
Stephen Curran: an endorser is allowed. An endorser is a role.
Stephen Curran: that is given to it did, and a an endorser is allowed to write transactions and allow to endorse transactions for others. So basically the adores are uses there did. And verification key from there did on the indie network when writing transactions to the network for themselves.
Stephen Curran: but they are also use that to endorse transactions for others. And so the common pattern is for an organization to have a single endorser, and for any other
Stephen Curran: services within the enterprise. to not be an endorser, but rather be an author.
Stephen Curran: an author is not allowed to write transactions unless they are endorsed means signed by an endorseer. So basically, all of the other issuers within an an entity, would send a note to an endorseer, saying, Hey, here's this transaction I want to write. Can you endorse it for me? The endorser signs it.
Stephen Curran: and either
Stephen Curran: writes it. The endorser, you know, submits the transaction for writing, or sends it back to the author, and the author sort of makes 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 is is able to do so.
Stephen Curran: And then on a public indie ledgers. Endorsers are responsible for for paying a try paying for a transaction that they write, and that they endorse.
Stephen Curran: So The ledger itself doesn't care what transactions they write as long as they're properly signed by the author.
Stephen Curran: and if necessary, and endorser and then that the endorser would then be charged for them. So
Stephen Curran: I would note that this model of having a central
Stephen Curran: endorsing
Stephen Curran: service within an enterprise may be useful on other verifiable data registry. So as we start to think about using other services the enterprise might have want to have control over who's allowed to write. So an example is in DC. Gov, we have a Central Digital Trust. And I think I've got that in here. Maybe I don't. I? I I think I've got it later. But basically, I'll I'll cover it briefly, in DC, Gov, we have a digital trust
Stephen Curran: group. And that digital trust group is charged with making sure that
Stephen Curran: other groups follow the
Stephen Curran: policies and regulations. for using for issuing credentials and for using common schemas and and doing things in a a collaborative way. So 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 PC, gum, are not
Stephen Curran: issuing credentials, for example, that they're not authorized to issue. They're not the actual authority over we don't want
Stephen Curran: rogue organizations. If you will. issuing credentials that they shouldn't be issuing on behalf of the Vc Gov.
Stephen Curran: okay.
Stephen Curran: so basically within occupy at least, and and certainly with the endorser service. there's 2 roles. The author role in the endorser role. the author simply has to know who is my endorser.
Stephen Curran: currently they can only have one reflecting that an author only writes to a single ledger. So we in BC got, for example, we write to multiple ledgers. There's an endorseer for each of those ledgers an author needs to know, hey? Which lens or do I write to? And therefore which endorse? Or do I use.
Stephen Curran: Basically, the A of the author is handed a
Stephen Curran: did for the endorser, and they can establish a connection with that endorser. And then and then send transactions to be endorsed. the endorser needs to know if it's endors or did
Stephen Curran: 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 endorse or sends, or a an author sends a request, should I endorse it
Stephen Curran: and
Stephen Curran: the endorser service doesn't have a controller
Stephen Curran: right now. So it isn't built in. You have to build your own it with the Aries endorse or 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 endorse or service that exists, either. Auto endorses everything because you've told it to, or rejects everything because there's no controller to override.
Stephen Curran: rejecting the requests.
Stephen Curran: There is a configuration on writing.
Stephen Curran: You know the it.
Stephen Curran: 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 indie the endorser must write the transaction to create. The authors did so. The author really has no role in writing the transaction that creates the authors did.
Stephen Curran: The author sends the did over, not the transactions, but rather that did in the bare key. And then the endorser writes the transaction and submits it to the ledger.
Stephen Curran: For all other transactions. The author wants to create, to create a schema, credit, death, revocation registries, and so on. The author must create the transaction. Send it over to the endorser. The endorseer may execute the signed transaction, or the endorser may pass it back
Stephen Curran: to the author to submit. So either of those work it doesn't really matter to Indie, who who submits it as long as the correct signatures are on the transaction. The author has to be the author, the and the endorse, or has to endorse it. So that's basically the roles and and functionality of the of of of the endorseer service.
Stephen Curran: so preliminary ideas we had for
Stephen Curran: for what? The
Stephen Curran: what a a finer grained
Stephen Curran: control, or might have a finer cru 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 endorseer, then that auto correct would work. The author could write
Stephen Curran: whatever it wanted, so a way we could enforce
Stephen Curran: control over the in the endorser would be to create some sort of allow list, a list of dids
Stephen Curran: 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
Stephen Curran: So they would submit a request, and then it would be held until it would either be rejected or right off, or held until there 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 and remove dids from it.
Stephen Curran: But that's hard to do. You know, if you're having a generic service, how do you create a a ui that will fit everyone's use? That's that's pretty tricky.
Stephen Curran: oops.
Stephen Curran: this touches back on the BC Gov requirements. But a little bit more we have. That's I mentioned the the digital identity and trust group approve rights to the ledger.
Stephen Curran: we we wanted. Vc, Gov wanted finer brain controls. They actually wanted permission, not over just whether a a an author is allowed to write transactions, but rather
Stephen Curran: every
Stephen Curran: 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 through. To look over that scheme or 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.
Stephen Curran: If if the schema should be one that already exists. The you know the the request to write a schema would be rejected.
Stephen Curran: similarly, you know, a 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.
Stephen Curran: Now that that creates a a a logistics problem, how do we implement such a thing
Stephen Curran: without that. And with that I'm going to turn it over to Emiliano Sunni, who is
Stephen Curran: working on ideas for
Stephen Curran: for implementing such a thing. So I'll stop sharing and pass it to you. A milliona
Emiliano Suñé: thanks even
Emiliano Suñé: I'll put a link in the chat in the meantime, because
Emiliano Suñé: what I'm gonna be sharing for the most part.
Emiliano Suñé: if I figure out how to share the screen, that would be great.
Emiliano Suñé: there is a button, I'll share screen it. You know, it's for me you're welcome.
Emiliano Suñé: all right. I think you can see my screen right?
Stephen Curran: Yeah.
Emiliano Suñé: So this is the an issue that I've logged.
Emiliano Suñé: and we've been having a conversation on in the here is in Dorset Service Repository in Github.
Emiliano Suñé: and the she describes
Emiliano Suñé: a little less in detail. but Steven, just exposed. So sort of like the requirements, we're looking at it implementing and
Emiliano Suñé: provides a suggestion or an initial starting point, and how to implement these access control, these
Emiliano Suñé: endorsement. more granular controls
Emiliano Suñé: and configurations. the idea
Emiliano Suñé: was to keep it
Emiliano Suñé: as simple as possible, at least for the first cut, as even mentioned. It's it's hard to come up with, like a
Emiliano Suñé: ux that works for everybody and especially if you, if you're looking at
Emiliano Suñé: at the Ui controls. So we
Emiliano Suñé: try to put together something that should work in most cases and should be extensible in the future. without
Emiliano Suñé: too many issues. I'll just kim
Emiliano Suñé: skip to the bottom the recommendation just to keep an overview, and then we can open the conversation. If you want.
Emiliano Suñé: The idea would be to have a few different levels of authorization. that are stored in the endorser service as a
Emiliano Suñé: permission matrix or allow list. So it would have at the very as an initial step, and allow list to
Emiliano Suñé: determine who is, in the first place allowed to
Emiliano Suñé: get a connection to the endorser, and even have the opportunity to request
Emiliano Suñé: any type of endorsement transaction. and that can be just like it.
Emiliano Suñé: Simple table that includes the did of the request, or or in case of multi tenant in this instances, and we're working quite a bit.
Emiliano Suñé: with multi tenants stack up. I in particular, with traction. We're trying to get that to be our default way to go to provision a new, a new agent for
Emiliano Suñé: a, a, a government business unit that requires one. So in that case, I I think we might just
Emiliano Suñé: want to match on the public URL for the agent. since it's gonna be the same for all of the tenants. and these will allow, will allow.
Emiliano Suñé: then, a lot. The the item is the allow list to establish a connection with the door, sir, nothing more.
Emiliano Suñé: The next step would be.
Emiliano Suñé: do you have a permission matrix that
Emiliano Suñé: finds each did to the operations that they can perform. they can public, they publish their own, did they public did on the ledger, they can publish schemas.
Emiliano Suñé: credit, and well publishing the did is only a true false flag.
Emiliano Suñé: Schemas and credits would have 3 different states that could be applied. These are reported up here that are auto manual and deny.
Emiliano Suñé: It comes from a suggestion from weight patterns. these are basically
Emiliano Suñé: the
Emiliano Suñé: what we'll do. Envision, seeing like the the 3 paths that could happen. if the request comes in. It could be automatically approved for a schema if more and more on that in a second. But
Emiliano Suñé: the endors it could work automatically on that request. It could require input from an administrator. This is what the that happens nowadays. we need to basically accept the the endorsement request via Api.
Emiliano Suñé: or we could add a deny in case I don't know the
Emiliano Suñé: that that particular author has been misbehaving, and the is not allowed to request endorsement anymore. And
Emiliano Suñé: this information matrix would be a top level
Emiliano Suñé: type of permission to explicitly set the
Emiliano Suñé: each did. It's allowed to do and how it everything is treated.
Emiliano Suñé: and there would be 2 additional allow lists.
Emiliano Suñé: depend on that. so there would be sort of like a a foreign key relationship on the Ds in these table
Emiliano Suñé: and these 2 tables.
Emiliano Suñé: one to allow that 1, one would be an allow list for schemas, and then
Emiliano Suñé: would specify schema, name and schema version that can be published. This goes back to what Stephen mentioned determine whether the author should be allowed to
Emiliano Suñé: publish that schema, or it would be better for them to reuse the schema that it's already published.
Emiliano Suñé: Some id documents might follow the
Emiliano Suñé: the pattern where a a higher or entity organization publishes the schema, and then.
Emiliano Suñé: in kind of as an example, it could be a Federal government
Emiliano Suñé: publishing like an Id. Documents Schema and the provincial governments having their own credential definition. as you can see. there's a possibility of adding wild cards, and
Emiliano Suñé: in case
Emiliano Suñé: it was determined that a specific schema name
Emiliano Suñé: is is okay, and for versions can be
Emiliano Suñé: update it automatically. And the same thing, so to speak, would happen for the credential definitions to tie any shorter scheme. I see, Steven, you have your hand up.
Stephen Curran: Yeah, just a quick confirmation. When you say manual on the permission matrix manual implies, go to the allow list to check versus
Stephen Curran: of 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.
Emiliano Suñé: Manual would just mean the like. The request gets to the endorse and stops, and then something needs to happen for it to go through
Emiliano Suñé: it could be updating the allow list and sort of kicking off the process. Again.
Emiliano Suñé: if
Emiliano Suñé: that specific entry can can be approved, or it could be a one off. An admin goes to the Api for the endorser, and manually approves that transaction and and moved it forward that that would be basically a way to handle exceptions. But the problem with that is that implies that the areas endorse or service will have a ui, and I think that's probably a bad idea
Emiliano Suñé: that you you you can call the Apis that are exposed right now, just, you know, using post one or something else right like that. That's really like a edge case scenario
Emiliano Suñé: could happen. It's it's there. There's no really way to prevent it, in in my opinion.
Emiliano Suñé: and depending on who's running the endorse or service. They may or may not, they may decide to to do it that way or not like. That's what would happen right now, like right now, if the
Emiliano Suñé: there's nothing in place. So if you sent to send a an endorsement request to the endorser, the transaction would just.
Emiliano Suñé: it will 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
Emiliano Suñé: calls the Api's for the agent to approve the endorsement request.
Stephen Curran: Okay? So what I'm suggesting is that that hang
Emiliano Suñé: option not be an option that basically they not be possible at all. They'll either get accepted or rejected. And
Stephen Curran: and and therefore either, you know, it's either if it's manual, and it's on the allow 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
Stephen Curran: retry
Emiliano Suñé: gotcha.
Kim Ebert: So Ste. You know, the the system challenges and manual workflows. because then you end up having to pull the all the endorser service to for exception. Right?
Stephen Curran: Yes.
Stephen Curran: yes, but the benefit of that is the endorser service is
Stephen Curran: It has no interface, no user interface, and no need to hang on to things. Otherwise you're you're basically just hung there.
Stephen Curran: if you reject it, at least you can have some.
Stephen Curran: So my thought is presumably the organization that the knows how endorsement happens.
Stephen Curran: you know how approval happens, such that they get on the allow list so they could decide what their retry strategy would be.
Kim Ebert: So there's
Kim Ebert: this, this, this endorser service, then, won't have any Apis to do manual processing that it does
Wade Barnes: it? It doesn't. But that that's why they what the the manual step was set there. Wait! Can I just want to throw in my 2 bits? I I the manual. The manual approval is already an existing workflow within the endorse of 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 endorse or service, and I don't think we want to stop them from being able to do that
Wade Barnes: 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.
Wade Barnes: if you built in, you know, if you built a a a Ui and notification system around that, if you decided to, you would end up having notification that a requests come in that would be queued for a for review that you could go in review the request, review the schema, and then, you know, a approved that through. Ui, I don't think we want to, you know, preclude people from being able to, you know. Do enhancements like that?
Tim Bloomfield: This is Tim, and yeah, in Ontario that would break our our complete automation if we didn't have that that ability. So we use pipelines to approve And the dorses don't know anything about the D's really not much. Anybody do, but they get request by a ticket.
Tim Bloomfield: and then they go in, and they have these pipelines to approve, you know, against the Apis.
Tim Bloomfield: and there's a chicken egg problem, I think, the other way around in terms of process. I'm not so sure you can always pre-configure the the allow lists before the requests are made. I'm not 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 to certain flows, especially if you're using a ticketing system or a a an enterprise request of sort of service. to request
Tim Bloomfield: approvals for things external to this, anyway, that's why we're doing it. So yeah, I I just I breaking that that that pattern will break our entire deployment.
Stephen Curran: so total now of total agreement. But now I think it just means that there should be a fourth one.
Stephen Curran: which is, allow list
Stephen Curran: so that you get so that
Wade Barnes: it it can be that you get approval or rejection based on whether it's in the allow list or not.
Stephen Curran: Okay. Auto meant whatever they want.
Wade Barnes: 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 what the did permission matrix. And then you would have the did listed in the allow list for schemas with
Wade Barnes: with name and version as wild cards, and in the credential definition, a long list at with wild cards all across. That would basically auto endorse anything
Stephen Curran: running through it. For an example here of how we're
Emiliano Suñé: how the things were were thought through or or not through.
Emiliano Suñé: but that's to some extent just to try and clarify. The one note is noted up here. I kind of like skipped
Emiliano Suñé: over it, because I kind of assumed that I was known. Keep in mind that there's plugs that can be set at the agent level to
Emiliano Suñé: fully automate certain types of actions as an example connections. You you might
Emiliano Suñé: set the endorser to always accept connections from everybody, but not process any request until further rules or input are are in place.
Emiliano Suñé: anyway, if we do.
Emiliano Suñé: just just to run through an example that might help clarifying what what I meant.
Emiliano Suñé: say, like
Emiliano Suñé: some a tenant from a multi-tenant service with the did ui whatever is asking to connect
Emiliano Suñé: for the endorser? If this is the base URL, the connection would happen automatically.
Emiliano Suñé: But until something else is set in the permission matrix and allow this, it no operations would be automatically endorsed.
Emiliano Suñé: Somebody would call in the in and configure the provision matrix to include
Emiliano Suñé: the the did and set
Emiliano Suñé: these flags the the way that they want it. So did pop. Public true means like these did will be able to request the endorser to publish the date to the ledger
Emiliano Suñé: and in Torso we'll accept the transaction, and we'll do it. That's
Emiliano Suñé: sort of like the only way to do it as the based on what it the presentation it's even gave
Emiliano Suñé: before explains. And then, based on these flags as weed was what was explaining, say, like the Schema endorsement. If these was set to deny the transaction request would be rejected
Emiliano Suñé: very clear and in and loud.
Emiliano Suñé: If it is set to manual, the trans. That the transaction is not rejected or accepted, it sits there and
Emiliano Suñé: goes in in a queue for an administrator or some kind of process. That means there could be a to it theoretically like in a autom automated process to review it and act on it.
Emiliano Suñé: If it is set to auto, then it would drill down and look into the Allow list for the specific item. Let's say this is the schema and check. If there is a did registered.
Emiliano Suñé: or that matches the one that is making the request.
Emiliano Suñé: If the schema that is being requested, endorsement for is in the allow list.
Emiliano Suñé: and if the version for that schema isn't the allow list, keep in mind, it could be wild cards. So in theory, if I really wanted to have something super open.
Emiliano Suñé: don't know the reason why I could put the wild cards in both columns.
Emiliano Suñé: In that case, if the the Allow list has an auto plug
Emiliano Suñé: and there is a match in the allow in in the allow list, then the the operation is completed, otherwise it would fall back onto the previous state sort of like hierarchically, which is manual, and it would just like sit there and wait for somebody to
Emiliano Suñé: to act on it.
Emiliano Suñé: We could change the default behavior to be to deny it. That's
Emiliano Suñé: something we we can discuss based on, or we could make it configurable. But that's kind of like how the the workflow
Emiliano Suñé: would go through. I see Warren has his hand up.
Warren Gallagher: Yeah, another possible use case, for this is something where?
Warren Gallagher: let's say you're a
Warren Gallagher: a software as a service operator, and you're running a multi-tenant acupy
Warren Gallagher: on behalf of a whole bunch of other
Warren Gallagher: issuers and verifiers. and you want to be able to
Warren Gallagher: have them be able to publish their their schemas and their credit deaths, and the like
Warren Gallagher: without them having to be in a list. But you're controlling access
Warren Gallagher: to the endorser through your, you know your network policies and whatever authentication mechanism. And so you don't necessarily want to be updating the endorsers lists to allow those those functions. So
Warren Gallagher: this is creating an overhead for that kind of deployment. If I understand this correctly
Emiliano Suñé: I mean, there would be a a small overhead, because the list would have to be maintained. But again, you could use wild cards for most of the
Emiliano Suñé: well, most the the schema is in 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 indoors
Emiliano Suñé: transactions for that specific day, and I I believe that could also be automated. I'll just give a a
Emiliano Suñé: take step forward, tiny bit to explain that.
Emiliano Suñé: the idea, at least initially, to make things simple and also tied into what.
Emiliano Suñé: as we as we see golf, think we might be using is to have
Emiliano Suñé: these tables and
Emiliano Suñé: in the endorser service match one to one Csv files. It can be maintained by the business user, or rather than having a developer having to go in and
Emiliano Suñé: and and changing the database, or having a specific Ui. the Csv files can be stored
Emiliano Suñé: somewhere. In our case it might be a Github Repository as an example.
Emiliano Suñé: and maintained via pull request that provides the benefit of being able to run this on the State at different them
Emiliano Suñé: moments in time and see the diff when you, when a request for update is is being submitted.
Emiliano Suñé: and then it then also would just expose some
Emiliano Suñé: Api endpoints to load those files, so to speak.
Emiliano Suñé: and the load process would be a fairly simple.
Emiliano Suñé: Whatever you're giving me is the the snapshot of what I'm gonna be using. There's not going to be update or merging or off
Emiliano Suñé: off records. It's gonna be. I don't know. I just pushing the credential definition of law list.
Emiliano Suñé: This is the new one. Everything that is there will be replaced. And because it would be iterative that should not.
Emiliano Suñé: Yeah. A big problem in tearing. Steven.
Stephen Curran: Yeah, 2 things like it's cool question answered actually by ready to talk your screen. What? What connections are allowed? So connection is allowed from your multi 10. It occupides. You could then say, the global So only connections from here would be created. But you auto endorse everything else. I think that covers your case.
Stephen Curran: you still might want the overhead of of adding and it addition just in case
Stephen Curran: you know, a in a 0 trust idea. You might want to use a little bit more, but but that's a possibility. so I think that would cover it.
Stephen Curran: I 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 of auto actually needing auto, everything for a given dead
Stephen Curran: versus check. The allow list for a given did so. I think it would be worth having the fourth. But I, you know, not a hill to die on. But just that would be my thought is, it's worth that fourth option.
Emiliano Suñé: Just look at the chat in the meantime, because I notice there's a couple of messages.
Stephen Curran: Yeah, I'll mention that while you're doing that, that that is the model we're thinking of doing that Amiliano 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
Stephen Curran: mechanism for approving things 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.
Stephen Curran: and then
Stephen Curran: My assumption would be. We mostly use you know.
Stephen Curran: Ha! Have a rejection on the other side, but but it's possible, the other way, that that they just hang there. If I just don't know what would happen if they're not in the allow list. Do they actually hang
Stephen Curran: hang there? Or do we send back a rejection if they're not in the allow list, and 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.
Emiliano Suñé: I I think this tied into the question in the child from Colton about the the manual
Emiliano Suñé: step, like basically his question. Like, if we have this automatic configuration, why do we need manual? And I I think
Emiliano Suñé: just to reason. One is just to provide flexibility. You may want to go a certain level of configuration, and and then, just like.
Emiliano Suñé: keep track of who you're endorsing for and do everything manually, or with another process that is not
Emiliano Suñé: built in into the endorser. The other one could be to Syria just ascribed Steven, where somebody from just going back to the Multi Tenant Agency Multi Tenant Agency, it's allowed to connect
Emiliano Suñé: connects with the endorser and submits an endorsement request
Emiliano Suñé: before the permission matrix and the allow list and credential definition of law list are updated. These could happen since the tenant might be generated, and you may not know the the did ahead of time. What would happen here is like
Emiliano Suñé: might have the transactions. Just sit there in and wait for manual approval, for with the Api. approve those manually, and then update
Emiliano Suñé: the permission matrix and allow list to match
Emiliano Suñé: what you just did.
Emiliano Suñé: you know, in order to like, not have them
Emiliano Suñé: have to retry. That could be an option.
Emiliano Suñé: Oh, I must have then misinterpreted the question. Sorry?
Emiliano Suñé: Oh, yeah. The overall idea is to to get something that is like flexible enough to cater to. Most not all use cases with some degree of configuration. Yeah.
Emiliano Suñé: whether this is right or not, I think this is to be debated and decided.
Stephen Curran: to and the other question I had was, 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.
Stephen Curran: So my thought there was we could add to the scheme of Allow this an extra field that says, Here's a here's a A, a. Csv list of the attributes, and then the the that the endorseer service could actually check, that
Stephen Curran: the
Stephen Curran: the writer is adhering not only to the name and version, but also the actual attributes. again, that might be going too far, but
Stephen Curran: we could always leave it as an open option in the future.
Emiliano Suñé: Yeah, I I
Emiliano Suñé: I honestly I had not thought about that. It could be something that we could potentially add as a new column and have wild cards.
Emiliano Suñé: I'm I'm wondering how
Emiliano Suñé: complicated it might become. if I'm if I'm
Emiliano Suñé: not wrong. I've heard some something about schema is becoming a little more descriptive. Then they are right now, and just a list of attributes. And at that point.
Emiliano Suñé: if we just like shooting ourselves in the in the foot. adding too much granularity. But
Emiliano Suñé: I need to think about it a little bit. That's a good point.
Stephen Curran: And then the other point I was gonna
Stephen Curran: mentioned. about the You github is one of the other reasons. We're using Github 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
Stephen Curran: issuers 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 credential is this, you know it is, is, has a human description to it, and so on
Emiliano Suñé: one thing that is missing from this list.
Emiliano Suñé: and I was forgetting there's a a a longer thread down here. You guys can go in and and check out and then separately, is whether we want to get the granular control down to the Revocation Registry and Revocation registry entry as well.
Emiliano Suñé: or do you want to set it explicitly? What what's gonna happen?
Emiliano Suñé: The I, personally don't have tedious 100 would 100% clear on
Emiliano Suñé: what should be allowed or not allowed, or would to but
Emiliano Suñé: just mention that there's that possible, that that level very hard as well, that is being discussed.
Emiliano Suñé: What about a link to the the schema for verification.
Wade Barnes: Yeah, this is talking to the what Steven was talking about, but but adding the attributes and stuff like that.
Wade Barnes: I just wanted to mention to the group one of the things that I was thinking about, as as far as the allowless and permission matrix goes is that it should be completely explicit. as to what's going on rather than leaving things implicitly
Wade Barnes: working on on something. So
Wade Barnes: you'll see in the comments I'm I'm really a proponent of of having the red, red, red.
Wade Barnes: red, red deaf and entries being included in the allow list in the permissions matrix as far as how those are to be processed as well. 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.
Wade Barnes: around. How to deal with those 2 objects based on what you're doing with either the schema or the more specifically the credential definition associated to those to those objects.
Wade Barnes: that whatever you code is going to be. One interpretation of what should actually be happening with those objects where A and that's not going to work for all situations.
Wade Barnes: If it's actually explicitly defined in the permissions matrix, then you can let who whoever is implementing this decide how they want to deal with those objects
Emiliano Suñé: you would have to be reported down all the way to the credential definition list or right, because, like each credential definition, is going to have their own red fridge that that you can imply
Wade Barnes: safely because because of. There is that one to one between the red tr and the red, the red red deaf and the reference entries. I mean, you're gonna have, you know, it's it's a one to many for the deaths and the entries. But
Wade Barnes: that that you can.
Wade Barnes: you know. imply not imply. But
Wade Barnes: you know, figure out.
Emiliano Suñé: yeah, what what I meant is like in a situation like this one where the
Emiliano Suñé: say that it's
Emiliano Suñé: the same did with 2 credit deaths. this is not the case, but whatever
Emiliano Suñé: see the same with 2 credits, if we only have flags at the top here at a top level information matrix. Then
Emiliano Suñé: I wouldn't. Whether this is a desirable or not I don't know, but like we wouldn't be able to say, Oh, for this first credit
Emiliano Suñé: don't allow more revocation registry interest to be published, but still allow it for the second one. That's what I was going with. because then we're going. We're getting to the point where we we seem to be wanting to like. Do the very
Wade Barnes: like point to point granular control, and at that point we would need it at this level.
Wade Barnes: Credentials against, you know, an any more revocable credentials against this particular schema. And the only way you can really do that is to, you know, stop them from creating retro definitions, you know additional.
Emiliano Suñé: You see, Colton Colton's comment in the chat, yeah, I did the the wild card.
Emiliano Suñé: It'd be used at these level. similar to what was envisioned above, because at that point you have
Emiliano Suñé: the the extra 2 columns here for the red bridge and reverge entry, and you could just have it populated by default with file wild cards
Stephen Curran: to me. there's a one to many credential definition to refresh definition, and one too many leverage definition to entries, so that if you have permission to
Stephen Curran: for writing a correct app. It implies you have permission to write any reverent Reg. It's associated. And if you ever wanted to cut off somebody from doing updates to. you know, adding more
Stephen Curran: definitions for updating the state. You just remove their allow list entry for the credit, and that would be good enough just because
Wade Barnes: they're they're all linked together. And so that would give you the control that you're looking for. Wait. But yeah, and that's that's I think that's where we also differ on on, you know, a a little bit on a an opinion with that like, I think once something's in the allow list.
Wade Barnes: I don't think it should be removed to indicate that it's no longer allowed it. That causes operational confusion later on, because you end up going. Okay? Well, you know, this person is, you know.
Wade Barnes: this.
Wade Barnes: 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 stuff issued against it. And then you have to go back in the history of the you know of the allowance to figure out. Okay, yeah, we did.
Wade Barnes: You know, we were endorsing this at 1 point in time, and it it disappeared at this other time, where, if it's explicitly denied
Wade Barnes: from the permissions matrix and left in the Allow list it. It is very clear from at a glance that you know
Wade Barnes: 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.
Stephen Curran: I think that's getting pretty subtle. I don't know if it that
Emiliano Suñé: you know. W. 1 one thing to say is like, if we add the extra control at this level. Either pattern would work because you could leave, leave the the record and and kind of change the permissions or delete it completely, and the results should be the same.
Emiliano Suñé: But either way you have to change the record. You you have to change something. Yes.
Emiliano Suñé: something needs to change, for sure.
Stephen Curran: All right. Well, that was all. I'll stop sharing
Stephen Curran: definitely. So we're gonna 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. open to have that. And and if any others want to use this
Stephen Curran: 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.
Stephen Curran: And with that we were right out of time, so there won't be any other topics.
Stephen Curran: and Sam will be back next week, so it'll all be better.
Stephen Curran: Thanks all
Emiliano Suñé: thanks. Everyone.