MitID

About Danish MitID

MitID is a new identity provider for digital personal identities. It is a collaboration between the Danish banks and the Danish public sector. This alliance forms a countrywide solution and provides a secure login mechanism for all citizens in Denmark. People in Denmark can use MitID for online banking, Digital Post, communication with public authorities, identifying themselves in other digital services and more.

Try it out

Here is how the MitID login box will look for the end-users: Signicat MitID demo.
Tip: Since it is a demo, any username and password will work.

For more frontend information, see Frontend policies and guidelines.

Time plan

MitID is the next generation of the Danish digital identity infrastructure and will replace NemID by mid-2021. There will be a transition period, where people can use both methods. The plan is to phase out NemID at the beginning of 2022.

The MitID core system is delivered in four main deliverables from March to November 2020. Signicat has planned the MitID implementation accordingly with the following milestones:

Since January 2020, Signicat has started developing integration with the MitID identity infrastructure. A beta version in Signicat’s development environment is available from July 2020. In January 2021, a pilot version will be available in Signicat’s production environment for selected service providers.

Contact Signicat for more information

Signicat will continuously add content to this page reflecting the status of the integration.

To keep updated on the development progress, you can sign up for the latest news by sending an e-mail to mitid@signicat.com.

Signicat will be happy to assist you in ordering and setting up MitID. Please, contact Signicat for more information.

Key features of MitID

This is an overview of important features in MitID (more details will come later):

  • A common, national identity and authentication solution.
  • Public actors, financial institutions and other private service providers can communicate with the identity core through identity brokers.
  • The MitID broker role requires a certification, and brokers can provide their own client solutions for end-user authentication.
  • Replaces the NemID code card with smartphone-based, password-based and physical authentication factors.
  • Secure login supporting all three Level of Assurance (LoA) from eIDAS – Low, Substantial and High. With Low as LoA, the missing “one-factor” login in NemID is possible with MitID.
  • Use on many platforms like web, desktop, mobile devices.
  • Single sign-on possible between services that use MitID.
  • Use together with Signicat’s MobileID InApp or a standalone MobileID App to build your own eID.
  • Integrate with Signicat Sign to create Advanced Electronic Signatures (AES). Qualified Electronic Signatures (QES) will come later.

Migration from NemID to MitID

MitID offers the same functionality as NemID with additional features and ease of use, flexibility and safer authentication of Danish citizens and businesses. The main differences are both within the underlying technology and by improved user experience.

Migration process overview

The main steps in the migration period for you as a service provider are as follows:

  1. Signicat presents an offer and information about needed steps you must follow to have a fully functional eID solution running through Signicat. To get help with this, please contact Signicat.
  2. You sign a contract with Signicat as a broker.
  3. Signicat registers you in the MitID Broker portal. You do not need any specific certificate for this.
  4. Signicat sets up MitID in a pre-production environment and gives you access to this environment.
  5. You do the necessary changes in your integration with Signicat. When going from NemID to MitID, be aware of the following changes:

For more general onboarding information, see Project and integration phases.

The transition period

MitID is scheduled to go live in May 2021 and NemID is scheduled to be phased out at the beginning of 2022.

This period between May 2021 and January 2022 will be a transition period for end-users to migrate from NemID to MitID.

Note: It is the Danish banks and the Danish government services (e.g. eSkat) that handle the migration of end-users from NemID to MitID. The broker or service providers have no role in this process.

In this transition period, Signicat recommends that you support both NemID and MitID, and that you, for example, present both the login options for your users on your login page.

These can be displayed in a portal that Signicat sets up or you can create it yourselves. Signicat’s API is flexible and makes it possible for you to create your own login portal with MitID from Signicat and NemID from the old integration.

Authentication with MitID compared to NemID

In short, the main difference seen from the end-user’s perspective is that MitID provides new authenticator devices and single factor support.

For NemID, the only way of authentication is two-factor. It also always results in the Substantial level of assurance (LoA). MitID opens up for single factor support. The default level of assurance is Substantial, but it is also possible to set it to Low or High depending on the required level of security for your online information/transactions.

What does this mean for you as a service provider?

This means that you in the migration period must decide the appropriate level of assurance for your different use cases.
For more details about recommended authenticator setup and level of assurance, see the Authentication section.

The broker role

One major change from NemID is that all services using MitID for identity verification (authentication or digital signing) must access the MitID infrastructure through a MitID certified broker. This means you cannot access MitID directly as you could with NemID, but must go via a broker.

There are high certification requirements to become a MitID broker (ISO 27.001 level). Only organizations certified according to Digitaliseringsstyrelsen’s requirements, can act as an intermediate between the MitID core system and the service provider.

