FAQ
Last updated
Was this helpful?
Last updated
Was this helpful?
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,
Partners on v3 will have 6 months to migrate.
Partners on v4 will have 12 months to migrate.
For troubleshooting, you may refer to the with the possible causes.
Please submit a request at if you encounter error with the implementation.
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
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.
Myinfo APIs currently only support web-based integration.
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
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:
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
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:
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
The library that you are using to decrypt the response string might not support A256GCM algorithm. Please use a library that supports the algorithm.
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.
To ensure that SFV works for your Myinfo user journeys, you may verify that camera permissions are enabled through the following methods:
Staging: Test additional Singpass Face Verification through the link provided on the Mockpass page
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
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 .