Skip to content

Introduction

eIDAS v2 aims at enabling Union citizens and residents of the EU to manage their digital identity and a variety of other electronic attestations of attributes (certificates, prescriptions, tickets, ...) in a European Digital Identity Wallet (EUDIW).

The technical architecture of the EUDI ecosystem and the set of technical standards envisioned to ensure interoperability among the different parties are specified in the Architecture and Reference Framework (ARF).

This document builds on the eIDAS regulation and the ARF. It proposes a technical architecture, an ecosystem governance and operating model and other considerations for the German national Wallet ecosystem implementation. Furthermore, it clarifies concepts and describes details in the context of the German implementation.

This document shall serve as a basis for discussions in the course of an ongoing consultation process. It takes into account the specifics of the German eID system, the decentralized nature of registers in Germany, and the use cases and requirements contributed through the consultation process.

The objective is to ensure the interoperability of the German national Wallet implementation within the EUDI ecosystem across all member states, while fulfilling the desired security, privacy, and user experience requirements and showing a viable governance and economic model.

From an architecture point of view, the goal of this entire process and this document is to ultimately have possible implementation options for a decentralized, secure and privacy-friendly wallet. The document does not claim to actually provide the corresponding implementation, as the corresponding future changes to the ARF or the publication of the Implementing Acts could also have a significant impact on an architecture that is unfortunately not yet foreseeable at this time.

EUDI Wallet Ecosystem Overview

The EUDI Wallet ecosystem comprises various roles and systems essential for delivering value to users, organizations, and society. While inherently complex, the ecosystem also interacts with external actors and systems that serve as core enablers or supervisory entities. Figure 1 provides an overview of the EUDI Wallet ecosystem, illustrating its key roles along with adjacent roles and systems. For authoritative and legally binding definitions, please refer to the EU eIDAS 2.0 Regulation.

EUDI Wallet Ecosystem Overview.

Figure 1: EUDI Wallet Ecosystem Roles and Components

(1) German eID Card (Outside German EUDI Wallet Ecosystem):

The German eID Card (nPA) serves as a primary PID source, enabling the PID provider to provide PID data to the EUDI Wallet upon the user's request. The eID system encompasses the eID for German citizens, the Unionsbürgerkarte for EU citizens, and the elektronischer Aufenthaltstitel for non-German and non-EU citizens. The Architecture for the German electronic Identity Card and electronic Resident Permit is specified in the BSI Technical Guideline TR-03127.

(2) Authentic Sources (Outside German EUDI Wallet Ecosystem):

Authentic Sources are public or private repositories or systems, recognised or required by law, containing attributes about natural or legal persons. Authentic Sources are sources for attributes on, for instance, address, age, gender, civil status, family composition, nationality, education and training qualifications titles and licences, professional qualifications titles and licences, public permits and licences, or financial and company data. Authentic sources are outside of the German EUDI Wallet Ecosystem as they are not part of the project scope of the German EUDI Wallet project.

(3) EUDI Wallet Ecosystem Orchestrator:

The ecosystem orchestrator is responsible for overseeing the development, implementation, and operation of the EUDI wallet ecosystem, while coordinating and consulting with both public and private stakeholders. In addition, the orchestrator facilitates testing environments, supports ecosystem onboarding, and ensures transparency regarding activities within the EUDI Wallet ecosystem.Further details can be found in the EGOM section of this concept.

(4) PID Provider:

A PID Provider is a trusted entity responsible for: - verifying the identity of the user in compliance with LoA high requirements, - issuing a PID to the Wallet, and - making available, in a privacy preserving way, information for Relying Parties to verify the validity of the PID.

The PID Provider ensures that person identification data, such as name and date of birth, is securely generated, validated, and seamlessly provided. The PID provider is part of the infrastructure of the German EUDI Wallet ecosystem. In the future, additional PID issuance methods that meet the functional and security requirements may be evaluated as part of the German EUDI Wallet project. The EUDI wallet ecosystem envisions a single PID provider.

