4. Onboarding System

The onboarding system registers operational entities (PID Providers, Attestation Providers, Relying Parties, Wallet Providers, and Authentic Sources) so that they can participate in the IT-Wallet ecosystem with clearly defined authorizations and trust relationships.

4.1. Onboarding System Architecture

The onboarding service MUST provide specialized onboarding processes that match the operational characteristics and regulatory obligations of different participant types.

Fig. 4.1 IT-Wallet Onboarding System Overview.

All Primary Actors MUST undergo administrative registration for legal and regulatory compliance, followed by specialized technical registration processes that MUST reflect their operational roles in the Digital Credential ecosystem.

1. Administrative Registration: All entities (Authentic Sources, Relying Parties, Wallet Providers, Credential Issuers) MUST complete initial administrative registration that validates their legal standing, regulatory compliance, and organizational eligibility to participate in the IT-Wallet ecosystem.

2. Technical Registration: Following administrative approval, entities complete technical registration through specialized pathways:

   1. Authentic Sources: Declare their available claims from the Claims Registry and specify intended verification purposes and organization type (public or private).

   2. Credential Issuers: Select Authentic Sources based on required claims, request integration approval (except for regulatory mandates), and register Credential types with automatic catalog publication per Supervisory Body policy.

   3. Other Federation Entities (Relying Parties, Wallet Providers): Undergo federation-based registration for cryptographic trust establishment.

3. IT-Wallet Registry Integration:

   1. Claims Registry and Taxonomy Integration: Claims Registry provides standardized data definitions for individual Credential attributes, while Taxonomy defines hierarchical classification (domains, classes, purposes) that are then referenced in the Digital Credentials Catalog for specific Credential implementations. All participants leverage these registries for capability declarations and issuance/verification requirements.

   2. AS Registry Integration: Authentic Sources registered with their declared claims and capability, enabling CI discovery and coordination.

   3. Federation Registry Integration: Operational entities included for trust validation during Credential operations.

   4. Catalog Integration: Credential types automatically published in Digital Credentials Catalog based on Supervisory Body policies for public discovery eligibility.

4. Wallet Instance Registration: Wallet Instances are registered indirectly through Wallet Providers, establishing user-level Credential management capabilities. Technical details are provided in Wallet Instance Initialization and Registration.

4.2. Authentic Source Registration Process

Authentic Source registration allows data providers to establish their authoritative role in the Digital Credential ecosystem through the registration of their data capabilities and standardized access mechanisms based on the Claims Registry and Taxonomy classifications.

Authentic Source entities MUST undergo registration procedures that validate their data authority, declare their available claims from the standardized Claims Registry, and establish technical integration mechanisms. Authentic Source entities specify intended use cases (formally purposes) that determine catalog eligibility per Supervisory Body policies.

Public Authentic Sources MUST leverage PDND integration to provide government data through standardized national infrastructure.

Private Authentic Sources MAY establish custom service interfaces that accommodate specific organizational or regulatory requirements.

Both pathways MUST assure data quality standards and establish audit trails for all data provisioning activities.

AS-CI Coordination Process: Following AS registration, Credential Issuers identify suitable AS entities through the AS Registry and request integration authorization during the administrative registration phase. For regulatory mandates, authorization MUST be automatic. Otherwise, Authentic Sources entities evaluate and authorize Credential Issuers requests based on business and technical criteria. Following administrative authorization, technical integration procedures establish the operational data access relationships before Credential type catalog publication.

Successfully registered Authentic Sources MUST be included in the AS Registry with their declared claims and capability. Credential types MUST become publicly discoverable in the Digital Credentials Catalog only after successful AS-CI integration and Supervisory Body policy approval for catalog eligibility.

Technical implementation procedures for Authentic Source registration are provided in Authentic Sources Registration Process.

4.3. Federation Onboarding Process

