E-Ident operational information
All coming customer affected changes for E-Ident.
2024-09-01: BankID on mobile was turned off September 1, 2024
2024-11-24: Service maintenance for several Finnish banks OP
FAQ: Traficom requirements for FTN signed authentication requests
BankID on mobile was turned off September 1, 2024
Time: 1st September 2024
Information
BankID on mobile was turned off September 1, 2024. It is no longer be possible to use BankID on mobile.
Details on our statuspage: signingandidentificationservices.statuspage.io
BankID BankAxept announcement: bankid.no
Service maintenance for Finnish bank S-Pankki
Time period: 2024-04-17 23:00 - 2024-04-18 07:00 EEST
Information
The Finnish bank S-Pankki has announced a service window for their identification services. During the service window, identifications with S-Pankki through the FTN service will be unavailable.
Service maintenance for Finnish bank OP
Time period: 2024-04-20 22:00 - 2024-04-21 07:00 EEST
Information
The Finnish bank OP has announced a service window for their identification services. During the service window, identifications with OP through the FTN service may be unavailable in short periods.
Service maintenance for Finnish bank Nordea
Time period: 2024-04-21 01:00 - 05:30 EEST
Information
The Finnish bank Nordea has announced a service window for their identification services. During the service window, identifications with Nordea through the FTN service will be unavailable.
FAQ: Encrypted ID Token for FTN customers
Background
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.
Documentation:
OIDC protocol
Encrypted ID Token
Code examples in the Get started guide and in the demo app
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-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA32frjzf3sUdKfHrwKWw5
6Kj1YXdQcQ+2BX4L5ZYFx1QztRcrQiz57yOtBBIsNCLmbLC0Gu+2dlKG4/FJVBcR
IOgXD+LQW2IUnV0AFR2N8EVlbilQvkKSA0FAAb+0D+v8Y6xcjlu5QJOLtOEY09cA
G3CseylRvNwnBJYwoainl7BEPAWjAAZ4FQV1PYrVFG7+YeyE33DH0FXG4VWOCvvC
b537PZwbisTkXfDslJZg+v+KTyPCQUt7ZUwKJ3b+WoxdEhKOaI3Dt/A/N3oQhZrX
+miH7MclhmOzNhayYCghyUks7CdPgy1fdRvhziFkwJ3chh3jhkJ4KEBnj0uVCrfS
XwIDAQAB
-----END PUBLIC KEY-----
Below is the same public key as above, but now formatted as a JWK (JSON Web Key):
{
"kty": "RSA",
"n": "32frjzf3sUdKfHrwKWw56Kj1YXdQcQ-2BX4L5ZYFx1QztRcrQiz57yOtBBIsNCLmbLC0Gu-2dlKG4_FJVBcRIOgXD-LQW2IUnV0AFR2N8EVlbilQvkKSA0FAAb-0D-v8Y6xcjlu5QJOLtOEY09cAG3CseylRvNwnBJYwoainl7BEPAWjAAZ4FQV1PYrVFG7-YeyE33DH0FXG4VWOCvvCb537PZwbisTkXfDslJZg-v-KTyPCQUt7ZUwKJ3b-WoxdEhKOaI3Dt_A_N3oQhZrX-miH7MclhmOzNhayYCghyUks7CdPgy1fdRvhziFkwJ3chh3jhkJ4KEBnj0uVCrfSXw",
"e": "AQAB"
}
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.
FAQ: Traficom requirements for FTN signed authentication requests
Background: Traficom requirements for FTN signed authentication requests mandates, the use of digitally signed authentication requests, also referred to as Signed Request Objects in the OIDC specification is now mandatory. Not abiding with this requirement will lead to discontinuation of service.
Question 1: What is the new regulation introduced by Traficom?
Traficom requires all FTN customers to use signed authentication requests, referred to as Signed Request Objects under the OpenID Connect (OIDC) specification.
Question 2: What does E-Ident require for authentication requests?
E-Ident requires all FTN authentication requests to include a signed request object. Only requests that successfully pass signature verification will be accepted and forwarded to the FTN electronic identification provider.
Question 3: What happens if an authentication request is not signed?
Unsigned authentication requests will not be accepted or processed by E-Ident.
Question 4: What format should the signature key be in?
The signature key must be provided in either:
JWK (JSON Web Key) format, or
URL to JWKS (JSON Web Key Set)
Include the KID (Key ID) if required.
Question 5: What should customers do to comply?
Customers must share their public key with E-Ident (via customer service email - support.esecurity@nets.eu) to successfully validate signed requests sent to E-Ident.
Refer the following link for a guide on how to generate a public key: https://doc.ingroupe.com/developer/operational-information#E-Identoperationalinformation-%E2%80%8B%E2%80%8BFAQ:EncryptedIDTokenforFTNcustomersrt5:~:text=Question%201%3A%20Is%20there%20any%20guide%20/%20example%20for%20us%20about%20how%20to%20generate%20and%20provide%20you%20with%20a%20public%20key%3F
Question 6: What is a Signed Request Object in OIDC?
It is a JWT (JSON Web Token) that contains the authentication request parameters and is digitally signed to ensure integrity and authenticity.
Refer here for additional details on the signed requests: OpenID Connect
Question 7: This request returns protocol404. Why? https://www.ident-preprod1.nets.eu/its/index.html?request=eyJhbGciOiJSUzI1NiJ9.eyJhdW
Your request is missing the 4 mandatory request parameters: client_id, scope, response_type and redirect_uri. These must be duplicated and provided outside of the request object.
Question 8: Are there any tools available for verification of the signed request object?
Yes, you can find a tool for this purpose on http://jwt.io
Question 9: Can we use the same JWKS for both request signing key and token encryption key?
Yes, you may use the same key for both token decryption and request signing, provided it is correctly published in JWK or JWKS format with kid if needed.
Question 10: Would you like us to provide a JWKS for the public key. Is the KID mandatory?
If the KID is required to ensure the correct key is selected from the JWKS you will need to send this KID to us for configuration.
Question 11: Which endpoints require signing?
Signed authentication requests are required for the FTN service through E-Ident. The affected endpoints are listed below.
Test endpoint: https://www.ident-preprod1.nets.eu/its/index.html?client_id=
Production endpoint: https://www.e-ident.nets.eu/its/index.html?client_id=
For additional information on the endpoints, refer https://doc.ingroupe.com/developer/service-access
Question 12: Which OIDC request parameters must be included?
For FTN, please refer the documentation on Signed Request Objects ( https://doc.ingroupe.com/developer/openid-connect#OpenIDConnect-Signedrequest ).
Mandatory Parameters Outside the Signed Request Object
Even when using a Signed Request Object, the following parameters must still be included outside the JWT:
request
client_id
response_type
Parameters to Include in the Signed Request Object
The following parameters must be included inside the Signed Request Object (JWT):
response_type
client_id
scope
state
redirect_uri
Optional Parameters to include in Signed Request Object
Refer here https://doc.ingroupe.com/developer/openid-connect#OpenIDConnect-Optionalt2
Question 13: What is a serialized, signed JWT, and is there an example?
A serialized, signed JWT (JSON Web Token) is a compact, URL safe token that contains authentication request parameters and is digitally signed to ensure integrity and authenticity. In the context of OpenID Connect (OIDC), this is known as a Signed Request Object.
It is used to securely transmit authentication parameters from the client to the authorization server, ensuring the request is trustworthy and tamper-proof.
For more details, refer to Section 6.1 of the OpenID Connect Core Specification: https://openid.net/specs/openid-connect-core-1_0.html#JWTRequests
Example JWT Payload:
{
"iss": " https://www.ti2-test.ingroupe.com/ti2_merchant/",
"aud": "EXAMPLE",
"client_id": "EXAMPLE",
"scope": "openid profile",
"response_type": "code",
"amr_values": "fi_tupas",
"state": "example-state-123456",
"nonce": "example-nonce-123456",
"redirect_uri": " https://www.ti2-test.ingroupe.com/ti2_merchant/return.html_env=demo"
}
This payload is then signed using the client’s private key to form the final JWT, which is sent as part of the authentication request.
Question 14: Are the iss and aud parameters required?
Yes, both iss (issuer) and aud (audience) are typically required in the Signed Request Object to comply with OIDC standards and ensure the request is properly validated.
Question 15: Will unsigned requests still be accepted after we configure signing?
Yes, unsigned requests will continue to be accepted until
Question 16: We are going to use a JWKS with multiple keys. Two of the keys, one for signing (“sig”) and one for encryption (“enc”), will have the same KID. Do you support this?
No. Each key published in your JWKS must have a unique Key ID (kid), even if one is for signing and another is for encryption. Reusing the same kid across multiple keys may cause validation errors, as the system relies on the kid to identify the correct key during signature verification. We recommend assigning distinct kid values for each key to avoid conflicts.
Question 17: We are using the same client for FTN, Swedish BankID and Norwegian BankID. Do we need to use signed request object for all these ID Providers?
No, it is mandatory only for FTN.