# eID -Denmark ## Overview MitID is a secure electronic identification (eID) system developed to provide Danish citizens, businesses, and public institutions with a standardized digital identity. It allows users to log in and authenticate seamlessly across various platforms, including online banking, government portals, and e-commerce, offering a streamlined single-login experience. MitID's key feature is **User Identification**, supported by OpenID Connect, enabling smooth integration with Danish digital services. ### MitID Onboarding Process Test Environment: 1.       The customer provides the necessary data to initiate MitID testing. 2.       ZignSec supplies a subscription key along with test link details in a secure format. 3.       The customer integrates and implements the MitID product. Production Environment: 1.       Zignsec conducts an acceptance test to ensure the MitID product is correctly implemented. 2.       Upon approval, ZignSec provides the production credentials in a secure format. ## Identification ### Authentication with MitID MitID offers authentication at both the highest and substantial levels of assurance, making it a trusted choice for accessing public services, financial institutions, and various business applications. With millions of users, MitID ensures a secure and reliable authentication process, fully compliant with Danish and EU regulations. ### Using MitID APIs for Authentication By integrating MitID API, you can authenticate users and receive their identity details. These details can be used to match and verify the user against an existing customer profile, ensuring secure access. #### Levels of Assurance Supported by the eID Scheme: MitID offers three assurance levels—Low, Substantial, and High—each defining how securely your identity is verified for different digital services. - **Low**: Basic services require only your MitID user ID and one additional confirmation, like a password. - **Substantial**: Most public services and online banking demand two forms of verification, such as the MitID app and PIN. - **High**: Available in select municipalities, this level requires two highly secure authenticators, offering the highest identity certainty for sensitive services. Most MitID users will require the assurance level “substantial”. This level is needed if you are using public self-service solutions, like skat.dk or sundhed.dk or if you are doing online banking or insurance. ([MitID online doc](https://www.mitid.dk/en-gb/help/help-universe/mitid-user/what-are-assurance-levels-and-how-to-raise-them/#:~:text=Your%20assurance%20level%20and%20your,doing%20online%20banking%20or%20insurance.)) #### End User Data returned The following data fields are returned directly from the eID scheme: - CPR -number (if legally permitted) - Indicator if user has CPR-number - Full Name - Date of Birth (DoB) - Age - UUID (Universally Unique Identifier) Note: Public entities, such as municipalities, are legally permitted to receive CPR numbers directly in the authentication response. Private entities, however, can only verify which CPR number was used during authentication. ## User Experience Guidelines for MitID Integration ### MitID Authentication Process Flow 1. Initiate the Authentication Session: - Send a POST request to create a new MitID authentication session. - Include the required parameters in the request body, such as: - Action type - Language preference - Authentication level - Any additional attributes (e.g., date of birth or identity assurance level). - Provide callback URLs for redirection upon success or failure, a unique relay state identifier, and a webhook URL for asynchronous updates. 2. Redirect the User for Authentication: - Upon a successful request, the response will include a redirect_url. - Redirect the user’s browser to this URL to begin the MitID authentication process. 3. User Completes Authentication: - The user enters their MitID credentials. - In cases of additional verification, the user may be prompted to switch to the MitID app. 4. Handle Authentication Outcome: - After authentication, the user is redirected to the specified success or failure URL. - Use the relay state parameter to map the response to the original authentication request. 5. Retrieve Authentication Results: - Use the session identifier returned during the initiation phase to retrieve detailed authentication results. - Alternatively, process the data received via the configured webhook for the same. 6. Verify User’s CPR Number (Optional): - To verify the user’s CPR number, make a request to the CPR matching endpoint. - This step enables matching of the CPR number to ensure secure and accurate user verification. This structured flow ensures a seamless and secure authentication experience, with optional CPR verification for enhanced identity assurance. ## MitID App-Switch User Experience Guide This document outlines the steps for integrating the MitID app-switch authentication flow, separated into **iOS** and **Android** sections for clarity. --- ### User Experience Flow 1. **Initiate Authentication**: The end-user opens the Service Provider (SP) app and presses the **"Authenticate with MitID"** button. 2. **Open Browser View**: A native browser view (Custom Tab on Android or SFSafariViewController on iOS) is launched above the SP app. 3. **Load Broker’s Landing Page**: The browser displays the Broker's landing page and initiates the authentication process. 4. **Navigate to MitID App**: If the MitID app is installed, the user is prompted to navigate to it via a button. 5. **Approve or Reject Transaction**: The user approves or rejects the authentication in the MitID app. 6. **Return to SP App**: The user is redirected back to the SP app, with the native browser closing or remaining open depending on the flow. 7. **Complete Authentication**: The Broker finalizes the process, and the user is logged in. --- #### Using the `mobileInfo` Parameter for App-Switching To facilitate seamless app-switching during authentication, the `mobileInfo` parameter should be included in authentication requests. This parameter allows users to switch from the service provider's app to the MitID app for authentication and then return to the original app upon completion. #### Request Format The `mobileInfo` parameter is included in the **request body** within the `"metadata"` object. ##### Full Request Example ``` bash curl -X 'POST' \ 'https://test-gateway.zignsec.com/api/v5/sessions/mitid/auth' \ -H 'accept: application/json' \ -H 'Authorization: Your API key' \ -H 'Content-Type: application/json' \ -d '{ "locale": "en", "redirect_success": "https://my_success_url.com", "redirect_failure": "https://my_failure_url.com", "relay_state": "my-unique-customer-id", "gdpr_user_id": "my-unique-gdpr-customer-id", "webhook": "https://my_webhook_url.com", "metadata": { "popupContext": false, "method": "Loa", "mobile_info": { "device": "Ios", "return_app_url": "https://translate.google.com/?sl=da&tl=uk&text=It%27s%20done!&op=translate" }, "level": "Low", "action": "LogOn", "referenceTextBody": "Log on to My Service", "serviceProviderReference": " My Service ", "requestedAttributes": [ "DATE_OF_BIRTH", "AGE", "IAL_IDENTITY_ASSURANCE_LEVEL", "IDENTITY_NAME" ], "psd2": true } }' ``` --- #### Usage Guidelines for `mobileInfo` - **iOS Devices:** ``` json { "mobileInfo": { "device": "Ios", "returnAppUrl": "https://universal-link-to-your-app" } } ``` Ensure `returnAppUrl` is a valid universal link. - **Android Devices:** ``` json { "mobileInfo": { "device": "Android", "returnAppUrl": "https://your-app-deep-link" } } ``` Ensure `returnAppUrl` is a valid deep link. - **Web/Desktop:** - If accessed via a browser or desktop environment, the `mobileInfo` parameter should be omitted or set to `null`. #### Authentication Flow with `mobileInfo` 1. The user initiates authentication from the service provider's app. 2. The app-switch is triggered, opening the MitID app for authentication. 3. After authentication is completed (approved or rejected), the user is redirected back to the service provider’s app using the `returnAppUrl` defined in `mobileInfo`. By correctly implementing this parameter, the authentication flow remains seamless, providing a better user experience. --- ### Android Implementation **1. Detect MitID App Presence** To verify the MitID app is installed, use the following method: **Check for MitID App** **public boolean deviceHasMitIDApp() {** ``` java public boolean deviceHasMitIDApp() { try { getPackageManager().getPackageInfo("dk.mitid.app.android", 0); return true; } catch (PackageManager.NameNotFoundException e) { return false; } } ``` **Additional Steps for Android 11+** To enable package visibility, add the MitID app package name to your AndroidManifest.xml as follows: ``` xml <manifest …> <queries> <package android:name="dk.mitid.app.android" /> </queries> <application …. /> </manifest> ``` --- **2. Open Browser View** Use Android Custom Tabs to open the Broker's landing page: ``` java CustomTabsIntent.Builder builder = new CustomTabsIntent.Builder(); CustomTabsIntent customTabsIntent = builder.build(); customTabsIntent.launchUrl(MainActivity.this, Uri.parse(“BROKER_URL”)); ``` --- **3. Configure Return Link** **App Links Configuration** To enable redirection back to the SP app: 1. Add an intent filter in your AndroidManifest.xml: ``` xml <intent-filter android:autoVerify="true"> <action android:name="android.intent.action.VIEW" /> <category android:name="android.intent.category.DEFAULT" /> <category android:name="android.intent.category.BROWSABLE" /> <data android:scheme="https" android:host="link.to.your.domain.with.an.app.links.file" /> </intent-filter> ``` 2. Host an assetlinks.json file on your domain matching the host in the intent filter. --- ### iOS Implementation **1. Detect MitID App Presence** To verify the MitID app is installed, check for its URL scheme (mitid-app): **Check for MitID App** On iOS, to verify if the MitID app is installed on the device, the service provider app can query for the URLScheme of the MitID app ("mitid-app"). The SP app must express its intent to query for this scheme by adding the URLScheme "mitid-app" to its Info.plist file under the key LSApplicationQueriesSchemes. See: [IOSCANOPEN]. The SP app can then verify the presence of the MitID app on the device as detailed below: ``` func canOpenMitIDApp() -> Bool { guard let url = URL(string: "mitid-app://") else { return false } return UIApplication.shared.canOpenURL(url) } ``` --- **2. Open Browser View** Use SFSafariViewController to open the Broker's landing page: ``` guard let url = URL(string: "https://broker.app.site/page.html") else { return } let safariVC = SFSafariViewController(url: url) self.navigationController?.pushViewController(safariVC, animated: true) ``` **Note**: Do not use WKWebView or UIWebView as they are unsupported. --- **3. Configure Return Link** **Universal Link Configuration** To enable redirection back to the SP app: 1. Host an apple-app-site-association file on the Broker/SP domain. ``` <intent-filter android:autoVerify="true"> <action android:name="android.intent.action.VIEW" /> <category android:name="android.intent.category.DEFAULT" /> <category android:name="android.intent.category.BROWSABLE" /> <data android:scheme="https" android:host="link.to.your.domain.with.an.app.links.file" /> </intent-filter> ``` 2. Register the associated domain in the app's capabilities settings. Universal Links allow the MitID app to redirect users back to the SP app seamlessly. --- By implementing these configurations for **Android** and **iOS**, the MitID app-switch flow can be integrated effectively, ensuring a smooth user experience. ### URL and Page Title Guidelines for MitID Integration MitID cannot be embedded directly on websites. It must appear as either a **pop-up** or a **redirect**. #### URL Requirements - **Domain Association**: MitID authentication must always connect to a URL under the MitID.dk domain. - **Broker's Role**: The Broker must display a subdomain associated with either the Broker or the Service Provider. - **Service Provider Emphasis**: It is strongly recommended to use the **Service Provider's name** for the subdomain. This approach fosters user trust, as end-users are more likely to recognize and associate with the Service Provider than the Broker. #### Best Practices for URL Structure - **Security and Clarity**: The URL should create a sense of security by clearly reflecting the Service Provider's identity. Avoid using the Broker's name, as most end-users are unfamiliar with their role. - **Name Consistency**: The URL name should match the name displayed in the MitID box for continuity. - **Shortened Names**: If the Service Provider's name is too long, use a shortened version in the URL, ensuring the MitID.dk domain remains visible for user confidence. #### Page Title Recommendation The page title for MitID integration should simply be **"MitID"** to align with the platform's branding and ensure clarity for users. ![[MitID-URL-page.jpg|300]] ### Update Reference Texts and Logo The MitID Partnership is committed to reducing fraud associated with MitID. While robust measures are in place, scammers continually find innovative ways to deceive users. To counteract this, it is essential to act wherever possible to mitigate risks. One significant area for improvement is the **authentication process**. During authentication, it must be clear and unambiguous to the end user what they are approving. This transparency helps prevent users from unintentionally approving actions they neither initiated nor intended. Recommendations for Service Providers To enhance clarity and reduce fraud, the MitID Partnership strongly recommends that service providers: 1.       Update the Reference Text Body 2.       **Update the Reference Text Header** (including action text and Service Provider name) 3.       Upload the Service Provider Logo These updates will improve user understanding and empower them to pause and reconsider before proceeding with an unintended action. Detailed recommendations for each update are provided below. ![[Reference-texts-and-logo3.jpg|300]] ![[Reference-texts-and-logo2.jpg|300]] --- #### 1. Update the Reference Text Body The reference text body is a descriptive text, up to **130 characters**, shown during the final step of the MitID box. In the MitID app, it is displayed only within the app interface. Why it Matters A well-crafted reference body highlights the specific action being approved and ensures the user understands the implications of their authentication. Recommendations for Updating the Reference Text Body - **Clarity:** Provide a clear, detailed description of what the user is approving. - **Context:** Help users understand the implications of the approval beyond authentication. - **Avoid Repetition:** Do not repeat the text from the reference text header; provide additional insights. - **Consistency:** Ensure alignment with the Service Provider's system and the MitID box. - **Character Limit:** Keep the text within 130 characters (maximum 3 lines) to avoid truncation. - **Alignment:** Ensure consistency between the Service Provider’s branding and the reference text to prevent confusion. - **Mandatory Text:** Always include a reference text body; avoid leaving it blank. ![[Reference-texts-and-logo.jpg|300]] --- #### 2. Update the Reference Text Header The reference text header consists of an **action text** and the **Service Provider name**. Why it Matters A clear and concise header ensures users recognize and trust the request, reducing ambiguity and hesitation. Recommendations for Updating the Reference Text Header - **Recognizable Name:** Use the exact Service Provider name that users are familiar with. - **Avoid Unnecessary Details:** Exclude suffixes like “ApS” or “A/S” to simplify the name. - **Avoid Broker Names:** Do not use broker names in place of the Service Provider name. - **Predefined Action Texts:** Select from one of five predefined action texts that best fit the approval type. - **Keep It Short:** Limit the header to two lines to avoid scrolling. - **Character Limit:** For names longer than 32 characters, ensure proper line breaks. - **Enhance Trust:** Align the name with what users expect to build clarity and confidence. ![[Reference-texts-and-logo4.jpg|300]] The 5 options for the action text: | Danish | English | Greenlandic | | ----------------------------------- | ----------------------------- | ----------------------------------------------- | | Log på hos <Tjenesteudbyber> | Log on at <Service provider> | Uunga iserit <Kiffartuussisuusoq> | | Godkend hos<br><br><Tjenesteudyber> | Approve at <Service provider> | Uani akuersigit <Kiffartuussisuusoq> | | Bekræft hos <Tjenesteudbyber> | Confirm at <Service provider> | Uani uppernarsaagit<br><br><Kiffartuussisuusoq> | | Accepter hos <Tjenesteudbyber> | Accept at <Service provider> | Uani akuersigit <Kiffartuussisuusoq> | | Underskriv hos <Tjenesteudbyber> | Sign at <Service provider> | Uani atsiorit <Kiffartuussisuusoq> | --- #### 3. Upload the Service Provider Logo Adding a Service Provider logo to the MitID app approval screen enhances trust and improves the overall user experience. To add a logo contact ZignSec support at [email protected]. Recommendations for the Service Provider Logo - **File Dimensions:** 200 pixels wide and 120 pixels high. - **File Format:** Preferably SVG; alternatively, use PNG with a minimum resolution of 144 pixels. - Aspect Ratio: - Use the full 200-pixel width for wide logos. - Use the full 120-pixel height for tall, square, or circular logos. - **Alignment:** Center the logo both vertically and horizontally. - **Proportions:** Maintain the original proportions; avoid stretching or squeezing the logo. - Background: - Use a transparent or pure white (#FFFFFF) background. - Avoid background colors unless essential to the logo design. - **Whitespace:** Minimize excessive whitespace around the logo. ![[Reference-texts-and-logo5.jpg]] --- By following these recommendations, Service Providers can ensure a clearer, more trustworthy authentication process that protects users and reduces the likelihood of fraud. ### Error Handling #### Handling User Cancellation The end-user can cancel an ongoing authentication or signing session at any time. If this happens, the user will be redirected back to the specified redirect URI provided by the merchant application. The merchant application must be prepared to handle this callback and respond appropriately. #### Handling Errors If an error occurs during an ongoing authentication or signing session, the following scenarios may take place: - The end-user might be shown an error message, often accompanied by an error code, with options to retry or return to the merchant application. - If the error occurs under the "right conditions," the user can be redirected back to the merchant application, using the same parameters as when a user cancels the session. - In rare cases, an error other than access_denied might be returned, along with an error_description parameter, depending on the situation. - In severe cases, the user might be stuck on the MitID platform with no option to return to the merchant application. ## API Overview ### Core Functionalities #### Environments We maintain environments you can use: - **Test (TEST)** environment: [https://test-gateway.zignsec.com/api/v5/sessions](https://test-gateway.zignsec.com/api/v5/sessions) - **Production (PROD)** environment:[https://gateway.zignsec.com/api/v5/sessions](https://gateway.zignsec.com/api/v5/sessions) #### Authentication Each request to our API should be authenticated by sending your subscription key in the “Authorization” header. Our support creates subscription keys for you (a pair for each environment), and it’s highly recommended to regularly rotate the keys (currently it’s done by sending a support request, but please let us know if you’d like to automate it). If you need different configurations, it’s possible to register multiple tenants and configure them differently. ### REST API #### Headers | Header | Description | Required | | ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | | Authorization | This header parameter is the subscription key you received from ZignSec during the registration process. Example: Authorization: 123456add0cff22873c428e987654321 | Yes | | Content-Type | Specifies the media type of the request body data. Set to application/json if JSON object. | Yes | #### OpenAPI specification and documentation ##### Live documentation - [Swagger UI (zignsec.com)](https://test-gateway.zignsec.com/api/v5/openapi/mitid/) #### API Endpoints ##### Authentication **Endpoint:** POST /auth - [Swagger UI (zignsec.com)](https://test-gateway.zignsec.com/api/v5/openapi/mitid/#/MitId%20Auth/CreateSession) **Description:** Standard endpoint. This API endpoint is to authenticate users ##### Match CPR **Endpoint:** POST /auth/{sessionId}/match-cpr- [Swagger UI (zignsec.com)](https://test-gateway.zignsec.com/api/v5/openapi/mitid/#/MitId%20Auth/MatchCpr) **Description:** This API endpoint is used to match sessionID against a CPR number ##### Get session details **Endpoint:** GET /auth/{sessionId}- [Swagger UI (zignsec.com)](https://test-gateway.zignsec.com/api/v5/openapi/mitid/#/MitId%20Auth/GetSession) **Description:** This API endpoint retrieves the status and details of a MitID identity verification session in Denmark. It allows you to check the outcome of a previously initiated verification request. ### MitID Session Result Response After completing a MitID authentication session, you can retrieve the session result to get detailed information about the authentication outcome. This is done by sending a GET request to the session result endpoint, using the unique session identifier provided during the session initiation. | Parameter | Description | | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | id | A unique identifier for the session created during the authentication process. | | errors | A JSON array containing error details, if any occurred during the session. An empty array indicates no errors. | | result | The authentication session outcome, containing a signed JWT token with the user's verified identity attributes. | | status | Indicates the current session state, which can be one of the following:<br><br>\| \| \|<br>\|---\|---\|<br>\|Status\|Description\|<br>\|Created\|The session has been successfully created.\|<br>\|Pending\|The session is awaiting user interaction or completion.\|<br>\|Finished\|The session has been successfully completed.\|<br>\|Failed\|The session encountered an error and could not complete.\|<br>\|Declined\|The user declined the authentication request.\| | Example of a Session Result Response: ```json { "data": { "errors": [ ], "id": "9df74aed-7a4a-4684-92ab-43da417c1ac2", "result": { "signedIdentity": "eyJhbGciOiJSUzI1NiIsImtpZCI6ImE1ZTk3NTZmLTgxMzItNDdhYy1hZmY3LTE5Y2FjMjY0ZTQ0MCIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL3ppZ25zZWMudGVzdC5taXRpZC5kay8iLCJpYXQiOjE2NTM2NDMwNjUsIm5iZiI6MTY1MzY0MzA2NSwiZXhwIjoxNjUzNjQ2NjY1LCJpZGVudGl0eSI6eyJoYXNDcHIiOnRydWUsImNvdW50cnlDb2RlIjoiREsiLCJmaXJzdE5hbWUiOiJTdGlnIFBldGVyc2VuIiwiZnVsbE5hbWUiOiJTdGlnIFBldGVyc2VuIiwicGVyc29uYWxOdW1iZXIiOiIiLCJkYXRlT2ZCaXJ0aCI6IjE5NDktMDUtMTAiLCJhZ2UiOjczLCJpZFByb3ZpZGVyTmFtZSI6Ik1pdElEIiwiaWRlbnRpZmljYXRpb25EYXRlIjoiMjAyMi0wNS0yN1QwOToxNzo0NS40OTU0NzU0WiIsImlkUHJvdmlkZXJSZXF1ZXN0SWQiOiI2OTFlMjE4My1mNjc3LTQ3YTQtOWQ0MC1kOWM0MmU4YzZhMGYiLCJpZFByb3ZpZGVyUGVyc29uSWQiOiJmMTRmMzA5My1mNjYxLTQ2ZjMtYTJlYS0zZTEzNjRiMzA1ODQifSwicHJvdmlkZXJEYXRhIjp7ImRrLm1pdGlkLmFzc3VyYW5jZWxldmVsIjp7ImxvYSI6IlNVQlNUQU5USUFMIiwiaWFsIjoiU1VCU1RBTlRJQUwiLCJhYWwiOiJTVUJTVEFOVElBTCIsImZhbCI6IkhJR0gifSwic3ViIjoiZjE0ZjMwOTMtZjY2MS00NmYzLWEyZWEtM2UxMzY0YjMwNTg0IiwiZGsubWl0aWQucHNkMiI6dHJ1ZSwiYW1yIjpbImFwcDoxNjUzNjQzMDY0MTgyOlNVQlNUQU5USUFMOlNVQlNUQU5USUFMOkhJR0g6SElHSCJdLCJraWQiOiJqd3RfbWl0aWRfMjEwMzIzIiwiaXNzIjoiTWl0SUQiLCJkay5taXRpZC5oYXNDUFIiOnRydWUsImV4cCI6MTY1MzY2MTA2NCwiaWF0IjoxNjUzNjQzMDY0LCJqdGkiOiJmNzE3NGMyMS03ZTcyLTRkYTktYTBkMS0yZGRkMmEzOTY3MDUiLCJkay5taXRpZC50cmFuc2FjdGlvbmlkIjoiNjkxZTIxODMtZjY3Ny00N2E0LTlkNDAtZDljNDJlOGM2YTBmIiwiYXVkIjoiMWNkZTMxNDQtMzRmYy00ZGU3LWE1NTMtZTViMTYwNzAyYjEyIiwibmJmIjoxNjUzNjQzMDY0LCJkay5taXRpZC5hdHRyaWJ1dGVzIjp7Im1pdGlkLmRrLmRhdGVfb2ZfYmlydGgiOiIxOTQ5LTA1LTEwIiwibWl0aWQuZGsuaWRlbnRpdHlfbmFtZSI6IlN0aWcgUGV0ZXJzZW4iLCJtaXRpZC5kay5pYWxfaWRlbnRpdHlfYXNzdXJhbmNlX2xldmVsIjoiU1VCU1RBTlRJQUwiLCJtaXRpZC5kay5hZ2UiOiI3MyJ9fX0.EWJiJuLoXk_x_nVp-oGdDtVLDl9moijNzrCCaGEtY2WceLMniH3eHF0HsiWDAyI4y92IORMQm4vxWQOUivMCyxJUv_0uebU3R854D06IDauG9-I24hMERsDE1uUsnAjC4W-CZbpzjuSFS0fq3g-H-garM7hwAHGtN4e2H9-M3A1TcP2SwZ8oEmPq5Eb6nQiZqjD8FmWfU1rB0IyRs9Z0KbQy8WwYZxt4YsRyJ9iP44-kz7_AprSwDygkjBC6gyyH8YJIx-SIy7C27r1e0UkDoe8JFaDOdWvfQR6jmX7PBfC2v9Hn8vLMGwHxuLeb5xecRNhTw8NwZM4BMIzorh6CFw" }, "status": "Finished" } } ``` For further information on decoding the signed identity token, refer to the [JWT Token Documentation](https://jwt.io/). After completing a MitID authentication session, the service provider can retrieve the session result, which includes a signed identity token in JSON Web Token (JWT) format. Decoding this JWT reveals the user's verified identity attributes. ####  Decoded Identity for MitID identity Verification The signed identity can be decoded with JWT Web Token convertors, see [**JWT convertor tool.**](https://jwt.io/#debugger-io) |Parameter|Description| |---|---| |iss|URL of issuer| |iat|time session was issued in Unix time format| |nbf|not before timestamp in Unix time format| |exp|time of expiry of session in Unix time format| |identity|\| \|<br>\|---\|<br>\|hasCpr – boolean that indicates whether it is possible to perform lookup/matchCPR e.g. true or false\|<br>\|countryCode – 2 character country code following ISO 3166-1 alpha-2 standard\|<br>\|firstName – name of person associated with the used eID\|<br>\|fullName – name of person associated with the used eID\|<br>\|personalNumber – CPR number of person associated with used eID only returned when lookup_CPR method is called\|<br>\|dateOfBirth – date of birth of person associated with the used eID returned in format YYYY-MM-DD (1949-05-10)\|<br>\|age – age of person associated with the used eID\|<br>\|idProviderName – name of product provider (MitID)\|<br>\|identificationDate – date of identification in timestamp format 2022-05-27T09:17:45.4954754Z”,\|<br>\|idProviderRequestId – a call-unique reference string for tracing and support issues e.g. “691e2183-f677-47a4-9d40-d9c42e8c6a0f”\|<br>\|idProviderPersonId – UUID of the eID used “f14f3093-f661-46f3-a2ea-3e1364b30584”\|| |providerData|data node from provider (MitID) containing raw original data. Note that this node should only be used as reference since this node could change at provider side.| Decoded Identity Example: ``` json { "iss": "https://zignsec.test.mitid.dk/", "iat": 1653643065, "nbf": 1653643065, "exp": 1653646665, "identity": { "hasCpr": true, "countryCode": "DK", "firstName": "Stig Petersen", "fullName": "Stig Petersen", "personalNumber": "", "dateOfBirth": "1949-05-10", "age": 73, "idProviderName": "MitID", "identificationDate": "2022-05-27T09:17:45.4954754Z", "idProviderRequestId": "691e2183-f677-47a4-9d40-d9c42e8c6a0f", "idProviderPersonId": "f14f3093-f661-46f3-a2ea-3e1364b30584" }, "providerData": { "dk.mitid.assurancelevel": { "loa": "SUBSTANTIAL", "ial": "SUBSTANTIAL", "aal": "SUBSTANTIAL", "fal": "HIGH" }, "sub": "f14f3093-f661-46f3-a2ea-3e1364b30584", "dk.mitid.psd2": true, "amr": [ "app:1653643064182:SUBSTANTIAL:SUBSTANTIAL:HIGH:HIGH" ], "kid": "jwt_mitid_210323", "iss": "MitID", "dk.mitid.hasCPR": true, "exp": 1653661064, "iat": 1653643064, "jti": "f7174c21-7e72-4da9-a0d1-2ddd2a396705", "dk.mitid.transactionid": "691e2183-f677-47a4-9d40-d9c42e8c6a0f", "aud": "1cde3144-34fc-4de7-a553-e5b160702b12", "nbf": 1653643064, "dk.mitid.attributes": { "mitid.dk.date_of_birth": "1949-05-10", "mitid.dk.identity_name": "Stig Petersen", "mitid.dk.ial_identity_assurance_level": "SUBSTANTIAL", "mitid.dk.age": "73" } } } ``` This decoded information allows service providers to verify the user's identity attributes as authenticated by MitID. ### Customization ZignSec offers customization and branding options for MitID authentication pages to align with your business's unique identity tailoring HTML and CSS files Requirements**:** 1.       **Customized HTML File:** A tailored HTML file reflecting your desired structure and content. 2.       **Customized CSS File:** A CSS file that defines the visual styling to match your brand's aesthetics. #### Sample Files: - Customization Page: - HTML File ``` html <div class="root">     <div class="header">         <img src="{{data.header.logo.src}}" title="{{data.header.logo.title}}" alt="{{data.header.logo.alt}}"/>         <h2>{{data.header.title}}</h2>     </div>     <div class="coreClientContainer">         <div id="mitid-client"/>         <h3 id="errorText">Please check if you have the access to MitID</h3>     </div>     <h3/> </div> ``` - CSS File          ``` css body { margin: 0; } html, body { height: 100%; } .root { width: 100%; height: 100%; display: flex; flex-direction: column; align-items: center; justify-content: flex-start; } #tulasi { color: orange; text-align: top; } .header { display: flex; align-items: center; box-sizing: border-box; width: 100%; background-color: purple; height: 44px; } .logo-container { height: 100%; display: flex; align-items: center; justify-content: center; margin-left: 10px; } .logo { background-image: url('https://zignsec.com/wp-content/uploads/2020/10/zs-logo-2.svg'); background-repeat: no-repeat; background-position: -2px -2px; color: #1e1e1e; outline: 0; width: 200px; height: 50px; } .content { height: 100%; display: flex; flex-direction: column; align-items: center; justify-content: center; } .coreClientContainer { display: flex; justify-content: center; } #errorText { display: none; color: orange; text-align: center; margin-top: 200px; } ``` #### MitID Customization Complete Package: ZignSec will assist in customizing the HTML and CSS files to meet your specific business requirements, ensuring a cohesive and branded user experience. ## Testing Once the ZignSec support team grants you access to the MitID test environment, you can begin testing. Here is a link to the test tool: [Link](https://pp.mitid.dk/test-tool/frontend/#/create-identity) Follow these steps: 1.       **Create a Test User:** Use the MitID Test Tool to set up a test user. ![[MitID-CreateNewTestID.jpg]] 2.       **View Test Account Details:** After creating the test user the details of the test user is shown. If you leave the site you can view the account details by entering the test user id and clicking the search button on the right. - Search options include CPR number, Identity Claim, or UUID. ![[MitID-IdentityDetails.jpg]] 3.       Authenticate Using the Test Tool: - Open the test app by clicking **Open Simulator**. - Trigger a ZignSec API call and navigate to the provided URL. - Enter the **Test User ID** (Identity Claim) to initiate authentication. - Switch to the app and confirm the authentication. ![[MitID-App.jpg]] 4.       Verify Results: - Check the authentication results using the **GET result** API or monitor the **webhook** for updates. ### Production testing Currently, there are no test users available for the production environment. Merchants who wish to conduct tests in staging areas using the production environment will need to use real MitID users.