Hello, that was word by my browser just crashed. Okay. Welcome movie. Alright so, anyway, we're just going through this process, you know we're talking about this security building block definition and how we publish that online so I'm Canadian. Can everybody hear me okay good. Okay, cool. So, um, so we'll get that published, I guess the other thing that I wanted to, you know, talk through and show you guys because yesterday was really super productive. If we worked out these Identity and Access sequences that should walk work for any sort of building block. Um, so you've got this self registration worked out, and we can look, look at this, but this has worked out and you know it is a cooperation between security and registration and, you know, architecture so work that out yesterday. So this is how you would register a new account. Oh yeah, what's your screen, I hear you but I can't hear. Alright, sorry. Um, okay, let's see. Right, so can you see it now.
Yes. Perfect,
yeah. Okay, so, um, we came up with these basic workflows that should be able to be reused or pointed to by any building blocks so these are just going to be standardized workflows. Um, so, uh, you know, pretty straightforward, but it clearly shows how security, and any, any building block. So these are more generic and if you've looked at these last week, they were kind of specific to registration. So this shows how any building block can, you know, facilitate, registration, um, right, so, um, so that's cool. Um, and this is registration via phone number email.
Right, so he said we we've, we've mentioned here this this is specifically a UI pattern, or is that just because it was the example.
It's specifically a UI pattern because you're gonna have to have a form right. Yeah, I mean it. I guess it doesn't strictly have to be but it seems like you're not gonna be registering a new user unless you're presenting them a UI, what's kind of the thinking.
No, I think it's good and I'll tell you the reason why is because it doesn't, because it explicitly excludes information mediator, which is I believe what we said for you is that when you do an authentication of UI you will go straight to the security system without going through information mediator, correct, that's correct. So, this shows exactly that. Yeah and that's why I think it's a good idea. So I think from the feedback that I'm seeing that this makes a lot more sense and is far less ambiguous.
Yeah, so totally clear right, great. I'm glad you feel that way too, because we
get max I just had one more, one more important. Yesterday, I've just been thinking on this diagram. At times we speak about, there is an application layer, about which consumes building blocks, right. So, in such cases between the user and the building block. Will there be a need to put something called application.
Yeah, I mean there will probably be an API, a you know a gateway of some kind. I mean an API gateway.
So, so essentially the user registers into the application and not into the building block. Well guess is already tied up with building blocks in the back.
Yeah, I mean sure yeah i mean you could think of it that way, but, but you're still going to be sending the forum somewhere right and and and it just says that this says you I mean, really, posting the form is hitting an API anyway. Um, but this just kind of makes it clear that the users, you know, accessing via form, which is really how this is going to work. Right.
I mean, let me just say the example, I am just getting into postpartum. Mother Child Care application. Yeah, and postpartum Mother Child application may use ID blog payments blog, whatever blocks. Yeah, so I really don't care, right. There is a payment block, there is a certain sub block I only care about my front facing UI is only postpartum Mother and Child Care application. Yep. So, in that sense, the user has to interact with an application UI. Yeah.
Well, yeah, but I mean that applications made of building blocks. So, you know, I mean we could change this to say application but I think the important thing is that we want to make it clear that every building block that presents a UI needs to follow this pattern right so if an account is required, then they need to force the user through this exact patterns, regardless of what the application is or which building blocks, it's made of, like, the user is going to be talking to a building block that's going to be presenting some UI. And so, yeah.
I'm still thinking that the application is that is the only thing that talks to a building block. The user doesn't Veritate talk to a building block, that's my I'm just thinking like,
well no I mean they do though because lots of building blocks, including ID and security, and certainly registration, they both, they all publish you eyes. So, when one of those users requires an account, then this is the pattern of how a user would register themselves.
So, if you compare this with your diagram that you had put for information mediator and all that, you had the network diagram is this compliant to the diagram.
Yeah, absolutely. I think so. Um, okay, so, um, and then we have this, uh, you know, self registration with foundational ID and this is a little bit more complicated, right, because this is where you want to choose a service and it says, oh, you know, you don't have permission, really. So then the user talks to the foundational ID, they provide proof of foundational ID with along with their email and phone number to the ID building block. And this is also like a UI, right, there's some sort of internal process flow could be instant could take days. And then the user receives a notification, right, that it is validations complete via email or SMS or phone number that they provided, and security, then the foundation ID is responsible for provisioning the user account with role based access. Right, so say this user is a doctor, and they're trying to use a medical application. They might talk to the building block UI and it might say, Oh well, we're gonna verify you. And if you don't if you're if you don't have that role, then your ID is going to get validated by some sort of flow, and then the you're you're going to the user is going to be provisioned the user account with role based access. And then again the security email sends an SMS or email with validation the user clicks that, and then they're registered and provisioned with this new role. So this kind of covers how, you know foundational ID can be used to, uh, you know, to validate a user. And then in addition, provision them roles, such as access to a medical application or a farm, an application for farmers say,
okay, okay, I'll just give it. Give it some time. I think that they I don't see the there is something about flow between these building blocks, right, where is that managed well, it's
all in the arrows. So,
when I said if I'm logging into some doctor's application. How does the user know what his doctor application.
Well, they don't. They don't know I mean, the the doctor, the doctor application is responsible to say this is a registration, like say this is another child MTTs mother child tracking system application that we talked a lot about so this would be a registration UI, Right.
So what I'm just asking what brings up the registration Why, what is it that brings up the registration, why
the UI, the user basically clicks a link. So they have a list of, you know, they go to some portal, it's got a list of services they click a link to a service say M CTS. And then this,
there is a portal in the front.
Yeah, I mean it could just be a static web page right of just links or it could be a bookmark. It could be a link you received an email, it doesn't really matter.
Yeah, no, no, no, I am only I'm only suggesting that back whatever the portal is in between the user and the building block UI as a necessary step of navigation.
Yeah, but it's not necessary, because if I send you an SMS that has a link, and says okay go register here, then you just click the link and you're right here, you don't go to the portal. I mean all the portal really is
is a list of links that is fine. I'm just thinking example an implementation perspective, would there not be something in the front where the user goes and chooses a service. Yeah, this service, you go to that building block is something in which links so this particular sequence of calling building blocks right, and we were calling that screen to all these why.
Well, I would say that that Ramkumar that that portal that you're talking about really is just a list of URLs and it could just be a static web page.
Yeah, okay. So, say something. Yeah, let's navigates me to the building block.
Exactly, so the user just clicks a link
block is an output to zero, and all that, I don't know unless you give me the page,
right. And so the user like, you know, the idea is the user clicks the link, this, this application says, Oh, I can see, you don't have, you're not a farmer. So then it redirects the user to the foundational ID verification UI, the user logs into foundational ID verification there's some sort of process flow, then that's completed and then they get provisioned for the new role as a farmer, and then they get a validation. And then they're in so then the next time they visit here they can get in because they have this role.
So the flow is fine. Yeah, that the very first time that fellow has to register as a farmer. He should see somewhere. Okay, here is where I registered as a farmer. Yeah, static page or a dynamic page is in front of the user, between the building block, and the user, there's no way for the user to route himself to a building block.
Well no, I mean they can, they just click a link right I mean in that link could be on a QR code on a billboard, it could be in an email could be in this mess. Yeah.
Huh, who use it to the first instance, how do they get to the link.
Well, they either click a link on a, on a static web page of like a list of services, or maybe they receive an email or an SMS that says hey, we've targeted you you should go register as a farmer,
or something that prompts them an SMS with the link or page with the liquids or something like that thing is in between them and routing. Yep, navigation, yep,
you're exactly right. I think that's exactly right Ramkumar, yeah. Um, but it's sort of like outside the scope of this registration, so that's why it's not shown here, it's just like the user chooses a service and then they're kind of logged in.
Okay so then it's a precondition, the user, user has been presented with the option, and has chosen. Yep, this particular
Yeah, somehow they clicked on a link, you know whether you know, and then
medical condition would have been mentioned, yeah.
So I mean, let me just put that.
Okay. All right, great. So, um, alright and then so here's how authentication happens.
Just two quick key phrases raise my hand problem is, sorry. Yeah so I think you will hear this from other people also so the foundation ID block is not the entity which provisions the user. It has to be the building block UI which provisions the user, the whole of the foundation idea is I authenticate you and I tell that this person is sovereign. So, yeah, then I put that person in the security Iam provision or not is again a call based on the business rules.
Okay, so I'm gonna just go ahead and I'm just gonna put a comment on here. So, uh,
yeah I think this kind of comes back to a kind of a broader point to that, that external master data is used within rules to to give access to business roles. So, if you look at most governance solutions, it will have a role in that says if person is a valid doctor in Ethiopia as an example on that request then grant. So what will happen is that the security Iam will look at what is the role for the business role, and it may it may go back to a foundational ID to verify the details and I think this is the patent is trying to be explained here. Because your rights foundation ID is not responsible for giving an authorization that sits your security, but IV foundation is responsible for verifying the rule that is association to the, to the giving of the authorization, which is really insecurities back and this is I think where a lot of confusion within the teams and it's rightly confusing. But generally, there is a policy, a rule, a policy wind security engine that says, People who make these criteria, can have this business role or this functional role, but the security system doesn't hold that information, and it cannot verify that information. And that's I think where the foundational ID comes in. Right, so
there's all our foundation ideas if you see what is the philosophy of foundation it is it is a minimalistic IT system it just proves, who you say you are. It will not say whether you're a doctor or an engineer or a farmer, all that will be held in functional systems, It will not be held in foundational ID for this it will only say that this is an intermittent is an intermittent and engineer. What she did is that the employee versus the girl bank employee that has to be verified with the respective system, all that, while with the GIS. From the side, you will always have this is the least
one more important. Folks, this continuing on, on that. Again, I guess, I mentioned this very briefly but I just want to reiterate because there are more people out here that there are two things. One is about verifying whether this person is a doctor, enrolled in a hospital or a staff member enrolled in a, in a bank or something, which is different, which is to say is this person, an enrolled employee. But the other thing was about. Is this person a qualified doctor. Is this person a qualified lawyer, is this person, owner of a specific piece of land. These are not foundational IDs, and they are not that they are the essential verifications required in order to authorize that person as a form. So you need to verify that and say yes this is a farmer. Yes, this is the owner of this land. Yes, this is a doctor. And that is required for any application the security, to have a guarantee that this guy is a farmer in order to authorize them to do certain things, right. So, that piece of verifying whether this person is a qualified doctor is very similar in the process, as compared to verifying whether this person is a valid citizen, because here you're comparing passport or some other documents. They're you're comparing their ownership documents as a as a education certificate or ownership of a land certificate or something. So the ID group has been saying that the process is very similar. The documents are different. So it may not be called foundational ID, because it is not relating to a an individual person's identity, but it is related to the profile of that person, whether that person is a farmer or a doctor or a lawyer or father or whatever.
So, so we should just refer to his ID building block is what the recommendation is, because it can cause confusion because foundational ID is a subset of ID building block is not the complete building block is the one that deals with citizen, an individual.
It building blocks, right, another way to say it building blocks are learning all types of ideas. Ideas a farmer ID as a doctor. Yes, okay. So we have to convert on that because that is one thing that is calling, causing a hell of a confusion right we have to create various for various groups related Yeah, I think we have a smooth way. Yeah, I
think that's a good point. Yeah, because, I mean, I think the the problem is that this kind of language is more often, maybe the other building blocks like myself didn't realize that, you know, the foundation ID has a very specific meaning of a subset of ID building block, because you know again if you read the document, it doesn't always clearly differentiate. Maybe it's changed since I last reviewed the document but when we last look. I last looked at the ID building block paper it was referring a lot to individuals. And that's maybe where it's getting confused so maybe when the team get back, Valerie and the team get right we can we can clarify that.
So I think we're gonna you know this is sort of like the unfortunate thing right is, we aren't able to actually meet with ID team so it's difficult to hash this out. However, you know, hopefully that that system will that situation will improve soon but what I like about this is it really isolates their functionality into just this reusable flow. Right, so at least when we do manage to meet with them. The only thing we have to hash out is how these roles and and whatnot are actually assigned because it might, you know, to a neatest point it might actually say okay the users provision the building block UI might be the one that actually, you know, does some more validation, right, to make sure it's a farmer, you know, who knows, right, and maybe the building block is responsible for provisioning the user account with role based access as a farmer because only the building block knows about that, or maybe as part of the foundational ID, who can say are the ID building block right.
Yeah. If you just replace that Id bracket foundational ID, yeah just ID. Yeah, that is, that then I can take an action item, you know maybe max, you and me can meet up with him one day with it between black and
white, I mean the thing is, yeah I mean I don't know that, you know, I mean I think I'm just gonna put these suggestions here. And then we can review it with, You know, security and whatnot and at least with a team we can and I think it'd be good yeah if you can set up a meeting with ID so we can sort this out that'd be really helpful, Robert.
I think the government is in the comment, it is not because it may be validating, because it can validate.
Yeah, and maybe. Okay, well I'm not sure that that's true, based on my conversations with, with, with ID so.
Okay, I'm just quoting last week's conversation there. So,
I'm just gonna put that there.
The process is very similar, only the documents are different. So that's what I gathered,
okay, well, so let's do we also want to flag that in this scenario, you read the bill of IQ I would have would be responsible for configuring the types of roles that are available but the security building block needs to provide
the administrative functionality to configure roles and then associate specific users with roles and permissions.
Exactly. And so all of that actually has been so that's the other thing I know that David Yeah, I know that David was adding all of that so a lot of that's already been added and this would be kind of an automated back end API based way of doing it is the idea. Because the presumption is that either the building block passes the role required to ID and then it does the determination I guess that's what this was kind of saying, and then once they're validated then it just gets provisioned. But yeah, there might be some additional workflow to determine if they're really a farmer or not or maybe that's this internal process flows enough, maybe it's all handled by ID I don't know.
And I don't know I'm just saying I do we also need to flag the part of the process where we configure the system as a whole in terms of defining the roles and
yeah so we did, we did flag this here so that role creation is handled by the IAM solution via either an admin UI or an API, so we did. We did flag that down below because that, that came up yesterday so I'm glad you brought that up. Okay.
Just for clarity sake. Yeah, the role creation lies with. Yes, farmer, etc. Yeah, but what a farmer can do or what adopter can do really depends on that particular building block right,
yes that's right so in that we kind of go into that in the next diagram here. Right. Um, so
just a quick clarification. So is the security building block going to be been for the whole of government or security building that is going to be part of each application.
I think it'll be probably more like one of these for each ministry.
It can be federated with like one face.
Yeah, I mean, you know, I think you'll get best results if there's one security one instance per government but I'm not sure that's realistic. So I think, more likely would be that there'd be one instance of this Iam person PR ministry. Right.
Probably, yeah I mean, well, you can have multiple applications right
yeah you can have multiple applications but I mean so when you consider the use case of, you know, postpartum infant care. There are all there are several applications that are all run by more or less the same people. So in that case I can imagine a security, I am solution being shared across those applications within that ministry so say the Ministry of Health. Um, and that's just based on the work we've done around use cases but the point is to make it flexible, right, so there could be one of these for government, which I'm not sure is realistic, there could be one per ministry, which may be more realistic or even one per application. I think it's up to the person, setting up the solution. Yeah. So should I put a note there about that because I mean I think this is the kind of question that's going to come up a lot, so I'm just gonna give credit where credit is due.
So I think we can, you know, address that in this document make that more clear. Okay, anything else. Sorry I can't see if you're raising your hands.
From that point of view, I don't only think that the security, the IAM has to be scalable, if required.
Oh yeah, definitely.
From an individual application to.
Yeah, exactly. Okay so let's, let's take a look at the actual authentication process so these are how you create an account so now the user has an account. They've got an unauthorized attempt to access a billing bucket notice this doesn't say UI, it could be a UI or an API is the idea, and then they're redirected to a UI that provides authentication. The UI user provides authentication credentials. Just Security Security returns an auth token, then request access with the auth token to the building block. The building block then validates the auth token, the tokens validated and returns a list of roles. The building block determines access rights based on those roles, and then returns a result.
Okay, the building block may actually not even display things that don't have access rights.
Yeah, I mean, well it's not going to display it I mean if you hit something and you don't have access, then it'll just redirect them to that, but if it determines here that you still don't have access rights, it'll return an empty result or an error message, but it's going to return some sort of result. Yeah.
So this is just for the self registration use case holder saying this is applicable for both.
Well this is once you've done self registration or internet or. Yeah it's applicable to both whether or not there's foundational ID or not involved.
A foundation IDs involved this doesn't make sense because the whole purpose of using foundation ID was to authenticate the person, store the credentials, there Right,
yeah. And so why is that once the users been provisioned these roles. Then they shouldn't need to talk to the foundational ID anymore. Right.
How do you establish identity. So suppose I have established my role. Once I logged in today you established me as a user in the mother and child care, tracking system tomorrow again if I want to apply for the second service second installment or check my status. When I check my status, the authentication happens through do I create a password or can I use my foundation ID to establish my identity.
Well, the way this is written is that you always have a email or phone number as an account and then that is essentially validated, along with your foundational ID, and one series of steps here, and then that determines whether or not you get access to the role. So, for
once, you are recognized as so and so, in the system, you don't have to do that again. Just know once I
know that I'm Kumar suppose I am recognized right Anita mittal@gmail.com. Next emanate comm.
As the person
can issue their
password or username password.
So but that flow is not there in the foundation it bases the password coming in the foundation ID. I didn't see that.
The next time to do that in order to get into this.
So you're saying the user will have a proliferation of passwords for each building block or each application you will create a new password.
There is a single sign on, and that requires your personal authentication, the very first time, you are recognized as a valid person to interact with those. That's my assumption. That's correct me if I'm wrong.
Yeah, so I mean, the idea is it's assumed that users click the link, and they have authorization, and they are authorized, you know, a with a valid access token for their email or phone number.
No, I think that makes sense to me, I think we're missing stuff, because a person is saying that talking about all of government architecture with a single account for accessing any service across any application, which is all interconnected with that architecture in which these workflows are being done. Are there more generic. Well, I mean the.
So, yeah, so the idea is, and can I just say I'm so happy that you've joined an EDA, I mean having you having you here has been invaluable. So, thank you so much for that. But the idea here is that the user creates a account, right, and then, in essence, as soon as they're trying to use a service that requires a foundational ID that foundational ID is bound to their user account. Right. So, so they might, they might not, you know, it's kind of up to them whether or not they have multiple usernames or, you know, accounts or not.
In principle, can I assume that if I start as Rob from the first time I registered in some application out here, it very funny me, and it said yes this is rockmart gave me access to the system, whether that access means you're giving me a link that you're giving me a username, password, that's something of a detail we'll work on but you gave me an access thereafter. And now I when I registered into the system. I registered as adopted. And he verified whether I my doctor certificate is fine. Right, but next time around when I'm registering a B either I'm also a farmer, by the way, so if I register as a farmer into some other program, I can still access the system, but I can't use Farmer program application, unless I register into farmer application. So when I register in the farmer application, I don't get another username password but I just get authorized to use that also, is it not, because I've been verified as a farmer.
Yeah, well I mean it's kind of up to what you provide when you're requesting access here, right, so there might be, there might be a requirement.
A very important point. If we don't do that, we will be providing tons of usernames and passwords to the same that.
Yeah, well, I think it's optional though, I mean because if the user wants to create or, you know, there might be, say that this user is a doctor, and they're required to use our hospital email to create the account. Right, I mean, that might be part of the policy per Trevor's, you know, come in earlier. So they might have to be, you know, using their doctor's email here, you know, in which case, they'd be creating a new account, if they use their Gmail Anita, Gmail, if you are registering for a doctor, then it's just going to bind that role to that already existing account.
Yeah, that's what I mean when you bind it to the existing account, you don't need one more username and password after that.
Now, and so you can bind the idea here is that if you provide the same phone number or the same email. You can be bound into multiple roles on that same account.
Yeah, so therefore single sign on. Otherwise, yes Single Sign On fails,
but you can't force the user to not have more than one account I mean it's kind of up to them. Right. And it's also up to the policy, whether or not you know they're provision an account here or not, I mean, there might be some error that happens you send him an error and say like, Oh, you have to register with your doctor account ID might not know about that but security might know about that because of policy. So then they'd have to start over and say like, Okay, I'm gonna try again, Using my hospital email account. Right. So,
that means that
the security building block would manage all the roles that are possible in a build building block. Yes, that is a practical I'm just
trying to reflect.
Well, yeah,
I mean, it's a new feature than they would have to announce all those new roles to the security layer as well.
Well yeah, I mean if they're new feature requires a separate role, and separate permissions. Then somebody who's building the application is going to have to go in and create the role in the I am solution, right, via an API, or via the UI. But the role or the role is, so you get this list of roles here right. And it could be Doctor farmer, parents, whatever. Then the building blocks, based on its fine grained requirements looks at that list of roles and determines whether or not that's enough, or what type of access to provide, and then it returns a result based on that, so it's always up to the building block to determine how the roles, apply to specific controls or access inside the building block itself
mess I think we have gone out on the right track if you're thinking of this architecture, probably we should pause and revisit, having the single high end, which is shared across ministries will not work because you have independent vendors, contractors working, and if any security loophole happens in ministers stop I have the farmers application. It is going to cause a lot of issues to everything. If you look at Estonia or any existing government application. I have not seen a single Iam solution for the role of government.
Yeah, I would agree with you, I mean I think it's much more likely that you're going to have one per ministry, personally, because
you're going
contradicting contradicting what was just now is that are we having the single line submission which is keeping rules for a farmer everything. So I, if I have two minutes, I can just tell you the way I'm looking at this field, the better person proves his or her identity in this education factor a credential, which could be a password. It could be a biometric, it could be a smart card, anything. Yeah, and if we want this whole of government architecture, we can say there are three identity providers, or four identity providers, or one. Yep, in the comments if it is 100 is the foundation Id like I've had in India, I can use my hard hat identity system. To prove my identity across all systems that are connected to other, but I go to my passport system, or go go to fair price shop, or I go to driving licence. All of them are connected to each other. And every time I say I'm Anita, I can use whatever user name for that function ID system, but my identity is established, only by other addresses Yes, she's Anita with ID number 1234567. Then the functional ad system can map me to a farmer, or to a student, or to a patient, they can create
their own
role and responsibility for me. But every time I prove I come and say hi Melinda DeVos as the foundation of this system, she's claiming to be Anita Can you prove. Is she claiming right, but she's Ramkumar when she's claiming to be Anita, how do you prove that that is true the dedication factor is could be password biometric or the smart card, or the OTP.
Exactly and that's that's intended to be captured here by this internal process flow. So this could be, you know, looking at uploaded copies of your passport, it could be real time where it's just, you know, checking a signature from a smart card or whatever. So this is entirely open ended, what what what the requirements are, and what happens internally is kind of a opaque to us. Right.
They should separate that what is the authentication that the person proves the identity in aggregate talking of remote, remote transactions. So if I'm sitting at my goal, and trying to access a service, I need to prove who I am. And that can be done by an identity provider, whether its foundation ID, or it could be a functional Id like a driver's license or passport system if they have an online authentication system. If you look at the European countries they have many other medical providers. So here we should say it's an IDP identity provider, but its foundation, it could be a subset, or it could be a functional ID. So anytime you go to a building block you want to create an account, they say establish your identity. Yep, it goes up, it could even be Gmail. So Gmail or Facebook is claiming my identity, that he has anatomical@gmail.com is a known person that this password. So it actually tickets me establish the identity that I go and create an account, and the time it has a mother, a childcare
customer.
If I go to a passport, which makes me a passport applicant, because I see the role of an applicant.
Yep. Yep. Um, I think that's where this ID building block. If we just generalized not just foundational ID, foundational and functional ID can be used for. As I mean it can be housed in the runs of ID. ID provider. Yeah, right. They have been called by various AM's Yep, as a need for authentication, but it does not imply that the one single, single aim. That's why I was saying, if you go back to Mother,
there's not going to be one single I am
right i mean that's really unlikely, and you both have that network diagram makes a lot of sense. Then, you have already put it there. Okay, in your architecture to have that network diagram, where you are shown information mediator. Yeah, connecting various building blocks, yeah, you have this in front of each one of them. Yeah, security, block is in front of each of those building blocks.
Yeah I mean conceptually That's right, yeah.
So it's not necessarily that it needs to be monolithic,
no it's not necessary at all so I mean I think, you know, I think we can all agree it's most likely that you'll have one instance of security, per ampere per ministry, right, and you'll have probably one instance of ID across the entire government. But the idea is to build this something that's flexible so you can support different combinations.
Yeah, but I think we've discussed this entire interface between how the building block will propagate its rules to the security I am very briefly last time. I think that has to be kind of as as that thing is an example for that available here now in the security building block.
Yeah, I mean, right, right here. So, okay, so User's Guide they you know, then they get this, they get an authentication token. Right. And then that's validated. You know they pass out token to the building block the building block validates it, make sure it's real. And then they get validation and then list of roles, and then based on that list of roles the building block decides how much access to user has like, keep in mind the this building block could be restricted to only talk to the ministry security system, or it might be, you know, right, it might be.
God does not have to publish to the security tool I am that I have got this five roles. So, the thing that I am is only checking what rules, you have that, and publishing into the building block, we are I am no clue what the building block requires,
right, right, exactly. It doesn't know,
say a building block requires another role which is not there right now, you're going to ask, but then it has to have a method of registering that particular role,
well that's what this is. Yeah. Okay,
so therefore there is no dependency for Iam to know now what roles are there.
No, no, it's completely generic right and it's so absolutely.
Okay, don't have to teach them what all rules are there in the system.
Well you do at some point, like you have to provision them, right, you have to say like, oh, you support farmers and doctors and administrators and whatever you know, liars, whatever the roles are right, somebody has to set that up.
That that setting up depends on what building blocks are put up there.
Exactly, it's up to the solution provider and you know, I think a neatest point is really
the backend backend configuration which I don't think is in this project.
Well, it's gonna be. Yeah, exactly.
So, are you are you thinking about some sort of protocol where the building block is informing the security layer, automatically about the roles that exist or do you think that something implementers would have to do manually. I mean, it doesn't.
I think we discussed this with the security group. There is somebody here from security touch upon it again. When the basic thing is, unless the building block tells the security. Here are my roles, there's no way for security, otherwise to know.
Yeah, so I mean you could do it by an API, I mean there's nothing stopping the building block from saying like hey security system, I need these roles to be created, they could do that.
So security must publish the API.
Yep. So, yeah, I mean that can be done manually with an admin UI or an API, but you definitely want the admin UI so that somebody who's doing like a security audit can go in and say like, oh, you know, should these people really be admins or whatever, right.
I think best is it publishes an API where valid application goes and registers its roles. Yeah, that's it.
Yeah, yeah. Yep. Well it's very clear that there's going to be an API to do that so I think we're good. Okay, and so this, this is just like the technical authentication which this will work for just about any auth method that I can think of. But it doesn't really specifically require you to revalidate your citizen ID or foundational ID. I mean I guess there is an assumption here which might be incorrect. Per Anita is point that you only need to provision the role and validate the ID once when you're provisioning the role as a doctor or a farmer or whatever it is foundational ID I would agree. But then, if it's functional ID, you might have to go check for each time farmer Doctor etc. Yeah, maybe. So, you know,
I mean they're on the road.
Yes, I mean you validate the username and password for sure, right, if it's not authorized then they're going to, you're going to validate the auth credentials as far as security is concerned, which could be.
I feel that if you remove that you lead back in another building blocks. Instead, we just packed that in ID, building blocks, functional and foundational.
Yeah, exactly,
becomes one process.
Exactly. So here's how we do provision a user. So the user says, I want to delete my account. There's some sort of internal process flow, Id provisions with security, and then they get a notification that their accounts deleted. Right. And if somebody dies like the deep provisioning account is very similar process only it's just done by an admin, right.
Last August speaking I'm not able to hear anything.
Yeah. Can yeah I'm trying to speak. Can anyone else hear me
or am I not audible. Hello.
I can hear you fine tune, otherwise sometimes think that the Wi Fi is worse than my home Wi Fi.
Not surprising. It is not uncommon so yeah so I mean we covered D provisioning as well here, you know, but the general idea is that we're trying to get the ID, building blocks out of the way of the other building blocks, and have these kind of generalized flows that are pointed to by other building blocks so that we can minimize the amount of interaction with ID because just because of risk right because we still don't know exactly what's going on with their building blocks, so. Yeah. Okay, so any other comments around this. Before we move on,
just to maybe stupid question. We're thinking about shooting out a contract to some security consultant for opening image within the next couple of days or weeks. Do you think that I could already, point them to the document as well to like somehow given a direction.
Yeah I mean So security consultant so is that for open.
Yeah, it's full of software first, and then I could imagine that in the terms of reference we put, like, one point where we ask for things we need to do to get to get up to speed with security recommendations from Gulf stack.
Yeah I mean I think this document is actually really really good. You know I mean I think there's one big weakness here still. Well, there's a couple so these need to be put into open API specifications, right. But I think yeah I think it's, it's fairly mature you could point them at this and it does have these are all really, really important considerations as far as cybersecurity, the cross cutting and functional requirements are really important to consider. But there's one one big weakness in here which is that some of these things have to do more with process, and some of them have to do more with, You know development. Right. So for instance, let me just see if I can find an example here, um, well even like time sensitive credentials right I mean, uh, you might. Alright so this, this virus. So this day zero infection prevention. Right, I mean this is not really something that other than supply chain attacks, it's not something that the development or, you know, a developers really need to consider it's more like something that happens at deploy time. And so I think this document really needs to, you know, we've asked, or we've. I've asked David and the security team to separate out these things right. You know some of these are more like stuff that you do at deploy time and some of the stuff things. So, this, this also right is something that this might be something you do at development time though, right, because you're requiring that any development be done as open source. Right. I mean, we've said that a million times but the point is that some of these are really have to do more with, I mean, I guess the best example I could find was a this, a lot of this fraud prevention like there's Osen right
are the security incident response right I mean this is sort of like, really important to consider, but it's really more important, it has more to do with once something's already been deployed. Then, as part of the development process so it. The feedback we've been getting from the other groups, so far is that it's a lot, right i mean this document is huge. It's 170 pages right now. So, you know that that would be the one caution is that Intel is broken out into, you know, incident so like incident response so it's more about like after you've already deployed something it's important but it should be broken to a separate section. In other words,
um, yeah, okay, I mean the practical things, maybe restructuring the document or something in detail, I think that that should be okay. I was just thinking of like giving them the idea of the general direction that we are heading, and maybe also pointing our developers to this already. Yeah. So,
like this one, this stuff, this crowd these cross cutting requirements. This is stuff you absolutely want to do now, right, like all your, your, you should point your developers to this now, right, because it's just, this is just really important. You know, critical stuff that needs to be done.
And they can they can come in to say one, I think that makes, makes sense so I will just share the link to the group. Okay and then of course, the temporary document it's it's a documented process.
Yeah, exactly, it's still in process but I mean, the more people looking at it, the better in terms of like, you know, here's the CTO of Estonia, like reviewing it, so that's good. Yeah, but I think it's I think it's fairly mature, there's just some caveats, right, and also like I'm not sure these flows are, you know, it seems like we're not entirely happy with them yet but I think it's much closer than what it was last week so and the other good thing is it kind of isolates the interaction with ID building block to just this very specific redirects. And then, you know the specific interactions with security, so it should simplify their process once they're getting ready to work on integrating with other building blocks. Okay, Anything else, when it comes to this security stuff. Alright. So, I will send you.
Let's just make a note that we do need an API protocol, for example, for during the building block and the I Am. Yeah and sister.
Yeah, and there are there are a bunch of those here. But I wouldn't you know I think in those data structures like there was example rest of indication API. So we should be giving feedback on this I mean I've given some feedback on here. Right, so, like it has to return include requests and respond to version numbers. For example, but it's, you know there is a there is a fairly detailed series of API's but you know there might be API's that are missing here right. So, I think, I would encourage the rest of this group to please review this help review it and point out things that might be missing right. So, yeah, we can do that now I mean so it's got all this Oh to stuff but, you know, it doesn't really have. So here, defining resources roles access and provision, oh no, API's only in soak. That's funny. So, um, I think these are the kind of like the most important API's, you know you can imagine, right, which is how you what we've been talking about defining resources roles access and provisioning. I'm
just gonna say,
Yeah, I mean it does mean that if somebody wants to integrate open I open it, I am, then they're going to be stuck writing a wrapper around it. I'm just not the end of the way. Yeah,
I think, you know, I'm not sure that what he's saying here is really about. But um, Yeah. So yeah, I mean there are there are pretty good examples here. But, okay, so, um, you know, I guess I'd encourage everyone to do a detailed review of this though, and see if I help identify things that are missing, like we just did. Right. Okay, cool. So this is why these flow diagrams are so important because it, you know, it's clearly identifying right that we're going to need this provisioning to happen, and we were not going to expect. I don't think we, you know, given our contract, and our standards we can't expect this to happen over so this has to be JSON. So, okay. Um, what else should we cover. I mean, the other thing I wanted to ask you guys to look at really is the information mediator spec. So, this is, you know, this is pretty close to complete as well. So I would like it if folks could review this. And it looks like Anita has. Oh, you just deleted and added the image, Okay. So, yeah, this is great. So I guess, you know, I would just ask that, folks, you know, um, and then there's registration, right, which is, you know, been asked for a, where's the registration. I think registrations. Next up,
jeez, I can't type the date sorry payments has asked for a review as well. So please, you know, look at those in all your copious amounts of free time.
Okay, let's see, let me just look at the agenda. Um, yeah, so, um, I think we just, yeah, so I think that's about all I have anybody have anything else they want to cover today.
Just a quick one. I wouldn't I did the onboarding with Anita. A few days back. I was looking for the graphic, the system architecture. Overview, with like GolfTEC internal billing box, and where where you also have the external systems or existing systems. Oh yeah, exactly. I didn't find it did you replace it with this level graphic or did I just look at the wrong document,
I think, maybe you were thinking about this one. You're not sharing. Oh, sorry. Uh, yeah, turn off my shirt. Hold on. Let's see. So this one
here successfully.
Okay, so let me just post a link to that so this is, this is sort of in progress. It's something that I've been working on with Christo, and then you might have seen some of these work their way into slides, so this is all going to be used the intent here is to use this as sort of like an introductory introduction to some of the, you know, concepts that were really big on income stack. Like, why should you care about agile methodology, why should you care about user centered design, etc. And, you know, event driven architecture, you know, where are the real benefits, but this is I think the part you were talking about.
Exactly, exactly, that's the one, which this one here, probably. Yeah, that one looks good, so I need to again can you see that's the one I wanted to show to you when I just found this graphic with the levels that Max did you share the link.
So, that we have a look.
I think that's very good for, like, onboarding, and it's actually one of the documents I should have shown to you.
Yeah. So yeah, definitely we want to review that I guess the other thing is, um, you know, there's this templates here. So I think this is the building block definition template. This one here. Right, so this is the thing we probably also want to review this and make sure it's got the right footers and maybe lose these tables. So I'll post a link to that as well.
All right, and then the other thing that I think is useful is, uh, you know, I'm Anita for you probably and this is it. So we got, we also have this workgroup cookbook. And this talks about, you know, this is intended for Workgroups. So, I'll also send you a link to that.
Just make sure that you know that's not missing anything obvious, because we really, you know, I've got a gotta prepare deck, you know by the first really took to onboard. I think it's three new groups. So that's going to be pretty important is making sure that we've got this, you know, these, these documents for onboarding improved, and ready to go and so we need to would really especially appreciate your feedback because you're, you've got the freshest eyes, you know of any of us so if there's, if you can review those and ask questions flag issues, that'd be super helpful.
Okay, good. um, anything else folks want to cover today.
Yeah, just another small questions when we talked about tooling, we, we always had. We always talk about auto attack. For the registry, building block. And we have the problem that, although it's a generic registry tool that it is not open source. Another question when you looked at tools so far have you looked at open source, your piece systems as well I think they are also quite flexible and generic in like setting up new registries. I don't know try to know although some of those,
you know, I, I have not, you know, uh, I think it would be good to do that. I mean I know you know a lot of the you know the Ingmar has been most, he's been writing most of the registration spec is basing his work on overtime but the spec run on the work that he's done in Nuke taught, but it's still just abstract requirements so there's any number of digital public goods that could provide that functionality, it's not necessarily, I mean, in fact because it's closed source it might not be at all, that's creating the solution so if you have specific pointers at, you know, tools that you think are, you know related, then I think it'd be great to, you know, if you could send those along, and then while we're, you know, All of us are reviewing the registration building block and registry building block digital registry building blocks then we can give feedback if there's you know missing functionality and things like that.
I mean it would be worth, because the whole exercise seems a bit like what the people from glue health has done for example, they have, they have taken the Triton up and they build a complete, complete health suit on top of it, and while it seems like like, well it has the basic, just like SAP R three or something like this it has the basic your key functionality built in. But then again, so customizable and programmable that you can like like that you're quite generic and setting up other applications. And that might be I don't know how far you are with that. Looking activity, but it sounds like. That could be a promising approach then it's called try to be over here with. Now, I'm looking at. They're all trying to land open Triton and although they are both from this, I think it was called Open, open Yapi,
and we're just one feedback on that. I spoke to those guys, we try to actually get them in. into into groups. They also, we also had a very brief introduction about dogs back to them, trying to go them into the room and they prefer not to join right now, but explore it at a later point of time, just, I think one thing I picked up from that discussion is that they have done it with for specific pieces within their system for specific pieces meaning like billing and HR and registration. One more, some block, and they have typically targeted private sector SME. They were kind of saying they have to evaluate internally whether they will be interested in government related stuff, and second thing is on the whether they whether they would be willing to come forward with dismantling their monolith into building blocks.
Did you talk to auto or did you talk to try to try to try to, okay, or.
So, I think Triton thing it's a foundation name which I am not able to recollect right now but I can send you some information.
Okay, so it was just a thought. and
so that they might have the functionality for taking breaks and comparing it just that they seem to believe that they have as a traditional European they have two blocks, which are all tightly coupled right now. And so we had a discussion with David. David was trying to woo them into considering splitting them into building blocks and overlapping with us right now.
I mean, parking private sector doesn't apply to do health in any case because health is targeting it also governmental health structures and hospital management systems, but maybe they have a different, it's a different project just using Triton so maybe
possible that way. Let me just, let me forward that main dance and you can take a look up your Mac's and take a look. And within that still have to go behind them, more than willing to
make maybe invite them module one for just a presentation, maybe they could accept
them, like another installment. We are inviting couple of guys Taylor is inviting for reviewing that might be preparing them for a review of the registration. I don't know if it's a useful thing to do, but if it is then no problem.
I was just thinking about this registry building block because then we don't seem to have a candidate for for two weeks.
From the I think we are confusing between two things quite often where I think one is on the registration building block, and the other one is the registry building block, which one are you registering. Registering Building. Building registries
of whatever.
So, I think, well, what's your take max on this. I have not. Honestly I'm not searched for alternatives, per se, but we have searched and then said no, then I will take it from there on.
Yeah, I mean, I think you know if you're aware of something that fits the bill, then we should absolutely invite them to collaborate. And, you know, give it a try.
Okay, so this is. Okay. Yep. Okay. You may not actually have the same name for the industry, in some cases it is called a document management system. It's more like you can define a document, and the document is used. And so it might be actually called a BMS system and other industry system that will figure out what they call it functionally, maybe we'll say, oh,
maybe it would depend on an older presentation from them to and ask them some opportunity to ask them some detailed questions.
Maybe we can invite them to one of these our architecture team meetings. Yeah, we're not interested, I shouldn't mail LCC. You guys on that. Be willing to open.
The platform was striking but then reach organization with me just go back and check the mail. Forget No. Okay.
So Mike's. The only other thing I was looking at, is our status matrix is Excel sheet. Yep. So, I saw your list today emphasising people populate that, so I think that's good. But two weeks down the line. We just discussed, that we will get to three weeks of discussion about the status happened in the last group meeting, and subsequently take Excel chart inputs as a base data. So I think in the next two, three weeks it's important and good for us to review actually in the class group meetings, and see if people have doubts or if people have any important updates.
Yeah well I have been, um, so yeah and then unfortunately, you know, Trevor couldn't join yesterday and also I think Arnold from payments, wasn't able to join because he had an old link to the old, old meeting room. But with, you know I have been bringing it up. Rest assured, in the
crosswalk what I can do is between you and me. I knew them to be in those groups so I can say this will come up for review. So let's do that. And in the meeting meetings you asked already. Yep,
just to make sure to remain on the line we have some solid data. Yeah, yeah, I
keep reminding them, so I'll keep reminding them. Okay, great.
Okay, so I'm done. Maybe. Have a nice weekend. Okay, sounds good.