link
Developer Pages

# Migration from NemID to MitID

Page contents

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.

The main aim of this page is to give you as a service provider help with migrating from NemID to MitID.

# Onboarding process for MitID

The MitID onboarding process for you as a service provider, consists of the following main steps:

click-to-zoom

  1. Contract phase:
    • 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 (opens new window).
    • You sign a MitID agreement with Signicat AS as a broker.
    • After you have signed, Signicat sets up a migration plan with you. This includes the estimated start of migration and planned end date, input on MitID UI considerations (including support for both NemID and MitID in the transition phase), choice of protocol, list of current NemID services and subdomains for NemID.
    • Signicat registers you as a service provider in the MitID Broker portal. You do not need any specific certificate for this.
  2. Development phase:
    • Signicat sets up MitID in a pre-production environment and notifies you with access to this environment. For information about test access and test users, see Test information.
    • You can now implement the technical integration with Signicat. Please, be aware of the following differences when migrating from NemID to MitID:

Important differences between NemID and MitID:

  • MitID cannot normally be run in an iframe. If you use Signicat and NemID in an iframe, you must change the integration.
  • MitID uses another graphical profile setup than NemID. For more information, see Frontend-setup > Graphical profiles.
  • Some security requirements from MitID might require other integration changes, e.g. supported protocols and use of subdomains.
  1. Deployment phase:
  • Signicat creates production credentials for you.
  • Before the deployment, you perform acceptance tests to ensure that everything works as planned in production before officially going live. If needed, we can adjust the setup in cooperation with you.
  • After you have accepted, the MitID service is deployed in Signicat’s and your production infrastructures.

You can run both NemID and MitID in parallel until October 2023.

For tips on how to set up a Logon flow in the transition period, see Logon examples in the transition period.

For more general onboarding information, see Onboarding to Signicat.

# The transition period

MitID went live in May 2021 and NemID is scheduled to be phased out at the end of October 2023.

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

Migration of end-users

It is the Danish banks and MitID.dk (opens new window) 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 logon options for your users on your logon page. See the following section about logon examples.

# Logon examples in the transition period

Here are some suggested ways you can set up Logon for the end-user in the transition period:

In the first example, the end-user is sent to Signicat's ID-portal and Signicat takes care of the rest. The two other examples require more development on the service provider's side.

# Logon via Signicat's ID portal

In this example, the end-user logs in via Signicat's ID portal. The ID portal is Signicat’s own authentication portal interface presenting a list of ID methods the end-user can choose between.

  • The end-user selects the Log on button on the service provider page.:

click-to-zoom

  • The end-user is redirected to Signicat's ID-portal and selects between the eID methods active for the service provider, like MitID and NemID.

click-to-zoom

You can determine in the response which ID method is selected from the ID portal:

  • With OIDC, the method used can be determined by checking the acr claim.
  • With SAML2, the method used can be determined by checking the AuthnContextDeclRef tag.

Graphical profile

The ID portal uses the standard graphical profile, as you use today for NemID. This is not tied to the graphical profile implemented specifically for MitID.

# Logon methods on your home page

In this example, the end-user can choose between either MitID or NemID directly on your home page. The following is just a sketch example of how it may look. You must implement this logon option yourself. You can design it as you wish as long as you follow the UX requirements for the MitID logon button.

  1. The end-user selects the Log on button on the service provider page.
  2. A menu is displayed on the service provider page where the end-user can select either Log on with MitID or Log on with NemID.

click-to-zoom

# Logon with one default ID method

In this example, the end-user does not need to choose between NemID or MitID.

At the beginning of the transition period, you can use the same logon set-up as you do today for NemID. NemID should be the default until autumn 2021, where we expect the number of MitID users to reach a critical mass. Thereafter, you should set up an authentication flow with MitID, including the option to switch to NemID. Signicat’s MitID Advanced Graphical profile add-on has built-in functionality for switching to the other method (see Switching beteween NemID and MitID).

The following is just a sketch example of how it may look with the MitID logon. You must implement this logon option yourself. You can design it as you wish as long as you follow the UX requirements for the MitID logon button.

  • The end-user logs in on the service provider page and is redirected to the MitID logon box.

