My ordeal with MyInfo Integration

Sometime back I was assigned with a spike to find out how to integrate with MyInfo. My first intuition was to check if there were any blogs/vlogs that talks about it.

But I could not find a lot that was very useful.

So I am trying to write my own, if it helps anyone else.

The MyInfo integration flow starts with the authorisation call (<myinfo domain>/com/v3/authorise).

This is a GET call in which we also need to pass the following query parameters.

This call will have a 302 redirect and the person will be taken to the Singpass Login Page. For development, we will use Mockpass. When the MyInfo domain of the authorise URL is either “https://test.api.myinfo.gov.sg” or “https://sandbox.api.myinfo.gov.sg” we connect to the sandbox of SingPass known as MockPass.

The authorise API redirects us to the MockPass login page which looks something like below:-

The QR code is just to test the Singpass app launch.

Once we click on Login, we will be taken to the Consent page where we click on “I Agree”

Once we click on “I Agree”, Singpass will pass us back the control by calling the redirect_url that we have passed to them in the authorise call and will also pass us an authorization code.

With this authorization code, we need to make our second call to <MyInfo domain>/com/v3/token.

This is a POST call that takes the following attributes in the payload:-

The response to this call is an access token in the JWT format.

Now that we have the JWT token, we use this to make our third and final call to <MyInfo domain>/com/v3/person/<sub>

The <sub> in the URL is an attribute called sub which is found in the access token from the token API, after we have decoded it.

This is a GET call that takes the following as query parameters:-

We also need to pass the JWT token in the request header.

The response from this call is the personal data that is requested for KYC.

Note:- Token and Person API calls also require digital signatures on the request.

Higher Environments

Before we can start to consume MyInfo UAT/Production APIs, we will need to submit a link-up request to onboard.

1. Submitting a linkup request

To submit a linkup request, do provide the following information:

• The nature of business (e.g. financial institutions)
• Detailed business use case
• Graphical envisioned user journey
• Timeline of product roadmap (Expected go-live date)
• Expected annual transaction volume
• Any industry certifications (e.g. ISO27000)

Send this information to sign_support@ndi.gov.sgand we will get back to you within two weeks.

2. Items required for onboarding

Once we get the approval to onboard, we need to provide the following items:

1. A WebTrust-accredited or an accredited Singapore-based CA-issued X509 Certificate that contains both the client_authentication and server_authentication in the ExtendedKeyUsage. We can either submit two separate certificates or as one. This certificate is used for establishing a mTLS connection for consuming NDI Digital Signing Service (DSS) API and for the DSS API to contact the RP/DSAP’s webhook
2. The full certificate chain of the above
3. A Certificate Signing Request for the National Certification Authority to issue us a certificate for the mTLS connection to NCA. The parameters must conform to the following:

• CN and OU values must be in the format “NDI-DSAP-[NAME]” (e.g. NDI-DSAP-ABC)
• Organisation (O) must be : Assurity Trusted Solutions Pte Ltd
• Country must be : SG
• Certificate Public Key must be : ECDSA 256-bit
• Key Usage: digitalSignature, nonRepudiation, Key Encipherment
• Extended Key Usage: id-kp-clientAuth
• The rest of the values that are not stated here must be left blank

4. Other onboarding information that may be required (e.g. IP addresses)

Thanks to all those who had the patience to read through here. I know for some these info may not be enough and they may look for a working implementation.

For all of them I plan to write a second part of this blog that may give more insights on the implementation.

Till then, happy learning!