For the complete documentation index, see llms.txt. You can also append .md to any page URL to get its markdown version.
Skip to main content
For the complete documentation index, see llms.txt.

For the complete documentation index, see llms.txt

Changes for MitID

This page describes the changes specific to MitID that are required when migrating an existing OIDC integration from Signicat Enterprise to the new Signicat Digital Trust Platform (DTP).

Overview​

  • MitID authentication works the same after migration.
  • The end-user authentication flow does not require any changes specific to MitID.
  • The main migration changes affect:
    • OIDC configuration, including your endpoints and client credentials.
    • Returned OIDC claims.
    • Requested scopes.
    • ACR values (if used).

Claims​

For an overview of the key claim changes, see the table below:

Note

The standard claims name, given_name, family_name, birthdate and gender remain unchanged.

For a complete list of MitID claims, see the Attributes reference page.

Scopes​

When migrating MitID, we recommend using the same set of scopes as in your current integration, while applying the mapping of the scope codes. For example, if you currently use openid, profile and signicat.national_id, we recommend that you replace signicat.national_id with nin thus resulting in openid, profile and nin. This ensures that you receive the equivalent user information.

Example: Scopes
openid profile nin
Our recommendation

We recommend that you only use additional MitID scopes if your application already depends on them, such as mitid-extra.

The exact claims returned depend on the requested scopes, the OIDC client configuration, CPR matching, and any optional MitID functionality used by the integration. Some MitID claims are conditional and are therefore not returned in every authentication response.

What does this mean?

For example, when name and address protection applies, mitid_name_and_address_protection may be returned and the standard name claims may be omitted.

You can find an example of how an OIDC authentication response and used scopes differ between Enterprise and our new platform below:

Example: Enterprise OIDC scopes
openid+mitid+profile+signicat.national_id+signicat.organization
Example: Enterprise response
{
  "sub": "<enterprise_subject_id>",
  "birthdate": "1902-12-18",
  "name": "Petter Johnson",
  "signicat.national_id": "<cpr_number>",
  "given_name": "Petter",
  "family_name": "Johnson",
  "mitid.has_cpr": "true",
  "mitid.transaction_id": "41497a86-390d-4110-b4bd-ffca35aace8a",
  "mitid.reference_text_body": " ",
  "mitid.cpr.source": "user",
  "mitid.ial": "HIGH",
  "mitid.loa": "HIGH",
  "mitid.aal": "HIGH",
  "mitid.fal": "HIGH",
  "mitid.uuid": "b3c6cddf-0b8e-4760-a38b-45afccfca30a"
}

Required application changes​

Update your application to read the CPR number from the new platform claim nin, instead of the Enterprise signicat.national_id or mitid.cpr claim:

Enterprise claim
signicat.national_id
Enterprise claim
mitid.cpr

Update your application to read claims specific to MitID using underscores (_) for our new platform, instead of full stops (.) for Enterprise:

Example: Enterprise claim with fullstop
mitid.transaction_id

To verify that CPR matching works as expected, make sure that nin is one of the requested scopes in the authorisation request:

  • A CPR number entered by the end-user.
  • A previously cached CPR number.

If your application uses the OIDC sub claim as an internal user identifier, then you must verify your identifier mapping before migration.

Note

The sub claim is still returned by our new platform, but the value may differ from the Enterprise value.

If you need to retrieve the identical subID value, then you can follow the Migrating from Enterprise documentation.

ACR values​

The acr_values parameter is optional. You should only use it if your application pre-selects MitID.

Pre-select MitID​

To pre-select MitID in our new platform, set idp:mitid in the acr_values.

Starting MitID authentication
acr_values=idp:mitid
Note

When MitID is the only method specified, the user is routed directly to MitID without seeing the identity method selection screen.

Additional MitID request parameters​

For additional MitID request parameters, see the MitID OIDC integration guide. This includes:

  • Native app switching.
  • Transaction reference text.
  • Other MitID-specific request options.

Test before cutover​

Migrating MitID authentication to our new platform has a low overall impact. End-users authenticate in the same way, and the returned OIDC response is largely unchanged.

Before production cutover, verify that your application can:

  • Complete a MitID OIDC authentication flow in our new platform.
  • Read the CPR number from nin instead of signicat.national_id or mitid.cpr.
  • Read MitID-specific claims using underscore-based names (for example, mitid_transaction_id).
  • Handle conditional claims, including users with name and address protection.
  • Handle any changes to the sub value if it is used as an internal identifier.
  • Pre-select MitID using acr_values=idp:mitid, if your application uses method pre-selection.
  • Verify any additional MitID functionality used by your integration.
On this page