click-to-zoom

  • If you have the add-on for using the advanced graphical profile for MitID, you can also add a link to the other ID-method on the logon page itself, e.g.

click-to-zoom

The grey label to the bottom right shows an example of how you can link to the other method:

click-to-zoom

For more details, see Advanced graphical profile > Label.

# 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.

click-to-zoom

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 page.

# The broker role

One major change from NemID is that all services using MitID for identity proofing (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 organisations certified according to Digitaliseringsstyrelsen's (opens new window) requirements, can act as an intermediate between the MitID core system and the service provider.

Signicat has been reviewed by an external auditor and is certified as a MitID broker.

Important note for service providers

As a broker, Signicat has some contractual requirements that you as a service provider must follow when using Signicat's MitID implementation. For more information, see Requirements for MitID service providers.

# Can I still use an iframe?

NemID supports being shown in an iframe. However, MitID does generally not support iframes, except under certain conditions. To ensure that your users get the smoothest possible transition, Signicat recommends that you redirect the user to a separate NemID screen if you are not doing so already.

If you cannot use a redirect, MitID supports being displayed in a popup window. However, this solution has additional challenges. For more details, see the Popup or redirect section.

# 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.

If you are using Signicat's SAML 1.1 client library and are migrating from scratch, we recommend migrating to OIDC (see How to migrate from SAML 1.1 to OpenID Connect).

Signicat also supports SAML 2.0, but that protocol is much more complex to implement on the service provider’s end and usually requires a federation agent already in place.

See also Supported protocols for MitID.

# How to migrate from SAML 1.1 to OpenID Connect

If you are using Signicat's SAML 1.1 client library and are migrating from scratch, we recommend migrating to OIDC.

# Setting up an OIDC client

To set up a new OIDC client for authentication:

  1. Log into the Signicat Customer Portal (opens new window).
  2. In the left menu, open OIDC clients. This requires that you have either the Configuration Manager or Administrator privilege within the portal. If you need any help with this, please contact Signicat (opens new window).

click-to-zoom

  1. Select the Add new OIDC client button. This displays a form with some fields for you to fill in:

click-to-zoom

  • Environment: Test
  • Client name: Begin with preprod and enter the company name or app name. This is not strictly enforced, but the client name must be globally unique.
  • Redirect URI: If you do not know the URI at this point, you can use Signicat's demonstration endpoint, which is https://labs.signicat.com/redirect. You can add more URIs at a later point.
  • National identity number and Profile: Check these scopes.
  1. Select Save client. A ticket goes to Service Desk, who will qualify and create the client.

When the client is created, you are ready to start integrating. For more details, see Using the OpenID Connect protocol.

# Invoking the method

This section only applies for NemID, since MitID is not yet available for service providers.

  1. Start a transition by invoking the authorisation endpoint as follows:
https://preprod.signicat.com/oidc/authorize?response_type=code&client_id=demo-preprod&redirect_uri=https%3A%2F%2Flabs.signicat.com%2Fredirect&scope=profile+signicat.national_id+signicat.certificate+openid&signicat_profile=demo&ui_locales=en&state=WHATEVER_STATE_YOU_WANT_HERE&nonce=971C185A63ED64A9B58BCEE466C0A9D13270840BFA49CFAE9181305D9D94EB11&acr_values=urn%3Asignicat%3Aoidc%3Amethod%3Anemid](https://preprod.signicat.com/oidc/authorize?response_type=code&scope=profile+signicat.national_id+openid&client_id=demo-preprod&redirect_uri=https%3A%2F%2Flabs.signicat.com%2Fredirect&acr_values=urn%3Asignicat%3Aoidc%3Amethod%3Anemid&signicat_profile=demo&state=WHATEVER_STATE_YOU_WANT_HERE&ui_locales=en&nonce=971C185A63ED64A9B58BCEE466C0A9D13270840BFA49CFAE9181305D9D94EB11)

The parameters are as follows (for more detailed descriptions, see Using the OpenID Connect protocol or the OpenID Connect Core specification (opens new window)):

  • response_type, state and nonce are standard OIDC parameters.

  • client_id and redirect_uri are what you provided when creating the client in the Customer Portal (see Setting up an OIDC client).

  • scope should be a list of requested scopes: oidc, profile, signicat.certificate and signicat.national_id is the most useful combination for NemID.

  • signicat_profile is the name of the graphical profile you want to present to the user. It can be omitted, in which case the default profile is used.

  • ui_locales specifies which language is to be used. For NemID, valid values are da, en and kl, provided that your service is set up with Danish, English and Greenlandic, respectively.

  • acr_values is how you specify the ID method. it is a URN value starting with urn:signicat:oidc:method: and ending in the method name from SAML 1.1, for example urn:signicat:oidc:method:nemid.

  1. Redirect the user to this URL. They will be redirected back to the specified redirect_uri in the following manner:
https://labs.signicat.com/redirect/?code=nHTStZuTeLkvccY2OuVV07TsPPBqQnSJ&state=WHATEVER_STATE_YOU_WANT_HERE&session_state=4463e8631a0efd2a4a0c252c1ab70c6ac36f75da8094869c761f988fc0cee210.3alLCopQpHFWY9_R

  1. Proceed as the OIDC documentation specifies. The Full-flow example lays this out quite nicely.

  2. Remember to verify the nonce and signature when you receive the id_token.

# Understanding the response

With a very few exceptions, all parameters from the SAML 1.1 token are mapped to the OIDC response or have equivalent values.

SAML 1.1 attribute OIDC token OIDC claim Example Comment
subject.name] userinfo signicat.national_id 0506524267
subject.format N/A urn:kantega:ksi:3.0:nameid-format:fnr 1) see below the table
authentication.method id_token amr urn:ksi:names:SAML:2.0:ac:OCES
authentication.instant id_token auth_time SAML: Fri Sep 18 14:37:56 CEST 2020OIDC: 1600433942 (2) 2)
unique-id.nemid userinfo signicat.certificate_unique_id 9208-2002-2-975874261923
signicat.unique-id userinfo signicat.certificate_unique_id 9208-2002-2-975874261923
signicat.service-name N/A demo 3)
signicat.method-name id_token acr SAML: nemidOIDC: urn:signicat:oidc:method:nemid 4)
signicat.plain-name userinfo name Tajs Jensen
nemid.firstname userinfo given_name Tajs
nemid.lastname userinfo family_name Jensen
signicat.security-level N/A 3 5)
nemid.subject-serial-number N/A PID:9208-2002-2-975874261923 6)
oces.plain-name userinfo name Tajs Jensen
nemid.pid userinfo signicat.certificate_unique_id 9208-2002-2-975874261923
nemid.cpr userinfo signicat.national_id 0506524267
national-id.dk.cpr userinfo signicat.national_id 0506524267
signicat.national-id userinfo signicat.national_id 0506524267
signicat.onbehalfof.name userinfo signicat.organization.name 7)
signicat.onbehalfof.orgnr userinfo signicat.organization.number 7)
nemid.organization userinfo signicat.organization 8)

  1. subject.format is a native property of the SAML token and would make little sense outside that context.

  2. authentication.instant and auth_time both denote the same time, but authentication.instant is a full-length ISO-8601 timestamp, whereas auth_time is a UNIX timestamp.

  3. service.name is not mapped because OIDC identifies the endpoint with a client_id, not a service name.

  4. signicat.method-name is packaged in a URN format to comply with the OIDC standard.

  5. signicat.security-level is a Signicat internal property and does not necessarily map to eIDAS or even STORK levels of assurance. Since OIDC does not inherently have a concept of security levels, this property has little value and is dropped.

  6. nemid.subject-serial-number is a duplicate of the PID number

  7. The signicat.onbehalfof. properties apply only to NemID for business owners.

  8. signicat.organization applies only to NemID employee certificates.