Federation onboarding, including administrative and technical registration processes, establishes the trust relationships and compliance checks that enable all entities (PID Providers, Attestation Providers, Relying Parties, Wallet Providers, and Authentic Sources) to participate in the Credential lifecycle. Operational entities (PID Providers, Attestation Providers, Relying Parties, and Wallet Providers) MUST complete onboarding that includes administrative eligibility verification and technical validation. For Wallet Providers, this includes conformity assessment of the Wallet Solution and subsequent Trusted List notification flows.

For PID Providers, Attestation Providers, and Relying Parties, the federation onboarding process typically includes:

• Entity Registration: Collection of core data (identification, entitlements, service supply points, and cryptographic public keys and certificates) needed to authorize entities and describe their capabilities.

• Certificate Issuance: Issuance of certificates that authenticate entities, reference the registry for entitlement verification, support certificate transparency, and describe registration status for Relying Parties and Credential Issuers.

• Registry Publication: Publication of all registered entities in the registry, with an online API (see Trust Infrastructure and Registry Integration) that can be used to verify entity registration, and requested attributes.

4.3.1. Registration Form Information Requirements

During the administrative registration process, all entities registering with National Registrars MUST provide specific information.

For entities regulated under the Architecture and Reference Framework (ARF) - namely PID Providers, Attestation Providers (QEAA Providers, PuB-EAA Providers, and non-qualified EAA Providers), and Relying Parties - the registration form MUST collect at least the following information as specified in Regulation (EU) 2025/848, Annex I and aligned with the use cases defined in the trust infrastructure onboarding documentation:

Table 4.1 Registration Form Information Requirements (Annex I)

Information Field	Description and Requirements
Official Name	REQUIRED. The official legal name of the wallet-relying party (entity name as registered in business or government registries).
Official Identifiers	REQUIRED. One or more official identifiers of the wallet-relying party, such as: EORI (Economic Operators Registration and Identification) LEI (Legal Entity Identifier) VAT number (Value Added Tax identification number) National business registration number Other equivalent national identifiers
Physical Address and Member State	REQUIRED. Physical address of the entity and Member State if not present in official identifier. The address MUST include: Street address City Postal code Country (Member State)
URL	REQUIRED. URL belonging to the wallet-relying party where applicable (e.g., organization homepage, service website).
Contact Information	REQUIRED. Detailed contact information including: Phone number Website URL (if different from main URL) Email address(es) for administrative and technical contacts
Service Description	REQUIRED. Description of the type of services provided by the entity, including: Service categories Target user base Service scope and capabilities
Attributes Request List	REQUIRED. Where applicable, a list of the attributes that the wallet-relying party intends to request for each intended use. This MUST reference: Specific claim identifiers from the Claims Registry (e.g., given_name, family_name, driving_privileges) Taxonomy classifications (domains, classes, purposes) for authorization policy evaluation See Claims Registry for standardized claim definitions
Intended Use Description	REQUIRED. Where applicable, a description of intended use of the data, including: Business purpose for requesting attributes Service context and use cases Legal basis for data access (where applicable)
Public Sector Body Indication	REQUIRED. Indication whether the wallet-relying party is a public sector body (boolean value).
Applicable Entitlements	REQUIRED. Applicable entitlement(s) of the wallet-relying party chosen from the following list: Service_Provider QEAA_Provider Non_Q_EAA_Provider PUB_EAA_Provider PID_Provider QCert_for_ESeal_Provider QCert_for_ESig_Provider rQSigCDs_Provider rQSealCDs_Provider ESig_ESeal_Creation_Provider
Intermediary Indication	REQUIRED. Indication if the wallet-relying party intends to act as an intermediary or to rely upon an intermediary (boolean value).
Entity-Specific Information	CONDITIONAL. Additional information required based on entity type: For PID/EAA Providers: Attestation type(s) that the Provider intends to issue (QEAA, PuB-EAA, non-qualified EAA, PID) For QEAA Providers: Qualification evidence (conformity assessment report, QTSP status) For PuB-EAA Providers: Public sector body evidence For non-qualified EAA Providers: Service provider information For Relying Parties: Service supply point(s) and technical endpoint information

