Singpass Developer Docs
Legacy Myinfo v3/v4
Legacy Myinfo v3/v4
  • Legacy Myinfo v3/v4
  • Data Catalog
  • Key Principles
  • Technical Specifications
    • Myinfo v4
      • Difference between v3 and v4
      • Technical Guidelines
      • Technical Concepts
        • OAuth 2.1 Concepts
        • Proof of Key Code Exchange (PKCE)
        • JSON Web Token (JWT)
        • Client Assertions
        • JSON Web Key Store (JWKS)
        • Demonstration of Proof-of-Possession (DPoP)
      • API Specifications
      • Tutorials
        • Tutorial 1: Myinfo Person sample Data
        • Tutorial 2: End-to-end Integration with Myinfo v4 APIs
      • Resources
        • Myinfo Connectors
        • Error Codes
      • FAQ
    • Myinfo v3
      • Technical Guidelines
      • API Specifications
      • Latest X.509 Public Key Certificate
      • Tutorials
        • Tutorial 1: Basic Person API
        • Tutorial 2: Using OAuth2
        • Tutorial 3: Implementing PKI Digital Signature
      • Resources
        • Myinfo Connectors
        • Error Codes
      • FAQ
Powered by GitBook
On this page
  • Q1. I am currently using Myinfo v3. When is the deadline to upgrade to Myinfo v4?
  • Q2. I encountered an error while developing my digital service integrating with Myinfo APIs, who can I contact?
  • Q3. My Enterprise Architecture design requires whitelisting of Myinfo APIs IP address. What is the IP address that I should whitelist?
  • Q4. How frequent does Myinfo APIs get updated? How do I get notified when there is a new version of Myinfo APIs? Can I continue to use the older API version even if a newer version is released?
  • Q5. Does Myinfo APIs support native mobile application?
  • Q6. Is there any requirement for the JWKS? Can we use the same url endpoint for our staging and production environments?Please ensure that JWKS URL :
  • Q7. How can I rotate my Signing Keys?
  • Q8: How can I rotate my Encryption Keys?
  • Q9. I am trying to decrypt the JWE response string returned from Myinfo Person API. However, I am getting the following error message:
  • Q10. My architecture design requires trusting of Myinfo web SSL certificate. Where can I retrieve the certificate?
  • Q11. What are the requirements for callback URLs in the app configurations submission?
  • Q12. There is no 'state' parameter in /authorize. How can I identify the specific request?
  • Q13. How may I test that my app is able to support cases where additional security verification with Singpass Face Verification is required?
  • Q14. What are the supports available for me to conduct performance testing?
  • Q15. Who do I contact if I require more details?

Was this helpful?

  1. Technical Specifications
  2. Myinfo v4

FAQ

PreviousError CodesNextMyinfo v3

Last updated 1 month ago

Was this helpful?

Q1. I am currently using Myinfo v3. When is the deadline to upgrade to Myinfo v4?

It is no longer mandatory for partners to migrate to Myinfo v4. Singpass is undergoing a technical refresh and a new version of Myinfo will be released in due time.

From the time the new version of Myinfo is released,

  1. Partners on v3 will have 6 months to migrate.

  2. Partners on v4 will have 12 months to migrate.


Q2. I encountered an error while developing my digital service integrating with Myinfo APIs, who can I contact?

For troubleshooting, you may refer to the with the possible causes.

Please submit a request at if you encounter error with the implementation.


Q3. My Enterprise Architecture design requires whitelisting of Myinfo APIs IP address. What is the IP address that I should whitelist?

Myinfo APIs does not support IP whitelisting as our API Gateway is using dynamic IPs. Please whitelist the following Fully Qualified Domain Names (FQDN) instead:

  • test.api.myinfo.gov.sg

  • api.myinfo.gov.sg


Q4. How frequent does Myinfo APIs get updated? How do I get notified when there is a new version of Myinfo APIs? Can I continue to use the older API version even if a newer version is released?

The Government plans to make Myinfo more useful for digital transactions by progressively including other frequently-used profile data.

When a new version of APIs is released, there will be a transition period for digital services to migrate to the latest version. The earlier API version is usually deprecated 6 months after the new version is released.

Please ensure that your support emails are registered in your app to receive important announcement such as Myinfo new version or new data items release.


Q5. Does Myinfo APIs support native mobile application?

Myinfo APIs currently only support web-based integration.


Q6. Is there any requirement for the JWKS? Can we use the same url endpoint for our staging and production environments?Please ensure that JWKS URL :

  • Is served behind HTTPS on port 443 using a TLS server certificate issued by a standard publicly verifiable CA issuer (no private CAs), with complete cert chain presented by the server

  • Is publicly accessible (no IP whitelisting, mTLS or other custom HTTP header requirements outside standard HTTP headers such as Content-Type, Accept)

  • Is able to respond in a timely fashion

  • Contains at least 1 sig key with alg ES256

  • Contains at least 1 enc key with alg ECDH-ES+A256KW

