Service maintenance on database
Time: 2023-12-03 00:00 - 02:00 CET
E-Signing, E-Ident (including FTN and ID Verifier), ID-Rights, E-Signing Portal and E-Consent will have a service window on Sunday 3rd December 2023 for production database maintenance. During the service window, these services will be unavailable. Most likely time of unavailability is during database switch-over at around 00:05 and 01:30 CET.
Service maintenance for Telia
- 2023-12-11 22:00 - 2023-12-12 03:00 EET
- 2023-12-13 22:00 - 2023-12-14 03:00 EET
Telia has announced a service window for their identification service in the above time period. The FTN service offers Mobiilivarmenne identification through Telia. During the service window, identification with Mobiilivarmenne through the FTN service may be unavailable.
Replacement of SSN with SUB for BankID Sweden
Time: 1st April 2024
When integrating E-Ident using OIDC protocol, the resulting ID Token contains a claim called "sub". After April 1, 2024, the value of the sub claim for BankID Sweden will no longer include social security number. An anonymous identifier will be used instead. The sub claim value will remain consistent for the same individual from this date onwards.
Customers using the sub claim to identify users should consider that the value will change after the given date. The "ssn" claim will still work as before.
FAQ: Encrypted ID Token for FTN customers
To be aligned with requirements to identity brokers from Traficom (Finnish Transport and Communications Agency), all FTN customers MUST use the OIDC protocol with encrypted ID Token in the communication with the FTN service. Below are links to documentation regarding both encrypted ID Tokens, and the OIDC protocol.
Frequently Asked Questions related to encrypted ID Token
Generate Public Key
Question 1: Is there any guide / example for us about how to generate and provide you with a public key?
Generation of an RSA public key should be done using your preferred encryption tool, and according to related documentation provided by said tool.
Here is an example on how you can generate a key-pair using the popular openssl command line tool:
openssl req -new -newkey rsa:2048 -keyout key.pem -pubkey -out pubreq.p10 -subj "/CN=MyKey"
The file key.pem will contain your password-protected private key that you must implement into your application. The file pubreq.p10 will contain both the public key and the CSR-request. The public key must be sent to us, and the CSR-request you can ignore.
Public Key Format
Question 2: In what format do you need encryption keys?
The public key must be provided for us in PEM format, as a JWK or as URL link to a JWKS on web.
Below is an example of a public key in PEM-format (base64-encoded ASN.1 binary):
-----BEGIN PUBLIC KEY-----
-----END PUBLIC KEY-----
Below is the same public key as above, but now formatted as a JWK (JSON Web Key):
A public key may also be added to a JWKS (JSON Web Key Set) on a publicly available web site. In this case, you must send us the URL, and we will register and use the URL to retrieve the public key. The advantage of publishing the key on your own web, is the fact that you may later update the key on your side, without involving us.
Key for test and prod
Question 3: Can we have a separate key for test and production?
Yes, we recommend that you create separate key-pairs for customer test and production.