Once again, please make sure your team’s documents are accessible from Teams from the appropriate working group’s folder in Microsoft Teams. If you need help with this, let me know!
If you have a use case that connects multiple building blocks, please link to it in the Logical Process Blueprint so other teams can find it: Logical process blueprint - Google Documenten
Agenda for this meeting:
Review each group’s progress (standup!)
Review progress on PPTs
Reminder about using the building block definition template
Reminder about writing down significant changes and decisions in a log under a header in your building block definition template
Reminder to provide source for all images and diagrams, ideally draw.io, web sequence diagrams so they can be edited and evolved.
Review last week’s key decisions and see if they’ve been addressed
Work on the next sprint’s logical process outlines and flow diagrams
We opened with standup, this time reviewing each team’s building block specification updates, questions and changes. Highlights included:
- Information Mediator demonstrated a working demonstration that showed Registration’s Registries and Registration building blocks connecting through Information Mediator. Information Mediator expects to ask or a formal BB spec review next week.
- Payments reviewed how voucher redemption will work and answered a number of questions the Architecture team had around how currency is held prior to payments. Cash is still king. Payments is working on the openAPI specs and hopes to deliver them by the end of August. Payments has asked for an architectural review around G2P payments in particular.
- Information mediator is moving technical details including JSON Schema specs and moving them to GitHub. The BB spec contains links to external resources.
- Architecture reviewed the current thinking about interoperability. We believe GovStack will need to build reference adapter building blocks to show how to connect with existing services, e.g. FHIR or SAP.
Key decisions made in this meeting:
- Information mediator is only for securing backend requests. Some communication may be made directly available by building blocks on the open internet.
- Building blocks MUST be secured so they don’t need to communicate through Information Mediator or API gateway - they MUST be completely autonomous from a security perspective. This means checking authentication and authorization for API and web calls instead of relying entirely on other services.
Previous key decisions:
- Payments will cover G2P and G2B use cases. OpenAPI will be done later
- Information mediator is nearly done moving editable diagrams into github and are working on OpenAPI specifications
- Information Mediator(Publish/Subscribe) will only send payloads to subscribers. A type and payload field will be published to the information mediator. Subscribing to the same service to a type/topic multiple times is allowed.
- Security highlighted the need for a Networking group to handle networking-related issues, specifically firewalls, reverse proxies that have been identified as key components. They will work on an OpenAPI/Swagger specification for talking to an API Gateway building block, see below:
- Information Mediator showed an excellent diagram highlighting a more detailed overview of how requests coming into Govstack will be handled: https://drive.google.com/file/d/1bp0DkRnITod0h96jIf6-AL2ks6NfGaoP/view
- Payments is debating whether or not they will handle cash or not. They will handle mobile to mobile and bank payments. If they decide not to handle cash/teller/reconciliation/accounting functions, we will need a separate group for that functionality.
- All groups will review the Data Verification and Validation - Unconditional Social Cash Transfer draft use cases at Logical process blueprint - Google Documenten
- Groups will look at https://discourse.govstack.global/ and see how it fits their needs. See the Architecture Team Resources topic for an exampe of how groups can list their resources for public consumption. Architecture will continue to evaluate discourse.
- Groups will fork a copy of GitHub - GovStackWorkingGroup/BuildingBlockAPI so they have a centralized, versioned repository for editable diagrams and other resources
- Groups will provide source for all images diagrams, ideally draw.io, web sequence diagrams so they can be edited and evolved. If possible, check them into your group’s forked copy of GitHub - GovStackWorkingGroup/BuildingBlockAPI to provide versioning consistent with your document versions.
- Groups will submit initial revisions of their building block specifications for review by the Architecture group as soon as possible.
- Architecture will give an overview and demo of how we use github for editing diagrams
- Architecture will work on a flow diagram outlining how webhooks work with Information Mediator and will meet with Information mediator team to review
- Payments will move language specific to their group from the Logical Process Blueprint Logical process blueprint - Google Documenten and link to it
- All groups will review and link to the cross-cutting requirements of the Security building block definition Security Building Block Definition.docx - Google Documenten. Groups will review additional functional requirements that and point to those as well. Groups are free to consult with the Architecture and Security groups once this is done.
- All teams still need to work on updated powerpoints
- Groups can request a formal review from the Architecture group at any time.
- All use cases that connect multiple building blocks should be linked from the Logical process blueprint: Logical process blueprint - Google Documenten
- Transactional system of record registries MUST use a document-based approach and MUST copy all records, e.g. a doctor’s record must be copied into a snapshot as part of a prescription. If you store a foreign key, e.g. doctor’s reg number and their phone number or address changes the record will be incorrect. Therefore, documents stored in system of record registries MUST copy all the data onto the document to provide a record as a snapshot in time, and SHOULD retain references to all foreign keys/references to objects copied for auditing, e.g. to the doctor’s address and phone number record URIs. This capability will be part of the registration building block.
Thanks to everyone that attended!
Action items for each working group:
Continue to work on your own copy of the Building Block Definition Template Building Block Definition Template.docx - Google Documenten. At least the Key Digital Functionalities, Cross-cutting requirements and Functional Requirements sections should be filled in based on the specific requirements outlined in the logical process blueprints: Logical process blueprint - Google Documenten and functional components in the logical process checklists for the use cases already covered (e.g. registration, payments and case management for Postpartum and Infant Care): Logical process checklist - registration - post partum and infant care.xlsx - Google Spreadsheets Logical process checklist - payments - postpartum and infant care.xlsx - Google Spreadsheets and Logical process checklist - case management - postpartum and infant care.xlsx - Google Spreadsheets.
Ensure your Building Block Definition Template and other documents are accessible via Teams so other groups can see them.
Review the logical process blueprint for the current sprint (Case Management - Postpartum and Infant Care) and add any comments or questions that come up: Logical process blueprint - Google Documenten
Confirm the components for your building block designated in the logical process checklist are correct: Logical process checklist - case management - postpartum and infant care.xlsx - Google Spreadsheets
Review the building block flow diagrams for Logical process blueprint - Google Documenten UC-P-USCT-001: Payment - Unconditional Social Cash Transfer (bank payments) - Google Documenten and UC-P-USCT-002: Payment - Unconditional Social Cash Transfer (non-electronic/cash payments) - Google Documenten
Identify folks who could be good for the new working groups we’re spinning up: consent management, messaging, marketplace, scheduling and workflow!
Next week we can review our progress and perhaps begin another sprint!
Agenda for next week:
Review each group’s progress (standup!)
Review group’s documents in the context of how a specific arrow in a flow diagram maps to specific functionality in the block
Reiterate that use cases are not to be taken as gospel, they can be rewritten and new use cases can be created that more accurately reflect reality
It’s fine to break a building block into multiple blocks that better map to functional domains
Reminder to provide source for all images diagrams, ideally draw.io, web sequence diagrams so they can be edited and evolved
Work on the next sprint’s logical process outlines and flow diagrams
Github and discourse overview
Meeting minutes (Cross-block meeting minutes has the recording and transcription):
I really do love that golden orb. I love it. It looks like a halo. Yeah. Well,
Max Carlson 0:17
yeah, honey says it looks like a sombrero. Yeah. Yeah, I’m good with either one. Yeah, yeah, or both, you know, yeah, yeah, totally.
I’m gonna go on mute and turn off my video for one second while I’m just finishing something on the stove. I’ll be listening. Okay,
Max Carlson 0:37
cool. All right, who’s joined fellow jet stir. Welcome fellow jet sir. So go on mute as well.
To save bandwidth.
This will give folks a few more minutes to join us, Welcome VJ.
Have you joined us.
This will give folks a few more minutes to join.
We do have a monthly meeting right after this right. Is that correct. Yes it is. Okay,
Max Carlson 3:28
yeah. So, In an hour and a half. Perfect.
Hello. Welcome Trevor welcoming Mar.
Good to see, to hear your allow logging, fine tune my presentations, while the meeting is going okay with you. Secondly,
Max Carlson 4:27
I’d love to. Thank you.
Are you, let’s see, I just shifted our presentation I’m running over to the template, like the Gup stack template. Is that what you’re doing as well as the idea that we’re all sort of converging around that big blue and white, PowerPoints,
using the same
thing doing it in Google Slides or on
on a Microsoft PowerPoint. PowerPoint. Okay. Microsoft base so yeah, It’s easier to use this one. Of course.
Max Carlson 5:31
All right, well let’s get started Ingmar Do you want to give us an update. Awesome.
Oh, it’s gonna be a quick one. We have been closing the document, especially a registration. Building template or functional descriptions requirements, and it’s starting to look better. We still have some recordings to go over and see if it’s, if it’s needed or not if it’s overkill or not. And then it’s the next paragraphs, which shouldn’t be hard but let’s see this this processes. Chapter in the end, which I haven’t yet figured it out but I guess it shouldn’t be a problem to describe how registration service process goes inside, building block.
Max Carlson 6:43
Yeah. And I think nothing more to report, although I could, I don’t know if Aleksandra is here or not.
Max Carlson 6:53
He is not as far as I know,
I was under red circuits from Informatica, yeah. No, he and he won’t. I don’t think you’ll be able to join the meeting tomorrow. Is there something I can pass along to him.
No, he made a great job in setting up the trust system so the I was just, maybe I can just share my screen for a second and that’s, it’s not waste of your time. But just to, just to give a quick screenshot of the thing that I did, together with Alexandre, because this is the third C registration system it’s the single window portal where all the services I’ve listed. It’s a kind of a listing of services. And then there’s one service which is called Graph stack test. I’m not logged in currently so it enables us to send requests to without, without being logged in. So what we did, we connected, one of the databases, which is another non persistent which is the registry domain
database as well. Sure, what we haven’t done.
There’s a database in the database engine, which is called Citizen register as one record and this is the, this is a very simple database, which I just created for a demonstration. Then I connected this database. To the information mediator or Trump system. And it’s offering all the API’s are automatically from this database. This, this is his list of API’s into Nabeel stood to search from a simple one to like read list gets a long list of items, and create and update and so on. Custom get, and then going back to the citizen portal for the citizen view. This is the service that I opened. And there are some input parameters, it doesn’t look very nice but it’s functional service. These are the input parameters, and I just added record ID. And if I click to read data then the request goes through the information mediator to the database and gets back, the answer from the one record, just to click it
returned an answer, which is the same record that I have in the database. Wow, that is awesome. So basically that’s any, any kind of a database. Well the database engine is is built in a way that it contains multiple registries inside. So you can have different, different databases so registries for different purposes. And automatically, it could offer all the old API’s today information mediator, and then the, the ScreenFlow, and registry registration system, it could just quickly pull this information and showing to the user. And or using to in the background for validation. That was just a quick, quick demo, what we what we tried to achieve, to see how hard it is to connect different systems to the extra information mediator.
Max Carlson 11:47
Very cool, um, anybody have any questions comments concerns about that, really neat. So, um, I just want to check in. How’s the status of your building block definition templates is that something. Do you have anything you want to show or any questions you want to ask about that or
I should. Very soon I want to send it to the architecture team to give us some feedback but I still want to work with it a little bit to just to clean up the rest of the document. It’s okay, next week.
Max Carlson 12:31
Yes of course anytime, yeah that’s that’s great news. So just let us know. And then, you probably have a presentation for this today as well. Right,
just, I’m just fine finalizing it. Okay cool,
Max Carlson 12:46
great, that’s awesome news. Okay, anybody else ask a question, Max Yeah, please.
All right, Ingmar just on the demo that it’s fantastic sorry I think I muted. Before, I was hoping I was hoping to hear you describe X Road in sort of layman’s terms. Now that you’ve interacted with it. Just to set up this demo. One of the things we’re struggling with I think a lot is just like terminology and how to externally communicate what extra does and does not do. Would you be willing to just like give a 32nd description of X road and how it facilitated the communication between these systems
in your demo. Well, I’ve been working with showed over over 15 years now so forgive that yeah okay, but it’s, it’s pretty easy to explain, but it depends if, if you understand it or not, was basically decentralized data exchange between government institutions or government databases or government systems is actually just a data exchange.
Yeah, exactly. I was, I was hoping that you hadn’t had lots of experience already with X road, and we could hear sort of an explanation from first impressions but no, That’s, that’s fine, thank you.
Max Carlson 14:24
Okay. All right, so who wants to go next. TJ, do you want to give us an update or. Yeah.
Yeah, hi. So now aside. So we will we are also working on the document, specifications, building block document so this is going to take some time the review and cleaning up on this document. And there were two questions I think that were set by Trevor, after the meeting last week. So one, that’s one of the reason I asked, Oscar to join maybe to talk a bit about the first part on the digital voucher, how we are taking care about it in the working in the building block. And the second part I reply by email to Trevor. Regarding the access points, I think that was missing from the slide, but I did this now, but it doesn’t. What I showed last time doesn’t contradict anything I think the recommendation was from the World Bank is more on how the payment is made from the government side, but then the other part which is the delivery point that’s up to the country to decide, whichever way they would like to do the delivery across different access points, so I don’t know if Trevor, you have still any questions on that otherwise I lead maybe Oscar. Talk about the digital voucher. I think Oscar is on the call from Yeah. Yeah. Maybe that’s my first prompt from Trevor and then we can. Yeah,
thanks for coming. I also had a meeting with James J. Last Friday, and I think we managed to sort of get a common understanding of what we, you know, we’ll see and it looks like most of the scenarios are are cosmic what it seems to be, is that there are kind of two kind of dual systems that happen in payments phase one is a banking based one. And another is a mobile money based one. And they coexist in various regions, such as West Africa and what have you, I think, you know the the assumptions that have been made is that both, both these systems will coexist, and it was effective, of who owns, you know, the various applications. The, the architect is always the same. So for example, it’s, it’s kind of a bit irrelevant whether Treasury holds the account or commercial bank holds the account there is still a banking platform somewhere there’s still a payment system somewhere there’s still no some way of doing settlements, somewhere, you know these things and, you know, I think where it’s getting where it was getting a little bit confusing, from my side is that there was, there was the kind of thing. It was unclear in my mind, the difference between institution and applications. So we managed to sort of, you know, resolve that kind of misalignment and I think now I understand the point of reference work better, it’s even easier to understand. The other thing that we discussed was how to redeem mobile money, and whether that was something that would be realistically achieved within the timeline and he says, You know you made some valid points about that these are really policy decisions that are made by the government, you know, like Kenya for example is quite advanced down the road, and other countries are maybe a little bit further behind in terms of the mobile money but. So we said, you know, what do you see happening in the Horn of Africa, and this is what actually seems a bit unclear, and we have to probably support both methods of, of, of, you know, mobile monies and traditional banking platforms, because, you know, it’s, it’s unlikely to be a completely exclusive market, whichever way it goes. So I think there’s kind of clarified a lot of thinking in, in, in my side. And I think the the architecture as we went through the document and he explained all of the patterns I think there were six different sort of patterns and so I think I feel a lot more comfortable, because I just didn’t understand how how like the mobile money platforms sort of set alongside the traditional banking platforms, but he explained that quite well. So I’m a lot more comfortable that I understand, you know, How it started to work.
Okay. Oscar, you want to go ahead, you had a question regarding divorce on your side.
No, I think, sorry, can you hear me, yeah. Yes I can hear you. Yeah, yeah. No, I think, I think you’ve summed it up. Welcome, I think, I mean the ecosystem will exist like side by side and we have like a payment gateway that can talk to either one of them. Yeah. But I think if it’s clear there’s no need to go into detail because that will just make it a longer discussion. Yeah, so maybe we leave with that, unless you have specific questions.
Then, no, no, sir I’m quite comfortable I said it was the only thing that I think we’re, we, I wasn’t really clear on is how the mobile money would be redeemed. So for example, yes, if you’ve got a voucher, it will obviously be redeemable at Calico outlets for, for patch, but it’s not so advanced things like point of sale and those kind of things. I believe that they have made some progress in Kenya specifically which seems to be the most mature mobile money market in, in the, in Africa, but even then the penetration I think they’ve seen they’ve got something like 8% of the payments are made using the mobile money at point of sale so it’s still cash is key, I think was the, was the, was the token although the digital currencies, it will either be a mobile money platform or a traditional banking platform with MasterCard or Cirrus or Maestro or visa or whoever, that kind of facilitates it on behalf of a bank, and both are covered. Okay so I live with that.
Max Carlson 21:32
Yeah, so I mean yeah, if you don’t mind, I mean, Trevor, could you just review, just for the group, and for everyone else, like, what the questions were that you had and how those were resolved, just a quick
Okay, so sorry God, God, I have a little bit of a problem with my connection so I didn’t hear the question, please continue.
Yeah, I think the the question from Max was, you know what were the outcomes of the questions that I sort of asked, and I think it was kind of pretty much what what I just explained that it was really around, you know, how you disperse the mobile monies to, to, to cash because you know the traditional banking systems are geared to that so that you know you’ve got big penetration, you know ATMs and you know you can get cash from shops and retailers because it’s all part of the point of sale and the merchant infrastructure that exists in most, most countries and I think it was just understanding where how far the mobile money has gone into that space. Obviously, you know, we also discussed about the West Africa region which is quite, quite an interesting use case because it is a regional currency there. So they obviously use the West African Franc, and the central bank, in that case actually holds a lot of reserves on behalf of governments and the multilaterals, so it kind of coexists. Alongside the traditional banking payments platform but they’ve got it, they’ve got a single currency there, so it makes it a little bit easier for them to do the, the settlement between countries and monitor the inflows and outflows because this is managed by a single central bank. That would obviously is not yet the case in the Horn of Africa because they haven’t got it but if there was a policy framework where they could, because it’s really to do with settlement. And what exchange rates you do and say for example in setup, when the countries, settle in between themselves they actually have a statistical currency that they use for working out what the settlements are between the central banks, and what the inflows are to in the country so it’s a slightly different situation so I think we would have to assume for now that if we were going to go into one of those countries in the Horn of Africa we will probably be working at a country level rather than a regional level. Although there is an intent to move to a regional level at some point of time that that takes a long time to get the policy frameworks, done in each country so I think if you think of banking payments and mobile money payments within a country, then that will be a suitable model for the, for the Horn of Africa. And again, the, it’s most likely that the majority of government agencies will hold their deposits in the central bank, but there may be a mix, particularly at council level local council levels, Sometimes those funds may not be held at, you know, in terms of the central bank so if you’ve got a local council or a local district. They may also have funds in a commercial bank, so again, both models will exist. Okay So Max is that sum it up for you. You know, it’s, we should be focused on a single country with a single currency. You know, there are the central, the central bank will hold a duality of the funds but they can be commercial banks, mobile money payments can be used and cash and other electronic payments and digital payments can be used, but cash is still poor formed a large part of the economy in those regions, I think that’s the, that’s in a nutshell.
Max Carlson 25:42
Great. That’s good news I mean that sounds entirely realistic and in a line. It records, lines up well with what I what I understand about the region. So, okay so payments. Do you have any other status, any updates you want to give about the building block definition or. Why don’t we start with that.
No. We wanted to have a meeting with you, Max. Unfortunately it was not possible. But, yeah, I’m going on leave, next, next week. Maybe week, I would want to send you an email maybe if you could have a look at the specifications and maybe provide some, some, some comments on that. So we look into the, into these, because my colleague Cano is back from his leave on the 16th of August. So we’ll be then he’ll be then looking at those comments on a site, but on our site, you know we’ll be cleaning up the document over the next, over the next coming weeks, with a view of, you know, completing the. Especially the part on the functional requirements and starting the open API’s specifications by no bogus.
Max Carlson 27:04
Okay, great. So, um, so is this uh, do you want to set up another time for a meeting before you go or should we just wait until Arnold comes back.
Yeah, I think it’s best maybe we wait until all is bad, what I will do I will share with you the story how the specs for the building block, you could let us know maybe if we if we’re doing it in the right way, especially the GTP payments, what’s been done so far and any advice on how to refine it further. That would be maybe for starters, that’s the guidance would probably need from you.
Max Carlson 27:47
Okay, great. So, um, yeah, so, I guess. That’s great news all has not just me but the architecture group will review the payment building block specification in particular around GTP payments, and if there’s other particular, you know what we can do the entire thing or if there’s particular parts you’d like us to focus in on just send me an email and we’ll we’ll do that.
I’ll send you something on Friday. I’m still cleaning up the document right now. Okay so, by Friday I’ll send you something and then you can work on that.
Max Carlson 28:22
Okay, wonderful. Thanks so much in sorry about the meeting. Missing You, earlier this week. Okay. Wonderful. Anybody have any questions, concerns, comments about payments in particular. No. Okay, great. Sounds like we’re making good progress there. Okay. Taylor, do you want to give an update on your progress.
Yeah, sure thing. So, we’re, we’re getting, getting down to the end, we’re gonna send over our BB spec draft on Friday. So this week it’s been sort of cleaning up the slides and the external communication around the building block and and shifting a lot of a lot of the technical details of the specification over to GitHub. So we’ve started implementing, like the JSON schema specs for the various entities that we deal with information mediation, those entities are things like broadcast that what we were discussing on last week’s call for Pub Sub, or for secure communication, things like an application, a service, a member on the information mediator. So that stuff has been shifted over to GitHub, and the building block spec itself contains basically a bunch of a bunch of links to where those resources can be found. One, sort of, we’ve, we’ve run into a couple of a couple of funny bits down toward the bottom of the information mediator building block specification or I suppose if this template specification things around, like workflows, and sort of how I guess, how the building block will interact with other building blocks, so I think we’re, we’re going to deviate a tiniest bit from the template, but I think it’ll be pretty clear what we’re doing there just because some of those sections seem like they’re more relevant for building blocks that are communicating with one another, rather than a building block that sort of is the is the road or bridge or tunnel through which the other building blocks communicate. But, no, no real red flags at this point and I’m so excited to get your review on it. Whenever you guys get to it but we’re also then on Friday.
Max Carlson 31:07
Okay great, super exciting, and I think you’re sort of like security in that, you know, it’s really kind of like this cross cutting thing but it’s also a building block because it has open API specifications, but it’s one that kind of goes across building blocks so I think that’s something we kind of need to figure out is how these more infrastructural building block specifications work, right, Um, there’s been a lot of debate, you know insecurity about, you know whether or not the cross cutting requirements should go in architecture spec or whether they should stay in the security spec so that that I think those, those discussions will help inform the feedback we give you, I’m so looking forward to that, looking forward to doing the review on Friday.
Wait can I throw one more thing out there for, just because your public reaction to please.
Max Carlson 31:57
And if there’s anything you know I’d encourage anyone on the call, you know, if you want to share your screen and show your spec and so we can all see it. Sometimes it helps visually.
Oh yeah, sure. Well, here let me share. I guess the best place right now might be in the diagrams. Yeah, so be sure to check. Can you guys see my screen now. Yeah. Brilliant. One of the, one of the sort of funny thing that we’re running into. And we won’t sort of resolve, per se, but it’s just a thing to, to note the information mediator building block as it’s currently defined is not only a little bit funny because it’s sort of the roads, on which messages travel between other building blocks, it’s also a little bit funny because any implementation of the information, patient mediator building block will involve at least two very distinct pieces of software. We, so you know early on we sort of kicked out workflow engine and we said that it’s important to remember that the information mediator building block doesn’t read your mail. So, so we have this big sort of disambiguation thing right up right up at the front. It basically says, you know we are. It’s not responsible for manipulating payload sent to and from various applications. In a sense, it’s both the Postal Service, and the roads, bridges and train tracks, but it does not read the contents of your mail. And within that, so we’ve like kicked out workflow and reading mail and manipulating manipulating the letters that building blocks are sending to one another, that’s a distinct thing. But we, we’ve included this Pub Sub facility. And that’s what we’re looking at here and this is, this is the only sense in which the information mediator actually acts like a postal service, where it, it sort of does some, it does some. I’m sure very active routing. Right, and whatever application, whether it’s built bespoke or whether some off the shelf application is used or or an existing framework is used to develop some application, whatever application is used to implement Pub Sub for a gulf stack implementation. That will be an application that itself sits on extra right so it’ll. So the information, the mediator building block has these two main layers one is secure communication, which we can think of as extra code, and the other is actually just another application, it’s just another service that is exposed by an application within the security server controlled by a member, and lives on extra and so we have a little bit of tension in the spec, I hope it’s clear enough. But when we talk about information mediator, we’re talking about at least two very distinct bits of software. One is sort of the extra type of software, and the other is some sort of application that facilitates Pub Sub, and that will have to play by the same rules as any other building block and Ramkumar was making the point last week that, you know, Pub Sub itself could be a building block it’s more of a technical building block than it is a sort of like use case driven building block. That’s about the little bit of tension there and I sort of wonder if other groups are finding themselves, sort of, covering multiple different software implementations within the same building block and how folks are dealing with that
you’re raising I think this is always been there, isn’t it. You’ve got to draw a line in the sand somewhere, right, because otherwise you can you can extend an extended, I don’t know if there’s an easy answer. Unless you have, you know, some kind of set of reference products, or in the background in the back of your mind that you’re using to kind of mark those areas of, you know, because it’s, It’s not a clear space, you know, even with things like the information mediator, it’s very closely linked to other sort of middleware components and functionality and I don’t know I think you just have to, you know, refer back to the dial your applications as a guideline and say well, if we use these ones, as a benchmark, then at least you cover, you know, the large majority of it, but I suspect that when we actually get to, you know, get
started building things in earnest.
Yeah and the products that are different products will be or have different use cases based on either line of business or industry, I would imagine. Yeah, yeah I think that’s where I started. Good.
Max Carlson 37:44
Oh yeah, I was just gonna say I don’t, I don’t think there’s like really a clear answer, um, to this to echo what Trevor saying, I mean I think it does, it is really worthwhile for all groups to look at existing digital public goods and use us as an inspiration. I think it’s fine just in terms of packaging to, you know there’s there’s kind of two ways to do it right, like for instance the security building block is probably, you know, they’re similar because it’s you know it’s a lot of its infrastructural, but there are some, you know, open API specifications and whatnot, that, that that actually make it a full on building block right. But there’s some debate as to how those are split up right, is there one big open API specification that covers everything, including, you know like I am and you know other security functionalities, or are those broken up into modules. So I mean I’m, you know, I think it’s, when in doubt, I think it’s always good to try to separate things out by concerns, right, and break the modules up that way. And so to that end, you know, it’s perfectly fine for workgroups to deliver multiple building blocks right so if you look at registration or sorry registries, they’ve got a ScreenFlow registration, they’ve got a registry or database type thing, as you saw earlier today. And so, you know, and even possibly, you know, I think we’re putting this on the back burner for now but there’s also a database adapter building block that could potentially under that domain so I guess my guidance would be to try to, you know, do what Trevor said look at digital public goods and see how they’ve kind of divided up the functionality and use that as a model. But also, you know to wherever possible just separate things based on concerns and then, you know, it just becomes much easier to concern consume the service because if for instance there’s an open API thing for information mediator, you know that that can be folded together into one thing or you know maybe it’s makes sense to have the Pub Sub API’s be completely separate and as separate entity, but it you know.
Yeah. Can we go to basic architecture diagram, where you have indicated that network of information in various building blocks to make their, which helps this clarification.
Max Carlson 40:11
I’m not sure exactly which one you mean, um, well we had two diagrams one showing API gateway one showing information, oh those Yeah, sure. Yeah, so those are. Yeah, sure. Let me let me, let me pull that up here a second. Yeah and I think I made some improvements to the, to those documents so yeah. Um, let me just share my screen. But I do want to make sure that we get through everybody and do their stand up at least because we do we’re a bit short on time this week. But yeah, let’s do this quickly. So, yes,
one thing, yeah, yeah, zoom in a bit. Yeah. Yeah, so the information mediator is sitting in front of every building block. Yes, I haven’t seen the Pub Sub, per se, the functionality of pops up. Yes, a central function, people can send whatever they want to publish, and it can send also ever wants to listen it doesn’t have to sit in front of each block. See that separate building block, which can be sitting in one place, it doesn’t replicate with information video to everywhere.
Max Carlson 41:25
Yeah, I mean it could be or, you know I mean maybe, you know, if you do that then every, then you’re just basically saying anybody who wants to use Pub Sub, you have to you have to know about this other building block in it. And I think that’s okay, you know, but, but on the other hand it’s it’s coins are registered with pops up. Yeah, so, I mean, uh, you know, the one common is like, if you do put it inside information media, and you put the Pub Sub functionality in there and the API is in there, then it’s a little bit more closely integrated in that are tightly integrated in that this building block can publish an event, directly the information mediator, they don’t have any other, you know, they don’t have to worry about connecting to some other service. So I think, you know, I think it’s a more in depth discussion but above all, we want this Pub Sub functionality to be easy to use and accessible to all building blocks so I think this is one case where we, you know, want to make sure that that we’re, you know, following that directive and doing whatever it takes to make it easier to use. So, and I don’t think that I don’t have a clear, you know, I don’t have a clear understanding I think this would be a larger discussion of, you know which direction is better. Yeah. So, and then there’s this sort of, there’s this nice diagram that Christo put in here, right. And, you know, this is sort of making the. So this is sort of more of the way the Estonian model works. Now, which is that, you know, things can connect directly to building blocks right. So, like, there’s this public internet and you might have gov stack services that are kind of utilizing, you know, a building block functionality. So, you know, I mean the first thing is so you know I fix this diagram up a little bit. But here, this is sort of, you know, another alternative, but emphasizing that there’s technically no need for a public API gateway as long as each API is able to protect itself by relying on the security building block. So this is kind of an interesting take on it and what I like about this is you know the reason why I wanted to show this in particular to the rooms is that, or to the to the groups is that you kind of need. Each, each building block should have should be able to, it shouldn’t rely entirely on the security building block to secure its services. Right. Um, so in other words, each building block should probably at least should just as a matter of practice, connects to a the security Identity and Access Management module and the security building block and validate that the credentials that is receiving actually have the rights to access the service that is a building blocks should be doing their own authentication, you should not entirely rely on the security building block, or like the API gateway to do that authentication right it can be sort of a first layer of defense, but you also want to recheck, or at least have the capability to recheck those authentication tokens. When they hit the building block itself. So, um, I guess, you know, the thought is that, uh, you know, it’s very important to make sure that every component, really liked the way this was written, the GOV SEC ecosystem is both externally visible and autonomous and it’s security. That means every component should be able to validate requests made to it. They don’t rely on the security of say a public API gateway, and what it means is technically it should be possible to make requests directly to the building block. If it’s open for public network and has its own API, right. So, in that case, well you could still use a single sign on for the security building block right the authorization, right, or the authentication rather that the person says who they are, they are who they say they are, but the authorization of them being able to do or not do a specific or make a specific request into the building block really is kind of like determined by the building block itself anyway. So I think what Christo is saying is that, given that you need to do that then each building block should also probably be validating the authentic the authenticity of the request, and also using utilizing the in the security building block to help determine whether or not the user is authorized or not. So, it’s just advocating for making sure if we really want these building blocks to be autonomous, from a security point of view, they should be validating security credentials as well on these API requests. And so this is something that I just wanted to throw out there I think it’s a really good idea.
That discussion on this just the past meeting. Yeah, I think the surgeon came up. Yeah, this is very point to nail down, because otherwise, each building block will be in the same situation as to what they should actually do with respect to authentication who is going to authenticate.
Max Carlson 46:27
Exactly. So I think the, the security building block has an identity and authentication module, right. It uses that module for requests through the API gateway right. So for example this diagram up here. So, however, each building block should also be able to connect to that identity and access management module to both authenticate requests, and to, you know for authorization. So, and that that is just an additional layer of security, right. So then if somebody misconfigured a public API gateway, then the citizen ID auth is still checking before it goes ahead and fulfills a request as to whether or not the user is authorized, and first authenticated and whether or not they’re authorized to make that request. So I do think this, this, it’s a bit more work, but I think it’s a it’s a it’s a really strong suggestion.
And what a split like authentication is done at the API but authorization is done by the, I mean, by the gateway, but authorization is done by the application.
Max Carlson 47:38
Yeah, exactly. I think there’s a split. But Crystal’s point is you don’t actually need every single request going through an API gateway, if the building blocks themselves are secured in an autonomous way. And I think that’s a really good observation, you still may want to use a public API gateway, but you’re not mandating it right. So,
I put very simple once you authenticate, the moment you authenticate. This guy can use this service, and you wrap into that service internal to that service you are authorized to have chickens authorization.
Max Carlson 48:13
Yeah, yeah. So, you know, I think this is just something I wanted to raise, It’s a good point. I’m glad you brought you raise this Ramkumar, it was like perfect with me this dovetail of like, you know, this debate that we’ve been having so Christo is you know he’s kind of just looking at all of this stuff and you know so this is some feedback from him. But I think, you know, making sure that the security bill are that all building blocks are autonomous from a security point of view, is a really good practice. So I want, I wanted to raise this so all groups are thinking about it. Um, and then we can kind of continue discussions around that. So, but I do want to make sure that we kind of we cover everybody. Anybody have any questions or comments about this.
Yeah i i That as long as as long as we’re sort of on the same page, that individual building blocks will have communication that takes place with the public Internet, that does not involve the information mediator, at all. Because they, they might have user interfaces and they might have browsers or mobile devices that interact with their API’s and we’re and we understand that will happens completely outside of the information media or happens outside of Vectra and happens outside of sort of anything we even think of as as secure communication, and that they’re sort of responsible individually for designing decent software and web browsers can talk to servers in smart ways, then I think, I think I’m on the same page but I wasn’t like 100% sure if I was hearing that.
Max Carlson 49:59
Yeah, well, I think that, just to be clear, everyone needs to understand, to your point, that information mediator is really only for API level communication, it’s just doing
between between the building blocks
Max Carlson 50:14
between building blocks and it’s just doing this JSON over HTTP between building blocks. That’s all it does right it’s not going to serve up HTML, like that’s something that’s been decided.
Max Carlson 50:54
Complimentary true. Can we agree that all user oriented interactions with the system will back to API gateway. Whereas interactions between back end systems will pass through information mediator.
Max Carlson 51:13
Yeah, and I think that’s kind of what this document shows or is trying to show is that you have the web UI, and those are served up somewhere else, and the information mediator is not involved. However, when that web UI needs to connect to get some information, say from the Children’s registry up here or the ID and auth system up here, that happens through an API gateway which connects through the information mediator here, or if this provides you know security and depth, then it can also the web UI, the UI could connect directly to the API and event module here but either way, it’s either going through the information mediator, which I think is, you know, that helps with the security, but there’s also this possibility that Christos, advocating for where you have the ability to connect directly right to a building block on the internet right but there’s still these, you know lines connecting, you know the information mediator, and that facilitates still facilitates the secure connections between building blocks. So yeah, so just so we’re clear, yeah, the information mediator is only handling Jason over HTTP, for connections between building blocks in the Gumstix system.
Okay cool, I think I can satisfy, sorry.
Max Carlson 52:33
No, no no no no, thanks for raising that. So, you know I mean I guess what this is advocating for is that other building blocks aren’t entirely dependent on the information mediator for securing them, And it’s probably a good practice, right, because, you know, it’s more it’s, it’s, then you’ve got security all the way, you know, security in depth.
So I just want to raise that makes a brilliant blog as a front end and a back end, front end is going through its own authentication system one two and a very good backend is going to the information mediator.
Max Carlson 53:12
Yep, I think that’s, that’s the right way to say it. Any questions concerns or comments about this. I’m glad you raised it Ramkumar thanks for bringing that up.
Okay. Maurice imer, you can be had the same discussion right. So from your application perspective. This suits right, this paradigm.
Yes, yes, meaning that that’s a good example to print out all the communication with the user has to go through the API gateway so it’s a direct web access to quote our survey. So from your point of view the publication is a valid step publication that sense is that we’re, we’re publishing a version of a service. And this version of a service is a basically a web page, which is not using does not have to use API gateway or 10 counties use when they are requesting data from and other building blocks. But if it’s a simple online webform that has no connection to other building blocks, then it is not communicating via information mediator, it’s just communicating directly with the user, the other page. The API gateway literally routes redirects to your URL. Well, in that case when the, when the Single Sign On is used, then I guess yes, but if a user is not authenticated then they will just will be directed automatically to the URL, we’re giving them, they’re just opening the web page of a service, and then they, they may want to log in and then the user is redirected to the authentication module or building.
Max Carlson 55:14
Yeah, I think that’s correct. I think we really need to, you know, work out these flows in depth. And I think when once we you know once we once we have, you know, concrete, open API specifications, then we can start working out the, you know, security requirements there as well. Right, just to make sure that building blocks are as autonomous as possible from a security perspective, and don’t depend on the API gateway necessarily or information mediator, 100% for their security, but use them as an additional layer of security, I think that’s, that’s the message that I’d like to, you know, talk to take away and don’t stress about it, we’re here to help you, you know, write the eight get the specifications to sort of follow this methodology but it does mean that each building block is probably going to have some more detailed specification, around how it does authentication and authorization of users, right, where needed. Okay. Um, so I think that pretty much covers stand up, I mean, from the security or from the architecture working group, you know, we’ve just mostly been reviewing, you know, trying to make sure this interoperability story really holds up. I mean I think there’s still some, you know, just to be clear I think there’s still some, you know, particularly when we’ve been talking to open MS and open HIE, because we’d really like to have a proof of concept or we’re talking to an existing hospital information management system or a portion of one. What that really means is essentially using the fire protocol. And I think, so if we can build a fire adapter that facilitates that, then I think then that’ll kind of overcome some of the some of the, you know reticence or, you know some people are still a little bit, kind of unclear about how go stack is going to help them, you know, so we, short, long story short, we’re trying to make sure that we’re as interoperable as possible with existing systems. But I think that we’re going to need to do the work inside of Gov stack to build these adapters, I don’t think the outside community, you know, is going to build a fire adapter for us, you know, I think it’s gonna be much better if we build a fire adapter that has some sort of partial small functionality, let’s say InnoGear integrates with open Ms. And then they could use a, you know, for instance, they can use a substack building block for processing payments within their service, right. So I think starting with some sort of small interoperability story and then giving people at least a starting foundation for, for some of these adapters that at least shows an example from the substack side is going to be really vital so that’s something that we’ve discovered, and then just continuing to work through this story, right, again, you know this high level, big picture of how all of these systems connect together including, you know you user interfaces. So, um, so, update from our side. Alright so, I think, does anybody have any questions comments concerns that they’d like to raise. Seems like we’ve lost a lot of people. Um. Okay, well let’s, let’s just, I guess that’s that’s enough for stand up then. So Ron Kumar Do you want to talk about your checklist, I know you had to you had asked for some time. During this meeting to to go over that with the groups.
I think the all hands, guides, they also, they also provided a 15 minute slot on next to go through the same thing. So maybe it is better to review it with everyone.
Max Carlson 59:15
Yeah Not everyone’s here, and we’ve got a half an hour until the big meeting anyway, so I guess unless anybody has anything else that they want to cover. I propose that we drop off. And everybody can polish up their slides and I think so that’s useful at this point. Okay, cool. So I have one more request Trevor, can you send me a brief bio, and I’ll try to slam that in the deck, otherwise it’s not going to make it. Oh, yeah yes sorry I’ll do that now. Sorry, no worries. Okay, thanks so much, everybody. Thanks, thanks. Okay. Bye, everyone. Thank you. Bye.
Transcribed by https://otter.ai