(5) (Q-, Pub-) EAA Provider:

An (Q-, Pub-) EAA Provider is an entity responsible for issuing Electronic Attestations of Attributes (EAAs) at the user's request within the EUDI Wallet ecosystem. EAAs allow users to prove specific attributes within the EUDI Wallet ecosystem in a secure, standardized, and legally recognized way. Qualified Electronic Attestation of Attributes (QEAA) Providers meet the highest eIDAS 2.0 trust and security standards, issuing legally binding attestations recognized across borders, while Public Electronic Attestation of Attributes (Pub-EAA) Providers are trusted public entities that issue legally recognized but non-qualified attestations. EAA providers can be from any domain (e.g. telecommunication, mobility) and the EAAs they issue may hold legal status and meet high security requirements specific to their domain. EAA providers are typically supervised by a competent authority within their domain. The EUDI wallet ecosystem envisions multiple (Q-, Pub-) EAA Providers.

(6) EUDI Wallet Registrar:

The EUDI Wallet Registrar is responsible for managing the registration and oversight of Wallet Providers within the EUDI Wallet ecosystem. It ensures that only compliant and certified providers are listed, helping maintain trust and security by verifying that Wallet Providers meet the required technical, security, and regulatory standards. The EUDI wallet ecosystem envisions a single EUDI Wallet Registrar.

(7) EUDI Wallet Provider:

A Wallet Provider offers users a combination of trusted products and services, ensuring sole control over their Person Identification Data (PID), Electronic Attestations of Attributes (QEAA, PuB-EAA, or EAA), and any other personal data within their Wallet Unit. This includes safeguarding sensitive cryptographic material (e.g., private keys) related to the wallet. By doing so, the EUDI Wallet Provider delivers a certified interface that allows citizens to manage their data securely while enabling, amongst others, pseudonymous logins, and the authorizations for payments, and qualified electronic signatures. The EUDI wallet ecosystem vision envisions multiple EUDI wallet providers.

(8) EUDI Wallet Conformity Assessment Bodies: EUDI Wallet Conformity Assessment Bodies are independent entities responsible for evaluating whether EUDI Wallets meet the required security, interoperability, and compliance standards set out under eIDAS 2.0. These bodies must be accredited under the EUDIW certification scheme. They perform assessments and audits as part of the EUDI Wallet certification process—initially based on national certification schemes and, later, on a unified European certification scheme. Their role is to ensure that Wallet Providers fully comply with all regulatory and technical requirements.

(9) QES-Provider/QTSP (Outside German EUDI Wallet Ecosystem):

EUDI Wallet providers must offer users free Qualified Electronic Signatures (QES) for non-professional use within a wallet-centric QES approach. To ensure compliance with eIDAS 2.0, they may need to collaborate with a Qualified Trust Service Provider (QTSP) for the issuance and management of qualified electronic signatures. A Qualified Trust Service Provider (QTSP) is a trust service provider that has received qualified status from a supervisory body in an EU member state. This status allows the provider to offer qualified trust services, which carry legal effects equivalent to handwritten signatures or other legally recognized processes across the EU. The EUDI wallet ecosystem interacts with multiple QES-Providers/QTSPs.

(10) Relying Parties:

A Relying Party (RP) is an entity that interacts with EUDI Wallets to verify a user’s identity and attributes for authentication, authorization, or service access. The scope of the EUDI Wallet ecosystem is to create a public and private ecosystem. Both public and private Relying Parties must register and declare their intended use of the EUDI Wallet to ensure compliance with the EUDI wallet ecosystem based on the eIDAS 2.0 regulation. The EUDI wallet ecosystem envisions multiple public, civic and private RPs.

(11) RP Registrar:

The RP Registrar (Relying Party Registrar) is responsible for the registration, validation, and oversight of all EAA Providers and Relying Parties that interact with EUDI Wallets. It ensures that EAA providers and Relying Parties declare their intended uses, comply with eIDAS 2.0 regulations, and operate transparently to maintain trust and security within the EUDI Wallet ecosystem. The EUDI wallet ecosystem envisions a single RP registrar.