The registration form MUST be designed to support both manual data entry and automated registration processes through qualified authoritative registries. The Registrar MAY import entity information from qualified registries (e.g., business registries, VAT registries, professional qualification registries, GLEIF for LEI records) to reduce duplication and streamline onboarding.

All information provided in the registration form MUST be:

• Accurate and current at the time of registration

• Verifiable against supporting documentation or authoritative sources

• Maintained and updated without undue delay when changes occur

• Compliant with applicable data protection and privacy regulations

For Authentic Source registration information requirements, see Authentic Sources Registration Information Requirements.

For Wallet Provider registration information requirements, see the section Member State Notification to European Commission, which specifies conformity assessment requirements and Trusted List inclusion procedures.

4.3.2. Responsibilities Matrix

The following table summarizes the registration requirement and the authority responsible for compiling the Trusted List (TL) for each entity type:

Table 4.2 Federation Onboarding Responsibilities Matrix

Entity Type	Registration Process	Trusted List Compilation (EC / MS TLP)	Member State TLP Role
PID Provider	Registration with Registrar	European Commission (EU-level TL for PID Providers)	None (no national TL for PID Providers)
Attestation Provider	Registration with Registrar	Member State / MS TLP (national QTSP TL for QEAA Providers; national TL for non-qualified EAA Providers)	Compiles, signs, and publishes national Trusted Lists for QEAA and non-qualified EAA Providers according to the national trust services framework.
Relying Party (RP)	Registration with Registrar	N/A (Uses Access Certificates/Registry)	None (not listed in TLs)
Wallet Provider	Notification only (to EC)	European Commission (EU-level TL for Wallet Providers)	Not applicable in pilot (notification from Member State to EC only)
Access CA	Notification only (to EC)	European Commission (EU-level TL for Access CAs)	Not applicable in pilot (notification from Member State to EC only)
Reg. Cert. Provider	Notification only (to EC)	European Commission (EU-level TL for Reg. Cert. Providers)	Not applicable in pilot (notification from Member State to EC only)

Note

Trusted Lists and Federation Registry: Entities listed in national Trusted Lists are also registered in the national Federation Registry, which maintains additional technical information (e.g., federation endpoints). Key validation can occur through both mechanisms: verification against the Trusted List and verification through federation endpoints.

Note

PID Providers, PuB-EAA Providers, and Wallet Providers are registered through the IT-Wallet onboarding system and subsequently notified to the European Commission for Trusted List inclusion. Wallet Providers do not receive access certificates or registration certificates from National Registrars. The Wallet Solution provided by the Wallet Provider must be certified by Conformity Assessment Bodies (CABs) according to the national conformity assessment framework.

4.3.3. Member State Notification to European Commission

The Member State MUST notify all PID Providers, PuB-EAA Providers, Wallet Providers, Access Certificate Authorities, and Providers of Registration Certificates to the European Commission. The information notified varies by entity type:

• PID Providers: Identification data, PID Provider public keys/certificates, Access Certificate Authority public keys/certificates for PID Providers, Service Supply Point (URL)

• Wallet Providers: Identification data, Wallet Provider public keys/certificates

• PuB-EAA Providers: Identification data (including conformity assessment report), Service Supply Point (URL)

• Access Certificate Authorities and Providers of Registration Certificates: Identification data, public keys/certificates

The European Commission compiles, signs/seals, and publishes Trusted Lists for Wallet Providers, PID Providers, Access CAs, and Registration Certificate Providers.

4.3.4. Trusted List Publication for Attestation Providers

For Attestation Providers (both QEAA and non-qualified EAA Providers), the registration process triggers Trusted List publication:

QEAA Providers: - After successful registration with the National Registrar, QEAA Providers are included in Member State QTSP Trusted Lists published by the Member State per `EIDAS`_ Article 22 - These QTSP Trusted Lists are notified to the European Commission per EIDAS Article 22(3) so that QTSP TL locations and signing keys can be exposed via the List of Trusted Lists (LoTL)

