Ramesh which was a bit busy these days coming back and
so we
were doing some internal reviews on this point if you plan to the it being blocked stitches, so I will present this because violet cannot attend today. Okay, so we'll review and prepare something just ever, like four slides to share with you what we're working on.
Okay, great.
Okay. Yeah, and by the way, if I if I can escape before the end of the first hour should be nice.
Okay. No problem. Okay, great. Thanks.
Yeah, and what about you, Mike, how's it going? Oh, progress you made on the the use case and demo?
Yeah, yeah. So that's, that's exciting. I feel like we're getting closer to having a real, you know, demo that we can use and showcase and there'll also be a good good excuse for all of us to, you know, start to prioritize maybe a few API's over others just so we have like a, you know, really comprehensive demo that's actually showing, you know, the different building blocks I think it's pretty exciting. So
yeah, so a good good let's say good reflection about the marketing side of it, you know, how to present it and so what is the goal with with your John's taking care of all the sets? That's interesting.
Yeah, well, pretty much super important. So, yeah, I'm cool. Yeah, everything's good, though. Otherwise, just really busy. Um, let's see who else is gonna join. I wonder. Let me just go into the other room and make sure people aren't going because I did that kind of. I use the Jitsi. Just kind of out of habit. Let me see if there's other people who are over there. Okay. Nope. It's just us.
Yeah, I tried to connect to
Taylor. Welcome.
Hey, guys. Hello, line. We're on Google meet today. Instead of just seeing what's happening.
Well, honey basically asked me to change all the meetings over because certain folks have trouble like, especially in the ITU joining via Jitsi I think I ain't had problems with it too. So corporate America is much more happy with Google meat. Or not corporate America but but corporate Europe and the NGOs. So sure, sure, sure. Okay, well, good. So um, yeah, so I guess we might as well get started. I don't want to hold the folks up. I know Jim has to leave in about an hour or so. Do you want to
I, yeah. I'm only good for an hour today as well, unfortunately.
Okay. Well, let's get started welcoming Mark. So, John, since you joined first, why don't you go first, you want to give us an update about ID progress. You're making?
Okay. Yeah, of course. My slides and do we wait for somebody else?
That's okay. I think we can start we got it. We got enough people.
So I've just put valuable
features in here that take some indication about what we are busy with at the moment. You should submit normally Caesar presentations, which is let's say because we use when shell was sort of this mature, mature the services. And so now I have the structures for you. Do you see Is it is it big enough?
Yeah, yeah, it's fine. I can see. Yeah. Okay.
So conky. So first thing is that we have worked on capabilities. And so it's under review internally, just to figure out what are the different capabilities you may have to Tecate? According to what you go
Alexander, can you join via Google meat? I apologize. We moved over to Google meat ethics training to our okay. It should be in your getting advice, let me know. So it's not as your end goal
is to see whether we can reach some kind of AI developers that can fit everything. So it can adapt to any kind of context
of the customer.
We have one concerns the API's requirements we're starting to work on some let's say a level requirements regarding the API's but the behavior that is expected on from the building block on these API's also sometimes we are settling for a month I will come back from this. And so now we foresee there is a need to work a bit on our glossary on the wording. So we're going to touch that in the coming days in a little bit clearer what is authentication, verification, registration, identification and so on. And to share this with you outside of first thing we decided to do is to change the name of the building block because we want to remove the latest ambiguity leaping which is authentication and verification. And so we go for verification, identity verification and so will our building blocks with the identity and verification by ID verification, we hold on to a person identity and so we try to verify according to what the person bring, and also what we have already on the system side. So it's very to a person identity. And when we say authentication is more how you verify your credential as a user of an information system. Okay, so one is more related to your area. And the other one is technical. Okay, and so we also understand constipation. So things have got stuck as users and also managing people's whichever needed so we go in with the wording. After by working on the, let's say on the requirement and on the API is we have realized that there is an element which is really important in the identity, which is the ID fish, Financial Management and Insurance. It's completely parts of the ID building block. Okay, because that's what's come from from this building block parties issue has been blocked, but also what is used when you want to authenticate. So we want to have a separate set focus on this server in order to define what is this sub module and also what does the API he has to present always interacting also with
with our vision book.
We have started to talk with the consent workgroup. So we had the first interaction. So we're going to go and the idea is to start to build some alignment with them. In terms of use case in terms of affording a low low, high end and it is also to to see whether we have any overlap is in let's say misunderstandings, we try to start work on this because that's really part of of what we do when you register somebody you need to get some consent about what you're going to do with the data. And the same when you are authenticating people you need also some kind of consent. And finally on the first use case and demonstration so a lot of building block is going to be used as part of the demo as part of the first reference implementation of the web stack. to authenticate the model. We are going to work on matching coprolalia API's we propose with a use case that has been prepared by Max as part of the mother and childcare scenario that focus teachers if you have any question you can ask so I'm going a bit on some details. On the sorry on the what the requirements from going under visited to interrupt ask a question. So under requirements we have three big domain service API requirements sets that are related to the API in the behavior of the component subcomponents of service of the ID building blocks so in terms of our government verification, to ensure management and notification which are our big four API's external API's, after we have a set of requirements also for functional purpose Identity Management identifiers management and identity uniqueness sets, so these are requirements that will be either mandatory iser or recommended either specific Okay, we have said these three category, it may evolve, but the idea is to say, the things that you must do for sure if you are providing a building block the things that we will come on you to manage this way. And there are things that will be specific to the context some time you will ask for offline for example, some time you will ask for online so this is specific. And finally, we will cover also some transversal requirements for now, we have two domains privacy protection auditability MommyCon. If you have any suggestion here in this meeting of domain we should cover all use case we should cover and identity. We will come to purpose unless we'll go on with this and incorporate this for you. We said by middle of November
this is this is fine. Thank you to feedback to comment. Well three actually the first one is that indeed. We are happy to follow your steps. So we have perhaps a week or two behind your schedule. So good to take the model from from your work and yes to all the others. We have started to coordinate our activities Second. Have you considered the what we call delegation of certain representation rights? So in the in the use case where we have mother and chunk, we, we found that also in terms of consent, actually, well, mother and child it's sometimes obvious that that child does approve her or his mother to act on behalf of that person. But also we are working on on use cases whereby this kind of delegation might be you know, might have different manifestations, but in terms of identity, how is it part of your work? Or where does one know and where is being kept? The link between different
delegation is really a business thing. For example, a kid is maybe represented by his parents, or in various domain facts, the same and so in identity and verification bridging works. What we cover is how you identify a different person. After showing the domain of social social registry for example, you may say, I can authenticate my family being myself or quiz on my kid being myself. So probably, this system this bridging broker system will have to determine we can authenticate for the family and then ask not at fault education. But this complexity of delegation is not normally the purpose of identity.
Now I fully understand the only the only moment whereby and this comes from the experience here here in Estonia is that if there is a kind of default delegation say exactly mother child relationship, which is in a way even, you know, actually, I don't know maybe maybe, inbound or you know, whether this is part of the identity and all these kinds of heart relationship. And then as a default, certain procedures are allowed but I take a note that actually it is a functional approaches feature rather than characteristics of an identity present
in facts, yes. So I acknowledge completely your your use case and it makes sense everywhere. In fact, whenever you have kids, you will have to wait for them. But they see this really as a as a business thing. And finally, when you want to get as a parent, you are guaranteed to manage the health of our kids or the education of our kids eyes. I see that in the reverse, but I think people open the description and see where finally that's too long. Right.
But even if it's a functional, then it is handled by you. Or where is this
panel? I think that's handled by the M module Identity and Access Model Management module of security, I believe. Yeah, that's what we're talking about when we're talking about a functional identity. Right. And then also, I mean, it might just be the business logic, right? Of the MCS, a mother, the healthcare database that that provides that sort of ability I mean, in my view, ID and verification is just about identifying the mother is who they say they are, or the child is who they say they are. And then from there, it's you know, delegating responsibilities and things like that are going to need to be handled by business logic or you know, by the Identity and Access Management module is it only you know, possibly been dealt
with which is true is what true what you need to you need to know your families. So this is what you have affected us all the registries that are linked to Social Security's on time, or even linked to civil registration, which is providing the link between the mother and the child at the beginning. So there is a there is a complete set of registry and application and system we need to have a look.
Right? I mean, that's a good point, right? Depending on how, you know, it could be within the scope of id given that it has a civil registry component, right. So it might make sense for that Civil Registry component to have the ability to link family members. Or even to you know, describe the relationship like this is a parent and this is a child, you know, so that at least when you're you know, querying like the you know, you when, when a registry or another tool is asking about a parent, then you can say, Oh, well, yes, this is the parent they are who they say they are, and by the way, here are pointers to their children, right. But that's still not complete, because depending on the rules and the policy, the children might be over 18 Right. So that's still not going to determine whether or not you can delegate responsibility or not. That might come into a consent management, right.
So if I if I may respond here. So again, this is exemplifies the discussions and I don't expect that we will resolve it here today. But as we as we have defined the consent is the decision which assumes that there is an option to opt in or opt out. And acknowledgement acknowledgments of any service provider to do certain things as a requirement to use any of those services, in our understanding is not a consultant and it can and maybe even should be managed slightly differently. And this mother child case is a perfect example of that. So there is there is no consenting ongoing, this is usually legally you know, predefined and then it has to be codified somewhere and then the all the other really need to know where to go for that information. And you know later on yada yada so again for us it's it's a we were as Aflac it would be interesting and important to know where this is handled, but by all means, we were brightpoint we will at some point come to a conclusion. It's it requires some something it's
good to have a look I think we should have a broker also with you and Hamish because we had an internal discussion with I mentioned but the claim and when you have a claim you are always let's say a requester says and subject and so it's gonna happen that you can separate Wisconsin by your claim, like the child and who is doing the claim, which is a person your ticket. So we need to dig into this to see how does it apply generally to identity?
Yes, it's great and let's try to do it. Within a you know, just focusing in on one of these use cases if we can, yeah, okay. Well, good. So um, great. So that's a great update. Is there something else you want to cover? Jelmer? No,
just just two things to say just that so stayed with us last time. So just show we are on track for of oil in what we said. So finalizing our specification reviewing internally financing scalability and getting getting ready for for delivering an external internal review by November, mid November. And also the fact that we will come out South together with us together with interstate and gently from Singapore.
Okay, wonderful. Great. Okay, great progress. Let's see.
Before we move on, yeah. I think on the from the previous discussion, verification and consent are two separate steps, right, you might want to verify before consenting. So, and concern and in the context of consent are we considering consent is a human consent?
Well,
I sense that it's not just some system evaluating some rule and saying okay, and
triggering, yes, yes, yes. Yeah. In that terms, yeah. This is part of the definition that that if there is a rule engine that you know, verifies certain procedures that is not considered a concept per se. However, if that rule is based on some earlier interaction with a a person, identify the person that has been given right, certain actions take place, then this link can be get can be created. But for us, we take wait a week or two. So we will I think we have carved out at least our initial definition and also developed use cases around that. But it's more converging towards Ramkumar what you described as a human consent.
Yeah, and so therefore, verification may be just a utility to help that consenting. Okay, yeah.
Yeah, I mean, you can really only have to your point Ramkumar, you can really only have an effective consent. If you've authenticated the person who's making the consent. Otherwise, it's like, how do you really know? Right? So that's a good point. Okay, great. So um, let's see who wants to go next. Give an update. Taylor, do you want to go? I know you're a bit short on time today.
Yeah, happy to. So you're just reorganizing my microphone. Can you guys hear me okay.
Yes.
So we met up yesterday, and have continued to make some progress on the stack itself. This last week was all about basically getting our discussions, getting our discussions into writing. So we're still very much in drawing out that table of functional requirements, as they are the necessitated by the use cases and defining the service API's. And we've we've got a longer list going there, but it's very much still in like the generative phase rather than sort of the review and settling down phase. And there's still a number of open questions around around service API's. Big change that we're incorporating, as per Premkumar recommendation is to sort of highlight a table of user journeys and use cases and requirements for the workflow block in those different use cases. And we've already found this sort of quite useful, because we're able to sort of focus our discussion of the functional requirements and the surface API's, on on really concrete steps in in the use cases. So that's sort of the big change, but it's just an another week of of progress in the functional requirements and the service API's. And that work is now pretty much documented in in the BB spec rather than in our running
great if you want to post a link to the BB spec.
Yeah, absolutely.
And also, if you could, I think, once again, if you could post a link to your presentations in the chat, if any your most recent presentation, honey has been asking about those from the previous meeting. So if you could post it in the chat as well, all of you that would really help out because we have to go update the the discourse page to make sure that the latest stuff is up there. Okay, awesome. So or I can I can probably find it a if that's easier for you. It's just those same workflow building blocks specification, right. Okay, and then Id if you don't mind posting your document as well just so other folks can look at it. That'd be great. Okay, so who wants to go next? I mean, do you want to give us an update on consent management?
Sure thing so we are committed to finalize the first round of use cases and capabilities by the end of this week. So actually, I'm in the middle of a writer for for a very good workshop we had two days ago. And that also gave us I can perhaps, you know, just for your information, maybe share the slide that max you mentioned would be could be helpful for others. So, we have we have the first draft definition of corporate consent management is also that it has see four distinct components in let's say two or three categories, if you will. So there is this individual and then there is somebody who processes the data. And then there is an outside either auditor or a facilitating service or who verifies that the consent is informed in a and then that the organizations who are providing information based on that consent are actually acting based on that consent. And we have, I believe, went through our stop now here. We have around 10 ish. Candidates for use cases as I said, I'm writing those up and identity building block register building block. From Kumar you may help me there. So we have identified the first building blocks that we would like to have a healthy engagement with the workforce really focus well yeah, identity work for when register is building block. The ones that we feel that exactly for the for the same goal in mind. John mentioned is to try to understand how do these interact with each other to avoid unnecessary redundancies
and have
good understanding of if there is a handshake ran over in terms of processes. So how that's going to be handled.
So one input there for discretion in this team is is coming up with it's been it's coming up with content management as in in this use case for the patient to say okay, these records are correct, whatever information captured is correct. Before that is actually submitted to the system. So is that an if that is a consent process, then will it also mean that it will invoke verification with the ID system at that point? This is an open question because if the patient is consulting, it should be known that the patient is the real person who is consenting
Yes, this is this is an example of those seemingly tiny but eventually very important nuances that we need to have a good understanding of how is this going to be handled? So? I wouldn't give a definitive answer right now here how we tend to handle that first because there's discussion group and then also, we agreed to have a separate meeting with with ID and verification group haven't fixed that date though yet. John, but we'll find it early next week, perhaps.
I mean, would it be helpful to have a very short call with workflow as well just by all means? Yeah. Okay. So maybe I'll I'll shoot you an email right now. And we can just we can organize that the services API for workflow, which is, as you might imagine, very small and very generic. So I don't think it'll throw too many wrenches into the works but I'd love to just walk through it with you.
Yeah. So we will be in good shape with with meaningful discussions with with many of the building blocks since, as I think you also mentioned that we are we are now writing down our thoughts in a coherent way so that it's easier for others to understand our thinking, and then also reflect and give guidance for further
discussions.
Okay, great. And I'll just point out we're all here. So we might as well make use of this meeting, if we can. So let's try to get through the stand up quickly so we can get dive into the use cases. Because we might be able to pin down some of the stuff today. Great, awesome. Okay, great. So um, who wants to go next? Ingmar, do you wanna give an update?
Or Aleksander?
Can you hear me now? Oh, yeah, I
can hear you knowing more. That's fine.
Okay, good. Well, basically, we finished the first version of the registries, digital registers building block. Everybody is welcome to give some comments or ideas if if something is not clear or needs to be added or whatnot. And I will keep on working on the registration building block definition. So other than that, no big news. I owe you technical documentation next. So about setting up the demo instance. So I'm going to send that soon as I have the last version, so
Okay, great. Perfect. So I'm just going to post a just so everybody has access. I'm going to post it in the chat so everybody can find digital registries. And please add comments. There so that we can get this out for review. Um, okay, great. So there's a link there, puts it in the chat. For everybody. Um, let's see. So, Alexander, do you want to give an update on your side?
Yes. Actually almost nothing changed from last week. And what I want to remind that we lost last time but we decided to find where publish subscribe could be used or or, or is used in the so our use cases or maybe some other places. So we need this to finalize our building block.
Absolutely. So um, we do have a meeting tomorrow with Christo, the CTO of the Estonian there's gonna be like kind of a mega pitch about all the ways this is being used in Estonian and could be used so hopefully that will resolve it. But definitely folks if you have concrete use cases where publish and subscribe is being used or needs to be used at scale and government, please let us know. Because we're trying to try to justify, you know, do we put this in for this version of information mediator do we defer it to a later version? Do we just put it in a separate, you know, work group? So um, yeah, so yeah, call for any sort of like, examples that you might have of publishing subscribe using government.
Did Are you guys still able to hear Max?
Oh, I was just I was just ranting away to myself. Sorry. Sorry.
No, we got we got the first part of that. You're saying that tomorrow's a meeting with Christo and sort of a pitch for all the benefits of pumps up
right. So it folks if you can if you have any concrete examples of pumps of use at scale and government please listen so okay. And maybe we can talk about that. I think that'd be because we need to decide are we going to include this in the current version of information mediator, defer it put in a different you know, workgroup? You know, what are we doing with this publish subscribe functionality. Okay, great.
Sure it May I May I ask a favor for that because I think I'm sadly not going to be able to join that meeting tomorrow. And maybe I maybe I should just send this like as a reply to your follow up note, Max for today's meeting, but the thing I'm I'm really interested in is I have no doubt that Christo and and others will will be able to sort of make the case for Pub Sub being an important part of a modern sort of, guff stack implementation. But what I'm really curious to hear their opinions on because they are also users of X road. And because the im spec is so heavily based on on X road as sort of a model as an architecture. What I'm most curious about for that meeting tomorrow is you know, whether they see sort of whether they see Pub Sub, as something that should be built on X Road, like should be almost an extension of X road, or whether it is sort of a separate thing that merely plays by the rules of X road. And I'd be really, really curious to hear about that specifically. Does that make sense as a question?
Yeah, I just, I think I just transcribe that so I'll make sure to find the answer that question.
Oh, that would be amazing. Yeah, amazing. Because I you know, he on the on the I am side, I think we're all sort of very much pro Pub Sub. Obviously there are security concerns being raised by other people. But the big if we get convinced that Pub Sub is something we want to include in the spec, and I think the immediate next question is like, is it its own building block or does it sit within I am slash when when sort of when it gets down to the practicalities, because I am, at least in the prototype will likely be extra. Is it an extension of extra code, or is it a separate piece of software?
Yep, that's a good question. So um, in my mind, it's probably both but I'm not the expert expert. So
yeah, totally. Like Christo and Alexandria, and all those guys who are talking about the pros and cons and that sort of stuff.
Perfect. Great, so I'll make sure to ask that question on your behalf. Okay. So and then. Anything else? Okay, I'm gonna post the link to the information mediated or spec so other folks can look at it and review it. Okay, um,
hello, Priya. Welcome. Don't Don't be afraid that there is quite a lot of changes.
Yeah, okay. That's fine. I mean, I you know, I apologize to put everybody on the spot here, but I think it's important that we all can look at each other specs and just kind of see where everyone is at. But yeah, 100% a lot of these specs are really early, you know, are in the middle of being overhauled, so please don't be too you know, harsh in your comments. Okay, or too critical. All right. So who wants to go next? VJ maybe, payments.
Yes. Hi, everyone. So I'll give a very brief update on the payments working group. So we're still working on the API specifications on our site. This is a section of the document. Most of the focus is now on. API's for the voucher management system, when provided by one of the working group members, and now we are working on the bug payments, API specifications. So we've had a number of meetings in the month of October, you know, with organizations like Mojo loop and also many firsts, and GSM as well. So now, we're waiting for these API's to come forward from these organizations over the next few weeks, to be able to complete this part of the world. So that's that's a very brief status on my side. And I think we had a question I don't know if I call it on or is but maybe I like to give the fruit on all I think is to maybe talk a bit about some of the issues that were raised. In the meeting we had on Tuesday. Which James and also with Oscar in many regarding the naming of the for the API's and flow diagrams are no good you.
Thanks PJ. I think actually Oscar is on the call. And he was yes.
Oscar? Yeah. Hi. Hi, Vijay.
Yes. Could you maybe raise this issue? Regarding the naming on the diagrams? Maybe we can discuss this together. With the Thanks.
Thanks, Vijay. Hi, everyone. So basically, we when we started developing the building block, we were building it based on the use case, which had the registration building block, talking to the payments building block. So in terms of the flow diagrams, we had developed them showing the big the, the registration building block as the calling building block. But then as we were going on okay, because some input from honor last week that maybe we should call them request, we should try to make it generic. But the challenge was we were we were feeling that it may dilute the use case that that it would be important to maybe at least have a specific use case with the registration building block and then maybe later on, think about how it could be abstracted into a more generic connection. So that was what had one comment.
Maybe this is useful because we do this last week as well. So I think the real trigger in that use case, we were just discussing whether the trigger there are two use cases at least one was when the for the for the monthly payment of the payroll based payments to the to the worker, the other one was basically payment token incentive patient. So this was a case of bulk payments, that was individual voucher payment and then there was also a payment scenario, which was a registration. So I'm assuming you're discussing about the P two g for registration in this case, right?
Because that's typically the
region of trigger for payment will come from different sources in the case of the payroll during registration registration matrix, so, so far from from the building block point of view payment building blocks, although for that use case it is good to map who is going to trigger me. It is not it is not necessary that the meeting with this guy must trigger. Right. So your API can be used by any authorized service consumer.
Yeah, I think that's right. I mean, remember these use cases are really just a focusing exercise to try to identify these interactions. I mean, they're not going to, you know, we appreciate you know, going off and generalizing it, but I think, you know, I think your instinct of sticking with the use cases for now is a good one. You know, we expect remember, I mean, remember, these API specs are going to change over time. They'll become more comprehensive over time as we add more use cases and get more feedback. So, um, yeah, I mean, I would, I would stick with it, but I think we're on Kumar's point is really good one. Try not to be too overly concerned with who is calling you but just really what information you need to get to satisfy that requirement. And then what information you need to give back and kind of what the internal requirements are for the building block to achieve that goal.
Okay. Know that.
Okay. Any anything else about payments?
No, I think that's Oh, yeah. There's one more question I think. I think we were saying for the time being, we focus on some of the use case that we have right now. And then there will be maybe some other at some other point, that would be like a version to where we would add new other new new use cases. I just, I was just wondering, in terms of timeline, when do you think that second version,
I have some input on that? For all the groups on the last week's was getting meeting. Once we finish the stand up, maybe I'll have to check with all of you on that. Give me a minute or two. Let us finish this stand up.
Okay. Okay, great. Let's let's go on my side.
Okay, cool. Yeah, I mean, I think in general, we're gonna be adding new use cases all the time but it's up to you to decide when you think the boat building block is autonomous and you know, comprehensive enough to call it a version one. You know, I mean, we can always add a version two and say like, these, these specific bits of functionality are going to go in version two, like you can call that now. Right. So I mean, that BTG payments, for example, Miko and version two. because not a lot of use cases are focusing in on that. Okay, so anybody have any other questions, comments, concerns about you know, pretty other groups. Great. Cool. So I think let's go ahead and dive into the use cases. So first of all,
I have Max Max. Yeah. Okay, sure. Okay, I just have one update. i Oh, yeah. Sorry. I guess that the use cases for we can discuss that also review it and clean it up, but to have posted in the Google Drive to one was the doctor's consultation use case. Another one was basically the payroll use case for the scheduler. And it's out there. Any review inputs are good, and if we can actually clean it up in this session, that will be very helpful.
Yeah, so can you post the links to that in the chat? Okay, that'd be really helpful. Okay, yeah. Sorry, I didn't mean to skip you. So, um, I guess, you know, architecture group. We're really busy reviewing specifications, trying to figure out help figure out how we're going to do sort of a formal technical review process, right, which is probably going to be done by other groups. And other stakeholders. And we're also really focused on how to get prototyping up and running, or sandbox environment up and running where we can we can do prototyping. So I'm gi Zed has been great in terms of stepping up and providing funding for that. So I now can go and purchase tooling and hosting on behalf of GM stack. So if there's anything that you need a you know, or that you feel would make your job more productive. Please let me know. So I've signed up for so far. I have a shared account for web sequence diagrams. So people can use the pro version of that. I've also signed up for a pro or not, you know the three person version of swagger hub, for example. So if there's any other tooling, you know, and also we have a DigitalOcean account, so we can do, you know, hosting and prototyping and things like that up there. So if there's anything else that you need that would help make your life easier, please let me know.
So next, this centralized version, especially the web sequence diagram was always asking for login. So is there a specific mail account that we can use now?
Yes, let me just post it in the chat. And then we can just share this around everybody
can use the same tool, the same account?
Yes. So let me just let me let me just post this
what they are,
yes. So I'm posting the account in the chat. So there is web sequence diagrams for you to use. If anybody would, like invites to swagger hub or anything else, just let me know.
And please, swag, a swagger call for me.
Okay. All right. Great.
Okay. Sorry, Mr. Ramkumar. You know, the link you just posted. We don't have access. If you could reverse access. That will be I mean, I requested the access of up
Sunday. Dr. Max, you had your permission, probably. I don't know. I'm able to access it. But should I give the permission or? Yeah,
I think so. I mean, we can sort that out later though. It's okay. Um, let's see. So yeah, I don't have access either. So I think you have to do it. Dr. Ramkumar? Yeah.
Okay, and how does it go and practically as give access or request to to
eat well, someone can request access, or you can just open it up and make it public. I think it's up near the top of the screen, I can show you in a minute.
Okay, go to the top and what to do.
Alright, so I'll just share my screen. So and this is a good excuse to kind of dive into the so up here. You can see this you know, status. I think here you can say like what folder it is. And up here where you hit share. So you can hit Share, and then you can say like, you want to share it with specific people, or you can get a link so I just have it so that anybody can edit. Right? That's the most least conservative anyone with a link can edit. So you send that link out and then anyone will be able to edit your document. Which is probably what you want. Yeah,
I mean, I'll make this drive with this folder itself editable. I can share the folder itself. Yeah, perfect.
Okay, great.
So and depending on how much depending on how much extra work you want to make for yourself, and or control, you want to cover the process. You also might if you if you make it anyone with a link can comment. They can still type in the document. It will just show up as a proposal. So you'll be able to see you know, what's been accepted by the group and then what is merely new text being proposed by outside member exactly up to you again, how you want to control that process.
Yeah, that's that's a really good point. I mean, I probably, you know, I'm kind of like, believe information should be free and open it up for edits, but then you end up with stuff like this, right? Whereas if you only had it open for comments, then this would have appeared in a comment that can be resolved.
Right, exactly. That would show up as like a bright pink,
green and then just consuming the link and paste it here.
Perfect. Yeah. So um, yeah, I mean, this one I mean, I feel like this one, it's okay. You know, because this is shared across groups, so anybody should be able to edit it really. But for your own personal specs, I'm with Taylor on this one. I would recommend that you just make it for comment only. Because this is even harder to clean up. I don't know exactly what to do. Like this guy's from the World Bank, like do I delete it? Right. Okay, so um, great. So anybody have any questions, comments, concerns about swagger hub? Let me just anyone else need a swagger hub?
Yeah, okay.
All right. Great. So, I will so Ramkumar and Alexander once I grew up. Okay, cool. A proposal. Yeah.
Max, could you create a group for all of us so when you just want to share your document?
Yeah, yeah, that's fine. Like a group like a Google group, or something? Yeah. Okay. Yeah, I'm okay, that sounds fine. I'll do that. And then I'll invite everybody in this meeting to it. And then, um, but for now, it's in the chat. So um, okay. And then I will provide you know, maybe I'll just add three more generic accounts. Well, now, let's do it the proper way. Okay, great. Excellent. Okay. So that's about it, in terms of housekeeping while it took a while. So maybe we should talk about
I guess, before we dive into this, I just had one input to the entire team. It's being now kind of review as to what the next steps will be because the first set of groups we are nearing the specifications and being able to kind of put it in open API. That's the assumption of all the all the first set of groups. So it's like, December 1 week. There is a plan to send these for external review with basically what they're calling technical review committee, which might consist of people from different documents and external people, but they are pretty much in the close circle of Gao stack. So in order to do that, was kind of figured out it might be better to have an internal review, internal peer review before that goes out to any external party. So the target is between now which is we are just entering normal in a couple of days, between now and end of November. Whatever the specifications of phase GenStat 1.0 of the phase one building blocks, anything that doesn't fall in because at one, zero, you can put it into the next phase document or in a separate document for the first phase needs to be reviewed and so the request for all the building block phase please identify new newer circles here from you know, who would be willing to review this and give their honest inputs, comments and feedback that you can absorb into it because our group has been inside of the box and many some outside the box inputs. So it may not be only people who are inside the AppStack, building block groups, etc. Right now, it might be but if you have no other parties like you, you can review with external parties and get the inputs number is the frame set up for that. So that might be the end of November we have the specs ready to deal with for external review. So maybe first week of December 30 Collect all the feedback from all these internal reviews and each building block group that updates it. First week it is submitted for external review. And by 15th of December. We are kind of ready to present to them the first presentation all the building blocks and architecture team can present to the external parties. And that will be much more technical. This is not a marketing presentation. So from that point of view, I think we are now targeting to achieve closure by now. But from the specification point of view internal closure, so it can go externally. This is the kind of target that has been said and I think we need to work towards this target and define draft at version one Dotto and Who are those guys who would like to review each building block group might have ideas about who was good to review it other than themselves. Please pull those books into the review. Give them a month. If you can send it this week or next week. By end up nobody would have collected the feedback.
So um, I know we've got like, just a couple minutes. So um, let's see, do we have anyone from messaging here? No. Okay. So, I mean, I guess we continue to really focus in on this registration for postpartum and infant care. Um, so I guess one question I have is for the new groups if you can please add links to your use cases that you've identified. So you know, Ron Kumar, please add links to scheduling use cases in the relevant sections.
Go to that, okay. And then,
even here, right. There is this step where you know, and this is for case management, but if you just search for the word consent, right, there's a very concrete use case here. And I can just, I'll just, you know, add a link, uh, you know, or so. So, you know, I in for example, consent management might want to link to one of their use cases in here, or if they're more general, please add links to those as well. Any questions about that? Like it? Okay.
Place can just mark it'll help.
Sorry.
Yeah, you can just mark that place for the comment.
Okay. So let me say that. I don't know if I have you in my Google Drive. But well, this is
I don't, Max. Sorry. I noticed that on it. Yeah. Right.
So Oh, yeah. Okay, great. You know, and then there is this, you know, there's this notion if you just do the search for scheduling, right. So I've got one in here already for you. Uh, you know, there was one for scheduling right here. So here
Yeah, yeah.
Yeah. So batch payments scheduled and I added a link for you or I added a comment in here already. So you know, just a reminder to do that. So, I thought it might be good also to, to maybe, well, we've got consent management here. Is there anything you know any, anything that the new groups have questions about, or payments that have question about these specific use cases or, you know, especially this registration and postpartum invocare? I mean, this one, it we're really zeroing in on it because we're trying to build an actual demo that shows this right. So
as a as a general comment for us some actions need to take place before this use case starts. So for instance, configuration and managing that configuration of consent is something that needs to be there before Sonia goes to any, you know, any other location, right so and I noticed that to be the same case, we with identity management and so on. Do you think it's it's reasonable to create some, you know, set up use case or something that we can perhaps also coordinate the these individual use cases also in the phase that remained outside of this customer journey type of user journeys? Yeah,
it's very valuable because almost all building blocks require some setup. There is a use case for setting them up their policy, maybe configuration, maybe, which may not be actually encountered within this user journey, this user journeys assuming it's already set up. The policy is already there.
Yeah, so I mean, I think, you know, I think it's, I think it's useful. Um, you know, it is interesting to consider it from a, you know, user's point of view, right? Because then you consider what, you know, what is the user experience and who is the person who's actually setting it up? Um, you know, but I also think in this case for this specific use case, right? It's useful to just say like this is a this is an assumption that, you know, that if there's consent management, it's already set up, right? Yes, I think I think,
yeah, we certainly for this one, we can we can add this but nevertheless, it's not only in just the setup, I think what we what we encountered, especially in the consent world, is that if the context will change, some policies will change, then you need to reconfigure that, right, that is also something that needs to be there. So I think, again, this is not an urgent thing. We can work without it, but I think it will help all of us to have this kind of government functionality or or user journey somewhere, also available so that we can map our individual use cases together against that. That
part as well. Yeah, I think so. So I mean, this might be one of those things where you know, sort of like a authenticate, you know, authorization for a request like that we have these generic flows that any building block can use to define how a request is, is author is, is authorized. Right? So like what roles are allowed for a given user and therefore, what information or whether that request can be so I think having generalized flows for these kinds of things is really really useful to consider, right. So I'm
I'm confused on that. Because what I am actually thinking is that for example, there is a setup, there is a configuration. The configuration required for various building blocks like for example the payments building block request configuration, it might have all the capabilities, but you need to configure it. Similarly, you have all the capabilities in consent management, but you need to configure a policy for according to which it would work. That could be all the capabilities were for workflow, but it requires a policy and configuration. So I'm seeing this again and again and again. But there is no use case in our our set, which says here is how we will configure this policy for any of these in fact, so should we consider that as you know another separate use case where you respective building blocks have to figure out how do they configure their building blocks? what capabilities do they provide for configuring their building blocks?
Yeah, so I guess I think it's really important to define what capabilities there are for configuring the building block. It's it's understood that all building blocks or you know or almost all building blocks are going to have a web UI for configuration. Right? So if you look at any of these, there's probably going to be some sort of web console that you can log into for administrators. I
know we're just stopping there. We're just stopping saying, Okay, there's a web UI. Let us read all of that. But the capability of what should be configured how configure is the m&m, talking about capability, not actual parameters of configuration, but how to define a policy. How to set up a policy consent management for example. Yeah, is
and also and also making that policy available to the other side. So each data holder needs to you know, kind of figure their policy and then the other end needs to find out what that policy is, before they starting before they set up their service, which then is capable of asking for consent in order to execute the service based on the policy. So next, I think at least from our end, you will receive a solid set of capabilities and use cases which I would loosely call would loosely fall on something that I would call governance, user story or governance functionality and once again, I repeat, it is not one thing that you do once and certainly the UI web interface is not enough. So you need some machinery, and also some activities and those activities are not bound to just one entity. There there will be workforce behind the scene behind these user stories that have been mapped that you know are constantly there in order for this lady to go with her child and start using all those cool government services.
Absolutely. So you know, while we're talking about it, we've got this nice use case here. Why don't we consider where we could put in a specific interaction with consent management? What do you think about that idea?
Right. I mean, well, actually, the workflow yesterday, we were looking at that the workflow is getting what is that line? I mean, it's too small to read. What is the exact line you highlighted now?
Well, I mean, you know, if you look at Yeah, so sorry. This is kind of like a little bit dense, but there is a stage right? Where, uh, you know, you're entering the surname, date of birth and ID number of the mother, right. So and then that goes and confirms whether the mother's eligible or not for the
exact step. And after the eligibility is confirmed. No, no, I'm sorry.
Then there's a proof of identity and photo. Right, right. And then this is validating against the Civil Registry here. So somewhere in here, it seems like we could add a step that says okay, we want to ask for consent for from somebody, right? Yeah, but I'm getting that data. Yeah, maybe from the mom, right, like, right about here. When you start collecting information, you know, or even here, maybe you could, you could have like a step that says, Okay, we're gonna collect consent from the mom. Because that makes sense.
After you've got the information basically because she has to verify and say Yes, after she has seen what you're submitting,
yes. So as a as a as a simple maybe maybe naive use case. For consent there is that if my data is available in certain registry, it is either I bring documents with me and then hand them over on paper for to be enrolled into this program or I consent the service provider to fetch the data on my behalf from civil registry. Or maybe there are there are there are some regional whatever. So for sake of simplicity from the Civil Registry, and then after that, consent has been acquired, this process can be initiated, okay. So, exactly one of the one of the use cases we have identified and we can we can provide it there.
Okay, well, so why don't we you know, just drop in just an arrow and a box in here for you and then you can fill it in. Does that does that make does that seem like a good idea?
Yeah, well, if you want me to do it right away, then that's probably not a good idea. But yes, I think we have.
I'm not expecting I'm not expecting you to do anything right away. I'm just saying, you know, if if, you know, the reason I want to do this is because this is what we're kind of basing our demo on. Right. Right. So if we can have like just a quick, simple example, that shows consent management, then I think that's that's great. So okay, this is
this is perfect. And we would have the this specific use case even drawn with the sequence diagram available, and we can we can link it easily.
Okay, great. Well, yeah, for now, I'll just put it in. So there's this optional validation from civil registry to avoid double register, right. So I'm just going to put it in here and say like, first of all, the registration ScreenFlow is going to talk to the consent management. Right. And you tell me and which module is consent? We'll just say consent for now. You know, confirm mothers and consent to request data from civil registry. Right. Okay. And then I will put another one back that says uh, you know, consent is recorded right, you know, or Kitson is confirmed, and we're good. Yes. Okay.
Great, and then so that's another that's a valid, that's a really important step before we go into actually making this request to the Civil Registry. Okay, cool. So, um, you know, I just thought we could maybe you know, fold that in. I mean, another thing is, you know, workflow Taylor, I know you have to go or maybe already left. But we do kind of want to try to get a rough idea of the shape of, you know, what a service API to validate if the mother's eligible and how to confirm eligibility, like what the response would look like. What the request response cycle would look like, just to ask a question and get a response back. So we've also got that in there. So I mean, uh, and then payments, we have this specific use case in here where we're, you know,
just a second Yeah, Max. Yeah. To me, it's a bit strange actually, in this situation. Mother is next to health care worker as I understand this use case. Yes. Why we go to read concentrate history.
Um, well, I mean, the mum might want to the mom might want to authorize access to the Civil Registry on her behalf.
Yeah, I can I can also that yeah, so Alexander. The idea is that which also came up in our discussions, just two days ago is that the way how this consent is being registered, can be many forms, it can be voice, it can be paper, it can be digital, but then this consent service is keeps track of okay, consent was the date the data holder, you know, who has in this considered registry, has receded and has released the data within the extent of the consent for instance, you cannot query every single data field in the Civil Registry. You can only ask for let's say the amount which is necessary in order to perform the task which you went to the doctor for. So and once again, in Estonia, it might be organized for legal and other purposes differently in some Kenya, it might be organized different, but this the idea is demonstrate that you can add this component and add it it can be I don't know default can be that that is always consented or you can opt out. For instance, if you don't want to or whatever. Or maybe I mean, this situation takes place. Let's say there is a devolved governance mechanism that there is a regional management of certain data and and the the Civil Registry is at the federal level or vice versa. So again, it's illustrated exemplify how you can make use with this. As doesn't help you
know, actually, what is the situation mother came to register in program? Yep. He's standing next to this healthcare worker, health care worker. What health care worker can do it can register consent of mother in concept registry. Yes, I understood it. Understand it. But if Mother is here and tells her worker goes to registry to check his concerns are in this consent registry or not. Actually, if healthcare work, why want to behave on base of this response from registry, the actual situation Ruby's mother, Master before before this process go on, go to consent registry and enter consent. They're
great, this was another discussion that we just had two days ago. It could be both ways, but conceptually doesn't make a difference. So we haven't sorted out fully yet. But in this case, healthcare worker is acting as an agent of certain registry. But in the end of the day, some of the registered must have written or recorded consent from that person. Whether this consent has been received prior the mother even knows that that she intends to go and get health care services, or this is part of the process conceptually doesn't make a difference. So you can build any workflow you want. But at least when going after the, the consent, I think the Estonian consent service, which is just about your life, is built in the same way at first you control does for this service. Do you have a consent for the service? If not, then ask consent, get consent, and then you know, render the services.
Okay, it made one more. Next step. More complex here. In this use case, after requesting from consent if there is no consent there we need to to get consent that store it Yes.
So it
will go
goes yeah, but have a job of the consent building block because you get a right now you say consent obtained in the backend it would have recorded a consent. That's assumption.
Okay, shall we say that we're recording the mother's consent? You know, but yeah, I don't know. I mean, should this be worded differently? Should this be in its own optional block?
All right. All right, if I may, once again, since we are actually cooking, you know, the cake here, but it's in another room currently. So for the sake of simplicity, if we keep here to flows, I take your point, Alexander, that this is too simplified, and even if stated in this way doesn't make sense, but we will update this according to the workflow that I said that we have with with a pencil and paper and in kind of narrative, but not yet drawn in sequence diagram, but this will be there in less than a week because there was exactly one of the discussions that went through. In this situation, when the consent consenting does take place, outside of the data holder or outside of the organization, which actually, you're consenting for.
Yeah, so I'm going to just simplify this a little bit. I'm going to move this consent flow, just and we'll agree for now this is just a placeholder. And then I'm going to move it inside its own optional block. Okay. Like that. And then, you know, then it's a little bit more distinct, because if you think about it, both of these might be kind of like optional steps. Yeah, you know, I will I'll make this a from external external services.
Right. See if there is a trigger for which option to choose how would you indicate that?
A I'm sorry.
Oh, you got an option block? Yeah, let's say whether to use the option or not. Is a is that decision? Right? Yeah.
I mean, I think that goes back to the configuration, right. I mean, this would be kind of something that would be part of the workflow, whether or not this was included as part of the workflow, the screen workflow or not, really, okay. So I mean, and I think that goes back to this question of, you know, considering the use case of the, you know, administrator and there's also, you know, interestingly, when we're talking through this yesterday, there's a back office, right, there's somebody who in the back office is typically after all this is done is reviewing it, and approving it right. For a lot of these things. So that's another use case to maybe, you know, think about I don't know, you know, I think I don't want to get too buried in you know, specific user journeys. I mean, also you could consider, you know, you could consider this, this use case from a lot of different angles, right. So, but go ahead.
I have a question. Yeah. To Ingmar. Yeah. Ismar do Do you know, how we will be, from your point of view how this interaction response and management content system do understand what to do here
think you're muted, buddy Well, uh, okay. So I think this is, you know, um, I think these are all like really good questions. I don't know. I mean, I think in this case, it's gonna it really is gonna come down to you know, what the
and then this other case where we have policy of whether this option should be chosen or not, maybe I don't know whether it should be in workflow or it should be packaged in ScreenFlow. And based on that, you have to have configuration here or there.
Yeah, I mean, it's gonna be you know, practically speaking, it's going to be one or the other. I don't think we need to worry too much about it. Because remember, this is like, you know, this is this is basically a forcing function to figure out what is the specific interaction going to look like for this API, right. So and I don't think we know the answer to that, because that's still you know, as I said, it's kind of like the cakes in the other room being baked right now. So, um, but I think it's a good question, Alexander. I mean, I think all of these optional box like how are those configured? Well, I mean, who's deciding whether or not they show up or not, and I think that's gonna come down to how this register of the ScreenFlow is configured.
No, yeah, that's where I'm just thinking, Max there is. There is a way to configure the ScreenFlow by just enabling, you know, by wiring it, or when you go to the workflow building block, there is a way to configure a flow by not just wiring it but actually specifying a workflow.
Yeah, well, I mean, that's all that's what that's what this does, right? So workflow is sort of like API level workflow and automation and orchestration. ScreenFlow is screen level orchestration. So, you know, um, suffice to say that you know, these are all happening inside of the ScreenFlow engine for this use case now. So. Yeah, but I mean, it'll be interesting to see like, right. I mean, it does go back to this question of like, is there do we want to consider the user journey of somebody who's reconfiguring this, right. So you know, there's there's kind of two steps to it. Right? I think that that we've identified there's the optional part about whether or not we obtain consent or not right, or whether or not we validate with the civil registry or not. Those are both optional. But there's also like, how do you configure the consent management to to you know, a system as policies change? You know, likewise, how do you change the could reconfigure the workflow here that's determining eligibility. So I think those are those are really important questions to ask. And I think, you know, workflow and consent. You know, consider you know, consider approaching it from a use case, a different user's point of view, right, like an administrators point of view. I think that's a that's a that's a really good question. I mean, certainly, when it comes to ScreenFlow, there's going to be two different categories of user. In this case, there's going to be somebody setting up the ScreenFlow, which would be like a business process analyst. But then, in the for this use case, specifically, we're talking it's a healthcare worker, right. Not a business analyst. So
So, this for now, step are a country based or mother based. So it's in Kenya, you need this optional step. This is one possibility in another possibilities that this step we don't implement for this particular mother.
I see. Yeah, no, I think I think the thought was, in my mind, in my view, was that this is something that is set up based on policy. Right?
Yeah. Yes. And that's the point I'm saying so see, I'm seeing this one bit of struggle that will happen. You've got all these building blocks lined up. And now you're implementing a particular use case? Yeah, okay. For this use case, something has to be configured in registration building blocks, something has to be configured in consent building blocks, something has to be configured in workflow building block, and I don't see a single place where I can sit down with the use case, and get the ability, the capability to go and configure according to the requirements, all these building blocks, right? We don't have that. So I'm going to scramble around. I'm going to go to this registration with one sheet of paper and figure out what all has to happen here and then I'm going to run to consent building block and then sitting out there it will have its own way of configuring and I'm sitting there so the guy who is actually trying to use these building blocks and build something, what are we offering to them as a as a configuration panel or something like that, you know, which is much easier to manage and homogeneous. It doesn't look like I got these 25 different ways of configuring because each guy designed his own UI. Yeah,
I you know, I don't know. I mean, personally, I'm not I'm not as concerned about that. Um, I think that's I think that's okay.
I have to use this model. I will ask that question. Right. What are you offering me so that I can utilize your make my life easy in building an app using your building blocks?
Well, let's, let's step back a minute though, because, like you have to consider, you know, the persona of the user, like who is going to be setting this up right. Is it gonna be a government employee? Or would it be like a, would it be an IT person because if it's an IT person, then having a config file is just fine? If it's a government employee of some sort, who's going to be configuring it, you know, then you want to have a nice friendly user interface to your point. I think it's a really good point
to bring in the direction of discussion, but that was very important. Yeah, because
I think Medicare as well means that Ramkumar it's a valid point and that's how we haven't tackled the things in anchored system as well. We have the configuration tool that where you can configure all the things that you need to configure that's collected from different building blocks into single view. Of of configuring it. That's that's how the logic was done. If you need an example, then there is one example.
Yeah, and I know workflow like any workflow engine, those have, you know, various configuration views, certainly identity and access management. tooling, right. Those are going to have
in their own group discussions, everyone is talking about a policy a configuration. And the needs may be different based on a single use case you may find across the board different different configurations. I knew had a pure raising your hand.
Yes. So I think that a might might not kind of bolt immediately for a centralized configuration panel. However, there is needs to be some sort of reconciliation mechanism against since I I do not come from an IT side, I come from a government side trying to build complex public services using digital tools. So well in the real world. There are there are rules and regulations that define for us. We need to say some preconditions now, like answer to the last question that Alexander asked though, is it a country based or or is certain optional triggers? related to an individual which already starts to point into which part of this building block universe it has to be configured? And in the end of the day, they have to be consistent so for that, in that sense, this centralized view of them is necessary otherwise, it's just a madhouse to get them functional. But yeah, I will leave the architectural decisions to some other people whether this is a coordinated, distributed effort or a centralized, enlightened King. Who will call the shots but something like that is needed.
Yeah,
I mean, I think for now, just for the sake of simplicity, I would strongly advocate so remember, this consent block could be centralized across the entire government, or it could be just within the Ministry of Health, right? We don't know that that's kind of up to the government. We need to give them that flexibility, you know, like, the Civil Registry. There's probably only going to be one of those but for you know, payments, like they could be specific to the Ministry of Health or it could be statewide or it could be federal, we don't know. So I think we need to make sure that just to be clear that there could be multiple instances of each of these building blocks. For the most part, you know, probably not a civil registry. That's probably a bad idea. But, uh, and so each instance needs to be autonomous like, right and so you need to be able to configure it. So I think for simplicity's sake, you know, I think we need to leave it up to the experts in the building block working groups to determine how are they best configured right, based on their experience? Is it is it config file the best way to centralize you know the configuration of consent management or is a web console? We don't know. I mean, let's leave it up to the workgroups to decide that.
My infancia is that consent management or workflow from their capabilities perspective, they may know what are the configurable rules, but they may not know which configurable is to be chosen for a given use case, because that is beyond the building block. So all of us are sitting together right now, and trying to break down this use case into this diagram in the in the process we are encountering maybe some particular configurations that are required to satisfy this use case right. So this is very manual that we are doing right now. So when if you give a configurable let's say consent management as a configuration window workflow has a configuration window of its own. It is still very manual right now. Honestly, we are doing a very manual process of breaking down a use case. Manually thinking and figuring out okay, what should be the configuration for this use case? And then going out there sitting before the workflow console, saying okay, this configuration sets up, but there is I mean, there is no linkage because the workflow guy or the consent guy, the building block, does not have an awareness that I am applying this policy for this particular use case there is no there is no such sense in these building blocks right now. They're just a bunch of capabilities. Right. So unless there is a way to convey that this particular policy applies in the consent building block for this particular use case, you will again get a set of policies, but where is the dependency? Where should that policy apply?
Yeah, so yeah, so yeah, and I think that's why it's so important to consider the context of the policies and you know, consider that these use cases are not all the use cases. These are just, you know, kind of designed to provide a forum to ask these kinds of questions. But it also does give us a sense for what we want to prioritize. I mean, I think I would be happy if all of those policies, were just at a minimum configurable. In in a config file. Right. I would say that having a
building blocks, maybe they're fair, therefore, it's good to think that there should be a What would I say a policy block in each of these building blocks?
Yeah, well, there there is a policy component to all building blocks, right? I mean, you have to consider, you know, we're considering we, you know, stepping back man, and we're trying to make something that's going to work as well for a place like Estonia, as it is for Papua New Guinea, right? Or, you know, Rwanda, for example, or the Ukraine, right. So we want to make something that's gonna work for all of these so it's got to be as configurable as possible. Right. So
that's an important thing, Max for all of us to sync up on that page. Anyway, all building blocks require configuration but we call it as a block. Creation block.
Max. Yeah, one thing that I would perhaps still repeat. So yes, even if I am not confident myself, but a centralized management of configuration is what we are looking but a user stories, so act. So currently, we, we have four different user journeys. And I think that where I'm 100% with Ramkumar is that this kind of given collection or compendium of those configurations that need to be taken, take place. I think it would be helpful to see them in one place, not take this as an assumption that there is a UI and somebody there will do it, but really have have like a governance user journey, if you will, in addition to those four, and once again, it is it is something that is outside of this what you show us here, but it's a necessary thing, which if left only to Oh, somebody will take care of that probably will will will not solve because the complexity grows over over our head again. Yeah, that is my experience not as an IT architect, but really architect of public service.
Yeah, exactly. I mean, you might be stuck editing configuration files forever, right. On the other hand, if we require like a specific kind of UI for a building block, then when we start writing that into the specifications, then it makes the building blocks more rigid in terms of the types of solutions they can accept. So
yep, no, oh, yeah.
Sorry, sorry.
Just wanted to jump in on one thing. Yeah,
I'm not imagining that there will be only a UI I'm imagining that there could be an API exposed in that building block to consider. Yep,
yep. Yeah, so Exactly. I mean, at a minimum, maybe there should be API's, maybe not. Maybe you don't want those API's right. For security reasons. Maybe you want it to be a physical file. But I think it's a really important point that all groups should consider the governance use cases for configuring their building block, you know, right. Because it have API's for configuration, you know, a UI or just files
you know, so yeah, I mean, I think it's really important to consider the policy right and what's best, right, yeah. So, okay, that's it. That's a really good point. Um, I am happy we had this had this conversation. So yeah, um, okay, great. Yeah, Alexander. Yeah.
I want I want to draw your attention that in the architect document, yeah, there is stated that configuration must only happen through environment variables.
Yeah, that's right.
What we are speaking right now about consideration files and stuff like that. It's, I guess.
It is a configuration as in system or a policy a soft policy like politics.
But I mean, they're you know, in most cases, there isn't a lot of difference. Like I don't know how you separate that, right. Cuz you configure the tool according to the policy. So Alexander, yeah, I mean, that's a really good point, right. Like we do require everything to be set in environment variables. So you know, in that case, you know, let's just update the notes. You know, because I do want to, I do want to stick to that
already most to environment
variables. Yeah. I mean, you know, part of the configuration could be pointing to a volume. You know, or a database where the actual configuration settings are stored. So I think it's, it's kind of open but if you allow if you allow things to be stored in config files, and it makes it much harder to containerize things
need a policy database? Needed database policy database. Yeah, maybe.
I'm just environment variables. I'll just change this. Right. So. Yeah. So it's kind of a technical detail, but you know, good. Good. Point. Thanks for catching me on that one. Alexander. Okay. So other other other points as we're sitting here staring at this, I mean, it's kind of a good, it's good to good to raise these questions. Okay. Well, so this is great, because, you know, this use case I mean, I think we got some more clarity about what the optional blocks mean. It means that it's kind of configured per policy. There is a you know, this open question of how each building block is, is configured. I think calling that out specifically, is is really useful. You know, I don't want to I don't want to I'm not sure that it's really an architectural decision, though. I think the the, what's it has to be defined by the building blocks depending on what they think is best. And if that means that in some cases, we never end up with a functional like UI for configuration, well, then that is problematic maybe. So, I mean, we should probably err in the you know, err towards making each of these things configurable. So, I mean, it is worth pointing out though, that we do have a, you know, when we're talking about GM stack in the large, larger sense, we do consider that every building block is going to have its own UI, its own API and events, its own domain specific business logic, and its own domain business data,
which will contain the policies. Yeah. So I
mean, you know, somewhere in here, probably in here, right. And this, you know, this is going to be tied to some configuration. But that's kind of its assume that each building block you know, may contain or most likely is going to need at least these kinds of components and internally. So yeah, and then, you know, and this diagram is kind of kind of maybe, you know, a you know, it's a little bit incorrect because the UI isn't going to be going through the information mediator at all. So, um, so that's kind of like, need to update that, but, um, good points. Okay. So I know we're running short on time. This has been a long meeting. Anybody and we've lost some folks who still here. Well, quite a few. Anything else that we should cover? Do you want to? You know, I think it's worth you know, considering which use cases to do next, right? I mean, the one that's currently on the table is this promotion. For postpartum parlimen infant care. So we could flesh this one out a bit as well. Um, quickly. There's just this really rough you know, kind of series of steps currently, right. So are we gonna just, you know, continue this one next week. I mean, this is sort of put in for a, you know, so that the, it it's to make sure that we have a good place to exercise messaging really, is kind of the spirit of why this one is next. Okay, well, good. So unless anybody has any other kind of burning questions, why don't we wrap up for today? Um,
yeah, I just want to end the NEC meeting, Max, can we put part of the agenda to review that use case for scheduling?
Sure. Absolutely. So I mean, you know, we could dive into that a little bit. Now. If you want. Um, you know, I mean, there's a few. There's this batch payment, right. So I guess what I would ask is Ramkumar. Why don't you put the links to your payment use cases in the document that
in the chat, I embedded in the link? Yeah. So
I need you to update the actual logical process blueprint and in general, you know, all teams if you can just update this update this document with links.
You know, next week, many of the detailed
use cases kind of gets cleaned up. It helps to focus on the functionalities and all that stuff. Okay.
Actually Max an additional comical attack from showing Alia Yeah. What I see for the payments, yes, you indicate that that payments will be generating some kind of QR code. And on our side, we believe these QR codes are just rendered. Yeah. So we split the information into registrations and then registration or render that information in some form of QR code.
Okay, well, let's change that. So we're going to request payment advice, right?
Yeah, maybe you don't consider this as a concrete case then. So that you give us some time to go ahead and discuss it in the group. Especially that bid for payments,
right? Yeah, that's fine. I mean, so you know, so we can we can make an ad. I mean, I'm fine adding a specific step here. That where the ScreenFlow is displaying the barcode?
No. That help clarify it.
Yeah. Then we will probably come back to you in the following weeks on, you know, specifically how that flow is going to happen. But in any case, we don't expect that we'll be generating any QR code.
Yeah, no, no, that's right. That's understood. So this is kind of out of date. Good catch. So let's just say that we're going to request payment advice and then, you know, Return Payment advice. details or payment details to generate barcodes. Does that seem reasonable?
This sounds good to me.
Okay, great. Thanks for pointing that out. pointing that out. Um, okay, good. So, you know, and the reason again, we're going to try to make this into a functional demo. So you know, that's why I keep kind of focusing in on this, this particular use case. But, yeah, so you know, in general, yeah. Let's make sure this is as accurate as possible. And, um, you know, this is probably another kind of workflow. I mean, we're calling it rules engine. So, any other changes that folks would like to see in here? Okay, I think I'm going to do this one. I'm just going to change this to workflow because that is kind of what rules engine is, isn't it? So, just to make that clear, this is a whole nother kind of workflow. You know, maybe that maybe this needs to be broken up into two components. Okay, anybody? have any other questions, comments, concerns, anything they want to raise? Alright, good.
I just want to reiterate this number, peer review to all the groups or and also send out a mail just to remind Yeah, that is required to be formally submitted. For them to take it up and give it outside. Exactly. Nobody's really acid test for all of us. Whatever we have done.
Exactly. So again, you know, we all groups will get your bit, you know, or groups or, you know, first wave groups to get the specs together, you know, a review by December 1. Again, please identify people who would be good for an internal review. You know, think about which stuff isn't going to make it for version one. That's okay. You can add it to another section for version two. And then again, we're gonna consider this governance use cases. So these are all you know, so Uh, okay, great. So, um, I think I think we're good for today. Please remember to update your milestone checklist as well. That'd be really helpful. Okay, good. Um, so anything else? All right. Just kind of my camera. Okay, well, thanks, everybody. Thanks so much for joining. Nice to hear your voices as always and nice to see you some of you and talk to you soon. Okay, thanks for taking the time. Okay. All right. Bye.