(12) Consumer Protection Organizations/Public (Outside German EUDI Wallet Ecosystem):

Consumer protection organizations and the general public can access the declared intended uses of relying parties interacting with EUDI Wallets, as these must be registered with the RP registrar. This information will be published online in machine-readable formats, ensuring transparency and enabling public oversight. Consumer Protection Organizations and the Public encompass multiple actors and stakeholders.

(13) (State) Data Protection Supervisory Authority (Outside German EUDI Wallet Ecosystem):

Federal and State Data Protection Supervisory Authorities oversee the EUDI Wallet ecosystem, ensuring compliance with data protection regulations and enforcing corrective measures in cases of non-compliance. Citizens using EUDI Wallets from their chosen providers can report any suspected misuse during interactions with relying parties to the relevant data protection authorities. Multiple (State) Data Protection Supervisory Authorities interact with the EUDI wallet ecosystem.

(14) PubEAA Trusted List

The PubEAA Trusted List is an official registry that lists recognized and accredited entities that provide PubEAAs. PubEAAs are electronic attestations of attributes issued by public entities such as social security status or tax information. The EUDI wallet ecosystem envisions a single PubEAA Trusted List.

(15) Authentic Sources Trusted List

The Authentic Sources Trusted List is an official registry that lists recognized and accredited entities of all member states. Authentic Sources are public or private repositories or systems, recognised or required by law, containing attributes about natural or legal persons. Authentic Sources are sources for attributes on, for instance, address, age, gender, civil status, family composition, nationality, education and training qualifications titles and licences, professional qualifications titles and licences, public permits and licences, or financial and company data. The EUDI wallet ecosystem envisions a single Authentic Sources Trusted List.

(16) QEAA Trusted List

The QEAA Trusted List is a registry of Qualified Electronic Attestation of Attributes (QEAA) Providers that meet the highest eIDAS 2.0 trust and compliance standards. It ensures that only accredited entities can issue legally binding electronic attestations of attributes that are equal to paper for use in the EUDI Wallet ecosystem. The EUDI wallet ecosystem envisions a single QEAA Trusted List.

(17) EUDI Wallet Certification Scheme

The EUDI Wallet Certification Scheme is a standardized framework that defines the security, interoperability, and compliance requirements for EUDI Wallets within the eIDAS 2.0 ecosystem. It ensures that Wallet Providers meet strict regulatory, technical, and security standards before their solutions are certified and approved for official use. Through this scheme, EUDI Wallets create trustworthiness, ensure data protection, and seamless cross-border functionality across the EU. The EUDI wallet ecosystem will have a single certification scheme.

(18) Domain-Specific EAA Lists

Domain-Specific EAA Lists are specialized registries that catalog Electronic Attestation of Attributes (EAAs) issued for specific sectors or use cases, such as healthcare, education, mobility, telecommunication or banking and insurance. These lists ensure that only recognized and trusted entities within a particular domain can issue and manage verified attributes for use in the EUDI Wallet ecosystem, supporting sector-specific regulatory and interoperability requirements. The EUDI wallet ecosystem envisions multiple Domain-Specific EAA lists.

Overview EUDI Wallet

European Digital Identity Wallets (EUDIW) as envisioned by the ARF and this document shall provide a set of well-defined, generic functions. Use cases are implemented by ecosystem participants on top of these functions as required. Figure 1 illustrates this concept.

Figure showing a Wallet and its connections to an Issuer, a Relying Party and additional services; Use cases 1, 2, and 3 affect different subsets of these entities.

Figure 1: The Wallet provides a set of generic functions to enable various use cases, here shown in three examples.

