Technical Guidelines

1. Transaction Log

Digital services which have integrated with Myinfo should track and store user transactions for potential issue management.

The following are some of the suggested minimum fields for tracking:

• UUID, Partial NRIC/FIN or NRIC/FIN (as relevant to usage under PDPA guidelines)

• Fields requested from Myinfo

• Time Stamp

• Transaction ID

In the event of user feedback or contact, these transaction logs may be requested by Myinfo to reconcile and resolve issues raised by the user.

---

2. JSON Web Key Store (JWKS)

The relying party is expected to provide public keys to Myinfo in the JWK format. These public keys will be used in the following (non-exhaustive) scenarios:

• Signature JWK used to verify the signature of the client_assertion JWT presented during /token request.

• Encryption JWK used to encrypt the retrieved user's data in /person request.

The relying party is expected to host the JWKS with below specifications:

• 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

The Relying party is expected to follow below key rotation and caching policies

• Retrieval of Myinfo JWKS should be cached for at least one hour and not retrieved for every JWT validation.

• For varying reasons, keys used for signing can and will be rotated/changed with no defined schedule, and at the full discretion of Myinfo. When a key rotation happens, the new key will be available from the JWKS endpoint and will have a different kid value. The new kid value will be reflected in all the new JWTs signed by Myinfo. In such cases, cached copies of Myinfo public keys must be refreshed by re-invoking the JWKS endpoint.

• All Key pairs are recommended to be rotated every 2 years with the old key pairs removed once rotation is sucessful.

• Keying materials e.g shared secrets, seeds shall be destroyed immediately or as soon as possible when no longer requried.

---

3. TLS & Cipher Suites

IMPORTANT: In line with contemporary industry best practices, Myinfo supports TLS 1.2.

The list of supported strong cipher suites include:

• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Recommendation on Myinfo Certificate pinning RPs must not do "cert pinning" or create any form of dependency to the TLS certificates to Myinfo domains. Myinfo reserves the right to rotate its TLS certificates without prior notice to RPs. Should your application architecture require cert pinning, we recommend that your application trust / pin against the root certificates instead.

---

4. Callback URLs

For security reasons:

• Different callback URLs should be used for staging and production environments

• Fully Qualified Domain Name (FQDN) of staging and production environments should be used (i.e. instead of IP address)

• Callback URLs should not contain Hash (#) or Wildcard (*) characters

---

5. Mobile App integration

• Myinfo offers integration via browser redirections. Native application integration is not supported.

• Integration should be done via in-app browser (not WebViews) or external browser.

• For services integrating on Android, setDomStorageEnable should be enabled.

• Camera permissions for your app must be enabled to support cases where additional security verification with Singpass Face Verification is required.