MitID

About Danish MitID

MitID is a new electronic ID in Denmark, replacing NemID. It is a collaboration between the Danish banks and the Danish public sector. This alliance forms a nationwide solution and provides a secure authentication 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. Since it is a demo, any username and password will work:

Signicat MitID demo

For more frontend information, see Frontend policies and guidelines.

Time plan

MitID will be available in mid-2021. There will be a transition period where you can use both NemID and MitID, although NemID will be phased out at the beginning of 2022.

Signicat will provide a MitID version in the pre-production environment from 1. February 2021. This allows you to start preparing and implementing your solution some months before the go-live date on 6. May 2021. If you would like to start the implementation before 1. February, please contact Signicat.

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 only use MitID through certified brokers.
  • Secure login supporting all three Level of Assurance (LoA) from eIDAS, Low, Substantial and High:
    • Low authenticates the user with only a password authenticator. This is not available in NemID.
    • Substantial authenticates the user with a two-factor authenticator combination, e.g. password + code display.
    • High authenticates the user with a more advanced two-factor authenticator combination, e.g. app + chip.
  • Integrate with Signicat Sign to create Advanced Electronic Signatures (AES).

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:
  • MitID cannot be run in iframe. If you use Signicat and NemID in iframe, you must change the integration (see Frontend guidelines and policies).
  • Some security requirements from MitID might require other integration changes, e.g. supported protocols and use of subdomains.

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 base certification and is preparing for the final MitID broker certification.

Supported protocols in NemID compared to MitID.

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

Note: Since SAML 1.1 will be deprecated soon, you must use either OIDC or SAML 2.0 for MitID.

For more details, see Supported protocols for MitID.

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. 

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. 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 Attributes section.

Low

With LoA Low, you can allow your users a simple password-based login.

Substantial

Substantial achieves the equivalent LoA of NemID authentications.

High

With LoA High, you can achieve the highest level of confidence using a two-factor authentication of your users.

Step-up

With Step-Up authentication, you can achieve a higher LoA for a user in a fast and simple way. For example: If a user is logged into your service with LoA Low, but tries to access a restricted area which requires LoA Substantial or LoA High, they do not have to re-enter their username, password, or any authenticators from their previous authentication. Instead, they only need to use the additional authenticator(s) that are needed to achieve the required LoA.

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. With this app, 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). 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 authenticators. Single-factor authentication can be to combine a username with one of the mentioned authenticators, for example a password.
If higher security is needed, you can use a more secure authenticator, such ass App, or use two-factor authentication, e.g. combining a password with Code display.

The following table (from the MitID broker package documentation) shows possible combinations of authenticators 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 MitID authenticators. MitID decides the possible combinations.

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.

 

 

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

To obtain 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:

 

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

To obtain High LoA, the end-user can add the Chip authenticator to the username and password combination:

 

Signing

With Signicat’s own authentication-based signing solution, you can electronically sign documents using a MitID authentication. This ensures a unified output format in accordance with EU specifications. The signing results in a PAdES (PDF Advanced Electronic Signature) consisting of one or more signed documents (XAdES, implemented as LTV-SDO).

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)
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 (for an example, see the image below).

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.

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 for MitID

Signicat supports both the OIDC and SAML 2.0 protocols for MitID. For more information about how to integrate with Signicat using these protocols, see the respective documentation pages:

OIDC response for MitID

This an example of returned user information for MitID:

{
  "sub": "79379634-251c-4f3e-a47d-526235822b91",
  "mitid.uuid": "79379634-251c-4f3e-a47d-526235822b91",
  "name": "Stig Hansen",
  "given_name": "Stig",
  "family_name": "Hansen",
  "birthdate": "1929-11-09",
  "mitid.age": 90,
  "mitid.address": "Strandvejen 64 3 TH",
  "mitid.identityname": "Stig7111",
  "signicat.national_id": "0911291673",
  "signicat.nationality":"DK"
  "mitid.cpr": "0911291673",
  "mitid.fal": "HIGH",
  "mitid.ial": "SUBSTANTIAL",
  "mitid.aal": "LOW",
  "mitid.loa": "LOW"
}

 