Signicat has passed the pre-qualification certification and is preparing for the final MitID broker certification.

Supported protocols

For NemID, Signicat supports both SAML 1.1, SAML2 and OIDC.

Note: Since SAML 1.1 will be deprecated soon, we recommend to use either OIDC or SAML2 for MitID.

Mapping of attributes used in NemID and MitID

This mapping table between attributes in NemID and MitID may help you in the migration process. The list presents the attributes for private identities (not business identities).

Note: The list of Signicat’s MitID attributes is preliminary and subject to change.

NemID:

Signicat attributes

MitID:
Signicat attributes
MitID:

Source attributes
(Auth response claim)

Description
OIDC: sub,
signicat.certificate_serialnumber

SAML2.0: subject.nameid.value

SAML 1.1: signicat.unique-id,
unique-id.nemid,
nemid.pid

signicat.unique-id,
mitid.uuid
mitid.dk.uuid Unique identifier for the eID
OIDC: name

SAML2.0: common-name

SAML1.1: signicat.plain-name,
oces.plain-name

signicat.plain-name,
mitid.name
name The full name of the user (if CPR) or the identity name (no CPR).
OIDC: signicat.national_id

SAML2.0: national-identity

SAML1.1: signicat.national-id,
nemid.cpr,
national-id.dk.cpr

signicat.national-id,
mitid.cpr
Not applicable

 

The user’s CPR (personal registration number). Given by user input and verified by MitID via the CPR registry
OIDC: given_name

SAML1.1: nemid.firstname

signicat.first-name,
mitid.firstname
TBD, may be derived from: name The user’s first name
OIDC: family_name

SAML1.1: nemid.lastname

signicat.last-name,
mitid.lastname
TBD, may be derived from: name The user’s last name
OIDC: email

SAML1.1: nemid.email

The user’s email
signicat.date-of-birth,
mitid.dateofbirth
mitid.dk.date_of_birth The user’s date of birth
mitid.age mitid.dk.age The user’s age
mitid.identity.name mitid.dk.identity_name The registered identity name of the user
mitid.loa dk.mitid.assurancelevel.loa Level of assurance
mitid.ial dk.mitid.assurancelevel.ial Identity assurance level
mitid.aal dk.mitid.assurancelevel.aal Authentication assurance level
mitid.fal dk.mitid.assurancelevel.fal Federation assurance level

UUID/CPR match service (former PID/CPR match service)

With NemID you need a separate agreement for using the PID/CPR match service. This is not necessary with MitID, since the CPR match is built into the MitID core. If you need CPR verification, you must use the CPR number as a parameter or Signicat can present a dialogue box where the end-user can enter the CPR number. This is similar to the NemID flow. 

Subdomains

The standard Signicat MitID service is available from signicat.mitid.dk. If you want to include your name in the domain, Signicat can offer you a customized sub-domain like <service-provider>.mitid.dk. For NemID and other methods, it will still be the same way of handling subdomains (see for example Signicat subdomain).

Authentication

Level of Assurance (LoA)

MitID is compliant with the NSIS standard, which is the Danish version of eIDAS (Electronic Identification and Trust Services in EU).

The defined LoA values for the transaction are Low, Substantial or High. Substantial is the default, but you can change this as required. LoA consists of the following assurance components:

  • IAL: “Identity Assurance Level” for the transaction. This refers to the identity proofing process and indicates how sure you are that the person is the true owner of the identity.
  • AAL: “Authentication Assurance Level” for the transaction. This refers to the authentication process and indicates how sure you are that the end-user is in control of the used authenticator.
  • FAL: “Federation Assurance Level” for the transaction. This indicates the requirements to a relying party for receiving information about the end-user.
    The level of assurance is decided by the combination of these components. When requesting an authentication, the request can either specify a target LoA, or a target AAL.

For an overview of attributes, see the section about attributes/claims.

Authenticators

With MitID, the end-user logs in with a username in combination with one or two authenticators.

MitID offers the use of the following authenticators:

  • Password: A high-security password authenticator implementation based on the Secure Remote Password (SRP) protocol.
  • Code display: A physical device authenticator showing a one-time password (OTP) to be typed into the service provider’s user interface within a certain time. It is based on OATH TOTP (RFC 6238)
  • Audio code reader: A sound-based TOTP token (time-based one-time password algorithm). The device reads aloud the OTP code to the user so the user can enter it in the service provider’s user interface. This is an alternative for visually impaired or if the user does not want to use the code app.
  • App: The user can use this app when a secure element is present in the hardware or in combination with the MitID chip, assuming proper activation. Both will give a High LoA. There is an alternative version of this app named App Enhanced Security. Then the user must enrol on a device with SE/TEE technology (secure element/trusted execution environment). These technologies are possible elements included in the NFC technology (Near Field Communication for smartphones). In addition, the user should not enable biometric unlocking of the app. This prevents the use of multi-user functionality.
  • Chip: This is a chip that supports the FIDO U2F standard. The end-user can combine this with the password or the app for reaching High LoA.

