MitID (DK)

​MitID is the next generation eID in Denmark, and it will replace NemID during 2021/2022. 

Enable MitID in your services

MitID will be available in E-Ident as NemID is today, and MitID specific information will be published here as it gets available. The information may be subject to change.

General information about MitID:

Timeline

MitID is currently under development and is planned to go live with pilot users in May 2021. The E-Ident service will use the broker delivered by Signaturgruppen. From the beginning of October, all users will start to receive their MitID identity. During the migration phase from NemID to MitID, it is recommended to support both identification methods.

  • Customer test availability: 11th May
  • ​​Production availability: October (right after pilot production)

​​Information about the end user

The information returned about the end user is listed in the table below. The content may change as the MitID development proceeds.

​Type​OIDC ​SAML​Comments
​Authentication Assurance Level ​aalAAL
 
​One of
  • https://data.gov.dk/concept/core/nsis/Low
  • https://data.gov.dk/concept/core/nsis/Substantial
  • https://data.gov.dk/concept/core/nsis/High
​Authorised to represent

authorized-

_to_represent

Requires scope=organisation

AUTHORIZED-

_TO_REPRESENT

​The organisation number (CVR number) of the organisation the user is authorised to represent. Only available when using the Private MitID - on behalf of companies function.
​Birth date

birthdate

Requires scope=profile

​​DOBThe user's date of birth.​
​​Danish CPR number

​​dk_ssn / ssn

Requires scope=ssn

​​DK_SSN

Requires returnssn=true

​The end user's social security number (CPR number). For the OIDC protocol, this is returned in both the dk_ssn and ssn claim.
​Identity Assurance Level ​ial ​IAL
​One of
  • https://data.gov.dk/concept/core/nsis/Low
  • https://data.gov.dk/concept/core/nsis/Substantial
  • https://data.gov.dk/concept/core/nsis/High
​Level of assuaranceloaLOA
​One of
  • https://data.gov.dk/concept/core/nsis/Low
  • https://data.gov.dk/concept/core/nsis/Substantial
  • https://data.gov.dk/concept/core/nsis/High
​MitID amr valuesmitid_amrMITID_AMR

​Possible values are:

  • mitid.password
  • mitid.code_token
  • mitid.code_reader
  • mitid.code_app
  • mitid.code_app_enchanced
  • mitid.u2f_token
​​MitID UUID

mitid.uuid / pid

​MITID_UUID​​Unique ID for this identity.
​Name

name

Requires scope=profile

FULLNAME​Name of user.
​Organisation name

​organisation-

_name

Requires scope=organisation

ORGANISATION-

_NAME

​Name of the organisation the end user is authorised to represent. Only available when using the Private MitID- on behalf of  companies function.
Organisation number (CVR)

organisation_number

Requires scope=organisation

ORGANISATION-

_NUMBER

​Organisation number of end user. Only available when using the Private MitID- on behalf of companies function.

Retrieve SSN (CPR)

The CPR number (Danish social security number)​ can be retrieved in this way:

  • OIDC: Set the scope parameter to ssn
  • SAML: Append the returnssn=true parameter to the identification request.

When this is set, the user will be prompted for their CPR number and this will be returned in the ID Token (OIDC) and Assertion (SAML). The CPR number will be returned in the dk_ssn and ssn claim in the ID Token and as the DK_SSN attribute in the SAML assertion. ​

CPR setup flow by requesting additional scope 'ssn'

To avoid asking for the CPR number for each identification request, the CPR setup flow can be used if the user is unknown and if there is a need for the CPR number.

The customer can request additional ssn scope if not already requested in current authentication transaction without any additional transaction cost, provided the user has already performed the authentication and the customer has fetched the ID token.

The CPR request flow will directly navigate the user to the CPR input page and the user doesn't need to perform authentication again. To initiate the CPR setup flow, the customer has to do a regular request with additional scope ssn in OIDC protocol or returnssn=true in SAML protocol and the parameter transaction_id.

  • For OIDC protocol, the transaction_id parameter value would be jti claim from ID token.
  • For SAML protocol, the value for transaction_id could be found at '/Response/Assertion/@AssertionID' from assertion response. For eg. value of attribute AssertionID=TI2-617b5cdc6fb84f16a6022e328d970bb7 then transaction_id value would be 617b5cdc6fb84f16a6022e328d970bb7.