# CPR matching service (former NemID PID/CPR match service)

With NemID you need a separate agreement for using the PID/CPR match service (PID=unique identifier, CPR=Danish personal ID number). 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.

For more details, see CPR matching (add-on).

# MitID CPR-PID service

To ease the migration phase between MitID and NemID, you can use the optional MitID CPR-PID service. This service allows you to retrieve the uniquie identifier (PID) for NemID as part of the MitID authentication. This is useful if you depend on the PID in NemID as the identifier for your users. If this feature is enabled, the assertion will contain both the NemID PID and the MitID UUID (universal unique identifier) and you should update the identifier accordingly.

If the PID service is unavailable or the PID is unknown in NemID, the NemID PID will not be included in the authentication result.

This service requires that the CPR matching (add-on) is enabled in MitID.

# Response examples

SAML2 attributes:

<saml2:Attribute Name="nemid.pid" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
  <saml2:AttributeValue xsi:type="xs:string">9999-2222-2-111111111111</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="nemid.pid.lookup.status" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
  <saml2:AttributeValue xsi:type="xs:string">success</saml2:AttributeValue>
</saml2:Attribute>

OIDC claims:

{
  "nemid.pid": "9999-2222-2-111111111111",
  "nemid.pid.lookup.status": "success"
}

Notes

  • nemid.pid is only included when the end-user has a PID corresponding to their CPR number.
  • nemid.pid.lookup.status can be one of the following:
    • success: The lookup was successful and the PID was found.
    • no_pid_for_cpr: The lookup was conducted without error, but the user does not have a PID.
    • error: An error occurred during the lookup.