Non-qualified EAA Providers: - After successful registration with the National Registrar, non-qualified EAA Providers are included in national EAA Provider Trusted Lists compiled and published by Member State Trusted List Providers (MS TLP) - These national Trusted Lists are published using ETSI TS 119 602 Annex H profile (Attestation Provider Trusted Lists), in either JSON format with compact JAdES Baseline B signature OR XML format with XAdES Baseline B signature - The MS TLP submits the published non-qualified EAA Provider Trusted List URL to the European Commission for inclusion in the LoTL

The Member State Trusted List Provider (MS TLP): - Receives notification of successful registration from the Registrar (or accesses Registry data) - Extracts cryptographic public keys, certificates, and relevant data from the Registry - Compiles Trusted Lists according to ETSI TS 119 612 or ETSI TS 119 602 specifications - Signs/seals and publishes Trusted Lists at publicly accessible URLs - Submits the Trusted List URL to the European Commission

4.4. Entity Lifecycle Management

Following successful onboarding, entities require ongoing lifecycle management to maintain operational status and compliance within the IT-Wallet ecosystem. Lifecycle management encompasses administrative updates, technical modifications, and federation exit processes that accommodate changing organizational and operational requirements.

4.4.1. Ongoing Operations Management

Entities MUST maintain current administrative and technical information to ensure federation participation and compliance.

Administrative Updates

Organizations MAY update administrative information through standard registry channels, such as:

• Legal Entity Changes: Company name changes, organizational restructuring, legal status modifications.

• Contact Information: Updates to official contact channels and responsible personnel.

• Regulatory Status: Changes in licenses, certifications, or regulatory compliance status.

• Service Scope: Modifications to service offerings or user base characteristics.

Administrative updates MUST follow standard governance processes and SHOULD NOT affect technical federation operations.

Technical Configuration Management

Technical updates affecting federation protocol operations require coordinated procedures, including:

• Certificate Management: Regular certificate renewal, emergency replacement, revocation handling.

• Infrastructure Changes: Endpoint updates, service migrations, capacity modifications.

• Compliance Updates: Security standard updates, policy changes, audit requirements.

• Capability Modifications: Adding or removing supported protocols, Credential types, or service features.

Technical updates MUST be validated by the Supervisory Body to maintain federation trust relationships and operational integrity.

4.4.2. Federation Exit and Removal Processes

Entities MAY exit the federation voluntarily or be removed by the Supervisory Body for compliance or security reasons.

Voluntary Federation Exit - Organizations MAY choose to exit the federation for business or operational reasons, including:

• Business Changes: Organizational restructuring or service discontinuation.

• Technical Migration: Moving to alternative technical solutions or providers.

• Regulatory Changes: Changes in regulatory environment or compliance requirements.

Voluntary exit MUST require coordination with dependent entities and proper handling of existing Credentials and user relationships.

Supervisory Body Removal - Supervisory Body MAY initiate entity removal for:

• Compliance Violations: Failure to maintain regulatory compliance or federation policy adherence.

• Security Incidents: Compromise of security infrastructure or failure to maintain security standards.

• Operational Failures: Persistent technical failures that affect federation security.

• Policy Violations: Violations of federation operational policies or agreements.

Removal processes MAY include investigations, remediations, and appeal procedures where appropriate.

Warning

For critical security incidents or immediate threats to federation integrity, the Supervisory Body MAY implement emergency suspension with immediate effect.

4.4.3. Lifecycle Coordination Requirements

Lifecycle management in the IT-Wallet ecosystem needs coordination between multiple participants to keep operations working and maintain trust relationships. The coordination framework covers three main areas:

• Stakeholder communication: When entities need to make changes that impact IT-Wallet ecosystem operations, they MUST inform the Supervisory Body and relevant federation participants in advance.

• Registry synchronization: When one entity makes changes that affect other entities, all registry systems MUST be properly updated ensuring that all changes are logged securely with timestamps and reasons.

• Business continuity assurance: Entities SHOULD balance between making necessary updates and keeping their obligations to users and regulations. This includes ensuring that the service is as available as possible, handling personal data correctly during changes, and staying compliant with legal requirements even in emergency situations.

Technical procedures and specific compliance requirements for lifecycle management are detailed in the Section Entity Onboarding.