It leads to an error response if the CPR flow is requested after the validity of the ID token or SAML assertion. The validity of an ID token and a SAML assertion is 15 minutes.

After the user has inserted the CPR number, you need to request a new ID token or SAML assertion.

Level of assurance and authenticator assurance level

The level of assurance for a specific identification may be set using the loa_value parameter and the authenticator assurance level may be set using the aal_value parameter. Both parameters accept these values:

  • low
  • substantial (default if not set)
  • high 

If the loa_value is set, the aal_value will be ignored. If both the loa_value and the aal_value parameter is undefined in the request, the loa_value parameter will as default be set to substantial.  

The actual used values will be returned as loa and aal claims/attributes in the ID Token/SAML assertion. In addition, ial and mitid_amr claims are returned. See the table above for the possible values.

Note: The customer must validate that the returned values are as expected.

User experience

The user may be presented with a choice to log in using MitID, NemID with code card or NemID with code file as in the first picture below. When the user selects MitID he/she will be redirected to the Nets broker for MitID. For E-Ident customers using the Embedded UI option, the service will break out of iframe when the user is directed to MitID. 

Note: The E-Ident service was recently updated with a third UI option - pop-up UI. As the user is redirected to the Nets broker for MitID during the identification, pop-up UI may be an option to consider when adding MitID as an identification method. Read more about the pop-up UI.

EID selection page (optional)

The below page is optional. Users may be sent directly to MitID by using the amr_values/forcepkivendor parameter on the identification request. The parameter value must be set to mitid. Read more about the parameters for OIDC and SAML. The picture below is an illustration of the page for pop-up and standalone UI modes. 

MitID selection.PNG 

MitID client pages

DK MitID - Step 2a.PNG

 

DK MitID - Step 3a.PNG

 

Enter CPR page

DK MitID - Step 4a.PNG

Customized UI options

The MitID client UI may be customized by using one of four UI templates. The MitID client is in the square while the customer's logo is in the dotted square. UI options_broker.PNGTemplates and customization:

  • Basic: Customers may set the background colour.
  • Split, Fluid Split and Topbar: Customers may set two different background colours, text color and supply a welcome text and an optionally CPR page text.
  • In all templates, the customer logo may be added. The logo file should be 150 x 37 pixels.

Background colours must be given as hex format (example: #ffffff).

Here is an example of a customized page based on the "Split" template:

UI split.PNG

Reference text

The user may be shown a reference text throughout the identification. To add a reference text, append the reference_text parameter to the identification request. The reference text will be displayed to user in both the MitID client and in the MitID app.

The reference text may be up to 130 characters. A short description of the parameter can be found here:

MitID logo and design

MitID design requirements and logos can be downloaded from the Nets eID broker here

Private MitID - on behalf of​ companies​

​A user may choose to use his or hers private MitID when acting on behalf of a company. This feature is also available when using E-Ident. During the logon flow, the user will select the company he or she will represent and this information is sent to the customer.

User flow​​​​ and implementation

  1. The customer sends an identification request to E-Ident.
    1. If OIDC, the organisation scope must be appended to the request
    2. If SAML, the returnorg=true parameter must be appended to the request.
  2. The user logs in with his/her MitID. 
  3. After the MitID login, the user will be prompted for his/her CPR number. This is used to retrieve information about companies the user are authorised to represent on his/her own
    1. In the background, a lookup to Virk.dk is performed using the CPR number. 
  4. ​The user is presented with a list of companies he/she is authorised to represent. 
  5. He/she selects the company he/she will represent in this session. 
  6. Information about the selected company is returned in the IDToken (OIDC) or Assertion (SAML) as the following values:
    1. IDToken  values:
      1. authorized_to_represent: CVR number
      2. organisation_name: Name of organisation
      3. organisation_number: CVR number
    2. Assertion attributes:
      1. AUTHORIZED_TO_REPRESENT: CVR number
      2. ORGANISATION_NAME: Name of organistation
      3. ORGANISATION_NUMBER: CVR number​
         

​User interface

After the regular MitID login the user will be presented with a list of companies the user is authorised to represent, and the user selects the one to use in this session:

Private MitID on behalf of companies.PNG   

We have registered these general test users that can be used for testing:  

  • ​User name: Mitid2, pwd: asasas12, cpr: 1403532411

For other users, please contact support.