And then also, um, you might want to turn off your video just to conserve bandwidth for folks. I will be recording this call. Um, so I hope that's okay with everybody. If it's not just let me know, I just like to transcribe it. Use the auto transcription in otter.ai. So if that's not cool, just let me know. Otherwise, I'm just going to hit record. Alright, cool. And then, um, great. So we've got a pretty good crew so far, let's give folks a few more minutes to show up and see where we see where we're at. Um, so I know the main agenda that we wanted to focus on today was looking at how foundational idx interacts with other building blocks. So I think that's, that'll be a really good exercise. So really excited about that.
Okay.
So, all right. We'll give folks another minute or so. In the meantime, I'm just going to pull up. So the security building block definition right now is where because security is there, they're doing identity and access management. That's where we put these universal flows for now. So I'm gonna pull up this document. So we talk about a universal flow. I mean, the goal is to try to make a series of interactions that work with ID for foundational ID and authentication. That can be used by any building block. So that's, that's what I mean when I say that, so. So I think we should maybe, you know, my suggestion would be that we just as much as possible, nail down these flows. Welcome, Alexander. Hello,
Max. I mean, while we wait for the other, so you just want to give a quick background of why this came from security? Why security polling talks right now?
Oh, it's just, I don't know. I mean, I just threw it in there. It you know, maybe it shouldn't be in the security building block, it should probably be in the logical process flows. But the reason is security is responsible for handling identity and access management. Um, with the CIO, they're responsible for that module right now is kind of how we divvied up the work, which is functional ID authentication and authorization. Right, so that's why I'm so that that's
to understand, I guess that with this is a different identity. Right?
Exactly. Exactly. Exactly. So if you look at if you look at if you follow that link, you can see that there's this, you know, and we've showed these in the summit. Um, no, yeah, also. So I posted the link in the chat, but I'll also share my screen, so we can just look at them. But you know, I mean, that's just, you know, one thing that I would really like to get out of this meeting if we can, so I don't know if you can see my screen. Yep. Um, so right. I mean, there's issues with this, right? So if they don't have an auth token, right. So this is this just shows how any building block could handle authentication, right. So if they don't have a token, then I guess they know that this isn't going to work. But so they first of all, they attempt to access with invalid or no auth token that's validated against security. So if the token is invalid, they get redirected to the authentication UI, where they provide authentication credentials, and attributes, right to the identity and access management, which could be you know, phone number password, depending on the Iam module, and if there's no account, then they get redirected to an account creation page. Eventually, the accounts created, they return an auth token, then they can request access to the building block. Again, the building block always validates the token. And because the valid tokens valid, the building block gets back a list of roles, which could be something like Doctor Doctor, right. And then based on those roles, it determines the access rights and returns a result. So this this could be used. You know, I think one issue that came up with this is that there's no it's not really clear. How this interacts with the UI, right? So and that's somewhat deliberate because, right? So for example, like how do you redirect the user to the authentication UI? Well, it's kind of going to be up to the building block right to to determine that. If it's an API call, then it's kind of up to the user. So that's a little bit deliberately vague. But so this is how any building block could essentially allow a user to authenticate themselves with the functional ID that a foundational ID. So any questions on this?
Well, I think if if security isn't the McCall, that's probably not the one we want to focus. I mean, we don't focus on that anyway. So Oh, yeah,
no, no, I mean, this has been designed with security. So yeah, so it's, it's fine. Don't worry about it. But I just want to make sure everyone's aware of it at least right. And there's no like, gigantic holes in this plan. Right.
But actually, I have one question. Yeah, yeah. user comes with building blocks to build and work with token. Yeah. Is it suppose that the building block can see that it's invalid? or it should every time go to security to check? Is it valid or not?
Well, the only time that it knows that is invalid if there is no auth token. Right. And so the building block is,
if no, yeah, that's okay. Yeah, but this invalid
stuff. Yeah. So it doesn't know it always validates. It always has to valid means
that every request is doubled in every request goes to security. It may think it's it's it's not good idea.
Well, yeah, um,
it should be some mechanism at the building block to check. Is it token valid or not?
Yeah, well, I mean, this is just kind of like the standard flow. I mean, there might be some mechanism that we can add, right? I mean, the thing is, like, when you talk about an auth token, um, there's sort of one source of truth about if it's valid or not. Right, which probably should be secure. I mean, there might be some, you might be able to look at and say, say, Oh, it's expired. I know it's expired, for sure. Right. Um, but
it's something like login.
Well, no, I mean, this would be this would be something like JW t on token or a cookie, right? Yeah,
as much as I remember J. wt token is signed. So yes, it's enough for Billy with Bob to check signature.
Exactly. So that might be possible, depending on the auth token, right? And you know, it's the same.
It's the same way, right? Yeah, it's a loser.
Well, so it could be a JW, right? And I'll token or sign. And depending on how you do your cookies, I mean, those could be signed to right, in which case, then you can bypass this validation step, at least to know if that token has expired or is still valid, right? With the JW T, it works because you say this token is valid for the next 15 minutes or the next two weeks or whatever. So it's enough for the building block to determine if that if the tokens been expired or not.
So also, if the token has details about the user and their roles, there may not be any need to have user profile is there there is no need to actually go to the aim. Right? It is expired.
Right? Exactly. Yep. Good point. So you know, let's add so so
good sign on case in that case. Well, hold
on let me just before we ask more questions, let me just write down those notes right. So the auth token could be signed with an expiry you know, DWT, for example, which might allow the building blocks to skip the validations.
For validations themselves.
Yeah. Right to Yeah, exactly. Uh,
personally, uh, you know, if the token contains rolls
expired.
Okay. Great. Good points. So I think this could still use some refinement. But the basic story holds. And the The reason is we want to make sure that each building block is secure by design by default, right? It's not relying on the fact that it's connected to an information mediator to authenticate and users. Okay. So that's a philosophy. Yeah. So I just
put on a bit where you made your comment,
so Well, let's finish. Let's fit. Okay, so this one, yeah. Uh huh. Right.
So if it contains roles, then it should also be role in a specific entity.
Yeah, well, exactly. Uh, yeah. Good point. Yeah. So yeah, I mean, because it might need the role. It might be us writing depending. Yeah.
Please show once more with beginning of another. Am I going to start with if you will, never goes without tokens? Yeah. Then this second validate altercation token. This is wrong. Actually. I made a prop don't have token.
Right, exactly. Uh, but it's still gonna. Yeah, so maybe we should change this line here. Yeah, good point. All right. So um, let me just pull up,
like a get a token. And if it's already there, if you use the cash token, validator that's not expired, otherwise, it could update.
Yeah, so I mean, so this is saying attempt to access with invalid or no auth token. So So how should we, you know, how do you want change this? Um, it's not really validate or, you know, request, right?
I'm saying a valid tokens. Yes. Okay. Um,
Is that better? We have our security guys here in this call.
Nope. I'm standing in for them. Well,
so we are, we are now putting down our factories. So
Well, I mean, not exactly. I mean, this is just how these this is how every standard Im system in the world works. So. Okay, so are we happy with this obtain valid authentication token? I mean, they're, you know, uh, as far as I know, nobody on the call is here from security. Right? Raise your hands if you're from? Yeah. Okay, cool. So, um, I'm just going to obtain valid authentication token. This is good. So I'm just going to share this.
Next Next line is also questionable. Which one if you want to obtain then you respond to this token? Is it well, it is not?
It's a good point. Right. Okay, so
right, actually, octane, really? dope, can it? It must be on the second stage. Exactly. Direction
works. Yeah, exactly. So I think, you know, so the point is, you know, I think this one, you're really validating the authentication token. If President
on there is no or no authentication token. There should be tokens.
There has to be a token. Yeah, that makes it better.
Yeah, actually, there's
no token directly redirect. That's, that's what,
yeah. attempt to access with auth token validator. I think I finished occation token, right.
Yeah.
token is invalid. Yep. Good. Okay. Perfect, though. So I'm gonna just say this back to the document and let's move on. So I like how we can constantly improve this.
So we want to see the progress on the foundation, right?
Absolutely. Absolutely, we do. So let me just insert this in here. I just wanted to set the context right. So and then, you know, Let me just insert this and then update the editable link. Right? And then we're good.
So
cool. All right. So Okay, so here's this, there's this totally, you know, so this is what, you know, I'd like to figure out is like, how exactly is this going to work? Right? So if the user is requiring a service request, you know, is requesting a service that requires foundational ID, then the building block might request that the user verify the foundational ID somehow, right? If they're talking to a UI, right?
Yeah. Let's, let's have a look and see how we can integrate all that.
Perfect. So um, you know, I know we talked about this a little bit at the summit, but, and Valerie, you just, you know, rightfully said, hey, let's, let's hold off on this. But let's, let's talk through this, you know,
so, I mean, if you can allow them to share the screen, then I think he can show you the adjusted version of that.
Perfect. No, that'd be that'd be beautiful. Yeah, so please, share the screen.
Okay, do you see it? Yes. You see, Google Drive, right? Yes. Okay, so what what we have done in the past days, we have started to write the specification for the go stack identity building block. Great. So from very different inputs we got from Valyrian dibawa. And also from Hamish Yeah. And so you know, he using this, this format that he was reading books and started to fill in the command with a question or interview series that you see we are still discussing to align the terms and so on. Yeah. We have some diagrams Also, we're working on them to define the external API's external services that is offered by as a building block. Could you
zoom in? Could you make the, you know, like, increase from 100 to 150%? or something? Oh, that works. Yeah, that's fine. Yeah, perfect. Okay, yep.
So we, we have things for our lunch things for management of credential things for authentication. Yeah. And also, we see that we have a need for notification. So he saw let's say the API is a tap publish outside the V blocks after we have some components in the building blocks that are also presenting some appear in between them. So which makes everything look identity building blocks, so let's say modular and interoperable in the inside, you may have different sub building blocks. Okay, so this is what we have done and we will we share the link But anyways, that sounds like Google Drive, autograph stacks, we can you can see easily. After here, we have some schemas that have been prepared by Ganesh to explain a bit the different subcomponents How do you integrate with an existing ID system? When you have already some assets in the government, they have already population, which is already some elements and so I'll do you plug the graph stack on to it. And after what what was important for us is to start to describe this appear in services. So exactly what it is. And so as we are working together with varnish on the conversions between mosey panacea identifies the OCR updated interface that we're going to use all month when we have nearly achieved authentication once when the key was still on. And the credential and services are two things that we need to work with. After there are some other in in that in our interface, like accessing the data, adding interoperability on the biometric hygiene so that you can switch easily from different vendors accessing to data in the population registry and and also managing the unique numbers. Okay, and so when when I'll put a tag what is important, I think to review for this meeting. is a use case in fact, so what we have, we have the legislation use case here. Do you see it? Well?
Yep,
yep. Well, it's a bit small, actually.
It's in it's a little hard to read. Yeah. Do you have those source for that one? demo?
Beautiful. Yes.
They're trying to get you they're trying to get you I'll show you. I'll share my login with you With you, dude. You You already paid for it. So
okay, yeah. So that's that one we are going to go into there just introduce to you what we have. Yeah, we have already station which is so all that of the person. And then a set of Check, check off unicity creation of unique number when it's necessary creation of the person report notification of the creation. And afterwards there is an optional part which is delivering this, this this identifier on top of a credential. Okay, so different process with care management system. So that's one. And the second one that may interest you. Now is the authentication. Okay, do you see it?
Yep.
Okay, so we start in a sub party system, which needs authentication. So basically what we have just seen here.
So one of the building blocks one of these other building blocks that needs a foundational ID authentication, for example.
Yeah, in fact, we have your sub sub components as a building blocks.
Right? Okay. But but just so I'm just so everyone's clear, and I'm clear that third party system needing authentication on the right, that would be like some other building block outside that's trying to use the ID system, is that correct?
Exactly. So you can reach in the hospital and so you need to authenticate the person which is coming to take an appointment, for example.
Yep.
Okay, so from this, from this system, there is a need of photons education, so the person will be in front of in front of this system. So the person ID will be a requested kind of login or number of the desktop user ID function ID, which will be provided to the system. And then the application may be transmitted to a screen verification screen, either a terminal Iser a specific web web based screen to perform the authentication. And this screen is going to request the ID credentials of the person. So can be account can be information on the cap, the person will provide the identifier on this car. Because identifier could be a unique ID number can be the card ID can be any kind of functional identifier which is organized by the backend, then request from the terminal to the applicant to request biometrics, face capture fingerprints, or baseball, wellness, considering biometrics, then this information is sent back to the terminal. And then we entering different possibilities. One possibility is to have a notification that says versus a back end to centralize system. So then we can call this API as a service that we have which is very prefer identity which you give the identifier of the person and the biometrics then is calling a population registry service to the identity of registering for a match between the biometrics receive and the biometrics that have been registered in the system for that person. And then you receive a Yes No. And then you go on with that. So you can have also the same way we have a password. So they're not considering the biometrics but we are just using a password which is verified by the system or you can have decentralized identity. So you can for example, something which is mobile card, and you are going to do the matching the one to one matching not against the server, but locally. So in that case, you will collect For example, when biometric and you will compare to biometric and quit encrypted inside the inside the QR code is
what what's often apparent is that when you when you do these use cases now is an optional part when you do these kind of use cases, because you are onboarding somebody on something and so maybe you need the name, you need an address, you need an email, you need more information in order to build your own functional file. So you can use the read attribute set service, which is going to collect a set of attributes for a defined person and defines quite a predefined set of attributes. And so again, going back to the authentication gateway to population register, which is suddenly by the attributes, and finally the attributes can be sent back to the sub party system.
Okay, I mean, this looks very comprehensive to me,
especially because I'm happy You understand? Well, just I think I mean,
there's 111 question I do have is some of these are alternate. And some of these are optional. So those first three, it would be one or the other. This first three blocks, right? Is that Yeah, exactly.
Yeah.
Or just look at, like, actually, the local versus the centralized could be alternatives. And within the biometrics and password, it could be either, or both. Also, it could be even multi factor authentication in certain cases, where it's a combination of one time passwords, plus biometrics, depending on the level of assurance that is required.
And one thing I forgot to mention Max, is that in the middle, before things get reviewed, we notify the authentication resident, so positive or negative. And this will include the token, you know, the token authentication tokens that you're expecting on your side.
Okay, so this is the foundational ID authentication token. Why would you be different from other?
You can you can you can comment, if you want that we didn't have time to review this together.
So this, actually, the the token would flow the other way, in the sense that it's the Authentication Service, which could send the token. Because that tokenization is used to identify the person with the relying party, basically, the third party system always gets the tokenized number so that they don't have to use the temporary Yeah, I'm
talking about the token authentication token, not the unique number of token.
I got it. Got it. And and actually, the other thing is this optional portion is, is not as there's no need for a separate call for getting the attributes. It would the result is optionally an A sir, no, or in addition to that, the attributes that are applicable to that particular call, depending on the
these, these options, nearby options are given as part of the message, or is it by policy,
by policy, by policy? See, the relying party makes a kind of request, right, depending on the kind of request and what policy is there applicable, the response would be just a simple verify of identity or organization introduced into the credential that is shared. So these data that is shared these attributes are actually going to be as it's a digitally signed credential. So how does
one set the policy
policy is governed by the trust provider. So in this case, the population registry service is the one which is putting the list of people, they would define the kind of services they offer, and what policies they offer. And policy could also be sectorally defined, for example, if it is for, depending on the use case, the policies could actually vary, because selective disclosure principles would apply on what information is shareable for the for the particular use case.
So that's a build time information for the front end, right. If we want to capture based on the policy?
Absolutely. I think that's where policy comes because it sent clearly decided, considering the use case, and then it's just applied all all relying parties, all third parties who are interacting with and getting credentials, they would basically abide by the policy. So when they think against is what data they would get.
Yeah, so I'm just wondering, does it require another place to define the policy? Or is it part of the
it is part of the ID building block? It's part of the condition of the block. So okay,
so you also require an admin service for it building?
it, that's an inbuilt thing. It's a I don't know whether we require almost every applicant. occasion would have its own every configuration documentation.
Yeah, it has got some admin service.
Yeah. It will be part of that may not expose an external API. It will be Internal module activity.
Yeah, that makes sense. I mean, it could also just be a config file. Right? But so these are modules. So I think, one bit of feedback on this document, um, if if you could change the visual appearance of the third party system. I don't know if you can do that or make it all caps. I guess you can't really. But it would be nice if it was clear that that was different. And these were internal modules. Maybe you just label them as a module like internal, external, yeah, or just make that's like, you know, I guess that's external. It's just not entirely clear. which parts of these are modules? So is a verification screen terminal? Is that a module of ID? Like this, the thing all the way on the left?
Actually, actually, there are two parts there. Yeah. One is the client application, which belongs to the third party. Yeah. And the second is, if they are collecting biometrics there, and these are being securely collected, they in turn rely on a common mechanism. Right, right. So that that is something that they incorporate into their client application, in which case it's it's a client component that is provided by the IT system, which is incorporated.
Okay. But I mean, just all the other so the other three models other than the external one on the right, those are all part of ID the other those other boxes at the top right, those are all internal modules, that you know, that are part of ID.
Okay, I have one formal comment here in this alternate flow it right now it sent at style delegation gateway. But trouble did go through this screen. This, this results. If you're if you're more with lower Yeah. Answer comes to gate by. But But actually, after notifier notification results goes from Terminal NOT gate, right? This is maybe an arrow is missing here from Yeah.
Yes, yes.
And that's it also trigger a redirection of the screen, because now you are authenticated, the workflow can continue. On or I mean, I'm just saying how does it trigger?
That depends on how the client side is designed, since we are providing essentially an authentication gateway, which is an API gateway, not a not a UI gateway. In that sense, it's not like a payment gateway to which you redirect totally. Right. It's more of an API gateway here.
So the API replies to the front end, this is
exactly the sort of that is managed with the front end. So this is an API gateway.
Not clear, though. I thought the front end is your screen or terminal, right? That you have written? Exactly.
That's the front end. And the ID building block authentication gateway is actually an API gateway. It's not like your payment, where you redirect to a Visa or MasterCard
site, this
should come let us go to the right side, where is the request landing first request lender landing on the application,
I think that's something we need to discuss and to see if it is an API gateway and can be also UI. Because the UI is to be undone by some reading book. You know, when you pay with your bank, your,
your bank, your shop, so this currently, what we have done is based on API, So currently, what we are depicting is an API gateway. If you will have to if it is UI, we'll have to come up with the way it will be done. And the interfaces will be different in that case, right. The way is invoked? And
yeah, I mean, because, you know, I think I think it's important to consider because, you know, if we're going to use this for some sort of two factor authentication, which is kind of what it seems like, like this is almost like a drop in replacement for the the diagram that I was showing earlier. Where instead of using the security Iam module, you're using the ID module, right? And either way, at the end of the process, you get back an authentication token to the external service.
Except
reference purposes, foundational right, let's just not
Oh, exactly, exactly, exactly. So this is
also associated with it. There is no expiry. None of those concepts. It is just an identity token. Yeah, and nothing more.
Okay. And so That external third party system then later could take that authentication token and validate it again. So
create an auth token based on this.
Well, let let me clarify about this token a little.
Yeah. Because I'm talking about that authentication result, including authentication token, that line.
Yes. Yeah. So the reason tokenization is being brought in is for privacy, right? Okay. We don't want the proliferation of the person's UI. And so there are attributes that that then add so that then databases will get built out of it. Right, and they will get profiled. Absolutely. What we want to make sure is that we are giving a pseudonymous or pseudo customer reference. So every third party would get a different number for the same person so that every time the same third party calls
the service, they get the same. So it's
like a nonce that's tied to that. That entity.
Yes, that's right. Okay.
Okay, yeah. You might want to put that right on the line or right below there so that people are clear what that authentication token is, because all that allows you to do then, I mean, what's the purpose of that practically speaking, then, right. So then I get this, that I'm this third party service, I get this authentication token, which is a nonce that's specific to my, my, you know, module, I guess, right? Or so then what can I do with that nonce?
I know how to identify the person in my database.
So we use that as the unique identifier for the person. Yes, I see. Okay, that makes sense. And then it but there's no ability to validate it later. Right?
It's just a number, right? It's not a question. There's no point of validation or anything, right?
So it's sort of like a blinded population registry ID something like that. That's blinded so that you can't share them in aggregate them across services. Is that correct?
Absolutely. Okay.
That makes sense.
Is it? Is it going to thought or is it just? I mean, I think there's a difference between allocating different numbers of blinding at law.
Line learning in the sense, it's the visibility, it's not transparent across users, right? That's that sense. It is very specific to this person. It is. Your right, we can totally say it's blinded. I agree with that. But the idea is to make sure that iraklis appears different in different cases.
So
to that extent,
right. And technically, like the the impact is the same, but it's not a binding mechanism, Allah David Chang,
right. Understood. But yeah, I mean, it's just a way to make sure that we're not leaking the population registry ID or some other attributes of the person into these third party systems. Right? And to make sure that, so and then here's another question. A follow on though, right? Like, you can imagine that you do a hash of the person's population registry ID and the some sort of ID from the external third party, right? So how do you determine, you know, that ID for what you're using to combine, you know, or look up from the external third party to determine that nos, right?
I'd say it can be cryptographically done, and there could be even totally dynamic so that it is not even stored at the population registry and right, so there is no persistent database. And it is also something that can be replaced. Let's say there is a compromise of the database or there is a leak, it's possible to actually repopulate this for a particular sector or for a particular third party afresh, right. So that without further profiling is not possible.
Yeah, that's great. So that's not precisely what I'm trying to ask me, what I'm trying to ask you is the external third party, you can imagine that there may be like five different services that are run by the Ministry of Health, say, right, so I want to make sure that those five different services get back the same authentication token for the same person.
Right, and let's see if it is so in that case, the Ministry of Health or they become the relying party, third party, right, you can have a single mechanism for all their services to do that's one way The second is if they are actually disparate services, different departments and there is a need to identify the person together, right? Yeah, there is there is something called a re tokenization. So this is something we come come to deal with in the context. Offer credit registry, for example, I'd say I have five banks, each of them is a third party, all of them get different for me, right. But then when my credit history is being taken care of by the credit bureau, they need to translate the records from each of these into one, right, they need to combine and create my credit history and my rating. So the credit bureau itself has a relying party, they have special access to a rate of organization mechanism where they can pass the bank token, and they will get the credit bureaus token for Mike, my token for the credit, so they can translate it for aggregation. And that would be typically supported only by only for specialized entities. That would not be an API, which is open to everyone.
Yeah.
token what, what does the token contains?
token is just a random number, essentially, but it is a cryptographic derivative of, of the person's unique ID.
So it is a cryptographic result, which says matches Yes or no?
No, it is take. Let's let us say that my ID is 123. And let us say that the external third party, they are ABC, right? Yeah, a cryptographic operation is performed on 123 and ABC, and new value is created. And that value is given to ABC to identify me. So it might be something like f 123, or something like that, right? It's a different number, which uniquely identifies me in the context of ABC.
So exactly,
it does, it doesn't it doesn't say whether I'm authenticated, or anything like that, it just allows you to like take it, and I'm gonna dig and use,
it's an idea that allows you to associate that particular user across, you know, across a longer time period, right? beyond just this exactly, authentication result
beyond the transaction. Exactly. So that's fine. If I'm
generating a second ID in place of the first original, hidden ID.
All right, so I'll give you an example. You have, I'm sure used virtual credit card numbers in the past, right? You can for online transactions, where you don't trust the third party vendor, you actually generate a credit card number, which is valid for 30 minutes, or one transaction and use it so then you can forget it, even though it's that number that we have shared it, it's not usable, again, like that in various ID scenarios, we can create these alias or virtual ID numbers, which are short lived, or one time use. Right. So irrespective of what identifier the user produces, at the beginning of the transaction. Right? Even if it is persisted, or whatever it is, there are no security concerns. But from a relying party perspective, the third party actually should get something which translates the same customer ID irrespective of what identifier I'm using for the transaction. Okay, that is when they know, it is me who is paying the bill for the connection I have obtained earlier. So when I got the connection, let's say, well connection, I use one ID number, and I'm making the payment, maybe I'm using some other number, and updating my address, I'm using something else, it could be that right across these transactions, they should be able to link it all back to my account. So the way to link it back is using this token.
So in that case, this token has a finite lifetime, right? There's no
lifetime it's a token. It could be replaced. If there is a breach. If if we can potentially
replace it depends on my unique number and consumer number. It's a one to one correspondence.
It is what it is also assault and see some other concepts that are elements
from the examining list. Yep. See from the example you gave it looked like I can use this credit card with another number only once or maybe for 24 hours. Where is that layer coming from? It's coming from some front end layer.
Where there is there is the identity building block. There is a credential management service which allows you to generate these numbers, as many of these as you want against your account transactions
wherever you are, will you declare it is valid for one on one transaction.
So you can ask when you're asking for a credential, you can ask for a one time use credential or a short validity credential. And these can be made available optionally by
the credential.
So, for example, in Philippines, every person has what is called as a PSN, filss number, right, that's like a unique ID, but then they also have a PC and offenses card number. So this card number is what is printed on a card and given that's like, if they lose the card, they get a fresh card, it has a new number or the previous number is removed. So the PSN itself doesn't get removed. But it cannot be used in any kind of authentication. But all these card numbers are these credentials, which are aliases, in some sense. They have validity, they are revocable. And some of them can be really short one time use kind of numbers.
Okay, so So in summary, then if I've understood right, the token is an alias of the original identity. Based on the request, the credentialing system can generate a token which has certain lifetime.
Yes, the lifetime portion is optional. We have seen, for example, if there is a KYC process that needs to be repeated every year, you can then say the token is expired. But then if the customer doesn't perform the KYC, it doesn't mean that their account is stopped or the token becomes invalid, and so on. Right. So expiry has to be handled in a very sensitive way. Because things don't happen in the way we want them in the real world. Right? People don't follow up and do things in time to let you know. So that
part of the that part of the logic can be left around to the application right can be left on the application, this guy is not valid is
revocation, replacement expiry, these can be built in on top as required. The basic concept of tokenization itself is there.
So you can you can as part of the credentialing, you can tell whether this whatever token they gave for verification, is it expired? Is it valid? Or is it invalid?
So again, Ramkumar only certain numbers, or alias IDs, or whatever can we use for authentication, the token cannot be used to initiate an authentication.
The only thing you use the this authentication token for is key in your database to associate that record with that particular person. Right? Yes. So in the case, in the case that I'm getting
a bit confused, if this token is getting replaced, what will happen to the database where your LinkedIn
well, then it's broken, right? then then then you have like, that, the next record that comes around, if it's single use, you'll get a different number. And then you create a record that associated with a different user, as far as you're concerned.
So see, the replacement of the token is not done without thought in the sense that it will be like this was the previous token, this is the new token is how it typically gets replaced. The the relying party basically gets an opportunity to
update the token. So is that another API
changes? That's that's not another API. But re tokenisation and the this thing are, are basically, that's an extra security mechanism, that we'll have to look at everything we have gone around to define the credentialing and the tokenization API's yet. Okay. Okay.
Okay. I think that's very important. Exercise.
Yeah. And then
the other thing is,
security, it's good to express that as far as how people can use that from Right.
Exactly. And then and then I think just somehow getting clarity on how that external third party, if it's a, you know, it could be a constellation of services, right? How can they pass in and you know, it when they're, when they're making the call in they're gonna pass their entity ID, right.
Matthew can can't, you can't, actually this team. I'm against this, this setup. So please consider it in architecture. This isn't what we want what we need actually, if we have organization a and organization B, then any information about person x isn't interchangeable between this organization Because I don't know what, what especially Yeah, we all walk from A to B first Sonics token, I have nothing instead of token to forward to organization.
Exactly, Alexander. Alexander, what happens is this is the use, if the data is shared with the user consent, at the time of providing the consent itself, it can be shared in the context of the user to the new organization. Right? If
you consent will be given a certain piece of data only. It's another conflict. Because if I cannot refer to persons, then it's very serious consequences of that.
Exactly, Alexander, it's a serious privacy violation. If anybody can keep exchanging data between any application randomly, they will connect dots, and it creates a problem. So these vvc consequences of these misuse of that in daily life. This is why moments
of reflection need to be on level of attributes that you don't have access to attributes not out to you, but you need to know about whom you are doing something.
If there is a need for two applications to talk to each other, you're right, that will be governed by a policy with one that
we are building infrastructure for, for different applications to interact. And we forbid, exchanging personal this person identity.
No, I think I think just to just to do, maybe differentiate here who's allowed to do what and Ramesh was just coming to that, I think the differences really between the must have and the need to have. And the sort of nice to have, if you want, I think what we're discussing here is predominantly identity information as the most sensible types of attributes out there, the one that basically connects across all various registries, that's the one that needs to be protected to the extent that it can be protected. Of course, there are mechanisms and then there will be institutions that have rights to overrule this, as we often see in the security conversations, as well as sort of internal security, where the police might have access rights and so on. But when it comes to two parties that don't have anything indicated by a policy, then where is that where, where do you see the problem Alexander in the person is knowing that their information is being priced to exchange and that's the only thing we're suggesting here, which is aligned with all modern policies on privacy and data protection, that the exchange is possible it's just we want the user to know and control
Yes, I agree. It's a philosophical question with its fundamental question.
But if it flows through the user, then it can be read of a nice for the actual third party very easily there is no issue technically
to match it can why why not to do it in not in an open way I mean, if you can do it every every time in somewhat
every exchange is transparent or what to everyone
by I mean Well yes, I am saying that it it if everyone can translate this one token from one customer to another, from one organization to another, then there is no need to to keep it separate.
Are you sending Are you saying that any institution that has a has knowledge or identity information about the person should be enabled to share that as they deem right and and useful for them? Without Oh,
let's let's keep this let's say I misinterpreted this one one more statement. So
okay. So you know, I guess there is still this question in my mind though, this external third party, right? I mean, it might have a constant of services. And it's going to want to be able to get back the, you know, like you might have five different modules that need to check foundational ID inside the Ministry of Health. So somehow, this system needs to know that those five systems are member of the Ministry of Health in order to return this authentication token that is scoped to the entire Ministry of Health, are we saying we just don't do that?
That would be through the API gateway,
because we don't we don't do that, we asked the ministry of the health to host the Authentication Service common for all their related services. So that then what it
means that there is no possibility to, to set up constellation. In case there is no common ministry above this constellation of shows that is,
that is that is one approach. The second approach is only people who need to aggregate data from multiple services, they get the right to access to the tokenization, so that they can aggregate the data in the context of their token itself. For analysis,
okay, so like the Ministry of Health, so so what that would mean, though, is these five different services would be forced to use different user auth tokens in their database, but then they could have a special ability to request the ability to translate from one to the other. Is that what you're saying?
Is it that these applications need to exchange data? Where is it that the ministry of health needs access to the information from all these
you know, we can have a system sector where tokens, tokens, God is not one values, it will show you can assume 61, which is the web, your functional ID, so we shine the SQL sector, you may have an identifier for all the riskier sector and maybe for justice, you may have a different token
city, john, there is a challenge with a difficult sector well ID is that the way is that the way departments are structured,
one application and another, it goes through the user with their consent with their awareness that their data is being shared across applications. Then, as part of that flow itself, it gets translated, each application understands the user and the context very well.
And also on this just to keep the responsibilities in order, my understanding is that this is actually something that registration building block is looking into, so we shouldn't start mixing it up. And I've just checked, I don't think there's anyone from them on the call. So maybe we can take that up with them.
Well, I mean, it's more or less, I mean, it's like a philosophical thing, right? I mean, I could have one service for ingesting, you know, user records that relies on an authentication token and another for updating them. It's accessible to employees and the Ministry of Health. And those are two different services. Right. But I wouldn't have any way to just go in and update the record of a person without using this additional token resigning capability, right. So it's more like that's my kind of, like, pragmatic question.
Yeah, so the tokenization is something that will be required. And those are typically more more on a need basis.
I think where we are struggling a lot of them
that I'm still here.
Okay, it's weird, we're
struggling is the method to propagate rate organization to the modules, which were already given a token.
The modules need not know. So the tokenization is something that is required. When somebody is aggregating information from multiple models, they themselves become a third party in one sense, right. So the example of the credit bureau that I gave, the credit bureau gets my records from five banks. Each bank sends it with a different token. But they are able to re tokenize these five tokens into my token for the credential. And they're able to aggregate thanks. So as long as access to this API to the article So so so does the bank issue the token in that case? Yeah, the when the bank has to send a report to the credit bureau, they will send it with a token issue to them. So they don't care beyond that. So we don't want to complicate the third party systems. Much only the aggregator systems have to do some little bit extra.
Okay, so
I think, quite a bit of light up as to how the third party now who came in and got this token, how would they use this talk?
They just asked max describe, use it as a unique identifier for this user from the foundational ID service.
Yeah, and so then that would get written into any records that you want to do associated with that person. The difficulty is that, so Okay, I have one more question about this external third party. How do you determine or how do you derive their sort of ID that you use to to create that signed off token.
So they are an authorized lying party, they would have undergone registration. And they would have been given maybe in our case, there's a partner ID or an API key or, or even a, d, Id can can can be actually issued to them, which is, which is there as part of every request that they make every API call that they make into that? budget?
That ID is unique to this organization? organization participates in different constellations? And tokenisation? unique constellation ID?
Is it a person ID, patient ID?
It's an organization ID relying parties, typically organizations here. Okay, so
if I wanted to, hypothetically, I have this constellation of five servers and the Ministry of Health that I want to all use the same, I would just have them all use that same API key, and then everything's good, right? Yep. Yeah. Okay. Well, that that that then then that kind of solves all of these issues, right? Because it's just, it's entirely scoped to the API key that you're using to do the foundational ID verification and authorized authentication?
Is it an organization or application?
Well,
an organization can have applications. So the
entity and
not the application, it could even be multiple applications and multiple keys. But the path back to the same organization, the organization ID, as long as it's common, the token would correspond with the same irrespective of the API key use.
Okay, so you can imagine like somebody, there's some UI configuration for the ID building block that the ID authority uses to register these external third parties. And then it provisions them with, you know, tokens or whatever they need to access the service.
Things like, that is where the policy of what they can get, what attributes they're eligible for. Those are also decided. Okay.
I mean, it's kind of, it's very interesting, because there's a lot of overlap with the information mediator, in the sense that the information mediator is ensuring that the two parties have the ability to even communicate with each other, right? So you might be able to use or leverage the security server or have an integration, where you're pulling the organization ID out of there. I'm not sure. But I mean, what do you think about that, Alexander?
To my, to my understanding, it's, it's right now it's a mess. And, okay,
so skip that.
One thing we did doesn't information mediator doesn't know the payload? Well, only between?
Yeah, exactly. But I'm just saying that on the other end, yeah. Okay. Fair enough. So it's, it's, it's encrypted, and that, and then, you know, it's decrypted on the other end. And then that's kind of where it's, you know, responsibilities and and so the ID This is a completely different system that is configured discreetly, within within ID building block. And that's how you associate, like a federation of like, five servers within a given Ministry of Information would be that you would come and register and say, Okay, give me an API key. And then I'm going to provision those five servers with an API key, for example, but it's always gonna it's there. All the all the information mediator is doing is is is enforcing that these two systems can talk, right? And they're two totally discrete things, then
I got a bit confused now, because we are talking about application IDs, entity IDs. And we started with person IPS. Have this confused now what are we actually exchanging
Ramkumar things changed in the sense that we are verifying a person's identity. It's just that the relying party, third party application also needs to be known. authorized. system. Right?
Yeah, it is not, at the level of the ID building block. It's not
and it's not handled at the directly at the ID building block level, there is a way to validate them as the authentication gateway level. Right. And that is by creating a list of authorized third parties, and not showing them that part,
that part does not care whether the organization can I mean, I think Max was right, that part can be put on information mediator, because mediator allows access for somebody to reach the identity building block based on their membership based on their entity and their application. That's what information mediator filters off there, it doesn't depend on anything, they're independently registered as valid applications. And their subscription to a particular service. For example, Id building block service has to be approved by the ID building block guy, the admin. They don't get to access this.
Yeah, so that that that is that the same process can be used to set them up? And when they actually call they just get validated against that.
Yes. In that sense that I think that part is covered in the information video, maybe you should just take a look at
it another ID it's not application ID it's a domain ID or constellation ID or something called that.
Member ID member ID
member is a member ID it says define sir physical member, but this physical member can participate in different activities. And each activity could be could be from other domains, the same can be can handle this insurance data and medical data, for example. And
so we treat them logically as different. Yeah, they are different, but
they are physically this same ID we have been in, in information mediator, it's not enough. It's, we need something more of them.
Yeah, okay. So So likely what
I will share what we have done in most IPS case, if the same organization or business is doing work in two verticals, and they need to then basically do two registrations, maybe the physical legal entity may be the same. But they end up having two registrations and two logical member IDs, right? If we use the term member ID in this case, and so they are seen as two different parties, essentially,
functionality this member need to implement is in between this verticals, then then you you're still in this situation that you need to combine in for from one side and another and you cannot do it.
I haven't seen too many cases of that kind of Alexander. And in fact, we have cases where it has been misused people who have registered for one automatically were without permission registered for something else, and they will send marketing messages by private agencies, which is why we don't want actually them to be able to link and so the so in that sense,
my opinion this this restriction must be done on level of services, then can I access attributes or I cannot access attributes, not not on the level that I cannot match individuals, but that certain attribute of individual is not accessible for me.
Can we can we look at Taylor, if you can please open up this information mediator registration, part of that will throw some light on exactly what we're talking because that's the picture I have in mind. And I think all of us don't have the same picture. It's good to see what is happening there. I think it is covered. I mind my gut is it's already covered there. But it's good to see whether something is missing? And if so, where it should be positioned? So are you online? Taylor? I see the icon, but I'm not sure.
Taylor or Alexander, if you can, if you can open the document. It will take some time. So, you know,
I think it's it's probably, you know, it's probably, Yeah, go ahead. But, you know, just to summarize, just so I'm clear, what we're saying is, these are two different things, whatever the ID, that information mediator has is not compatible with the ID that we'd be passing in or, you know, API key to use the ID, authentication, foundational ID Authentication Service, right? So two different things. Let's just keep it that way. It's probably more flexible. We don't want them to be tightly coupled anyway.
Yeah, the foundational ID related token is about a person. And information mediator is looking at three things. Yeah, that's not
that's not what I'm that's not precisely what I'm talking about the What I'm talking about is the entity ID that is combined with the personal ID to generate that hash, right. To generate the token that comes out of foundational ID authentication. I'm just saying that the organization ID should not be read from it's not appropriate to read that from the security, or you know, from from that from the information mediator. It should be handled at an API level where, you know, you're depending on what API token you're passing in to the ID system. That's what determines your organization ID.
backs? Do, we don't have API tokens in our mediation scheme? Exactly.
So that's the responsibility of the person on the other end, all the information mediator is is plumbing, it doesn't know anything about these tokens, and it doesn't know anything about the organization ID that's all I'm saying.
No, just Alexander, I cannot reach the same name, same characteristics in the information mediator. It will not allow to duplicate. So internally, it must be generating a unique ID for the registered members and services. So I mean, inherently, there is something inside information mediator, which is generating a unique ID for the member member in the sense of an organization. Right, and surveys and an application, these are all getting registered there. Right, you're returning back.
Exactly. And so I guess what we're saying is that this ID registration would be completely discrete and separate from the information mediator. registration.
Yeah, the ability to access a particular service, which may be an external service, or a building block service, is controlled access to that service is controlled by information mediator, that is our fundamental assumption. And so in whichever ways you configure the mediator, mediator is the guy who is deciding whether you can access it building block or not. Now when you access it, building blocks, how you pass information is a different issue. Because information mediator does not care what information you pass.
Yeah, so all I'm saying is in order to actually use these ID API's, right? Through the information mediator or otherwise, you're going to need to pass in some sort of API key that's provisioned by the ID building block UI. And then that's what's going to determine your organization ID, which is used to give you back your the the hashed personal token, or whatever it is that you can use in your database to associate the user with the record, that you're writing it on the on the in the third party billing block. That's all I'm saying. It's
just to just to be clear on that, that that organization ID is different from the member or application or service ID on the information mediator, right? Yes.
It's just more flexible.
If there is a way to harmonize those, we should try I think that's what Ramkumar is trying to tell. You.
Just give some thought to the same organization somewhere in the system. It's like having a person with two IDs Yeah, I mean so
so so my thought my mind there's a business question there. Like is the is the hierarchy And the the sort of the structure of members is I guess what they're technically called. But the structure of members in the information mediator, which is sort of a technical concern, as much as as a business concern, is that structure precisely the same as the structure of organizations from the perspective of the ID building block? And if so, then I think we could probably make a good argument for for sort of using the same ID but if not, then I don't see why why we'd want to shoehorn it.
I that's why I requested if you can open up that your specification where you are registering the members applications and, and services. And you will see that in it block will also have to be registered on the information mediator if somebody has to access it.
Yeah, so that's the that's the thing, like in order. So just so we're clear, guys like it guys, the reason I'm bringing this up is, in theory, in order for another building block to be able to connect to the ID, foundational ID and I think authentication system through building through Gov stack, then it's always going to go through this information mediator. And the information mediator has secured the message made sure that those two parties are allowed to talk to one another. Right. So there's an essence of contractual agreement that the ID service is, is being allowed to talk to this third party, right? So if the thought is if, if that's allowed to happen, if the connection or if the connection was allowed to succeed, then you already know something about that contractual relationship. Right? So
as long as we get it, as long as there's a mechanism to get sufficient information to make our decisions, I think that's good. So what we need in order to make sufficient decisions, I think we will come back with at least so then we can ensure that it meets expectations. So Ramesh
is now looking at this. From your diagram, Ramesh, I think that the first line that coming from the external guy requesting authentication was coming directly to the UI of your service. In here, the assumption is nobody can access your building blocks. directly, they have to come through information mediators. So I think that that first line itself up your diagram, none of
that is still the third party applications UI only. It is not coming into the ID building blocks till the first time when it actually comes to the ID building block is when it said it hits the authentication gateway, as the first time it is coming.
So that is information mediator for you. Right? That
can come through the information in mediator, so that we know exactly who's the organization and will not
get one. Yeah, that's I think that is where there's integrate. That's right, I'm saying that since entity is already registered there, the entity or your VP of the guy who's consuming or all, unless they are approved here, doesn't allow access.
Yeah, I mean, approval from the
entity admin, which they which are all created here. So I
think it's worth exploring, but I'm not sure that we should tie these things directly together. So you know, let's explore it. But I'm not sure that the as Taylor said, that the information mediator constellation structure is going to be exactly the same as organization structure. So I think it's actually better to just keep these things discrete and separate. And what that does mean is that in order for somebody to use foundational ID, they first need the information mediate or access. And then second of all, they'll need to go through this registration process with the ID UI somehow, you know, to be provisioned, you know, the ability to access the ID building block.
Max, this is going to be not just the ID building block, every registry that you're going to have out there is going to have the same. Yes, exactly. Yes. The same for every register, okay, so anybody
who actually wants to validate who wants to validate a citizens foundational authentication is going to need to be registered with both information mediator and with the ID building block.
So that's
just so whatever makes
that makes perfect sense to me. Yep.
Perfect it building
blocks that need an API for registering people
registering
And we will have if there will be n. n applications or organizations who need foundational IDs and there will be n copies of information, we shouldn't
do that, actually, there should be one single list of providers and one single list of consumers and permissions. And that should be managed by some mediator, like the information mediator. That is where gateways themselves should be working on that basis. Right? So I'm totally with Alex on this.
I, yeah, that was a parking place for that, for people to come and publish their services, and other guys to come and subscribe for those services. And is that not what we envision is
that the whatever is the provider, and whatever is the relying party, right, so that that definition, and the contract should have sufficient information for the individual building blocks to be consuming. So that's what information goes there. How many contracts have to be there for the same number, all the things we should structure it out properly, so that it meets the requirements of all buildings.
Also, for discovery, if somebody wants to come and discover it blog, and then decide to bind to it, they must be able to do that in the information mediator.
I have a proposal Actually, let's take, let's take some of our use cases and try to try to play with this. With this proposed scheme for For example, If mother is checked against foundational ID, and then we need to pay for this mother some money, how payment block Know what? who is who, who is recipient of money.
Payment building block knows only a certain account number and check the foundation
to pay for account I must know name of owner.
Oh, yeah.
Yeah, so that's the KYC of that person, I seen the bank.
It means actually, that payment bloke need to know, foundational ID of mother.
Well, the assumption in that use case was that the person has a bank account, which basically means the bank has already done the authentication KYC and then given an account number, blah, blah to that guy, or that, that lady?
So payments
guys out here. Can you help us?
Yeah, so um, you know, I think that's a really good suggestion, Alexander. You know, why don't we talk through a few of these use cases, in light of actually doing this payment? And Id building block? Um,
how do folks feel about? Yeah,
yeah, you guys are able to see my screen, yes, have shattered. So I have taken a simple case, even in India, if I had to go and apply for a visa, let's say to Europe, or us or something like that, right, I have to produce a whole bunch of documents. Right? In a connected world. Each of these actually are different, and organizations having this data. Each of them you could think of the insurance companies as a registry of insurance policies issued medical records, bank, employment records like that. So now as part of this, I can prove my identity, I can prove my employment, I can prove my educational skills, I can guarantee my vaccination, I have travel insurance, police clearance, I have enough money to travel, a whole bunch of things can be checked, right? But all these are lying with different different means they're lying with different different parties. And today we produce paper in order to do this. And then some of these systems are integrated. Each integration is very specific. Instead of that, if we have the information mediator, if each of these registries have some standard way of verifying claims, like then it's very easy for the actual console later. vitia visa issuing authority to just Go and discover these services hit the network send a standard request, the information mediator takes care of routing the right request to the right party. Right. And the authorizations are already in place as to the constellate is authorized relying party for all these services, and they can actually check. So n number of pro fighters can be there. And all these can be checked, and then it can come back. Right? So the tomorrow, if there is one more provider, they just joined this network. And the relying party doesn't have to worry about that. As long as they are authorized to access. They are good enough to go.
For example, yeah, yeah. So this
is, so we can, we should be able to scale it to n. And for each of these, if we have to start. If the bank creates a database of relying parties, whom they are authorizing, and all it becomes a problem, because then it has to be done by n. n number of insurance companies and number of universities and so on. So we don't want them to do that. So all universities registered as providers, all banks, registers providers, the banks may also register as relying parties separately, right? They can have a dual role. But then everybody who offers a service, which can be used consumed by others, they all register as providers. So there should be one provider registry, there should be one relying party registry, n number of contracts, and what is allowed where those contracts, what is authorized or not. Yeah.
So right now in the context of information, you see this page of information mediator, so this organization can be one of them, the bank, those are our organizations. And these contracts are by by virtue of subscribing for the service that the organization has declared, it will provide. Right and fourth step, managing a list of allowed consumers at the bottom, you'll see this, this is where that contract is generated. This is the list of who can use for services.
But just for my understanding that rubbish on the example, you've just shown, who is the organization you refer to where they register, who, in fact, actually is that? So
that would be a relying party, it could be constellate, which is issuing visas.
And so they all register with each other? Or is there an intermedia,
there would be a single directory of providers and a single directory of the line parties. So if they want to register as a relying party, and then they apply for access to maybe universities, to banks, to whomever they need to interact with, right? They should ask for it. It could be even a paid service that they are enabled to access, or it could be a free service, or the contract gets set. And around the contract. There is policy also on what was shared, what is not shared, selective disclosure can also be brought in and
you you talking like trustless type thing?
Yes, this, this basically sets up the trust, and then it because the relying parties are also known, the providers are also known. So I wouldn't call it as trustless. But yes, it it gets. It could call it that way. But yeah, it means the same thing. All
the signs that I mean, there must be some sort of auditing process that that sets the trust.
Exactly, that that's where the governance portions come in, right? None of these things work without governance. So there has to be some way. There'll be somebody who governs this digital transformation activity. So there will be people who will do that, but then sectoral administration is very possible. Yeah, I agree.
It's just I think that is important, actually, one because we tend to talk very technical, I think it's important for everyone here to understand that we're talking about quite a governmental structure here. So this isn't done in a day. And this is not ready to go either. And this is from a technical perspective.
If I follow the
program,
this example man, can you put it on screen?
Sure. Yeah,
actually, could you post it as well? Yeah. And then let's talk it through. And I want
to explain how I understand it. There's a guy below comes to a visa office and says, hey, my ID is 123. It's the case passport somewhere. Oh, Visa agency. Want to check employment records? For that reason visa agency says to identity, please give me ID offer employment registry for REAL ID 123. And this check, returns, hey, this guy for employment registry is 234. Visa asks from employment trustee data about 234. Then it asks, identity, hey, I have Guy 123. And I need ID for bank. Citibank and identity check on sir, Guy 1234. Citibank is 567 when this visa agency asks, Citibank, give me records about 567? Is it? Is it the way how it works? As I understand it the right way?
There are many ways that's one possible way. Normally, what would happen is when this person requests, they actually at this point of time, they give their ID number and alias possibly, and they are attached to give their consent. The visa agency uses the same ID number and consent and makes requests all of these parties, right? They internally can then but identity
or what number he gives him, it could be
generated just for this purpose of his visa application. Visa
application ID ID for visa application. Yeah, yes, that's right.
Okay. And then these internally, they can all talk to the ID block and get it translated to their token, and they know which data to give out, essentially. Okay,
so bank, Citibank talks, identity agency and says that, hey, I have
visa, Visa,
Visa request a guy with identity 123, please say, What did what, what guide corresponds for me? Yeah,
they could do an art and, and they could, they could do that. Or when the consent goes along with the consent, we could actually get a, their, their token number, so that they could actually use that.
So who stores the token number? The ID building block, right?
Right. I the building block is the one which can don't store it can generate the token number, the flag is it can take technically be stored also, if required.
So the bank saying that the bank would effectively be taking this passport request ID and asking the ID building block told me the correct bank account number, or passport or not the not the correct bank account number, it would be you know, the correct user. foundational user ID. So I can go and look up their bank account balances, they
can just do a simple write a demographic card kind of thing and get it to come back.
Okay, and then the bank, the bank would know that. So the bank would then know what what user ID they should use to look up in their database to associate the records the bank data with that person? Yep. Right. Right.
So providing the consent for doing that.
Just Just one second guys, that means that the ID building block will have to store
all my properties.
Oh, it has to get a bunch of IDs for all these applications. Yes, yes.
Yes.
No, hang on a second. No rubbish. That's correct. It
doesn't store. What it does. It generates it on the fly, right? It doesn't need to. It knows how to regenerate it every time.
So now I can generate in on the fly if I know real unique ID but I don't if I don't know my real unique ID I cannot deny right on fly ID from another school.
Yeah, so people don't know how to decrypt your stuff and take the actual user Exactly.
See, if I if I'm, let's say my unique ID is 123. But for the visa application, I generated an alias id 456. And I pass it. And that comes to me, I know that this alias ID 456, which I've generated, is mine a year, but I can use a token
but the guys can make coming to this visa office, he don't know his ID for a reason. He knows.
Okay, it's it's not the ID we are not talking you're talking about is not the number issued by the visa agency. I'm talking about the user sharing an ID number. That number is what is used to it everyone. The passport application, the visa application software,
will take capture this guy's passport ID 123 and send it to the ID building block. Now Id building block is supposed to generate a token based on that ID. But somehow the bank is supposed to understand how to use the token and features this guy's account number. How is that possible? bank doesn't know what the token you have generated to these guys it these days, user ID in their bank account, right? called loop closing.
So let me take a step back and explain what happens is, let's say that a foundational ID has been issued for this person, he has an identity card. And now he walks in, he can that card has a number, that number is what he provides here. Or if he wants, he can generate a new number from the identity system. And that's what he provides. Right? It's not his passport number, it's not any of the other things, these are just additional information,
how he do it on mobile, or what on mobile,
or on a portal, he can do it. Or he can just use the number that this printer on his card if he has one. So there are mobile driver's license, as well as verifiable credential space, digital credentials, which you can hold, which you can share. And if he wants, he can generate a temporary number, a temporary credential for use in this case. Okay.
And so then then that same, that same, that same number is passed to each of these services around the cloud, exactly.
Okay. And since these are generated by the identity building block, when it comes back where any of these services for the identity building block, it knows codes.
So then each of those, each of those things around the cloud are going to have to ask the ID building block and say, Hey, you know, this, you know, person's driver's license ID, what that you gave me was 123. So give me the my version of that ID. Right. Yeah. And then that's how I would look up the bank balance.
All right, that's right. Okay, okay. Fine.
So the credentials that are submitted here, passport or driving license, it's assumed that those are the credentials already captured in generating the foundation,
right? That's right. Okay. Okay. So it's looking up
and basically saying, Okay, if you give me a driving license, ID, I can tell you his whatever ID in the context of the bank balance, if I would, I get to know
the city. If as we if you City Bank as an example, the city banks token would be returned. Okay. And they would use that the token would be associated with the account, or the customer ID of the user, and then they will use that to get the information back. So that
means for every account in Citibank, there must have been a token in the ID building block.
Yeah, it depends on the bank, whether they want to link it at the account level or the customer level. Normally, the customer having multiple, they will link it to the customer and
ask on the table in class, it led to store everybody's, every user ID in every service that they've ever learned, which is
Yeah, which is why we then store it, which is why we cryptographically generated.
Yeah, so they're generated on the fly.
I am confused. That is one part of the cryptographically generating that is fine. But this guy's user ID in the bank relates to this guy's user ID in driving license is gonna be stored somewhere, right?
No, it's generated on the fly using something like a cryptographic hash.
Yeah. has to be stored somewhere. Where is it stored? No, it's
not stored, right? It's, it's like you combine that number, this person's number 123, with some salt that only the ID system knows, right? And then that gets combined with the bank, Citibank ID, and then that generates the you compute hash of those three things together, and you get that unique ID that the bank would use. Yes, it's
a repeatable operation. And we can repeat it for every party case of re tokenisation, it has derive it back and to the root hash, and then regenerate it for a different party.
But this operation is not invertible.
It's not always a hash. It's, that's why it's a cryptography. I said, it's a cryptographic operation. And not necessarily Oh, gosh,
yes. Okay, sorry, I, you know, sorry. It's gotta turn there.
I mean, just one thing, when maybe you want to talk to as well as, of course, that provides power to that function that does all of that. So do you want to explain how that that power is? The power issue? So?
Sorry, I didn't understand your question.
Well, I guess the way you describe it right now comes close to the idea of a hub, right? I mean, there's there's something that sits in the middle that sort of connects the various parties on the basis of a audit structure that provides a level of trust to it. But there is power, I mean, that then there is power that aggregates at that point in time. So how do you manage that power? level that aggregator function?
application? Exactly. So it that could be just a reusable client, that could be given to every relying party for them to use so that their problem is abstracted in some sense. But so that that's a that's a technical building block that they could essentially use to do that, but in
your question, it's probably not just a technical solution, right? I mean, you still need to actually identify how the technology then is managed by some sort of, I don't know, content management, I mean, yes.
So there are there are going to be protocols, what we have to define other protocols. And actually, we have good references out there. So what honey had shared earlier, the verifiable credentials, there is a whole bunch of work around that on the protocols that can be used for this kind of thing. And there is there is also for example, for discovery. There is something the is a or uses a protocol for discovery, some finger I forget what it is. And then, in the case of verifiable credentials, it uses something called D ID registry. And these can be used for resolution, essentially, it's like a DNS of sorts, right? Where you can translate
a provider,
actually to the endpoint, and what policies what services that they can offer. So there are ways for discovering these services. And accessing them. Who can, who can actually access that is controlled by contracts for discovery is something that's possible through existing mechanisms and protocols, we can consider some of those.
So I mean, but if I understood what your question, Valerie, you're talking more about, like, you know, like the policy aspect of it, right? Like, if you have a centralized authority that's handling all of that, then the power is going to accrete there. Yeah,
right. Exactly. I would go beyond policy, I would say there must be some sort of consensus mechanism, which is shared by trusted parties where one can't overrule over the technology or the policy. So the consent in the UK, right? So the consent
management is distributed in some way. And you know, I mean, and also, I mean, the ID mean, maybe the ID system can be distributed as well. Right, exactly.
I think that's what it should be. Yeah.
It's actually it's beyond that, it should go into the hands of the user.
Right? So their credentials are in their phone or something, right? Yes,
yeah. Or it could be on the cloud, but they have choice of provider, and they have a choice, but they have the control through the provider, where they decide to share and what not to share what to allow and what not to allow, right. But there could be certain mandated shares like like Alexander was referring to some of those cases where it is mandatory to share the user may or may not be asked in certain cases, right. And so those those would have to be done transparently, through policy and legal infrastructure in the country. And there are also cases like if we imagine this within a country, it's, it's complex enough? What if these are in different countries? What if my university is in a different country? What if my, I have bank accounts in different countries? And how do these requests actually translate across cross borders? And of course, the administration has done differently, right? each, each country would have its own governance system of authorizing the parties and so on. So the trust is something that has to actually percolate across all these networks. So it may be a network of networks also, or a common network and so on.
Exactly. But still, all of that network of network and so on will underline a certain logic, and that logic also needs to be distributed. That's the poor. Yes, yes,
it is. And typically, if there is an alliance of countries, they would agree upon legally, contractually, how they would operate. And those are the rules that would bind the way that gets executed. And the same country might be part of two different alliances, which offer and operate in two different ways. I can, I can stop imagining the kind of complexities that are there. But then there's the way the world works. Yeah, no, I
just wanted to point that out. Because I think Maxim and Ramkumar maybe I think it's important to understand that we're now starting to really talk beyond technology, this isn't just a technical solution to it, this will only work if there is a very strong governance, management behind that, that keeps all of the controls in power. Nine.
Yeah, well,
I mean, I, you know,
I guess if, if it's possible, you know, so you know, we're talking with the consent management folks earlier this week. So there is a consent management building blocks, so we should definitely be talking to them about all this stuff. First of all, but second of all, yeah, I mean, just the more that we can build this system and spec it out in such a way that it maybe must be distributed, then the better. I mean, that's kind of better for the citizen, isn't it? Yeah,
I think I mean, just to that point, first of all, I my question would be the Content Management Group, are they looking only at policy from the user? Or are they looking as well at content? For example, between different market actors? I believe
it's just the user. Right? Yeah, that would be my
understanding as well. So that that that would then need to be broken up if we want them to take care of this. Alternatively, not sure. If other building blocks look at it, as well in the way we do. But we could also keep that piece in there, we just need to make sure that people understand that there are certain necessities so we can put that as a precondition was moving like that. Yeah, that's
it. I think there's so sorry, Ramkumar, go ahead.
Well, I'm just supporting that part. That functionality in it building block.
Yeah, okay. Yeah, I mean, that, yeah, that's fine. I mean, because you want it building block to be a, you know, self contained and everything, but, and
when we need to sort this out in between us was we know how to explain a bit all these concepts and this token?
Yeah. Yeah, I think so. But I mean, you know, we at least, need to make sure that, you know, I mean, conceptually, you could embed the consent management building block inside of this one, you could be an instance of that, right, and still be independent. So I'm just saying the design of the API's and functionalities for the consent management, you know, might be applicable here, or at least making sure that they're interoperable, I think is really important. So yeah,
yeah, no, and maybe one other point. So what what Ramesh was describing is, I think, extremely, if not the same. I mean, this is so aligned with what we've been developing with smart Africa. So I think there was an added value in going that direction as you, as you said, Max, as well, I mean, make it as distributed as possible. And if it's aligned already with what one of the key stakeholders has in there, then. Yeah, I think there's only add an added benefit to them. Well, okay.
But I mean, you know, agreed in, you know, stepping back a minute, right, this project. I mean, I know, it's called devstack. And we're really trying to make something that works well, for governments, but for I always try to put the citizen first and think about what the citizens needs are first, and I think for citizens is always better if there's some sort of distributed ID system, right? I mean, that's pretty clear to me, because,
yeah, you can use technology for it. Exactly.
And I think if the last minute, that's what I mean for certain things, like, like we were talking about before, as well, Alexander was making that point that in some cases, you just don't have that in some cases there was a must have and that's it. But no, I think I mean, all of this. We've gone through that with smart Africa mean that we had over stakeholders involved. And I'm sure that Ramesh as well and work with most of that. I think that the user centricity to all of this is obvious. But that's when we really need to look at security, privacy, that's one feature access usability is another feature of it as well. So eventually, we will have to make that very clear on how that really works. But right now, I feel like we're only at that point where we say, how does that interoperate with other building blocks. So I think that's the focus for now. Right? Agreed,
agreed, I'm just suggesting that as much as we can, do, you know, something that is future forward, and citizen benefits the citizen, right? I mean, so for instance, like consent management, for example, is optional, right? You can't force a government to use consent management. But if, depending on how the consent management is architected, it could be a huge boon to cybersecurity, right? So in that way, you're kind of convincing governments, you're saying, well, you can turn this off. But if you do, it's less secure. Right? Because you're more prone to leakage and things like that. So I mean, I think there's there's ways that nuanced ways where we can encourage people to use these more distributed situation, provided the technology is available, right. And we should try to, as much as possible, err in that direction. I mean, we can't force anybody to use a distributed ID system, or turn
on. But I think we should take a stand. It's not about forcing if we cannot, while doing this, push that governments will not take it. Right? Typically, all optional stuff is turned off, and then turning them back on. Easy, right? So we should make it friction free, we should make it easy for them to do it with all this on. Right, exactly. That's how we should say, rather than saying it's optional, right, find a way to make this part and parcel of how things operate. Exactly,
exactly. Well, and that's the council that I gave a consent management team as well, which is, it should shift turned on, and you should have to do extra work to turn it off. Like that is for sure. Right? So if possible, like applying that axiom to it, then it should ship with a distributed option turned on and you have to go in and at least turn it off. And if you turn it off, right, like there's some sort of warning that says, well, you're kind of like, more vulnerable to cyber security attacks, because now you have a centralized location, that somebody
I think, this one so I mean, I've had many conversations on a national basis, trying to explain that, that that in itself is not a strong, strong enough argument. That's why I'm saying we need to think about the distributed governance because you always have a rogue government approach that wants to switch off ultimately, and you can't really, you can't really stop that from happening. If the power sits with one party. That's where we are, we have to think about distributed governance structures. And that's exactly where that comes from.
Don't give us which exactly, we
don't give, don't give us which, but even even there, it's like, if you have a distributed governance structure, no one was able to use any switcher. And anyway,
I think it depends a lot on how much we educate them about the options. You do not educate them about luck. I don't think people would have time and patience to dig and understand these options. I have a question. It's just more of a strategy as to how you position? Well, what do we at the end of the day, what do we want them to? Do? We want them to use this in distributed way.
I have a
question. What is the relation between golftec id building blocks and masik?
That's a good question.
So um, as I you know, as I understand it, there's collaboration between Moses and Hosea, right to try to harmonize the standards. But you know, I'm not Yeah, so please explain. So,
in fact, from an external being growth standpoint, standpoint, sorry, what you should see easy appear in the services. So you don't really know if there is mosey permit beside, right. And so, what counts is a set of API's, we are harmonizing between music and OCR, in order to have interoperability standards for interoperability in the web stack. Which will be
sure I understand the question Alexandra. Maybe she will just want to explain that I just want
to details and I saw on on on this slide Mozi brand. My question is actually, where shall I find additional information with description of buy the building block or and description mosaic robots?
No, I think that the way this works is just I guess it's like in any other building block, we have people in our team that come with a very neutral background, for example, academic. And then we have people who provide standards like OSHA, and we have people who have an actual solution as well. Like, for example, like roll who represents the Estonian solution. And like, most open, I think, Ramesh has input to this is as valid as any of the others and is used in a neutral way as all the other. So I don't think that we there is any relation directly with one with one solution. I am also, if you want to know about identity, then we will have to refer you back to the document that john just presented at the beginning, which is the amalgamation of all the knowledge that is reflected in the building block. Yeah. Okay.
Right. So yeah, so it's, you know, but some of the some of the ideas and whatnot are derived from from Mosab in their in their design. So
just like anywhere else, but like I said, I mean, the concept that we have developed with smart Africa are extremely similar. So I can guide you also to the blueprint that we've written. For smart Africa, which had not normal, simple, more fun, and yet, we all come to the same conclusion because we all try to find the best solution. So I think it just represents alignment. Can
you put the link to this? Smart Africa, Redmond? And also Ramesh,
if you don't mind? Can you put a link to that? And Mosab building a Digital Public index?
in the chat? Can I share the PDF?
Yeah, or just put it if you have a link? Yeah. However you want to do it. But if there's a publicly accessible link, just throw it in the chat, if that whatever is easier? Sure.
Yeah. Cool.
All right. Well, this is great. And then so the ID building block is accessible from the substack route. Right. So that's great. The root drive. So we can go and read the spec there. Mmm, wonderful. Okay, so
I think, Mac's next steps as we review that would be definitely worthwhile trying, like we did had some hands on to actually address a use case. Exactly. Because what Ramesh showed thrown a lot of light. We have to we have to do the same exercise to really see how this orchestration happens. Exactly.
Yeah. So I think that's a really good idea. You know, I agree. I know Alexander raised that point earlier. So what I propose, you know, I know we're running low on time for today. I mean, we could keep going, but it's kind of a marathon meeting, what I propose is that we meet again next week, and just go through the use cases, and apply those a little bit. And in the meantime, we can review this, this, this this flow that we were talking about earlier. But you know, I think actually applying it in a very specific way to the use cases, to show how the payment or you know how that actually works. Because we have the system where, you know, somebody is, you know, there's an optional foundational ID step, actually, for the registration, right? Like, optionally, we want to verify the mother's foundational ID, right? So working through that, and how that actually happens would be really, really good. I think. So if folks have the appetite for it, I propose we meet again in a week and just go through that, because then we can talk about how it relates to registration, how it relates to payments, write it right in, you know, just one or two of those use cases. And, yeah,
I mean, I agree, Max,
is there any way that you could make sure they will be on the call?
What can you visually represent them? You know, I mean, I can sort of represent them, but I can't make promises. I mean, we got our old firm, the payments group here. You know, the ID group. I mean, that, you know, or the registration group. I mean, the main person, Ingmar is currently in the Faroe Islands. So he's not able to attend, but I think he's getting back soon. So hopefully, he'll be able to make it. But I can represent registration for sure. Yeah, but you know, I mean, payments, I think there's some nuances. You know, so it'd be great to at least have the payments in the in the, in the, you know, Id group if we can next week, and just also, I mean, I know payments, you've got a bunch of questions, right? So we've kind of like, this has been iD iD day, which is really good. But I think you know, it, that would be a great, great focus for next week, if at least, you know, folks can join who were on this call.
No worries max will be on the call next
week. Okay, perfect. And then I'll try to get Ingmar as well. Sorry.
Just to add, I think it will be useful because I took off at some point, but it'll be useful for you. If you could share with us some of the questions that need to be addressed so we can have preliminary disk mushrooms in our group before we attend next week, that's my talk the discussion. Are you interested? Oh, sure,
that's fine. I mean, I think we would just try to go through this process of how a mother registers invalidates her foundational ID, and then maybe how that payment is made later to the mom and the doctor. And then how that you know how mechanically those steps work with the ID building block to, you know, do the correct foundational ID authentication or at least associate? The, the ID the foundational ID tokens across those services, right. So we can just talk through that. I think it'll be really good. It's not super payment specific,
because we already have the drawings for that one. So that's, yeah, perfect.
Exactly. So I mean, I think it'll be mostly a review. And pretty quick, I'm hoping and then, you know, we also need to give you guys some, I know you got a bunch of outstanding questions. So. So we're gonna try to answer a bunch of those tomorrow and our architecture meeting, but you know, we want to give some airtime as well to the other groups next week. But I think getting this. So let's do that. Let's meet next week. And Fox, let's dive into some of those use cases and just, you know, look at it from that viewpoint, as well.
Max, I've just put the link in. Okay, into the
chat. Wonderful.
Thank you so much. Okay, and thanks for sharing that, Valerie. Alright, well, good. So I guess it's been a long meeting. So does anybody have any questions, concerns, comments that they want to raise? Nope. Okay. Great. So let's just meet next week. Thank you so much, everybody who attended, I mean, this has been extremely productive. And thanks so much for all the hard work on the ID specification, it's looking really great. So um, you know, I think that universal flow, once people understand what these authentication tokens are, and what the implications are, and the fact that you're passing in some sort of organization or you know, maybe sub organization specific, ID to even be able to use the, like an API token to be able to use the API once those are understood, I think, I think is mostly understood upon this group in this group. But I think once that's clear from the documentation, that'll be really, really helpful as well. Okay, cool. Well, great, so I guess I'll suggest that we break and then meet next week. unless anybody sounds good, thank you,
everyone. Thank you so much. All right. Bye.
Bye. How's it gone? Hello, how
are you doing with a mouthful? You open?
Yeah. I don't know that one.
I can't believe that. You did that I was just like, oh my god