Possible authentication combinations

MitID supports different combinations of authentication methods. For easy user access, it is recommended to start low, e.g. with single-factor authentication. Single-factor authentication can be to combine a username with one of the mentioned authentication devices, for example a password.
If higher security is needed, you can step up to two-factor authentication. This means the end-user in addition to username and password, must use an additional authentication device like for example a code token. The following illustration shows a possible step-up scenario:

The following table (from the MitID broker package documentation) shows possible combinations of authentication methods and what level of assurance the combinations give (Low, Substantial and High):

For example, a password alone gives single-factor authentication with Low as LoA. Password together with a code token gives two-factor authentication with Substantial as LoA. Password together with a chip gives two-factor authentication with High as LoA etc.

Note: As a broker, Signicat supports all these authentication methods. MitID decides the possible combinations. The service provider decides which should be the default authentication method.

Authentication flows for the end-user

The authentication flow for the end-user depends on the level of assurance for each use case and which authenticator(s) the end-user uses. This section shows some authenticator combinations with photo sliders.

Username and password (single-factor, Low)

The following flow is a basic single-factor login with username and password. It gives Low as LoA, which is the missing “one-factor” login in NemID.

  1. From the service provider site, the end-user selects the MitID Login link. This displays the Load page. The Load page sets the stage for a safe and secure end-user experience.
  2. After the load screen, the MitID Login box is presented in front of the broker’s landing page. The end-user enters the username.
  3. The end-user enters a personal password.
  4. When the end-user is successfully identified, the Approved screen is displayed. The end-user is redirected to your site as logged in.

Tip: Click on the image below to start the photo slider.

App in combination with username (single-factor, Substantial)

To obtain Substantial LoA, the end-user can replace the Password authenticator with the App authenticator in the above flow:

Tip: Click on the image below to start the photo slider.

 
Chip in addition to password (two-factor, High)

To step up to two-factor authentication with High LoA, the end-user can add the Chip authenticator to the username and password combination:

 

Code display in addition to password (two-factor, Substantial)

To step up to two-factor authentication with Substantial LoA, the end-user can add the Code Display authenticator to the username and password combination:

 

 

 

Audio code reader in addition to password (two-factor, Substantial)

Visually impaired can use the Audio code reader authenticator as an alternative to the Code display authenticator. This is also a step up to two-factor authentication with Substantial LoA:

 

 

Frontend policies and guidelines

The UX scheme is a central part of the MitID brand, and there are strict rules on how to set up the end-user interface, e.g. for the MitID Login box. However, you do not need to worry about these rules, since Signicat as a  broker will handle it for you. In addition, there are some GUI elements that you may decide or adjust yourselves (for more details, see the guideline sections below).

Customizing the frontend

You may decide or adjust the following elements for the MitID Login box:

  • Pop-up or redirect?
  • Texts like reference text header and action texts, e.g. Log på.
  • Colors (More information will come later)
  • Language (Danish, English or Greenlandic)
Graphical profile of the MitID broker landing page

In addition to having a custom domain name (see Subdomains), you can also customize the graphical profile around the MitID Login box. This area around the MitID Login box is called the MitID broker landing page. You have three choices:

  • Use one of the two standard landing page templates that Signicat offers.
  • Use Signicat’s static page. This allows you to create your own landing page. However, this requires a more manual process to change.
  • Use Signicat’s custom dynamic page. This means you will have access to change the page yourselves, for example, if you would like to customize your page with campaigns or occasional branding.

Note: The landing pages must be WCAG 2.1 AA compliant. Signicat validates this.

For general information about Signicat’s standard graphical profile around identity methods, see Graphical adjustments and customization.

Pop-up or redirect?

This choice is up to you and is all about user experience (see more details below). Both ways are equally secure. The following sub-sections describe the advantages and disadvantages of both redirects and pop-ups.

Pop-up

The popup is displayed on top of your website when the end-user is asked to authenticate and will be closed once the authentication is successful.
Advantage: The end-user does not shift context and can see your website behind the popup when using a PC.

Disadvantages:

  • For mobile devices, the pop-up is displayed in a new tab and the end-user switches context.
  • End-users may experience problems with pop-up blockers, resulting in never seeing the MitID Login box.
  • If the end-user enlarges the text, a scrollbar may appear, and this is not allowed.
  • Some flows may require more space than is suitable for a pop-up.