4.5. Onboarding Journey Maps

The following journey maps provide a detailed view of the onboarding experience from the perspective of each entity type and their operators. These visual representations help organizations understand the specific steps, requirements, and interactions they will encounter during their onboarding process.

Each journey map shows the complete process from initial planning to final registry integration, highlighting critical touchpoints with the Supervisory Body and dependencies between different entity onboarding processes.

4.5.1. Ecosystem Overview

Fig. 4.2 Complete ecosystem onboarding showing the main processes

The IT-Wallet Registry system coordinates all registrations through five main components:

1. Claims Registry for standardized semantic definitions of individual Credential attributes.

2. AS Registry for data sources and capabilities.

3. Federation Registry for operational trust relationships.

4. Digital Credentials Catalog (see Digital Credentials Catalog) for Credential type discovery.

5. Taxonomy for hierarchical classification organizing Credentials by domain and purpose.

The following journey maps illustrate two distinct Credential scenarios:

• Public Catalog Scenario: Mobile Driving License (mDL) provided for a public discovery via Credential Catalog.

• Private Credential Scenario: Corporate Employee Badge from Company (Private AS, and therefore provided for discovery via Credential Offer only).

4.5.2. Authentic Source Operator Journey

From the Authentic Source operator perspective, the onboarding process begins with evaluating existing data capabilities against the standardized Claims Registry and Taxonomy classifications, determining which user attributes can be made available as a Digital Credential. The operator submits a registration request to the Supervisory Body, declaring specific claims from the Claims Registry with the Taxonomy domains and intended purposes.

Example - Public Authentic Source (mDL Scenario):

• Claims Declaration: Selects standardized claims (given_name, family_name, driving_privileges, etc. ) from Claims Registry.

• Taxonomy Classification: Domain MOBILITY_TRAVEL, Purpose DRIVING_RIGHTS.

• Use Case: Public service - driving authorization verification (eligible for Credential Catalog).

• Integration: e-Service PDNDintegration following government standards (see e-Service PDND).

• Catalog Outcome: mDL becomes publicly discoverable after CI integration.

Example - Corporate AS (Employee Badge Scenario):

• Claims Declaration: Selects claims (given_name, family_name, employee.job_title, etc.) from Claims Registry.

• Taxonomy Classification: Domain MEMBERSHIP, Purpose ASSOCIATION.

• Use Case: Private corporate access control (non-eligible for Credential Catalog).

• Integration: Custom API for Credential Issuer integration.

• Catalog Outcome: Badge remains private, available only via Credential Offer.

Critical phases include administrative verification by the Supervisory Body (which involves regulatory compliance checks outside the technical scope) and technical validation. The process concludes with registration in the AS Registry, making the declared claims discoverable by Credential Issuers for integration requests. The integration requests can be also send by the Authentic Sources to a specific Credential Issuers.

Warning

Important dependency: Declared claims in AS Registry remain unavailable to end users until a Credential Issuer completes registration, integration approval, and technical implementation. Catalog publication depends on Supervisory Body policies for public discovery eligibility.

4.5.3. Credential Issuer Operator Journey

Credential Issuer operators start by discovering available Authentic Source entities through the AS Registry and evaluating integration feasibility based on required claims. The registration request specifies which Credential types they intend to issue, select appropriate Authentic Source entities, and demonstrate technical capability to access the required data sources. Alternatively, the Credential Issuer operators receive directly the integration request by the Authentic Source.

Example - mDL (Public Scenario):

• AS Discovery or AS Integration Request: Identifies the Authentic Source providing mDL attributes in AS Registry with required driving license claims. Alternatively, Credential Issuer receives the integration request directly by mDL Authentic Source.

• Integration Request: Automatic approval due to regulatory mandate.

• Technical Setup: e-Service PDNDintegration following government standards (see e-Service PDND).

• Catalog Publication: mDL automatically published in the Credential Catalog.

• User Access: Citizens discover mDL through a public catalog in Wallet.

Example - CI for Employee Badge (Private Scenario):