Due to security reasons, we recommend that you have a different JWKS URL for both staging and production environment


Q7. How can I rotate my Signing Keys?

Relying parties can rotate their signing keys in a self-driven manner. To do this with zero downtime the Relying party must

  • support use of JWKS URLs and be onboarded as such

  • ensure their replacement signing key has a different key ID (kid) to the original key

  • ensure their replacement signing key matches the other cryptographic key requirements

To do this with zero downtime, the following procedure should be followed by the Relying Party:

Time
Action

Prep

Relying party generates a new signing key pair (K2) supported for signing.

T0

Relying party adds public key K2 to its JWKS endpoint (and leaves K1 on the endpoint)

T0 - T+1 hour

Myinfo’s cache will expire, and re-retrieves the relying party’s published keys from their JWKS endpoint which now includes K2

> T+1 hour

Relying party changes their system to start signing client assertions using the new signing key K2

Clean Up

Post-validation, relying party can remove key K1 from their JWKS endpoint when they are comfortable their new signing key is working


Q8: How can I rotate my Encryption Keys?

Relying parties can rotate their encryption keys in a self-driven manner. To do this with zero downtime the Relying party must

  • support use of JWKS URLs and be onboarded as such

  • have the ability to decrypt tokens produced with either one of two different encryption keys based on either

    • selecting the correct decryption key by its key ID (kid)

    • trial-and-error decryption against multiple keys in a collection

  • ensure their replacement key matches the other cryptographic key requirements noted above

To do this with zero downtime, the following procedure should be followed by the Relying Party:

Time
Action

Prep

Relying party generates a new encryption key pair (K2) supported for decryption. The existing key pair (K1) is still available for decryption of ID tokens

T0

Relying party removes public key K1 and adds public key K2 on its JWKS endpoint

T0 - T+1 hour

NDI’s caches will expire at any (indeterminate) time within this period, and start encrypting tokens with new encryption key K2.

T0 - T+1 hour

Relying party may be receiving tokens encrypted with either K1 or K2 keys throughout this period; and must be able to decrypt either.

> T+1 hour

Relying party can remove support for decrypting with the previous K1 key


Q9. I am trying to decrypt the JWE response string returned from Myinfo Person API. However, I am getting the following error message:

*A256M is not valid algorithm*

The library that you are using to decrypt the response string might not support A256GCM algorithm. Please use a library that supports the algorithm.


Q10. My architecture design requires trusting of Myinfo web SSL certificate. Where can I retrieve the certificate?


Q11. What are the requirements for callback URLs in the app configurations submission?

Please note the following requirements for callback URLs submission:

  • Use different callback URLs in staging and production environments.

  • Use static callback URLs (i.e. dynamic callback URLs are not supported)

  • Use Fully Qualified Domain Names (FQDN) for both the staging and production callback URLs (i.e. static IP address or port numbers in callback URLs are not supported)

  • Multiple callback URLs may be submitted for each environment.


Q12. There is no 'state' parameter in /authorize. How can I identify the specific request?


Q13. How may I test that my app is able to support cases where additional security verification with Singpass Face Verification is required?

To ensure that SFV works for your Myinfo user journeys, you may verify that camera permissions are enabled through the following methods:

  1. Staging: Test additional Singpass Face Verification through the link provided on the Mockpass page

  2. Production: Test that SFV works for the Myinfo user journey on different modalities (e.g. mobile/computer browser, native mobile app). You can test SFV through the following steps: a. Initiate the Myinfo user journey in your linked up service with the above App IDs b. Log in with your Singpass ID and password instead of the QR code c. Select Singpass Face Verification as the 2FA method instead of SMS OTP


Q14. What are the supports available for me to conduct performance testing?


Q15. Who do I contact if I require more details?

We recommend that your application trust / pin against the instead, as the web SSL certificates will be renewed from time to time.

Use the default pre-configured as staging callback URL for localhost testing. We do not support other localhost port and http configurations.

You are required to maintain a session with the user's frontend browser. This can also be used to tie the correct code_verifier to code_challenge ()

Performance Testing in Production environment is strictly not allowed. Please submit a request at if you are planning to conduct performance testing in Test environment.

If you have any other query, please submit a request at .

error codes page
partnersupport.singpass.gov.sg
root certificates
http://localhost:3001/callback
PKCE
partnersupport.singpass.gov.sg
partnersupport.singpass.gov.sg