Recommendations for desktops:

  • When using a pop-up on a desktop, the broker landing page should be as limited as possible to create a familiar experience for the end-user. For example, avoid unnecessary elements around the MitID box.
  • Center the pop-up on the screen and anchor the MitID box to the top.

Recommendations for mobile devices (tablets and smartphones):

  • Set up the switch between the original tab and the MitID tab automatically so the users do not get stuck nor must navigate themselves.
  • The space around the MitID box must adapt to the screen size.
  • Center the pop-up on the screen and anchor the MitID box to the top.

Smartphone:

Tablet:

Redirect

A redirect means the end-user is redirected to be authenticated on the broker landing page where the MitID box is shown inside the landing page. When the authentication is successful, the user is sent back to your website.
Advantage:

  • The user can bookmark the redirect page to log in directly.
  • Easier to implement.
  • A pop-up on a mobile device is displayed in a new tab, so redirect is recommended for those devices to avoid a bad user experience when switching between tabs.

Disadvantage: The user leaves your web site.
Recommendation: Center the pop-up on the screen and anchor the MitID box to the top.

Language

Supported languages are Danish and English. Later versions will also support Greenlandic. Language is set in the configuration as a string (da, en, kl).

Reference texts

The reference text consists of:

  • Reference text header (action text + name of service provider): Adjust the wording in the action heading that fits best, e.g. Log på, Godkend på, Bekræft på, Accepter på, Underskriv på, before the name of your business. Max 60 characters.
  • Reference text body: Max 130 characters.

Integrating with MitID through Signicat

Integration with MitID will be done via the same API as Signicat’s other ID methods. See Get started with authentication for more information. Through the single point of integration, you can additionally get access to Signicat’s wide portfolio of integrated ID methods, and also other services like signing, identity paper verification and lookups.

Supported protocols

Signicat supports both the OIDC and SAML 2.0 protocols. For more details, see the respective documentation pages:

Frequently asked questions

Q: Why is Denmark changing the digital ID infrastructure?

A: NemID was launched in 2010 and is based on a 10 years old infrastructure and 10 years old contracts between the Digitisation agency (digst.dk), the Danish Banks and Nets. There is a need for a more secure and user-friendly solution. For more information, see digst.dk.

Q: What are the advantages of the MitID architecture compared to NemID?

A: For the service provider there are lots of advantages: Better support for standard security protocols, risk data support, three levels of assurance compliant with eIDAS, built-in step-up authentication to mention a few.

Q: How do we get started with migrating from NemID to MitID?

A: All service providers must use MitID through a MitID broker. You must find a MitID Broker and make a contract with them to offer MitID login or signing. For more information, see Migration from NemID to MitID.

Q: Must we show both NemID and MitID login to end-users during the transition period?

A: Signicat recommends that you support both NemID and MitID in the transition period. For more information, see Migration from NemID to MitID.

Q: Who can issue a MitID identity?

A: The government (Kommuer) and banks.

Q: How will MitID look like?

A: Seen from the end-user, there is no big difference in a typical login flow. Most of the new things are “behind the scene”. For more information, see Authentication with MitID compared to NemID.

Does the end-user just need a username and password and is it safe?

A: Yes, MitID supports single-factor authentication like username and password. This is obviously not as secure as two- or three-factor authentication, but in many cases enough and easier to use.

Q: What types of authenticators (app, chip, display device etc.) should we require from end-users to get the appropriate level of assurance (low, substantial, high)?

A: As a service provider, you must make a “risk assessment” for information/data assets the user can access and assign the appropriate level of assurance. Different combinations of authenticators satisfy different LoAs. For example, just “Password” will only satisfy LoA “Low”, while “Password + Chip” will satisfy LoA “High”. For more information, see Possible authentication combinations.

Q: Which environments will be available and when?

A: Signicat will release the core part 30. June in beta (this assumes no delays from the supplier). MitID will go in production in May 2021. For more information, see Timeplan.

Q: Will it be possible to create test identities for non-production testing?

A: Yes, Signicat can do that for you as our customer.

Q: Which protocols will be supported for MitID?

A: SAML2 and OIDC.

Q: How is it planned to implement functionality to increase Level of Assurance during the user session?

A: There is a built-in function in the MitID protocol that supports step-up from one assurance level to another. The user must only activate the authenticator required to go to next level of assurance and not do a completely new login.
The step-up may require the service provider to store certain attributes from the original authentication and pass them on as request parameters. The exact protocol here has yet to be fully determined.

Q: Can MitID be used for payments?

A: It depends on the application using it. MitID is not a payment method, but an electronic identification method (eID).

Other sources