• AS Discovery or AS Integration Request: Identifies the Authentic Source in AS Registry with employee access claims. Alternatively, Credential Issuer receives the integration request by the Authentic Source.

• Integration Request: Requires recipient approval.

• Technical Setup: Custom API integration with authentication.

• Catalog Publication: Badge excluded from public catalog per supervisory policy.

• User Access: Employees receive badges only via direct Credential Offer from company systems.

The technical setup phase offers two distinct integration pathways depending on the Authentic Source type:

• Public AS Integration: Uses the PDND platform for accessing government data through standardized APIs.

• Private AS Integration: Establishes direct API connections with custom endpoints provided by private organizations.

Following successful integration testing and Authentic Source approval, the Credential Issuer is registered in the Federation Registry as a trusted Entity, enabling actual Credential issuance to end-users.

Warning

This step activates Credential availability for end-users. Public Credentials become discoverable through the catalog, while other Credentials remain available only via direct Credential Offers.

4.5.4. Wallet Provider Operator Journey

Wallet Provider operators follow an independent onboarding path that focuses on application certification and security validation. The process highlights the development and certification of wallet applications that can securely store and manage Digital Credentials for citizens.

A key technical requirement involves implementing Wallet integrity and authenticity check mechanisms. These checks enable the Wallet to obtain a Wallet App Attestation, which serves as proof of the Wallet's security and compliance status during Credential operations.

The certification process includes security evaluation, covering wallet architecture, data protection mechanisms, and user privacy features. Successfully certified wallet providers are registered in the Federation Registry and can distribute their applications through app stores.

4.5.5. Relying Party Operator Journey

Relying Party operators begin by identifying which EAA types are required for their specific services and evaluating integration complexity with existing authentication systems. The registration request provides evidence of legitimate needs for accessing specific Credential types and User attributes, outlining the intended service use cases and organizational characteristics that justify Credential access.

Example - Car Rental Service (Private RP):

• Business Classification: ATECO code 77.11 (car rental services).

• Authorization Request: Driving authorization verification for rental eligibility.

• Claims Requirements: given_name, family_name, driving_privileges, etc., from mDL.

• Use Case Justification: Legal obligation to verify valid driving license before vehicle rental.

• Authorization Scope: Granted access to MOBILITY_TRAVEL domain, DRIVING_RIGHTS purpose.

Example - Municipal Services (Public RP):

• Organization Type: Public Administration with IPA code requirement.

• Authorization Request: Citizen identity verification for municipal services access.

• Claims Requirements: given_name, family_name, tax_id_code from PID.

• Use Case Justification: Public service delivery requiring citizen identification.

• Authorization Scope: Granted broader access reflecting public service mandate.

Example - Corporate Access Control (Private RP):

• Business Classification: ATECO code 62.01 (computer programming activities).

• Authorization Request: Employee verification for corporate facility access.

• Claims Requirements: given_name, family_name, employee.job_title from Corporate Employee Badge.

• Use Case Justification: Workplace security requiring employee identification and access control.

• Authorization Scope: Granted access to MEMBERSHIP domain, ASSOCIATION purpose.

• Credential Discovery: Badge available only via private Credential Offer (non-eligible for Credential Catalog).

Technical integration focuses on developing authentication flows that can verify Digital Credentials presented by Users. This includes implementing cryptographic verification mechanisms and establishing secure communication channels with the federation infrastructure.

Service authorization by the Supervisory Body MUST involve policy-based evaluation that considers organizational type (private vs public administration), business sector classification, and legitimate service requirements. The authorization process grants specific operational scopes that define which Credential domains and purposes the Relying Party can request. Following approval, the Relying Party is registered in the Federation Registry with clearly defined authorization boundaries for Digital Credentials and User's attributes acceptance.

4.6. User Experience Journey

When all entity onboarding processes are successfully completed, Users can discover and install certified Wallet Instances, obtain available Digital Credentials and present their Digital Credentials to registered Relying Parties (see Functionalities Overview).

This seamless integration depends on all relevant entities having completed their respective onboarding journeys.