 Alright, thank you. Thanks for having me. I'm my name is James, and I'm a lead solution architect in Galtech, and part of the National Digital Identity Program. So, a few things before I start, and that is I have to apologize if I'm going to be running a bit fast, because I'm trying, I really have lots to share with you guys, and I'm trying to squeeze what we typically would do in a hard day event, all in one hour. So, bear with me, I'll have a Q&A session at the end of the session, and if you have questions, do feel free to raise them at the end of the session. So, first of all, let me introduce what is Galtech. Galtech is the implementation agency for the smart nation. So, as part of the Smart Nation Digital Government Group, we are together with Smart Nation Digital Government Office, SNDGO, we formed that part of the group, and Galtech is the implementation arm, SNDGO is the policy arm. So, we are serving 5.4 million users across the whole of Singapore, and we operate 600 different digital services, and over 3,000 ICT systems, and 227,000 ICT professionals, and across six different centres of excellence. So, today what I'm going to share with you is I'm going to do two things. First thing is I'm going to share with you what's possible with the National Digital Identity APIs, and the large part of it, the first tranche of those APIs are my info, and there are more to come. So, I'm going to show you what's possible, what other people have done, then once you know what's possible, I'm going to share about how you can integrate and onboard your applications, and quickly develop applications that make use of these APIs. Sounds good? So, National Digital Identity, it is the cornerstone of Singapore's Smart Nation initiative, and it is one of the strategic national projects. And we aim to give every user three things, identity, which is who are you. Authorization, which is do you have the authority to access certain things, and then consent, which is do you allow me to pass your data, your information to another third party application? So, the Singapore NDS stack is made up of four different layers. I will start from the bottom. First layer at the bottom is the foundational layer, which is the trusted data. Next layer is the trusted identity, followed by trusted access and trusted services. At the bottom, we have my info, and of course we have more to come, so stay tuned for new products that are going to be released under the trusted data layer. And the trusted identity layer is our national certification authority, which is currently in the midst of building. And as you can see, the bottom two layers is going to be led by the government, and the top two layers are going to be a collaborative effort with the industry, with people like you. We're going to develop applications, services that will enable a smarter nation, convenience to all users, right? Okay, I'm going to play a quick video and to give you an idea of what is my info if you have not heard about it, okay? My info. It's a service for all Singaporeans and PRs that pre-vails forms for you. Anyone with a CMOS account can use this time-saving feature. Your verified data is crafted into your own digital user profile. Once you authenticate yourself with CMOS, you can use your digital profile across a wide range of services. Just confirm your data and you're good to go. This means no more same old boring questions and no more repeated document submissions. So here's to life made so much easier. Any service requiring sensitive information such as your finances will prompt you for your permission. You can also use my info for private sector services like banking. Rest assured that your data will only be released with your permission. Life is too short to fill up long forms. So take your next step towards a national digital identity and use my DNA. Alright, let me just... Alright, they say a picture tells a thousand words and a video tells a thousand pictures. So life is too short to fill up long forms. I'm sure all of you agree. If you have filled up repetitive forms throughout your life, you'll find that my info is the service that will help you to be able to transact faster, easier and more securely. So my info actually we started this initiative in January of 2016. That's couple of years back. And when we first started it, we actually wrote it out to all our government services. So we saw very encouraging results from our government services and we saw like up to 80% reduction in transaction time because these forms no longer need to ask you to submit your documents, a photocopy of your NRIC, your passport, a photocopy of your tax notice. Just to verify when all the data has already been captured by the relevant government agencies. So we made it available across all our services and we are in the midst of rolling out to all our government digital services and right now it's available at 121 digital services across government agencies, 40 government agencies. And we're planning to roll that out to 160 by the end of the year, okay, by the end of this FYC. So having seen so much success within the government, we decided, hey, why not we just introduce this service to the private sector. So that's what we did in the middle of 2017 and we started a pilot with some banks. We said, let's take a very simple use case. Let's take account opening, a bank account opening. So we used to have to go down to the bank, take a queue number, wait for hours sometimes, to wait your turn to get to the counter and then just to realize that you needed to have your NRC and you forgot to bring your NRC. And they would take photocopies and photocopies of all your documents and then they would open an account for you. So we wanted to simplify this know your customer AYC process with the banks. And we've seen some very encouraging results. So some banks did tell us that of all the eligible users who have MyInfo accounts, half of them choose to use MyInfo to transact. And out of those that use MyInfo, we see 80%, up to 80% reduction in the application time. And then up to 15% approval increase in approval rates for the applications because the data is of a better quality. There's nowhere where you can have manual human error when you're validating forms because you're not validating and verifying manual forms anymore. So let's take a look at that example. So this is one of the services we have that are familiar with you. That's good. I hope it's familiar with you. So if you go to DBS today and you try to apply for a multiplier account, let's say you are one of the very low minority of people in Singapore that do not have a relationship with DBS or POSB. You don't have an account there. So what you do is you apply for a bank account and step two, you say, I want to retrieve MyInfo to apply for a bank account. Once you say I want to retrieve MyInfo, you will be prompted with a sync post-logging. And after successful sync post-logging, we will ask you for a consent saying that those services is asking you whether do you allow them to access these data sets in your MyInfo profile. And when you say yes, I agree. Okay. The data is transmitted directly to the DBS servers from MyInfo and application is complete. You just need to verify your information and submit. That's it. No additional form filling, no additional data or document that you need to upload. And that's it in a matter of minutes. This saying know your customer process has been already integrated with many banks and financial institutions across the financial industry and some other industries as well. So you have that today. If you haven't seen one, go look for them. We also had some encouraging responses, feedback from UOB. They said recently in July of this year, they rolled out a 15-minute car loan application process. So the idea is that you can go down to the car showroom and say I want to buy this car. Then you start the application process. Take the car out for a test drive. And when you come back from the test drive, you can drive the car home. So that is what they actually rolled out. And they say that because of MyInfo, they have up to 15% increase in approval rate from the bank loan for the car. Next, we have OCBC. OCBC rolled out in June an instant bank account opening. So the idea is that you apply for a bank account with OCBC digitally using MyInfo. At the end of that 5-minute, 3-minute process, you will get a bank account number. And you can use that bank account number to transact immediately. So they say 50%, half of the people who have MyInfo choose to use MyInfo to apply for a bank account. Some other statistics from OCBC, from the first half of the year to the third quarter of this year, they actually saw a 3 times increase in digital bank account opening. And out of those, this pie right here, 90% of them choose to use MyInfo. And as a result of the, there's no need for them to verify the manual document submissions, they see a 20% operational efficiency improvement. So that's quite a lot of money if you have ever been in the banking sector. So if your application is not part of the MyInfo ecosystem, we encourage you to come and join us, join the growing ecosystem. So you might see some familiar icons up there. So these are services organizations that already have services integrated with MyInfo today. Right, so how do you get involved? Okay, there is a QR code here, you can scan it. And this is actually our newly revamped National Digital Identity API portal. So it's a portal that's built for developers like you and partners, business partners. So what you can do as a developer, you have open access, no need for a login, no need to apply for account, you can just access our sandbox APIs, try out the code, look at our sample source code, later I will give you a tour of the source code. And all our technical documentation is all up there for you to see. So what we want to do is to get you guys to be enabled, give you the tools that you need to quickly build your app. So for partners, if you want to take that amazing app that your developer has just built, and you want to take it to production, all you need to do is to login with corpus on the bottom, apply for a link-up request, and we will get you started on the onboarding journey. Pretty simple. So the portal looks like this. If you have not gone, do check it out. There are a lot of APIs up there, which are still in the midst of baking. But the mature ones that are ready for integration is my info. So we have a vibrant community of developers and partners, just some numbers. We have 3.3 million illegible profiles. That means 3.3 million past users in Singapore who have a MyInfo account, automatically provision to them already. So they can start using your services immediately. We have more than 260 digital services across government and commercial sector that is already linked up with MyInfo. We have more than 50 data items that are verified by the government, which ensures your data quality. And we have thousands of developers and partners who have visited our site. If you look to the right-hand side, where we have a chart, just to give you an idea of the exponential growth of MyInfo, in 2016 when we first started, we had about 30,000 transactions the entire year. The next year, we had a little bit better, we had like 110,000 transactions in 2017. And that's the year that we started doing a pilot with the banks. So what happened from 2017 to 2018 is we decided that the benefits were so great that we provisioned all Singpass users with MyInfo account so that everybody can transact. So then you see the transaction numbers jump. So this is not a year yet. In nine months, we have hit 6.6 million transactions, 6.6 million instances of people who have transacted with MyInfo to do something digitally, right? Across government and commercial sector. And the latest number as of right now is 8.3 million, right? So we're seeing exponential growth. And 2019 is going to be even greater because we are onboarding even more digital services, right? So that gives you a little bit of an idea of the scale that we're working at. And these are all powered by our APIs, which later I will show you. Okay, so what's next in 2019? So the vision for us today, we have what is on the left side, personal data. Personal data. Individuals can transact digitally. We've verified data from the government. In 2019, this is what our goal is, to empower the businesses, okay? So they can enjoy the same level of flexibility, convenience, all right? And security that the individuals already have today. So if there's ever a better time to get onboard, now is the time, okay? So subscribe to our mailing list, which is on the NDI API portal, for new features, new data items, and new updates on when this is coming, okay? So now, what are the possibilities? What's possible with your app today? How can you use my info to add value to your application, to your product and remove the friction for our users to access your applications? What other data sets do you need that we don't have today? Okay, you can talk to us, right? Because we're always expanding our data items. And for partners, what new services do you want to build? There's not existing, but you want to build something new because of the possibilities that my info has created for you. Okay, so some food for thought. So now that I have shown you what is possible, hope I save your time. Yes, I hope, yes. Alright, I'm going to talk about how you can build your application to link up with my info, right? And it's actually pretty simple. First, let's understand the my info data, the data format, okay? If you go to the NDI API portal and you go to trusted data, and under trusted data you click my info, you will see our API library. This is the entire API library for my info. So it gives you a little bit of introduction, tell you about our data, give you the guidelines and the implementation guidelines that you need to adhere to when you develop your application. Some online tutorials, which later I will go through. And other resources and our API specifications. All here, so everything you need to build your prototype app is here, okay? So if you go to the API specifications, right, you will see this is our API specs, sorry, a little bit cut off, right? But we are now at version 2.1.1 and it's constantly evolving. You see the rate of change for our version. So we're adding new data items, right? Every few months, okay? Right? In the API specifications, you will see sample responses, sample code, right? The code command that you need to use to fetch the data. Right? And then we have a detailed, very, very detailed explanation of every single data item we have available in my info. So let me just walk through very quickly. So each data item, for example, like the name, you have the value of the name. Okay? Simple enough to understand. You have the data classification. Right now, because our data is all personal, data is classified as confidential, subject to PPA. Right next source. This is very important. So this flag or rather this value tells you where the data is coming from. So if the value is 1, it is coming from a government verified source. So that means if, for example, it's your text document, right? So this means that the text numbers are actually coming from the verified government source. So what this also means is that if you receive a data field from my info that is government verified, you must make it non-editable on your digital service form. Because if I already verified it for you and you allow the user to change, then it's not verified anymore. Right? That is a rigorous verification process that each data source agency does to make sure the data quality is there. Okay? So that is very important. If it's true, it's user provided. It means that we are capturing some fields, not a lot, that we feel that the user can provide. For example, they want to provide an alternative mailing or billing address. We allow that. But we want to tell you that this field, we are not verifying. Our agencies are not verifying. Right? You have to do your necessary verification if your business requirements requires it. Okay? Third, there are some fields that are not applicable to that person. The data field that you requested is not applicable to the person transacting with you. You will see a flag. Three. Okay? Not applicable. Okay? Which means that it's not applicable. Right? It's a very different value from now. Or blank. Okay? The last value is a little bit special. We have a category of data items that are verified by SyncPass as a result of the SyncPass onboarding process. So these are, these are fields like email address, mobile number. Right? So sometimes the email address mobile number because it's verified by SyncPass but it's not verified by a government agency. The difference is this. The difference is if it's verified by SyncPass it means that we are verifying it using an OTP or one-time password. Right? So we can tell you for certainty that this email address or this mobile number exists. Okay? It's there. Okay? Somebody is at the end of that email or that mobile numbers because they have actually verified the one-time password with us. But we cannot tell you whether this mobile number or email address belongs to this person. Okay? So that's a very big difference. Government verified means that this field belongs to that person. Okay? So that's a subtle difference. Next, last updated. Last updated means the last time this data field was updated from the data source. Right? So we typically update our data regularly every working day. Right? So the latest you will see a gap in the data. The longest gap will probably be one working day unless there's some exceptional situations. But this field allows you to see, you know, when was the data last updated. Okay? So that you can know when to retrieve the data again. Yes, please. I don't split the name into the surname and... That is very good question. Okay? The answer is... The short answer is no. And the reason is because today ICA does not split your name into first name and last name in middle name. Right? So the data is as captured by the government agency, the data source. Right? So unfortunately, the way that they captured data, you know, is one name. Okay? Of course there are compound names in... In ICA, they actually have different types of names. They have your primary name, your alias name, your ethnic name, and all those. They are available in my info as well. Right? It's just that the data agency, the data source agency did not split the name into first, last name. Okay? So that's the reason why. Good question though. Okay, some data fields are actually code values. So you will see a code. Right? Something like that. And it doesn't mean one to one. It means this guy stays in the detached house. Okay? So the API specs provide you with the detail to let you know what to expect when you're building your application. Okay? So one of the key highlights. Personal data... The data format for our my info person data, it's kind of like this. It's very simple to read JSON format. Okay? Each data field has some compound values to tell you it's like a metadata of the actual data item, including the actual data. And please familiarize yourself with the data formats. And they are all available on our API specs. Okay? There's no login, no registration required. Just go and take a look. Okay? Also note the guidelines for using government verified data and refer to the specs on the portal for detailed explanation on every single data item. Okay? I have some time to take questions before I go into OOF. Any questions? Yes. Data on credit assessment. It's credit rating. That is coming soon. Okay? I don't have a confirmed date yet. But again, stay tuned on the portal. Subscribe to our mailing list. And once new data items are out, usually within the next few days when the data item is available, we will send an email to everyone on our mailing list. All right? Yes? Sorry? What are the some? Okay. Right. Yes. Short answer is it depends on your business requirements because for example, we work with the banks and the banks have a very stringent KYC process. Right? They need to check certain things. Okay? And those guidelines are being set by MAS. So again, depending on the industry, the requirements that you have, you check whether the fields are available in my info and then you use that to do your own KYC. Right? Any other questions? Before I move on, this is the heavy part. Okay? Let's go. All right. My info uses OAuth. OAuth 2 to be specific. And what is OAuth 2? OAuth 2 is an authorization framework. And to put it very simply, it defines three different roles. It's a typical three-legged OAuth. It defines the resource owner, which is the user. The client, which is your application. And finally, the resource server. In our case, it's my info. Right? So basically it allows the application to request the resource owner for permission to access the resource that the user has. The user has ownership of. All right? So my info, if you... Can I get a show of hands who have known OAuth? Right? Quite a fair bit of you. That's good. All right. So for those of you who know OAuth, you know that OAuth has so many flows, so many different implementations, so many different interpretations, and RSCs built on RSCs built on RSCs. Okay. So I will be more specific here. The authorization code ground flow. And the reason why will become apparent later. Okay? And we also use the API gateway as a facade for all the APIs. So we facade everything through an API gateway. So you don't have to call the resource server directly or the authorization server directly. Just call our API gateway and we'll take care of the rest. Okay? One party to call. Between our authorization server, which we call Consent Platform and Sync Pass, which is the identity provider, we use OpenID Connect to do the identity authentication federation. Okay? Of course, there's a lot of other black magic that happens at the back end. All right? Which is why I will not review. Okay. Let's take a look at the OAuth authorization code ground abstract flow. Very simplified. Okay? Too simple for some of you who already know OAuth, but indulge me. Okay? So typically in this flow, an application will request authorization from the resource owner. The resource owner having established his identity will return with an authorization grant. Or usually authorization code. Using the grant, the application will then ask the authorization server for a access token. The access token once received by the application can then be used to request for a resource that the user has ownership of and given permission. The protected resource will be returned back to the client. Simple. Right? Very simple. Okay? And we implement that using three different APIs. Authorize, token, and the resource API which we call person. Okay? If I lose any of you here, feel free to stop me, right? Because, yeah, we are jumping in really into the deep end. So let's talk about authorized API. What happens in the authorized API? Right? Let's say you are building a bank application for credit card application. So on the browser, your user will say, I want to apply for the credit card using my info. So what you do is you call our authorized API on our API gateway. Okay? Our API gateway will do a 302 redirect through the browser to the sync pass for the person to login. Sync pass. Okay? Simple. When the user has completed the sync pass login process and successful, okay, we will redirect him to our consent platform. Right? Consent platform will say, oh, good. You have logged in successfully. Then I will show the user, okay? Do you give permission to allow this application to access your my info data? So this is the consent page, right? So then the user says, I agree. Consent platform captures that consent and then does a redirect to your application via the browser with a very short lift of code. Okay? Very short lift of code. Okay? So using the off code that you received from the next step is you call, you make a server-to-server call using the off code to our token API posted on our API gateway. Right? So what we will do is we will validate are you correct? Are you who you say you are? Are you the correct application? And then we will forward the call to consent platform. Consent platform will say, yes, this off code reflects somebody who has just logged in. So I'm going to generate a access token in a JWT format and then it comes back to you. Okay? So now you have the access token. Right? Step three. Person API. So now that you have the access token, okay? You verify the signature of the access token because the token is actually signed by us to prevent any tampering. So if you validate the signature of the token, it's okay. It means that the token has not been tampered with. Once you verify the signature, inside the access token, you will get the identity of the person who just logged in, the ID, either the NRIC or the FIN number. Right? So using this FIN number or NRIC, the person ID, as well as the access token in the barrier of your request, what you do is you call our person API, again, facade it by our API gateway. Okay? What we'll do is, is it the correct person that you're calling for? Is the access token that you presented to us valid? Okay? And is the permission valid and aligned with what you are requesting for? So if all checks out, we'll forward the call back to our resource server, which will do another similar verification. And if everything checks out, we will return the person data back to you. Okay? And that is all of it. Questions? Yes. Is there an API from your side? Or how does the customer migrate? How does the application do it? Yes, your application can do that. There are quite a lot of open libraries that you can use to validate the signature. Right? So we're selecting a signature key? Yes, correct. Yeah. So we will give you the public key. Okay. Then you validate the signature using our public key. Okay? One more question. The data you're passing in the access token you generally found. So is that in plain text or tokenized? It is neither. Okay? And I'll explain later. Right? It's neither plain text nor tokenized. Right? I'll explain later. Okay? Understand what you mean. Yeah. There's no token introspection. Okay? But it's not also not in plain text. Okay? So let's go on to a little bit deeper. Right? So if implemented OAuth, we need to secure the APIs because evidently as my friend here has raised some questions, we all know, those of you who know OAuth 2, you know that OAuth 2 is not secure inherently. Okay? By itself it's not secure. But there are things that we can do to secure it. Okay? So of course, mindful, because we're dealing with all of our data, you know, our income, our very private data, we take security very, very seriously. Right? So that's why we need to secure this whole process. And OAuth by itself is not secure, but we need to enhance it to prevent a man-in-the-node attack. Okay? And here's where I will explain the man-in-the-node attack. A typical scenario. Not everything. I won't be able to go through all scenarios, typical scenario. Okay? So in OAuth typical fashion, okay, I'm going to go through this quickly. You call the authorized API, authorization server redirects through the browser to give you the off-code. And you use the off-code to present to the authorization server for a token, access token, get the access token back. Using the access token, you call the resource server, get the data. Simple, right? But there's a problem because a man-in-the-node attack can happen. So this is how it will happen, right? One of the ways. So when you're doing the authorized and login and all that, but what happens if you are sitting in a, you know, like a cafe and somebody is moving a Wi-Fi hotspot and you don't know what it is because they say free Wi-Fi. So you just log on, right? So by doing that, they inspect every single packet going through them, which you access. So during this time when the authorization server is returning you the off-code, this guy who's acting as a hotspot steals the off-code and immediately calls the authorization server and say, hey, it's me. Please give me the access token, right? Then the authorization server, of course, doesn't know anything because I gave you the off-code, right? So the authorization server says, okay, I'll give you the token. And now this guy, this red guy has your access token and he can do anything he wants with it. So what he does, of course, is steal your data, right? So that's the typical scenario of a man-in-the-node attack. So how do we secure this? How do we make it such that you cannot do this? You cannot attack it in the middle, okay? So at GavTech, we spend a lot of time thinking about security and consulting with various different divisions within the government to come up with a solution for this. It's actually pretty simple, okay? So we secure two things. First, we secure the request. Then we secure the response. So what we do to secure the request is the requests are secured using PKI digital signature, asymmetric key for two-way mutual authentication at layer seven, okay? Right. So back to this dangerous scenario, okay? So what we do is before we even allow the application to call us, we say, hey, let's do a key exchange. And that is what NDI API portal is for. Let's do a key exchange. You give me your public key. I give you my public key. You can verify who I am. I can verify who you are, right? So now with the key exchange, it means that only this application who uses his private key to sign the request will be recognized by me. If you're not using the correct signature, I will reject you. So this means that this guy, even if he steals that off code, it's useless to him because he can't call because he doesn't have your private key. Again, private key is supposed to be private, okay? Very deep, very, very deep, right? But it's so important that you do not put your private key in your client application because that's secure. You keep it in the server side where you have your firewalls, you have your edge defenses, right? And if somebody steals your key, you do a key rotation, right? So you have a lot more control there, right? So now without the correct private key, he cannot call the resource server as well. So rejected, rejected. But the application that was on board, we can verify that, hey, you are who you are. Layer 7, mutual two-way authentication, okay? And we say, yes, you are who you are. I will return to you the token. Likewise, application calling the resource server, we will say, oh, you are who you say you are. I will give you back the data, okay? So this is how we secure the request, by knowing exactly who we trust, knowing exactly which application to trust. Because I'm not sure if you have seen the Facebook strike, Google implementation. I'm not saying they're not good, but they just don't have as much to lose, you know, your income statements and all that. So they don't use this method because it's very heavy, it's very intensive. You have to do a lot of stuff, right? And you cannot trust everybody. And inherently that is the issue. You either trust everybody and you get hacked, or you trust, choose who you trust and you secure yourself, right? So that's the paradigm and the balance of security versus convenience that many people who implement OOF struggle with, okay? Now, a little bit deeper, how do we sign the request? Again, there are many implementations out there that tell you you sign the request to sign the request. But if you don't sign the request properly, you actually are still vulnerable of getting hacked. So I'll explain. First of all, you have your request with the header and the parameters. Okay, you use a set of token parameters that we have defined up front. Okay, these are required by our API gateway. Then you construct a base string. Okay, using the header, the parameters, and the authorization token parameters. So this base string is a representation of your entire request, along with some randomized non-... Okay? So this is a representation of the entire request. Then what you do is you use your private key, you sign on the base string. So you don't sign on the header or the parameters, you sign on the base string which represents your entire request. Okay, this is to prevent somebody from tampering your request. They can intercept you, change your parameters, and send the message to us. And if you didn't sign on the whole representation of the request, the recipient will think that you're okay. Right? So now you have the digital signature. Okay, you create the authorization header. Many of us will be very familiar with the authorization and put this signature in the header. And this is the request that you send to us. Okay? So very simple ABCD token parameters, base string, sign to get the digital signature, and put it in the authorization header. Okay? Right, I hope I haven't lost anyone yet. Bear with me. We are just getting deeper and deeper. Okay? Next, securing the response. So, securing the response, why do we want to secure the response even though we already established two-way mutual authentication? We have HTTPS, channel encryption. Isn't everything secure when we enter everything in HTTPS? Is it not really? Okay? So, we secure the response further by encrypting the payload that we send back to you. Right? So when we send the payload back to you, we encrypt it using JSON web encryption. Okay? And this is encrypted using your public key so that only you with your private key can decrypt it. Okay? And this ensures that even if the payload is intercepted midstream by some unknown factor, they won't be able to make sense of it. It will be all gibberish to them. Okay? Right? So, how do you decrypt our encrypted response? Wow, it's getting very difficult to integrate with my info. I wish I'd never come. Right? No, actually it's pretty simple. Okay? So, the header, the JWE compact serialization format, which is the format that we use, consists of five parts separated by dots. So, first part is the header, which tells you what algorithms we use. Okay? Next is the encrypted key, which is actually the key to decrypt the payload, the content encryption key. Okay? I'll spend a little bit more later, but we encrypt it using, we encrypt this key using your public key. Okay? Next, we have the initialization vector, which is a secure random value. And then we have the ciphertext, which is the actual payload that is encrypted. Lastly, we have the tag, which is to ensure the integrity of the whole format. Okay? So, now how do you decrypt this colorful format? First, using the header to know what other algorithms you use, take the encrypted key, content key, take your private key, and run the decryption. After the decryption, you will get a content encryption key. Okay? So, take note. Your private key is asymmetric. The content encryption key is symmetric. Okay? And symmetric key, this key is generated every single time we encrypt a payload. It's never used. Okay? So, then you take the ciphertext, take the decrypted content encryption key, and the initialization vector and the tag, run the decryption algorithm based on what is defined in the header, and you get your payload. And you will see Tan Xiaohui again. Anyone else? Questions so far? Yes. A symmetric key that you've used here, is the same as the key you used earlier for digital signature? No. Different. This is a... This key is generated every time. You are talking about the other key, private key. This is your private key. So, this is the same... Yes. which you've been encrypting your... Yes. It's the same key that you used to sign the request to generate your digital signature to come to me, right? So, I use that same key pair, the public key to encrypt this guy and send it back to you. So, only you have the... Right? Okay? So, for the sake of those who are not crypto experts here, simplified version is the content encryption key is symmetric because it performs better. Also, it allows for encryption of a larger payload. Okay? It's fast. But it's not very secure. Okay? The asymmetric key is used to protect this small payload, which is a very small key. Okay? And because it is more secure, but it's less efficient, slower, and can only encrypt up to the bite length of the key. Okay? Right. Time for a demo. Okay? I hope I have not lost all of you. Okay? I still have a little bit of time for demo. Okay, so if you go on our website, our portal, and if you go to tutorial... Oh, I'm not connected. Sorry. Forgot to connect my internet connection. Yeah, that is... Yeah. Just give me a minute while I can... Yeah, one of my friends help me. Do you have a Wi-Fi hotspot? Yeah, or something. This one? We work? Yeah, okay. Looks good. Yeah, let me try again. Okay, we're back in business. Okay, if you go to the portal and you go to the tutorial, tutorial 2 specifically, you will see that there is a sample application from GitHub, which I have already opened up here. You download the sample application. Okay? This is what you will get right here. Sorry. Okay, so for simplicity's sake, I'm just going to quickly go through. Okay? And I have downloaded the sample application already. It's in my workspace. And what I do is I'm just going to start it because I've done all the installation. Okay, then we started this demo app. So it's an app that we built in Node.js. Okay? And it kind of gives you a flavor of what you can do with your app and you can use it as a base to get yourself started or you can do your own stuff. Right? So once I've started the app, okay, I just go... Okay, so I have my app up. So this is the mindful demo application. All right. So you have... Remember the three APIs? The authorized token and person API. So here, when you click on this button, what we are doing at the back end is to call the authorized API. So when we do that, you will be directed to Sync Pass. See? Right? Okay, thanks. Okay, so Sync Pass. So all you need to do is log in. Of course now, if you have Sync Pass Mobile, if you have not downloaded Sync Pass Mobile, go download it from the Apple App Store or the Play Store. Right? It's really convenient. Okay, so... Because this is a staging and test environment, so there's no need for 2FA and all the stuff. Right? So once we finish the log in, it does the call back and you can see this is ConsenPage. This application is asking you permission to give your data. So when I click, I agree. Okay, it comes back. And then on the back end, I'm actually doing a lot of stuff. I'm doing the token call, getting the access token, and then using the access token, I'm calling my info again to get the data in. A matter of seconds, comes back. Boom. Right? So it's that simple. Okay, and there's a sample code available. You can take it, use it, okay? Build on it. Or build your own. Okay? Questions at this point? Must be too simple. I need to come up with more difficult material. All right. Very simple, very short demo over. Okay? Right? So congratulations, you have learned how to integrate your application with my info. Very simple. So tomorrow I will see 20 new applications. Right? Okay? Right? What if you want to try? Okay? We do have our tutorials online. Okay? I've shown you where is it. Okay? Go check it out. No login required, no registration required. Just go and have a look. Okay? Some references. So we use a JWE. Yeah, since everyone likes RSEs or on RSEs, so I thought I'd just leave it here. Okay? We have some tools to help you check your base string, whether it's correct. Help you check your signature, whether it's correct. And then expect it for like if you run into any problems. Because that's, in our experience, that's where most developers have problems with. So we actually build some tools to help you verify them. Okay? Right? Q&A. Questions? This is going to be, after this it will be the end of my session. Any questions? Yes. We do not have any MPM packages. What we do have is the GitHub. Yeah, so you can just clone it. Yeah. All good? Yes. Let me just go here. If we go to our portal and you click my info, API data. So this actually gives you the full data catalog that's available. Every single data item. So one call? Yes. One call, you can get whatever you need. Yeah. Because just now I showed you, right? You know, I'm accessing so many. It wouldn't happen so fast if I'm calling every single time for each data item. Yeah. Yes. Of course. Right? So all the data items are here. Where is it coming from? Whether it's in government verified and all the different, and we update it constantly. Okay. Base string checkers here if you need. So we have different parameters that you key in just to check that your code is doing the right thing. Okay. Same thing with the signature verifier. Okay. Yeah. Resolvers are available to you. So with this, yes. Thanks. Yeah. I think I spoke too long just giving me a hint that I need to quickly wrap up my session. All right. So you have all the tools available to you. Okay. In the API library over here. So do check it out. And keep an eye out for new APIs that are going to be released in the upcoming year or two. Okay. There will be national digital identity APIs to allow you to do various different things. Okay. And when we get the information, we will communicate them out to our mailing list. So do remember to sign up for our mailing list. All right. Any last questions? Yes. Okay. That is an approval process. If you want to take your application from just the prototype to production. So earlier I mentioned that you use the same portal, but you log in using corpus. You need to get a corpus account that's representative of a company. And once you log in, there's another UI allowing you to do a link up request. You say, hey, I want to use my application to link up with my info. Here's what my screenshots look like of my prototype. Please approve me because I need this to do what we ask for all your justifications there. And then once our people have reviewed them, approved them, then we will bring you on board. And you can start applying. Okay. Yes. My question is from the very beginning when you talked about who you had created accounts for in my info. You said initially that it was for citizens in PR, but then you also said it was for anybody with a sync pass. So is this for everybody with a sync pass or just PR system? So we provision that to everybody with a sync pass. But there are some exceptions. So sync pass has some very special accounts that are used for certain text purposes of individuals that are not Singaporeans or not citizens and not even a recognized foreigner within Singapore. So those are not included. But majority of those are. So if your application encounters somebody that is not eligible, we will return you, return you 404 error. And then you handle it gracefully on your end. Yeah. Last question. All right. Yes. So there is one more indication for where a user can download the application and register and can download that app in the mobile phone and can do a login where it sends a pop-in message in your application. Okay. That is you're going to sync pass mobile app. Yeah. That's a different app. Yeah. Okay. Not sure about that, but I think I paste some blockers in that. So over there the recognition is not happening. So I register my app with the redirect URI. I get 200 or 302. But the recognition doesn't happen. So can any of you support on that? Sure. We actually do have support contacts available if you go to the APR library right here. Right. Yeah. Over here. We should have been posting the approval you wanted. But I'm working for OCC Bank. Ah. A friend. Welcome. So we don't have an exposed URL for an app for music. All right. So what we have is in-house. Okay. Let's see the web flow also. So when I just give my user name and the user name. Okay. Sorry to cut you off. But since you're a friend, we can talk later over drinks, right? Right. It seems a little bit more complex and in-depth. So I don't want to hold up the other people who want to go and have their dinner or something, right? So thank you so much for having me and I hope to see your application as part of our community very soon. Thank you.