# Subdomains in NemID and MitID

There will be no changes for how subdomains are handled in NemID. You can continue to run NemID as before, including on your own subdomain (see Establishing a Signicat subdomain).

MitID is designed to appear as a separate entity and the entire MitID flow must be hosted within the mitid.dk domain, including the CPR dialogue box. All this is handled by Signicat, so you do not need to take any action. Signicat can also offer you a customised subdomain with your own name, like service-provider.mitid.dk. For more details, see Frontend > Subdomains (add-on).

# From NemID to MitID signing

Signicat supports signing for both NemID and MitID. Like with NemID, you should create MitID signatures using the signed statement technique. This means that the two signing schemes are quite similar when it comes to setup and configuration.

This section focus on the migration from NemID to MitID signing and how to configure this. For more information about the MitID signing solution, see the Signing page.

# Setup for one signing method (either NemID or MitID)

This example uses NemID, but you can replace this with MitID.

For the SOAP interface DocumentService v3, equip the method statement with a signed-statement parameter:




 



<task id="1">
	[...]
	<signature responsive="true">
		<method signed-statement="true">nemid-sign</method>
	</signature>
</task>

Note

If you fail to include the signed-statement="true" parameter, the signing method will be invoked as a third-party signature. This will still work but offers an inferior user experience.

For Sign API it is even simpler:








 





"tasks": [
	{
		"id": "1",
		// insert rest of task definition here
		"signatureMethods": [
			{
				"name": "nemid-sign",
				"type": "SIGNED_STATEMENT"
			}
		]
	}
]

For MitID, the method name for signing will be mitid-sign. You may invoke it as you would for a third-party signing method in the SOAP interface.




 

<task id="1">
	[...]
	<signature>
		<method signed-statement="true">mitid-sign</method> </signature> </task>

Correspondingly, in Sign API you would simply switch out the name parameter.







 


"tasks": [
	{
		"id": "1",
		// insert rest of task definition here
		"signatureMethods": [
			{
				"name": "mitid-sign",
				"type": "SIGNED_STATEMENT" } ] } ]

# Setup for combining NemID and MitID

In the transition period, you will likely want to combine both the legacy NemID signing method and the MitID method in the same flow and let the user choose between them. This is one point where the flexibility of Signicat’s APIs really pays off.

In DocumentService, just specify two signature elements:

<task id="1">
	[...]
	<signature>
		<method signed-statement="true">mitid-sign</method>
	</signature>
	<signature>
		<method signed-statement="true">nemid-sign</method>
	</signature>
</task>

It is also possible to specify two methods in the same signature element:

<signature>
 <method signed-statement="true">mitid-sign</method>
 <method signed-statement="true">nemid-sign</method>
</signature>

Sign API provides this setup:

"tasks": [
  {
    "id": "1",
    // insert rest of task definition here
    "signatureMethods": [
      {
        "name": "mitid-sign",
        "type": "SIGNED_STATEMENT"
	  },
	  {
	    "name": "nemid-sign",
		"type": "SIGNED_STATEMENT"
	  }
	]
  }
]
Last updated: 20/09/2023 12:20 UTC

← Level of assurance and authenticators →