The following functions are defined:

  • PID Issuance and Presentation: The EUDIW shall enable the user to identify and authenticate themselves to a Relying Party by receiving and presenting their Person Identification Data (PID). (See Wallet Function: PID Issuance and Presentation for details.)

  • Qualified or non-qualified Electronic Attestations of Attributes ((Q)EAA) Issuance and Presentation: The EUDIW shall enable the user to receive, manage and present (qualified) electronic attestations of attributes in a generic manner, i.e., any (Q)EAA compatible to the technical standards defined in this document can be stored in the EUDIW and subsequently presented to any compatible Relying Party.\ (See Wallet Function: (Q)EAA Issuance and Presentation for details.)

  • QES: The EUDIW must support the identification of the signatory and their non-repudiable consent to initiate a QES. (See QES for details.)

  • Login: The EUDIW shall enable the user to login into services by authenticating to a Relying Party. (See Wallet Function: Login for details.)

Use Case Examples

Use Case 1: In the example "Use Case 1", an ecosystem participant uses the Wallet login function only, so it acts as a Relying Party towards the EUDIW. There is no dependency on any other ecosystem participant. The Wallet will provide the functionality to prove possession of certain cryptographic keys. The rest of the user experience and logic must be provided in the use case implementation.

Use Case 2: In example "Use Case 2", ecosystem participants use the functions to issue and present EAAs. This means there need to be one or more Issuers for a certain EAA type or multiple EAA types and there are one or more Relying Parties processing presentations of those EAAs. The lifecycle management process for those EAAs is out of scope of this document, the lifecycle requirements depend on the specific domain. The Wallet will ensure a certain security (resistance) level as requested by the Issuer of the EAA. The Wallet provides the core functions to request and retrieve an EAA as well as to present an EAA in response to an RP request. The Wallet will also display all relevant information about the transaction (i.e., which data is requested by whom and for what purpose) to the user and get the user's consent for the transaction. The embedding of these functions into the overall user experience of the use case is out of scope of the Wallet.

A visual example of this use case can be viewed under the following link to make the process described above more tangible. The design of the screens is to be understood as an exemplary realization and not as a specification. The focus of the screens provided is to present the use case of an exemplary bank account opening step by step in a visually comprehensible way.

User Journey: Bank account opening

Use Case 3: Besides the standard roles (Holder, Issuer, Relying Party) there can be any number of services offered to ecosystem participants by leveraging the Wallet functions. Remote signature creation, electronic archiving, and payment APIs are some examples. The example "Use Case 3" illustrates this concept. There, EAAs are used to authenticate the user at such an additional service. A remote signature creation service could, for example, be built on top of the "Online Identification with PID" Wallet function.

Extending Protocols and Use Cases

The functions provided by the Wallet use a set of pre-defined standard protocols. Wallets can, however, decide to implement other protocols as required for use cases, especially if the use case requires a domain specific standard (e.g., car keys).

The presented Wallet architecture does not (in general) implement use case specific functionality. It is an electronic identity and generic infrastructure component whose role to the ecosystem is to provide key and attestation management capabilities on the required security levels. It shall be possible to roll out new use cases (within the boundary of the Wallet functions and supported technical protocols and formats) without the need to change the Wallet's implementation.

Used Standards

Below is the list of standards and specifications used in this document:

This document does not preclude implementing additional standards or specifications, but the different flows and examples in this proposal are solely based on the above-mentioned standards.

Terminology

