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:
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?
We recommend that your application trust / pin against the root certificates instead, as the web SSL certificates will be renewed from time to time.
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.
Use the default pre-configured http://localhost:3001/callback as staging callback URL for localhost testing. We do not support other localhost port and http configurations.
Q12. There is no 'state' parameter in /authorize. How can I identify the specific request?
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 (PKCE)
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:
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
Q14. What are the supports available for me to conduct performance testing?
Performance Testing in Production environment is strictly not allowed. Please submit a request at partnersupport.singpass.gov.sg if you are planning to conduct performance testing in Test environment.
