Service maintenance with customer test DNS update
Time: 2022-11-30 09:00 - 13:00 CEST
: This change has been rolled back and will be implemented at a later time to be announced.
Nets will perform maintenance on the FTN/E-Ident, E-Signing and ID-Rights services in the customer test environment. The customer test platform will be upgraded through introduction of new servers. As a consequence of this upgrade the DNS will be updated to reflect new IP-addresses for our services when accessed from Internet. Details are described in the table below:
Services in production will not be affected, only the customer test services.
Service maintenance for Finnish bank S-Pankki
Time: 2023-02-05 00:05 - 06:00 EET
The Finnish bank S-Pankki has announced a service window for their identification service. During the service window, identifications with S-Pankki through the FTN service will be unavailable.
Service maintenance for Finnish bank OP
Time: 2023-02-05 02:00 - 06:00 EET
The Finnish bank OP has announced a service window for their identification service. During the service window, identifications with S-Pankki through the FTN service may be unavailable.
Norwegian BankID SEID 2.0 changes
Customer test: 10 May 2022
- Production: Some time during January - March 2023 (postponed from 1 November 2022). Excact date will be published here when this is decided by BankID BankAksept AS.
BankID BankAxept AS has announced changes in their BankID service. These changes will be visible in Nets E-Ident and E-Signing services wherever Norwegian BankID certificate is visible. In addition to this, the following applies:
- For Nets E-Ident through OIDC the changes will be visible in "sub", "no_bid_pid" and cert related claims.
- For Nets E-Ident through SAML the changes will be visible in "subject", "NO_BID_PID" and certificate related attributes.
For Nets E-Signing service the UniqueId field, included in "GetSDODetails" response will have the same value as the BankID Subject serialnumber field, and will thus be updated as described below.
Please find below a detailed description provided by BankID BankAxept AS:
INFORMATION FROM BANKID BANKAXEPT AS:
BankID certificate contents will change for both End-user certificates to physical persons and Merchant certificates. The reason for this is an alignment of national standards for certificate contents with corresponding European standards.
For physical persons the name field in the certificate will be extended with a separate field for given name and a separate field for surname. The common name will be kept as it is. The serial number inside the same sequence will stay the same, but it will be encoded with a prefix UN:NO-. This is a preparation for international use.
Certificates to physical persons contain some identifiers to statements about content and usage of the certificate. One such statement is added, another removed, but it is not likely that will cause any practical problems.
The most significant change to merchant certificate is that we add a sub-field called OrganizationIdentifier in the name field. This adds to prefix for international use to the national organization number. For compatibility reasons the original organization number is still kept in the SerialNumber sub-field.
We ask you to pay extra attention to your use of changed and removed attributes. In particular in the person certificates:
Subject Serialnumber - this is now prefixed with “UN:NO-“
- SubjectAltName - this is removed
- Subject Distinguished Name - minor changes in formatting
We updated our preprod environment with the changes on Wednesday 10 May 2022. The changes can be tested in our preprod environment. The changes will go into production around 1 November 2022.
It is highly recommended for everyone to test and verify their systems against preprod before the changes go into production.
Overview of the changes:
- Change: (new) Subject Serialnumber = “UN:NO-“ + old Subject Serialnumber (PID)
- Add: givenName (G ?)= substing of commonName following format of common name “surname + comma + space + givenName)”
- Add: surname (SN) = substing of commonName following format of common name “surname + comma + space + givenName)”
- Add: qcStatement-2 iht. RFC 3739  og ETSI EN 319 412-1  kap. 5.1.1 med verdien id-etsi-qcssemanticsId-Natural.
- Keep: esi4-qcStatement-1
- Remove: esi4-qcStatement-2 (QcEuLimitValue)
- Keep: esi4-qc-Statement-5
- Keep: esi4-qc-Statement-6
- Change: Subject Distinguished Name
- Remove: SubjectAltName
- Change: QcStatements
Keep: Subject Serialnumber. Stays the same just because of compatibility reasons
- Add: organizationIdentifier = “NTRNO-“ + Subject Serialnumber
- Change: Subject Distinguished Name
- Remove : SubjectAltName
- Keep: No QcStatements
Required upgrade to use encrypted ID Token for FTN customers
Time: As soon as possible or the 31st January 2023 as the latest
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. This means that several customers need to update their implementation with support for encrypted ID Tokens and a few customers need to change the implementation from SAML to OIDC. Below are links to documentation regarding both encrypted ID Tokens, and the OIDC protocol.
Customers are kindly requested to update their implementation now and in any case well before the deadline 15th September 2022. Please
contact support to request update of your customer configuration and with other questions.
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.
Startup in test
Question 4: Could we enable encryption in test environment now?
Yes, you can start with customer test now, and later enable encryption in production.