This document uses the following terms and abbreviations:

  • Two Factor Authentication (2FA): 2FA is a security system that requires two distinct forms of identification in order to access something.

  • European Digital Identity Wallet Architecture and Reference Framework (ARF): A toolbox including a technical Architecture and Reference Framework (ARF), a set of common standards and technical specifications, and a set of common guidelines and best practices. ARF 1.2.0

  • Authentication: The process of verifying that the claimed identity is valid. It involves proving that the user is indeed who they claim to be. eIDAS 2

  • Authorization: The process of granting or denying specific permissions or access rights to resources, systems, or data based on the authenticated identity of a user or entity. It determines what an authenticated user or entity is allowed to do. eIDAS 2

  • brainpool: A set of elliptic curve domain parameters over finite prime fields that are recommended for use in cryptographic applications. RFC5639

  • OAuth 2.0 Demonstrating Proof of Possession (DPoP): DPoP binds a token to the client that requested it to protect against misuse. DPoP

  • Electronic Attestation of Attributes (EAA): ‘Electronic Attestation of Attributes’ means an attestation in electronic form that allows the authentication of attributes. eIDAS 2 Article 3 (44)

  • Elliptic-curve Diffie–Hellman (ECDH): Elliptic-curve Diffie–Hellman (ECDH) is a key agreement protocol that allows two parties, each having an elliptic-curve public–private key pair, to establish a shared secret over an insecure channel. This shared secret may be directly used as a key, or to derive another key. RFC6090

  • German eID system (eID): Architecture for the German electronic Identity Card and electronic Resident Permit is specified in the BSI Technical Guideline TR-03127. BSI TR-03127

  • eID-Server (eID-Server): eID-Server for Online-Authentication based on Extended Access Control Version 2 (EAC2) between an eService and an eIDAS token, e.g. the German National Identity Card, the German electronic Residence Permit, the eID-Card for Union Citizens or an EAC-compatible mobile eID based on secure storage on a mobile device, that was derived from one of the former documents. BSI TR-03130

  • eIDAS regulation version 2 (eIDAS): Regulation of the European Parliament and of the Council amending Regulation (EU) No 910/2014 as regards establishing a framework for a European Digital Identity. eIDAS 2

  • European Digital Identity Wallet (EUDIW): ‘European Digital Identity Wallet’ means an electronic identification, which allows the user to securely store, manage and validate identity data and electronic attestations of attributes, to provide them to relying parties and to other users of European Digital Identity Wallets, and to sign by means of qualified electronic signatures or to seal by means of qualified electronic seals. eIDAS 2

  • (European Digital Identity) Wallet Provider (EUDIW Provider, Wallet Provider): The obligation to provide an EUDIW arises from the eIDAS Regulation. The MS determines whether it provides the EUDIW itself, mandates the provider(s) or recognizes one or more Wallet Provider(s) by another organization. eIDAS 2

  • embedded UICC (eUICC): A removable or non-removable UICC which enables the secure remote and/or local management of Profiles. GSMA

  • Hash-based message authentication code (HMAC): HMAC is a specific type of message authentication code involving a cryptographic hash function and a secret cryptographic key. RFC6234

  • Identity Owner (Holder): The entity, such as a natural person, a legal person, or a device, which is subject of verifiable credentials from credential issuers and being in control of the reception, storage, and sharing of such credentials with relying parties. ARF 1.2.0

  • Hardware Security Module (HSM): A HSM is a device for providing cryptographic functionalities whereas the life cycle of cryptographic keys and the performance of cryptographic functions is managed within a highly protected hardware environment.

  • Identification: The process of claiming or recognizing an identity. It involves presenting an identifier that represents an individual or entity. eIDAS 2

  • Internet Engineering Task Force (IETF): The Internet Engineering Task Force is a standards organization for the Internet and is responsible for the technical standards that make up the Internet protocol suite. It has no formal membership roster or requirements and all its participants are volunteers.

  • International Organization for Standardization (ISO): The International Organization for Standardization is an independent, non-governmental, international standard development organization composed of representatives from the national standards organizations of member countries.

  • PID presentation format (ISO mdoc):

  • Issuer: An entity that issues credentials to a Holder. Sometimes referred to as Provider. OpenID4VCI

  • JSON Web Token (JWT): JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. RFC7519

  • Level of Assurance (LoA): eIDAS Levels of Assurance (LoA), BSI TR-03107

  • Message Authentication Code (MAC): The result of a HMAC performance. RFC8446

  • OpenID for Verifiable Credential Issuance (OpenID4VCI): OAuth protected API for the issuance of Verifiable Credentials. OpenID4VCI

  • OpenID for Verifiable Presentations (OpenID4VP): A mechanism on top of OAuth 2.0 RFC6749 that enables presentation of Verifiable Credentials as Verifiable Presentations. OpenID4VP

  • Person Identification Data (PID): ‘Person Identification Data’ means a set of data, issued in accordance with Union or national law, enabling the identity of a natural or legal person, or of a natural person representing a natural or legal person, to be established. eIDAS 2

  • Person Identification Data Issuer (PID Provider (PI)): A Member State or other legal entity issuing Person Identification Data to Users for later use. ARF 1.2.0

  • Person Identification Data Provider (PID Provider (PP)): A Member State or other legal entity providing Person Identification Data to Users. ARF 1.2.0

  • Public Key Infrastructure (PKI): Systems, software, and communication protocols that are used by EUDI Wallet ecosystem components to distribute, manage, and control public keys. A PKI publishes public keys and establishes trust within an environment by validating and verifying the public keys mapping to an entity. ARF 1.2.0

  • Proof of Possession (PoP): Evidence provided by the Wallet regarding the possession of the respective key material.

  • Qualified Electronic Attestation of Attributes (QEAA): ‘Qualified Electronic Attestation of Attributes’ means an electronic attestation of attributes, which is issued by a qualified trust service provider and meets the requirements laid down in Annex V. eIDAS 2 Article 3 (45)

  • Qualified Electronic Signature (QES): ‘Qualified Electronic Signature’ means an advanced electronic signature that is created by a qualified electronic signature creation device, and which is based on a qualified certificate for electronic signatures. eIDAS 2

  • Qualified Trust Service Provider (QTSP): A Trust Service Provider who provides one or more Qualified Trust Services and is granted the qualified status by the supervisory body. ARF 1.2.0

  • Relying Party (RP): ‘Relying Party’ means a natural or legal person that relies upon an electronic identification, European Digital Identity Wallets or other electronic identification means, or a trust service. eIDAS 2 Article 3 (6)

  • Selective Disclosure for JWT (SD-JWT): A composite structure, consisting of an Issuer-signed JWT (JWS, RFC7515), Disclosures and optionally a Key Binding JWT that supports selective disclosure. SD-JWT (Draft)

  • SD-JWT-based Verifiable Credentials (SD-JWT VC): Verifiable Credentials with JSON payloads with and without selective disclosure based on the SD-JWT format. SD-JWT (Draft)

  • Secure Element (SE): Secure Elements are physical components in electronic devices that securely store and protect sensitive data and applications and may provide certain secure cryptographic operations. Secure Elements for mobile platforms

  • Seed Credential: A credential derived from the electronic Identity Card. It is used to request a fresh PID credential created on-demand from the PID Provider.

  • Smart-eID (Smart-eID): The smart eID enables citizens to store their electronic proof of identity directly in their smartphones. Smart-eID Act

  • Trusted List (Trusted List): Repository of information about authoritative entities in a particular legal or contractual context which provides information about their current and historical status. ARF 1.2.0

  • Trust Service Provider (TSP): A natural or a legal person who provides one or more Trust Services, either as a qualified or as a non-qualified Trust Service Provider. ARF 1.2.0

  • Interacting entity (User): A natural or legal person using an EUDI Wallet. Also referred to as Holder. ARF 1.2.0

  • User Experience / User Interface (UX/UI): The user interaction work flow (UX) and the user interaction functional and visual elements (UI) of a software and/or hardware application. Wikipedia User experience design

  • Verifiable Credential (VC): A credential created by an Issuer in a way that the integrity and authenticity of the credential can be cryptographically verified. OpenID4VCI

  • Wallet Secure Cryptographic Device (WSCD): Hardware-backed secure environment for creating, storing, and/or managing cryptographic keys and data. Examples include Secure Elements (SE), Trusted Execution Environments (TEEs), and (remote or local) Hardware Security Module (HSM). ARF 1.2.0

  • Wallet-Relying Party (WRP): wallet-relying party means a relying party that intends to rely upon wallet units for the provision of public or private services by means of digital interaction. eIDAS 2 Article 5b