SAML 2.0 response for MitID

This an example of returned user information for MitID:

<saml2:Assertion ID="IDkqi3itbx256cl3qvjmzyaebk3c1dndorw278q53g6ejacd94m" IssueInstant="2020-10-13T10:15:58.815Z" Version="2.0">
<saml2:Issuer>
https://test.signicat.com/std
</saml2:Issuer>
<saml2:Subject>
<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" NameQualifier="MitID">
79379634-251c-4f3e-a47d-526235822b91
</saml2:NameID>
</saml2:Subject>
<saml2:AuthnStatement AuthnInstant="2020-10-13T10:15:56.204Z" SessionIndex="umhnvu56o8l3owdy6wl65b6jbmqk171wopfk3ts9pzi6chkt0">
</saml2:AuthnStatement>
<saml2:AttributeStatement>
<saml2:Attribute Name="national-identity" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml2:AttributeValue xsi:type="xs:string">0911291673</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="national-identity-country" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml2:AttributeValue xsi:type="xs:string">DK</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="common-name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml2:AttributeValue xsi:type="xs:string">Stig Hansen</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="given-name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml2:AttributeValue xsi:type="xs:string">Stig</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="surname" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml2:AttributeValue xsi:type="xs:string">Hansen</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="date-of-birth" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml2:AttributeValue xsi:type="xs:string">1929-11-09</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="mitid.age" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml2:AttributeValue xsi:type="xs:string">90</saml2:AttributeValue>
</saml:Attribute>
<saml2:Attribute Name="mitid.address" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml2:AttributeValue xsi:type="xs:string">Strandvejen 64 3 TH</saml2:AttributeValue>
</saml:Attribute
<saml2:Attribute Name="mitid.identityname" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml2:AttributeValue xsi:type="xs:string">Stig7111</saml2:AttributeValue>
</saml:Attribute>
<saml2:Attribute Name="mitid.fal" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml2:AttributeValue xsi:type="xs:string">HIGH</saml2:AttributeValue>
</saml:Attribute>
<saml2:Attribute Name="mitid.ial" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml2:AttributeValue xsi:type="xs:string">SUBSTANTIAL</saml2:AttributeValue>
</saml:Attribute>
<saml2:Attribute Name="mitid.aal" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml2:AttributeValue xsi:type="xs:string">LOW</saml2:AttributeValue>
</saml:Attribute>
<saml2:Attribute Name="mitid.loa" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml2:AttributeValue xsi:type="xs:string">LOW</saml2:AttributeValue>
</saml:Attribute>
</saml2:AttributeStatement>
</saml2:Assertion>

Attributes

You use MitID to verify the end-user’s identity and obtain relevant personal details about them. These attributes can be obtained during authentication:

SAML 2.0 OIDC Description
NameID sub, mitid.uuid The universally unique identifier for the eID of the end-user.
national-identity signicat.national_id,

mitid.cpr

The CPR number of the end-user.
national-identity-country signicat.nationality The nationality of the national ID (always “DK”).
given-name given_name The first name of the end-user.
surname family_name The surname of the end-user.
common-name name The combined first name and surname of the end-user.
date-of-birth birthdate The end-user’s date of birth.
mitid.age mitid.age The end-user’s age.
mitid.address mitid.address  The end-user’s address.
mitid.identityname mitid.identityname The identity name of the end-user’s eID, i.e. their username for authenticating with MitID.
mitid.fal mitid.fal Federated Assurance Level. This will always have the value “HIGH”.
mitid.ial mitid.ial Identity Assurance Level. This value is associated with the end-user’s eID, assigned as part of the MitID registration process and later only changeable through additional registration processes.
mitid.aal mitid.aal Authentication Assurance Level. This is calculated based on the authenticators that have been used and their strengths.
mitid.loa mitid.loa The Level of Authentication for the authentication. This is calculated as the minimum of IAL, AAL and FAL.

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 (Kommuner) 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-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: 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: SAML 2.0 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: Does MitID support iframes?

A: No, MitID does not support iframes. Instead, you can choose between implementing the login box using either redirect or popup. For more information, see the Popup or redirect section.

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