> For the complete documentation index, see [llms.txt](https://docs.1kosmos.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.1kosmos.com/identity-verification/non-doc-verification/eid-verification.md). # eID Verification *** ## Overview An electronic ID (eID) is a digital identity credential issued by a government, regulated bank consortium, or accredited identity provider. Examples include eIDAS-notified schemes across the EU, BankID in Sweden and Norway, MitID in Denmark, itsme in Belgium, iDIN in the Netherlands, FranceConnect in France, and similar schemes in other regions. Where these exist, they're typically the most trusted, lowest-friction way to verify identity — the user already has the credential, the issuer has already done the heavy identity proofing, and the assurance level is government-defined. eID verification reuses that existing credential rather than re-proofing the user from scratch. ### What happens during eID verification {% stepper %} {% step %} **The user picks their eID provider** If your verification flow supports multiple eID schemes (common in cross-border deployments), the user selects which one they want to use. Otherwise the flow goes straight to the configured provider. {% endstep %} {% step %} **The user authenticates with the eID** The user is redirected to their eID provider — their bank app, the national identity portal, a mobile eID app, or a smart-card reader, depending on the scheme. They authenticate using whatever the scheme requires: a PIN, biometric, hardware token, or push approval on a registered device. Verification never sees the user's eID credentials directly. The eID provider does the authentication and returns a signed assertion. {% endstep %} {% step %} **The eID provider returns verified attributes** After successful authentication, the eID provider sends back a set of verified attributes — typically name, date of birth, a national identifier, and optionally address. These attributes carry the assurance level of the eID scheme itself. {% endstep %} {% step %} **Attributes are validated and stored** The verification service checks the signature on the assertion, confirms the assurance level meets the flow's requirement, and persists the verified attributes alongside the verification result. The user can then continue with whatever the original transaction was. {% endstep %} {% endstepper %} ### What you get back A successful eID verification produces: * **Verified identity attributes** — name, date of birth, and other fields the scheme exposes (varies by provider and what the user consents to share). * **A national or scheme-specific identifier** — for example, a Swedish personal identity number from BankID, or a Belgian national register number from itsme. Treat this as highly sensitive PII. * **Assurance level** — the scheme's stated level, mappable to NIST IAL or eIDAS Substantial/High. * **A signed assertion** — the cryptographic proof the verification actually came from the issuer. Retain this for audit. For the wrapping result schema, see [Verification result](/identity-verification/core-concepts/viewing-verification-results.md). ### Why this method works well | Benefit | What it means in practice | | ----------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Very low friction** | The user authenticates with a credential they already have and use frequently. Median completion times are 10–30 seconds. | | **High assurance out of the box** | Most eID schemes are issued at substantial or high assurance — equivalent to or stronger than document + selfie verification. | | **Regulator-recognized** | In the EU, eIDAS-notified eIDs are accepted by member states for KYC under AMLD. In the Nordics, BankID is the de facto standard for financial onboarding. | | **Reduced fraud surface** | The user never types attributes manually, so typos, mismatches, and synthetic identity injection at data entry are eliminated. | | **Inclusive of users without travel documents** | Many citizens have an eID but not a passport. Supporting eID broadens your verifiable population. | ### Use cases where eID is the right default * **Financial onboarding in markets with strong eID adoption.** In Sweden, Norway, Denmark, Belgium, the Netherlands, Estonia, and similar markets, your users will expect to see their eID as the primary option. * **Cross-border KYC under eIDAS.** A user in one EU member state can verify into a service in another using their notified eID. * **Re-verification and step-up.** A user who originally onboarded with a document can step up to a sensitive action using their eID — fast for the user, cryptographically strong for you. * **Recurring compliance refresh.** Annual or biennial re-KYC where you just need fresh evidence the user is still who they were. * **Public sector and healthcare.** Government services and health platforms in countries with national eIDs almost universally use them as the primary verification method. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.1kosmos.com/identity-verification/non-doc-verification/eid-verification.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.