8. Onboarding System and Lifecycle Management

Warning

This section is a work in progress and it is published in draft form. The general structure is in place, while several parts are still to be written and the content may change. The subsections marked as draft below contain only a short description of what they will provide.

The Onboarding System is the set of components, services, processes and procedures that admits an Entity into the IT-Wallet ecosystem. The Onboarding System publishes the information that other participants need to recognize the Entity. The Onboarding System manages what happens after the registration.

The Onboarding System covers:

• Entities: the Wallet-Relying Parties, the Wallet Providers and the Authentic Sources, from their registration until the cancellation of that registration. An Entity is registered, updated, possibly suspended and reactivated, and finally removed.

• Trust Artifacts: the certificates, the registration certificates and the federation statements that are issued as a result of a registration, and that are always derived from it.

• Credential types: the versioned definitions published in the Digital Credentials Catalog, with the claims, the schemas and the Authentic Sources they depend on. A Credential type is registered, activated, versioned and deactivated.

• Registries and catalogs: the National registries that the system writes, and the European catalogs and Lists of Trusted Entities towards which the system aligns or notifies.

For each of these, the Onboarding System covers the whole lifecycle and not only the first onboarding.

All events related to Entities and Credential types produce effects on the Trust Artifacts and on the registries, and those effects are described in this Section, together with the events that cause them.

As defined in Infrastructure of Trust, two Trust Frameworks coexist in IT-Wallet, EUDIW and National Trust Framework, and the Onboarding System makes the registered Entities able to operate on both of them.

The National Trust Framework is the registration layer for all the Entities of the ecosystem and provides the mechanisms that the components of the Onboarding System use to authenticate each other.

The data structures of the registries are defined in Registry Infrastructure. The profiles of the Trust Artifacts are defined in Infrastructure of Trust. The technical mechanisms that publish the status of a certificate are defined in Revocation Mechanisms. The way the artifacts are consumed at runtime is defined in Trust Evaluation Process.

The section is organized in five parts. The Overview gives the actors, the components and the way the two Trust Frameworks are used. The Registration Model gives the static view, that is what each role provides and what it obtains. The Onboarding Processes give the dynamic view, that is how each procedure is carried out. The Notification and Publication provides the procedure that brings the notified categories into the Lists of Trusted Entities, of which the Onboarding System handles the collection of the data. The Lifecycle Management gives the states, the events and their effects on the registries and on the Trust Artifacts.

8.1. Overview

This Section introduces the actors that take part in onboarding, the components and services of the Onboarding System that realize them, and the way the two Trust Frameworks combine. It gives the reader the context needed to follow the registration model, the processes and the lifecycle described in the Sections that follow.

8.1.1. System Actors and Roles

Two families of actors take part in onboarding, the entities that are onboarded, and the trust-infrastructure entities that operate the onboarding itself. The trust-infrastructure roles are realized by the components and services of the Onboarding System, described in the next subsection.

8.1.1.1. System Actors and Roles: Entities being onboarded

• Authentic Sources: onboard to make their data available to the Credential Issuers, so that the data can be included in the Attestations.

• Wallet-Relying Parties: onboard to be authorized to rely on the Wallet Units and to obtain the Trust Artifacts they need to operate. They are further split into the following roles.

  • Credential Issuers, which onboard to be authorized to issue the Credential types they declare.

  • Relying Parties and Relying Party Intermediaries, which onboard to be authorized to request User attributes from the Wallet Units.

• Wallet Providers: onboard to have their Wallet Solution recognized in the ecosystem and to be notified.

8.1.1.2. System Actors and Roles: Trust-infrastructure entities

• Supervisory Body: during the onboarding the Supervisory Body verifies the eligibility and the compliance of the entities. The Supervisory Body avails itself of the Registrar for technical registration. The Supervisory Body acts as the National single point of contact for the notification to the European Commission.

• Registrar and Register: the Registrar performs the technical registration of the Wallet-Relying Parties and writes their records into the Register as defined by [CIR2025/848].

• Provider of WRPAC and Provider of WRPRC: issue, respectively, the WRPAC and the WRPRC. The WRPAC profile is defined in Wallet-Relying Party Access Certificate (WRPAC) Profile. Automatic issuance of the WRPRC is defined in Wallet-Relying Party Registration Certificate Issuance.

• National Federation Authorities: the Federation Trust Anchor and its Federation Intermediates, which register Federation Entities and apply the metadata policies. Each Federation Authority issues the X.509 certificates and the Trust Marks for the Federation Entities it registers, while the registration Trust Mark is issued only by the Federation Trust Anchor, as described in Trust Mark registration-entity. In IT-Wallet the National Trust Anchor also operates the root Certification Authority of the National X.509 signing PKI, whose root certificate and its distribution are described in PKI Architecture.

8.1.1.3. System Actors and Roles: Entities that interact with the Onboarding System without being onboarded

• Attestation Scheme Providers: they own the Attestation Rulebook of a Credential type. They request the registration of the corresponding versioned entry in the Digital Credentials Catalog. They provide the definition and the schema taken from the Rulebook, see Credential Type Registration. An Attestation Scheme Provider is not registered as an Entity for this role. Within IT-Wallet the role is held by an organization that owns the Rulebook.

Note

A single organization may perform several of these functions at once.

Wallet Instances are not Federation Entities and are not onboarded directly. A Wallet Instance is registered indirectly, through its Wallet Provider, see Wallet Instance Initialization and Registration, and it is deemed reliable through a Wallet Instance Attestation issued and signed by that Wallet Provider, see Wallet Instance Attestation Issuance.

The notification of a notified entity is a Member State process defined by [CIR2024/2980], described in Notification and Publication.

8.1.2. System Components and Services

The trust-infrastructure roles are realized, within the Onboarding System, by a set of components, each providing one or more services. An onboarding entity interacts with the system through a single entry point, the Onboarding UI. The Onboarding UI orchestrates the flow and routes each request to the responsible component. The Onboarding UI is therefore not shown as a separate component in the diagram below.

The table below lists the components, the services each of them provides, and the onboarding process that each service realizes.

Table 8.1 Components, Services and Processes

Component	Services	Realized process
National Federation Management	Federation registration, issuance of Trust Marks, publication of the signed registries	Entity Registration, Entity Update, Entity Suspension and Removal, Registration Trust Mark Issuance
EUDIW Registration Management	Verification and registration of the Wallet-Relying Parties in the Register	Entity Registration, Entity Update, Entity Suspension and Removal
Certificate Management	Issuance and update of WRPAC, WRPRC, Sign/Seal and National Authentication certificates	Certificate and Trust Artifact Issuance, Entity Update
Notification Dataset Management	Collection and maintenance, in the notification dataset, of the information subject to notification	Entity Registration, Entity Update, Entity Suspension and Removal
Authentic Source Management	Registration, update and removal of the Authentic Sources in the AS Registry	Authentic Source Registration, Authentic Source Update, Authentic Source Removal
Claims and Schema Management	Registration of the claims and provisioning of the schemas	Claim Registration, Schema Provisioning
Catalog Management	Registration, activation and versioning of the Credential types in the Digital Credentials Catalog	Credential Type Registration, Credential Type Activation and Deactivation, Credential Type Update

The components write to the National registries and data stores described in Registry Infrastructure, which are grouped by purpose as in Registries and Catalogues of the Ecosystem.

Two data stores are kept separate on purpose. The Register holds the Wallet-Relying Party registration records defined by [CIR2025/848] and drives the issuance of the certificates. The notification dataset holds the notifiable information defined by [CIR2024/2980]. They overlap only in the identification data, so the split keeps the registration distinct from the notification.

The diagram below groups the components by responsibility and shows the data stores they interact with. A component can realize processes of more than one family. The groups of the diagram do not coincide with the families of Onboarding Processes. The correspondence is the one given by the table above. The Authentic Sources register only in the AS Registry, without a Register record and without Trust Artifacts, since they are neither Wallet-Relying Parties nor Federation Entities. The Credential Issuers, instead, register as Entities and also declare the Credential types they issue, and they are added to the issuers of the types they declare in the Digital Credentials Catalog.

Fig. 8.1 IT-Wallet Onboarding System.

8.2. Registration Model

This section provides the static view of the registration with the aim of defining the information each entity has to provide, which conditions it has to meet and which artifacts and registry entries it obtains. It is organized as a common part and a profile for each role.

8.2.1. Registration Data Model

This section defines the complete set of the data the entities provide to the Onboarding System, together with the data that defines a Credential type, with its semantics and, where applicable, its normative reference. The data is identified by a format-agnostic Data Identifier.

The following tables provide:

• Base registration data provided by every entity, whatever its role.

• Extended registration data provided by an entity depending on its role, where each Registration Profiles instance specifies which extended data the role provides and how the entity populates it.

• Credential type definition data that describes a Credential type.

Depending on the role, the registration data is then encoded in a different data model. For a Wallet-Relying Party the data model is the WalletRelyingParty schema of the Register (Register of WRPs). For an Authentic Source the data model is the entry of the AS Registry (Authentic Source Registry). For a notifiable Entity the data model is the notification dataset. The Credential type definition data is encoded in the versioned entry of the Digital Credentials Catalog (Digital Credentials Catalog). The mapping to the destination data models is given in Mapping to the Registry Data Models.

Table 8.2 Base Registration Data

Data Identifier	Description	Normative reference
legal_name	The name of the organization as it appears in the official records.	[CIR2025/848], Annex I
identifier	One or more official identifiers of the organization. Within IT-Wallet the Value Added Tax Identification Number (VATIN) is REQUIRED for every entity, and a public body additionally MUST provide its national identifier of type NTR, valued with its IPA code, that is the code of the Italian Index of Public Administrations. An organization that has a European Unique Identifier (EUID) MUST provide it. The other identifier types of Table 2, such as Legal Entity Identifier (LEI), are OPTIONAL and are not supported in the current version. For more details refer to the syntax of the organizationIdentifier defined in clause 5.1.4 of [ETSI EN 319 412-1].	[ETSI TS 119 475], Table 2
legal_nature	Whether the entity is a public sector body or a private entity.	[CIR2025/848], Annex I
contact_information	The postal address, the information web page and the contacts of the organization. The contacts include at least an institutional contact for the administrative communications, for which a certified electronic mail address (PEC) is RECOMMENDED, and a technical contact for the user support of the service.	[CIR2025/848], Annex I
service_policies	The terms and conditions and the privacy policy of the service, each published at its own URL.	[CIR2025/848], Annex I
data_protection_authority	The authority contact email competent for the supervision of the entity under the data-protection law. It MUST be provided for each intended use of the Wallet-Relying Party.	[CIR2025/848], Annex I, in compliance with Regulation (EU) 2016/679.

The extended registration data is provided in the table below. A given entity provides only the subset that applies to its role, as defined in the corresponding profile in Registration Profiles.

Table 8.3 Extended Registration Data

Data Identifier	Description	Normative reference
entitlements	The entitlements the entity requests, which state the roles it intends to play in the ecosystem.	[ETSI TS 119 475], Annex A.2
service_description	The trade name and the localized description of each Relying Party Service the entity offers to Wallet Units. In the EUDIW Trust Framework this data is provided per Service, see relying_party_services. How that trade name is carried in more than one WRPAC or WRPRC is deferred as specified in Register of WRPs.	[CIR2025/848], Annex I; [EIDAS-ARF] Reg_34
intended_use	The attributes a Relying Party intends to request from the Wallet Units, registered on its Relying Party Services, see relying_party_services. A separate WRPRC for each combination of intended use and Service is deferred as specified in Register of WRPs.	[CIR2025/848], Annex I
relying_party_services	The Relying Party Services registered by the entity, as WalletRelyingPartyService objects of EUDI-TS 5. serviceIdentifier is not required. The WRPRC is issued automatically as defined in Wallet-Relying Party Registration Certificate Issuance.	[CIR2026/1730]; EUDI-TS 5, WalletRelyingPartyService; Register of WRPs
provided_attestations	The Attestation types a Credential Issuer intends to issue. Within IT-Wallet each of them references a versioned entry already present in the Digital Credentials Catalog, and the declaration adds the Credential Issuer to the issuers field of that entry, together with the issuance capabilities offered for that Credential type (the supported issuance flows, the parameters of the deferred issuance and the documentation of the issuance service), see Digital Credentials Catalog.	[CIR2025/848], Annex I
intermediary_relationship	Bound to a Relying Party Service. For an intermediated Relying Party Service, the reference to the Intermediary Service it uses (usesIntermediaries). For a Relying Party Intermediary Service, the declaration that it acts as an intermediary (isIntermediary) and the Service identifiers it serves (servedWRPServices, [CIR2026/1730], Annex I). A pure Intermediary Service MUST NOT register an entitlement (EUDI-TS 5).	[ETSI TS 119 475], Table 10; [EIDAS-ARF] RPRC_04; EUDI-TS 5
trust_framework_scope	The declaration of the Trust Framework in which the entity intends to operate, according to Infrastructure of Trust and Trust Framework Selection. The declaration is provided by the roles for which this choice is not already fixed by the notification, and it determines the Trust Artifacts the entity obtains and the way the other Data Identifiers of the profile are provided. It applies to the entity, while trustedAuthorities of a Credential type applies to the validation of an Attestation of that type.	This specification
federation_entity_identifier	The identifier of the Federation Entity in the National Trust Framework, that is the iss and sub of its Entity Configuration.	OID-FED, Section 3
federation_entity_key	The public key with which the Federation Entity signs its Entity Configuration. It MUST be provided in JWK format. The rest of the federation configuration is published in the Entity Configuration reachable at the .well-known/openid-federation endpoint.	OID-FED, Section 3
certificate_signing_requests	An array of Certificate Signing Requests in PKCS #10 format, one for each X.509 certificate the entity needs to obtain, that is, depending on the role, the WRPAC, the Sign/Seal Certificate or the National Authentication Certificate. A Wallet-Relying Party operating in the EUDIW Trust Framework provides one WRPAC Certificate Signing Request. One WRPAC Certificate Signing Request for each registered Service, and one for each intermediated Relying Party Service, are deferred as specified in Register of WRPs. Each request carries the public key to be certified. It MUST be distinct from the Federation Entity Key. Their profile is defined in Certificate Signing Request Profile and they are the input of the Certificate and Trust Artifact Issuance, where they are presented in the ACME order.	RFC 2986
provided_claims_purposes	The claims composing an Attestation, selected from the Claims Registry, and the purposes it uses, selected from the Taxonomy, together with the data-provision capabilities. It groups the data_capabilities of the AS Registry entry, see Authentic Source Registry.	This specification
visual_identity	The visual assets of an Authentic Source, that is the logo of the organization and the logo and the background color associated with a provided dataset, each with its integrity digest and its alternative text.	This specification
conformity_assessment	The outcome of the conformity assessment of the entity, such as the Conformity Assessment Report or the assessments performed under the National certification scheme operated by the Italian National Cybersecurity Agency (ACN) and the functional testing under the EU functional conformity assessment framework (FCAF). It MUST be provided by the notified categories.	[EIDAS-ARF], Annex 2
service_supply_point	The URL at which a Wallet Unit starts the process of requesting and obtaining an Attestation from the Issuer. It MUST be provided by the notified categories that issue an Attestation requested by the Wallet Unit.	[EIDAS-ARF], Annex 2
signing_trust_anchor	The trust anchor supporting the validation of the Attestations the entity issues, that is the public key and the name. It MUST be provided as an input only by the categories whose Sign/Seal Certificate is not issued by the National Root Certification Authority, see PKI Architecture. For the other categories the trust anchor derives from the Sign/Seal Certificate issued through the Certificate Signing Requests.	[EIDAS-ARF], Annex 2
verification_endpoint	The cross-border verification interface exposed to Qualified Trust Service Providers for the Annex VI attributes exported to the EUDIW Catalogue of Attributes, conformant to ETSI TS 119 478 and declared in the data_capabilities of the entry of the Authentic Source Registry, see Authentic Source Registry. It is provided by the Authentic Source.	[EUDI-TS 11], Section 2.1

The data below defines a Credential type and not an entity. For this reason it is not registration data, it does not follow a profile of Registration Profiles, and it is the input of the Credential Type Registration. It is provided by the Attestation Scheme Provider, which owns the Attestation Rulebook of the Credential type, and it is taken from the Rulebook itself. The same criterion applies to the definition of a claim, registered through the Claim Registration.

Table 8.4 Credential Type Definition Data

Data Identifier	Description	Normative reference
credential_type_declaration	The Credential type, anchored to its Rulebook. It creates the versioned entry of the Digital Credentials Catalog and it groups the Digital Credential Metadata of the type (the unique identifier and the version, the human-readable name, the classification by domains and classes, the User authentication methods and the minimum Level of Assurance), together with the reference to the Authentic Sources, or to the parent Credential types, that provide its data, see Digital Credentials Catalog.	[CIR2025/848], Annex I
credential_technical_specification	Technical definition of a Credential type, that groups the Technical Specification fields of the Digital Credentials Catalog, that is the Credential schemes, the Credential formats and the authentication policy, see Digital Credentials Catalog.	[CIR2025/848], Annex I
credential_policies	Conditions of use of a Credential type, that group the Terms of Use fields of the Digital Credentials Catalog, that is the Credential validity, the restriction policy, the pricing policy and the Credential purposes, see Digital Credentials Catalog.	[CIR2025/848], Annex I
trustedAuthorities	The trusted authorities that define the trust framework of the Credential type in the Digital Credentials Catalog, that is the trust anchors a verifier relies on to validate the Attestation, see Digital Credentials Catalog.	[EUDI-TS 11], Section 4.3
rulebookURI	The URI of the human-readable Attestation Rulebook that defines the non-machine-readable aspects of the Credential type in the Digital Credentials Catalog, see Digital Credentials Catalog.	[EUDI-TS 11], Section 4.3
bindingType	The type of cryptographic key binding required for the issuance of the Credential type in the Digital Credentials Catalog, one of claim, key, biometric or none, see Digital Credentials Catalog.	[EUDI-TS 11], Section 4.3
attestationLoS	The attestation Level of Security of the Credential type in the Digital Credentials Catalog, that is the attack potential resistance required for user authentication and key storage, see Digital Credentials Catalog.	[EUDI-TS 11], Section 4.3

Note

The provided_attestations remains part of the registration data of a Credential Issuer, because it is the declaration of the Credential types the Credential Issuer intends to issue and not the definition of those types. The two are distinct: the definition creates the versioned entry, the declaration adds the Credential Issuer to its issuers field.

8.2.2. Mapping to the Registry Data Models

The Onboarding System collects the registration data and the Credential type definition data, and they are then encoded in the data model of the destination, that for the registration data depends on the role. The table below maps each Data Identifier to the fields of the destination data models, for the Data Identifiers whose mapping is not one-to-one with a single field.

Table 8.5 Mapping of the Data Identifiers to the destination data models

Data Identifier	Destination fields
legal_name	In the Register, the legalName of the legalPerson. In the AS Registry, the organization_name_l10n_id. In the registration Trust Mark, the organization_name. In the Digital Credentials Catalog, the organization_name_l10n_id of the issuers element of the Credential Issuer.
identifier	In the Register, the identifier array, each element carrying its type and its value. In the registration Trust Mark, the vat_number for a private entity, the ipa_code for a public body and the legal_identifier. In the Digital Credentials Catalog, the organization_code of the issuers element of the Credential Issuer.
legal_nature	In the Register, the isPSB flag. In the AS Registry, the organization_type. In the registration Trust Mark, the public_body.
contact_information	In the Register: postalAddress, email, phone, infoURI, supportURI. In the AS Registry: contacts, homepage_uri. In the registration Trust Mark, the email and the support_uri. In the Entity Configuration, the contacts and the organization_uri of the federation_entity metadata. In the Digital Credentials Catalog, the contacts and the homepage_uri of the issuers element of the Credential Issuer.
service_policies	In the Register, the policyURI of each element of the policy array, distinguished by its type. In the registration Trust Mark, the privacy_policy. In the Entity Configuration, the policy_uri and the tos_uri of the federation_entity metadata. In the Digital Credentials Catalog, the policy_uri and the tos_uri of the issuers element of the Credential Issuer.
data_protection_authority	In the Register, the supervisoryAuthority. In the AS Registry, the dpa_contact. In the registration Trust Mark, the supervisory_authority.
entitlements	In the Register, the entitlements array of each services[] element. In the registration Trust Mark, the entitlements. In the Digital Credentials Catalog, the legal_type of the issuers element of the Credential Issuer.
service_description	In the Register, the entity-level tradeName where present, and per Service the serviceTradeName and the srvDescription of each services[] element. In the registration Trust Mark, the srv_description. Binding subject.commonName and the WRPRC name to one Service is deferred as specified in Register of WRPs.
relying_party_services	In the Register, the services array of WalletRelyingPartyService objects, each carrying the members defined in EUDI-TS 5, including serviceTradeName, srvDescription, intendedUses, entitlements, providesAttestations, isIntermediary, usesIntermediaries and servedWRPServices. serviceIdentifier remains optional. The Service identifier in the WRPAC and the WRPRC srv_id are deferred as specified in Register of WRPs.
intended_use	In the Register, the intendedUses array of the corresponding services[] element, each element carrying its intendedUseIdentifier, purpose, privacyPolicy and credentials. In the registration Trust Mark, the credentials and the purpose.
provided_attestations	In the Register, the providesAttestations array of the corresponding services[] element, each ProvidedAttestation carrying format and type as defined in EUDI-TS 5. In the registration Trust Mark, the provides_attestations. In the Digital Credentials Catalog, the element of the issuers array of each declared Credential type, including its issuance_flows and its service_documentation_uri.
provided_claims_purposes	In the AS Registry, the data_capabilities, that is available_claims, intended_purposes, integration_method, integration_endpoint, api_specification, data_provision, update_frequency, service_documentation_uri.
visual_identity	In the AS Registry the logo_uri of the organization_info, background_color of the data_capabilities, each with its integrity digest and its alternative text.
credential_type_declaration	In the Digital Credentials Catalog: credential_type, version, credential_name_l10n_id, domains, classes, authentication, and the authentic_sources, or the parent_credentials, that provide the data of the Credential type.
credential_technical_specification	In the Digital Credentials Catalog, schemaId. The formats and the schema documents are the supportedFormats and schemaURIs of the SchemaMeta identified by that schemaId.
credential_policies	In the Digital Credentials Catalog: validity_info, restriction_policy, pricing_policy, purposes, legal_type.
conformity_assessment	In the notification dataset, the conformity assessment report.
service_supply_point	In the notification dataset, the service supply point.
signing_trust_anchor	In the notification dataset, the trust anchor.

Some information are present both in the registered data and in the self-signed Entity Configuration of the Entity. The registered value is authoritative. The Registrar asserts it in the Register and the Federation Trust Anchor asserts it in the registration Trust Mark. The informational parameters of the federation_entity metadata are published under the responsibility of the Entity. Where the Onboarding System requires a value that the Entity also publishes in its Entity Configuration, the Onboarding System MUST read the Entity Configuration. The Onboarding System MUST verify the match. A mismatch MUST block the registration. After the registration, a mismatch MUST be solved through an Entity Update. Within IT-Wallet the metadata_policy of the Subordinate Statement fixes the organization_name of the federation_entity metadata to the registered value. The name shown to the User cannot diverge from the one carried by the WRPAC and by the WRPRC. The other informational parameters are not fixed.

8.2.3. Eligibility and Compliance Preconditions

Before any technical registration, the eligibility and the compliance of an entity MUST be verified by the Supervisory Body. The Supervisory Body relies on the Registrar for the entities the Registrar registers. For the notified categories, the Supervisory Body acts as the National point of contact toward the European Commission. Where a National and an EUDIW obligation overlap, the EUDIW obligation is authoritative.

The verification applies to Authentic Sources, Wallet Providers and Wallet-Relying Parties, and its content depends on the role.

• Authentic Sources: the Supervisory Body validates the legal standing and the data authority of the organization and classifies it as public or private. The trust of an Authentic Source is governed by the PDND framework and it is out of EUDIW and National Trust Frameworks.

• Wallet Providers: the eligibility is established and the conformity assessment of the Wallet Solution is driven. The assessment covers the security of the wallet architecture, its data-protection mechanisms and its user-privacy features, and it is the precondition for the Wallet Solution to be certified. The certification of the Wallet Solution is an external process, and this phase uses its outcome as an input. The certification follows the National certification scheme operated by the Italian National Cybersecurity Agency (ACN), and the functional testing follows the EU functional conformity assessment framework (FCAF).

• PID Providers: validated per National designation as providers of Person Identification Data. PID Providers are subject to the National certification scheme operated by the Italian National Cybersecurity Agency (ACN). PID Providers are subject to the functional testing under the EU functional conformity assessment framework (FCAF).

• QEAA Providers: validated through the qualification and the supervision of the issuing Qualified Trust Service Provider.

• PuB-EAA Providers: validated through the conformity assessment required by Article 45f of the eIDAS2 Regulation.

• Non-qualified EAA Providers: validated for the eligibility to issue. Their trust anchor is distributed through the National Trust Framework and it is defined in the applicable Attestation Rulebook.

• Relying Parties: the Supervisory Body performs a policy-based authorization, evaluating the organizational type, that is public administration or private entity, the business-sector classification, and the legitimate requirements of the service.

• Relying Party Intermediaries: additionally demonstrate their eligibility to act on behalf of Relying Parties, pursuant to Article 5b(8) of the eIDAS2 Regulation ([EU_2024_1183]).

Note

The Credential Issuer declares the Credential types it intends to issue, each anchored to its Rulebook, and its integration with the relevant Authentic Sources is authorized where needed.

The Supervisory Body also approves the claims, the schemas and the Credential types before they are registered in the registries. That approval is a precondition of the Claim Registration, of the Schema Provisioning and of the Credential Type Registration.

The identity proofing of the Wallet-Relying Parties MUST be carried out by the Registrar according to [ETSI TS 119 461]. The verification of the entitlements MUST follow Annex III of [CIR2025/848]. Within IT-Wallet the identity proofing is applied to every entity that onboards, including the entities that do not operate in the EUDIW Trust Framework, even where it is not strictly required for them.

For the notified entities the certifications are a mandatory input to the onboarding, and in every case the eligibility and compliance verification is a mandatory precondition for the technical registration.

8.2.4. Trust Artifacts Registration Outcomes

A successful registration produces, depending on the role and on the scope of operation, the Trust Artifacts. For the notified categories, the entry in a List of Trusted Entities follows from the Notification and Publication, which is a separate process. The way each artifact is produced is described in Onboarding Processes, and the effects of the later changes in Events, Registries and Trust Artifacts.

The table shows the artifacts that vary by role. The X.509 certificate column groups the X.509 certificates the entity obtains, in particular the WRPAC, the Sign/Seal Certificate and the national Authentication Certificate. The WRPRC is shown on its own. The WRPRC is not an X.509 certificate but a JSON Web Token or a CBOR Web Token.

Table 8.6 Trust Artifacts Registration Outcomes by Entity Type

Entity type	Register record	WRPRC	X.509 certificate	LoTE entry
PID Provider	yes	yes	the WRPAC, and the Sign/Seal Certificate	PID Providers LoTE
QEAA Provider	yes	yes	the WRPAC. The Sign/Seal Certificate is the qualified certificate issued by the QTSP	EUMS TL, referenced in the LOTL
PuB-EAA Provider	yes	yes	the WRPAC. The Sign/Seal Certificate is the qualified certificate issued by the QTSP	PuB-EAA Providers LoTE
Non-qualified EAA Provider	yes only if it issues an Attestation published in a EU Rulebook	yes only if it issues an Attestation published in a EU Rulebook	the WRPAC only if it issues an Attestation published in a EU Rulebook, and the Sign/Seal Certificate	None, trust anchor distribution defined in the applicable Attestation Rulebook
Relying Party	yes, only for RP operating in EUDIW	yes, only for RP operating in EUDIW	the WRPAC if it has a register record, and the Authentication Certificate where the RP has no register record and it operates in the Proximity Flow	None
Relying Party Intermediary	yes	No	the WRPAC	None
Wallet Provider	no	no	the Sign/Seal Certificate	Wallet Providers LoTE

Note

The federation registration is common to every entity and, as a result of it, every entity obtains a Subordinate Statement issued by its Federation Authority, and a registration Trust Mark.

Note

For a Wallet-Relying Party operating in the EUDIW Trust Framework, the WRPAC column is one access certificate and the WRPRC column is one registration certificate, issued automatically as defined in Wallet-Relying Party Registration Certificate Issuance. One WRPAC per registered Service, a separate set of WRPACs per intermediated Relying Party, and one WRPRC per combination of intended use and Service are deferred as specified in Register of WRPs.

Note

An entity operating only at national level obtains no Register record, no WRPAC and no WRPRC. It holds its Entity Statement and its registration Trust Mark from the federation registration, and, where its role requires it, its X.509 certificate, that is the Sign/Seal Certificate for a National Credential Issuer or the Authentication Certificate for a Relying Party operating in the Proximity Flow.

8.2.5. Registration Profiles

This Section describes the registration of each role as a profile. Every profile provides the base registration data defined in Registration Data Model. Each profile below states only the extended registration data the role provides and how the entity populates it, together with any specialization of the base data. An entity can hold more than one entitlement in a single registration record and for more than one role, so the profiles are not mutually exclusive and they compose. For example, an entity can be at the same time a Relying Party and a QEAA Provider. In that case the input of the entity is the union of the two profiles and the outcome of the entity is the union of the two. A Non-Qualified EAA Provider and a Relying Party MUST declare, for each role and for each Credential type, whether that role operates in the EUDIW Trust Framework or only within the national boundary. At runtime the requested Credential selects the Trust Framework, as specified in Trust Framework Selection.

Note

The definition of a Credential type is not part of any registration profile, as described in Registration Data Model. It is provided by the Attestation Scheme Provider, see System Actors and Roles, through the Credential Type Registration.

8.2.5.1. PID Provider

A PID Provider is a Federation Entity that is notified and registered in the EUDIW Trust Framework, and its Sign/Seal trust anchor is published in the PID Providers LoTE. In addition to the base registration data, a PID Provider provides the following extended registration data, as defined in Registration Data Model:

• entitlements.

• service_description.

• relying_party_services.

  • The Services of the PID Provider, as WalletRelyingPartyService objects of EUDI-TS 5. The Service carries provided_attestations for the PID type. serviceIdentifier is not required.

• provided_attestations.

• federation_entity_identifier.

• federation_entity_key.

• certificate_signing_requests.

  • One Certificate Signing Request for the WRPAC, with which the PID Provider authenticates towards the Wallet Units.

  • One Certificate Signing Request for the Sign/Seal Certificate, with which it signs the issued PID.

• conformity_assessment.

• service_supply_point.

8.2.5.2. QEAA Provider

A QEAA Provider is a Federation Entity that issues Qualified Electronic Attestations of Attributes, and its Sign/Seal Certificate is the qualified certificate issued by the Qualified Trust Service Provider it belongs to. The attestations it issues MUST follow QEAA and PuB-EAA Data Model. In addition to the base registration data, a QEAA Provider provides the following extended registration data, as defined in Registration Data Model:

• entitlements.

• service_description.

• relying_party_services.

  • The Services of the QEAA Provider, as WalletRelyingPartyService objects of EUDI-TS 5. The Service carries provided_attestations. serviceIdentifier is not required.

• provided_attestations.

• federation_entity_identifier.

• federation_entity_key.

• certificate_signing_requests.

  • One Certificate Signing Request for the WRPAC, with which the QEAA Provider authenticates towards the Wallet Units.

• conformity_assessment.

• service_supply_point.

• signing_trust_anchor.

  • Provided as an input because the Qualified Certification Authority of the QEAA Provider is not subordinate to the National Root Certification Authority but belongs to the perimeter of a Qualified Trust Service Provider.

8.2.5.3. PuB-EAA Provider

A PuB-EAA Provider is a Federation Entity that is notified and registered in the EUDIW Trust Framework, and its Sign/Seal trust anchor is published in the PuB-EAA Providers LoTE. The attestations it issues MUST follow QEAA and PuB-EAA Data Model. In addition to the base registration data, a PuB-EAA Provider provides the following extended registration data, as defined in Registration Data Model:

• entitlements.

• service_description.

• relying_party_services.

  • The Services of the PuB-EAA Provider, as WalletRelyingPartyService objects of EUDI-TS 5. The Service carries provided_attestations. serviceIdentifier is not required.

• provided_attestations.

• federation_entity_identifier.

• federation_entity_key.

• certificate_signing_requests.

  • One Certificate Signing Request for the WRPAC, with which the PuB-EAA Provider authenticates towards the Wallet Units.

• conformity_assessment.

  • The Conformity Assessment Report issued by a Conformity Assessment Body under Article 45f of [EIDAS].

• service_supply_point.

• signing_trust_anchor.

  • Provided as an input because the Qualified Certification Authority of the PuB-EAA Provider is not subordinate to the National Root Certification Authority but belongs to the perimeter of a Qualified Trust Service Provider.

8.2.5.4. Non-Qualified EAA Provider

In addition to the base registration data, a Non-Qualified EAA Provider provides the following extended registration data, as defined in Registration Data Model:

• entitlements.

• service_description.

• relying_party_services.

  • REQUIRED where the Non-Qualified EAA Provider operates in the EUDIW Trust Framework. The Services of the Provider, as WalletRelyingPartyService objects of EUDI-TS 5. serviceIdentifier is not required.

• provided_attestations.

• federation_entity_identifier.

• federation_entity_key.

• certificate_signing_requests.

  • One Certificate Signing Request for the Sign/Seal Certificate, with which the Non-Qualified EAA Provider signs the issued EAA.

  • A Non-Qualified EAA Provider that operates in the EUDIW Trust Framework additionally provides one Certificate Signing Request for the WRPAC, with which it authenticates towards the Wallet Units.

• service_supply_point.

• trust_framework_scope.

  • A Non-Qualified EAA Provider that operates in the EUDIW Trust Framework obtains the Register record, the WRPAC and the Sign/Seal Certificate. A Non-Qualified EAA Provider that operates only within the national boundary obtains the Sign/Seal Certificate alone. The Wallet Unit authenticates that Provider through the National Trust Framework. The Attestations of that Provider are validated against the trust anchor distributed by the Entity Configuration of the Federation TA. The IT-Wallet ID, the national-scope Electronic Attestation of Person Identification Data, is an example of an Attestation issued by a Non-Qualified EAA Provider that operates within the national boundary, see IT-Wallet ID Data Model and IT-Wallet ID. It is an EAA and MUST NOT be confused with the EUDI Person Identification Data, which is not an EAA.

8.2.5.5. Relying Party

Besides the base registration data, a Relying Party provides the following extended registration data, as defined in Registration Data Model:

• entitlements.

• service_description.

• relying_party_services.

  • REQUIRED where the Relying Party operates in the EUDIW Trust Framework. The Services of the Relying Party, as WalletRelyingPartyService objects of EUDI-TS 5. serviceIdentifier is not required.

• intended_use.

  • Nested in relying_party_services. The Attestation type and optionally the attributes the Relying Party intends to request from the Wallet Units.

• intermediary_relationship.

  • Nested in relying_party_services. In the EUDIW Trust Framework, REQUIRED where the Relying Party Service operates through a RP Intermediary, and in that case it references the Intermediary Service identifier (usesIntermediaries). In the National Trust Framework the Relying Party does not declare the relationship. The relationship with the RP Intermediary is established through the federation. The Relying Party sets its authority_hints to the RP Intermediary that federates the Relying Party. The RP Intermediary side is described in Relying Party Intermediary.

• federation_entity_identifier.

• federation_entity_key.

  • REQUIRED for a Relying Party that operates without an intermediary. A Relying Party operating through a RP Intermediary MUST NOT provide it, because it is registered by its RP Intermediary according to the National Trust Framework.

• certificate_signing_requests.

  • One Certificate Signing Request for each X.509 certificate the Relying Party needs. That request is one WRPAC when the Relying Party operates in the EUDIW Trust Framework. That request is the National Authentication Certificate when the Relying Party operates only in the National Trust Framework and supports the Proximity Flow.

• trust_framework_scope.

  • The artifacts follow the declaration of this role. The Trust Framework of each presentation is selected as specified in Trust Framework Selection.

Note

A Relying Party (intermediated or not) MUST register through the Onboarding System to obtain a registration Trust Mark (see Trust Mark registration-entity), and in case of a Mobile Relying Party Instance, to obtain an Authentication X.509 Certificate. A Relying Party that operates in the EUDIW Trust Framework MUST have a record in the Register of WRP, it MUST obtain its WRPAC, and it MUST receive its WRPRC automatically, as specified in Wallet-Relying Party Registration Certificate Issuance.

8.2.5.6. Relying Party Intermediary

A Relying Party Intermediary declares that it acts as an intermediary in both the National and EUDIW Trust Frameworks. In the National Trust Framework the Relying Party Intermediary is a Federation Intermediate, that is it onboards its intermediated Relying Parties autonomously, publishing their Subordinate Statements, as described in Trust Mark registration-entity. In the EUDIW Trust Framework it is registered with isIntermediary set, and it federates its intermediated Relying Parties that operate in the EUDIW Trust Framework, as declared in their trust_framework_scope. It provides the same Data Identifiers as a Relying Party, with the differences in the table below. The Data Identifiers not listed here are provided as for a Relying Party.

Table 8.7 Relying Party Intermediary Registration Data, differences from the Relying Party

Data Identifier	Value
intended_use	It MUST NOT be provided. A Relying Party Intermediary does not request attributes for itself, but on behalf of the intermediated Relying Parties. In the Register, each of its services[] elements has isIntermediary set to true, omits intendedUses, and lists in servedWRPServices the Service identifiers it serves ([CIR2026/1730], Annex I).
entitlements	It MUST NOT be provided for a pure Intermediary Service (EUDI-TS 5).
relying_party_services	REQUIRED. Each Service is an intermediary Service: isIntermediary is true, and servedWRPServices lists the Relying Party Services it serves. serviceIdentifier is not required.
certificate_signing_requests	One WRPAC Certificate Signing Request. The issued WRPAC authenticates the Intermediary. One WRPAC for each intermediated Relying Party Service is deferred as specified in Register of WRPs.
intermediary_relationship	Set on the intermediary Service, that is the Relying Party declares that the Service is a designated intermediary. It is declared in both the frameworks.
federation_entity_identifier	The Federation Entity Identifier of the Relying Party Intermediary within the National Trust Framework.
federation_entity_key	The Federation Entity Key of the Relying Party Intermediary.

Note

The registration of a Relying Party Intermediary and the registration of its intermediated Relying Parties are linked, the Intermediary declares that it acts as an intermediary, and each intermediated Relying Party references it in its own Relying Party profile.

8.2.5.7. Wallet Provider

A Wallet Provider is a Federation Entity that is notified, but it is not registered in the Register, because it does not act as a Wallet-Relying Party. Its registration data is part of the notification dataset, and its Sign/Seal trust anchor is published in the Wallet Providers LoTE. Besides the base registration data, a Wallet Provider provides the following extended registration data, as defined in Registration Data Model:

• entitlements.

• service_description.

• federation_entity_identifier.

• federation_entity_key.

• certificate_signing_requests.

  • One Certificate Signing Request for the Sign/Seal Certificate, with which the Wallet Provider signs the Wallet Unit Attestations.

• conformity_assessment.

8.2.5.8. Authentic Source

An Authentic Source is out of the EUDIW and the National Trust Frameworks, and its trust is governed by the PDND framework. It is not registered in the Register and it is not a Federation Entity, so it does not provide the federation data and it obtains no Trust Artifact. Its registration data is the entry of the AS Registry. In addition to the base registration data, an Authentic Source provides the following extended registration data, as defined in Registration Data Model:

• provided_claims_purposes.

• visual_identity.

• verification_endpoint.

  • Provided only where the Authentic Source is responsible for an attribute exported to the EUDIW Catalogue of Attributes, so that a Qualified Trust Service Provider of another Member State can reach its verification interface.

8.3. Onboarding Processes

This part gives the dynamic view of the onboarding. Each process is described with its Input, its Outcome and its Process, that is the sequence of steps.

The processes are organized in three families.

• The Entity Onboarding covers the registration of an entity and of an Authentic Source, and their update, suspension and removal.

• The Certificate and Trust Artifact Issuance covers the issuance of the certificates and of the Trust Marks an entity obtains.

• The Attestation Onboarding covers the registration of the claims, of the schemas and of the Credential types, and the lifecycle of the Credential types.

The Sections Process Dependency Map and Notification and Publication below provide respectively the order of the processes and the dependencies between them, and the notification process of the entities that are subject to it.

8.3.1. Process Dependency Map

This section maps every onboarding process against four relations:

• Preconditions are the conditions that MUST hold before the process can run. They include the completion of another process and the conditions that are external to the Onboarding System, such as the certification of a Wallet Solution or the qualified status of a Qualified Trust Service Provider.

• Started by is who or what starts the process. A process is started by an external party that requests it, or it is invoked by another process, or it has no explicit request and it is a re-evaluation of conditions.

• Activates are the processes that start as a consequence of this one.

• Enables are the capabilities that become possible afterwards, which are not processes of the Onboarding System.

The processes are carried out by the components described in System Components and Services, and one table is given for each family of Onboarding Processes.

Table 8.8 Process Map of the Entity Onboarding Processes

Process	Preconditions	Started by	Activates	Enables
Entity Registration	Eligibility and compliance verification, including the identity proofing and the verification of the entitlements	The Entity, which requests the registration	Registration Trust Mark Issuance; Credential Type Activation and Deactivation, if it completes a versioned entry	The request, by the Entity, of the WRPAC if EUDIW Trust Framework, of the Sign/Seal Certificate if National PKI, and of the National Authentication Certificate if Proximity Flow; the Notification and Publication of the Entity, if notified category, for which the Onboarding System maintains the notifiable information
Entity Update	Entity Registration	The Entity, which submits a change of one or more categories of its registration data	Registration Trust Mark Issuance, where the change affects the data it carries; Wallet-Relying Party Registration Certificate Issuance, where the change affects the registration data	The request, by the Entity, of the re-issuance of the X.509 certificates that carry the changed data; the automated revocation and re-issuance of the WRPRC by its Provider; the re-verification of the eligibility where the change affects the Authorization Information; and the Notification and Publication of the change, if notified category
Entity Suspension and Removal	Entity Registration	The competent authority or the Entity, which requests a suspension, a reactivation or a cancellation	Credential Type Activation and Deactivation, if Credential Issuer	The Notification and Publication of the new status of the Entity, if notified category
Authentic Source Registration	Eligibility and compliance verification by the Supervisory Body; the subscription of the Authentic Source to PDND and the publication of its e-Service	The Authentic Source, which declares its registration data	Claim Registration, if a claim is missing	The registration of the Credential types that reference the Authentic Source as their data source
Authentic Source Update	Authentic Source Registration	The Authentic Source, or the notification through PDND of the change of an e-Service	Credential Type Activation and Deactivation, if a type loses its data source	—
Authentic Source Removal	Authentic Source Registration	A request of removal	Credential Type Activation and Deactivation, if a type loses its data source	—

Table 8.9 Process Map of the Certificate and Trust Artifact Issuance Processes

Process	Preconditions	Started by	Activates	Enables
Wallet-Relying Party Access Certificate Issuance	Entity Registration, with a record of the Entity in the Register, if EUDIW Trust Framework	The Entity, with an ACME order, for the first issuance or for a re-issuance	Wallet-Relying Party Registration Certificate Issuance	The authentication of the Entity towards the Wallet Units
Wallet-Relying Party Registration Certificate Issuance	Entity Registration, with a record with a valid registration status in the Register and a valid WRPAC, if EUDIW Trust Framework	The Provider of WRPRC, invoked without a request from the Entity when a valid WRPAC exists or when the Register record changes	—	The presentation of the registration data of the Entity to the Wallet Units
Signature and Seal Certificate Issuance	Entity Registration, if National PKI. For a QEAA Provider and a PuB-EAA Provider the certificate is qualified and it is issued by a Qualified Trust Service Provider outside this process	The Entity, with an ACME order, for the first issuance or for a re-issuance	—	The signature or the seal of the Attestations the Entity issues
National Authentication Certificate Issuance	Entity Registration, if Proximity Flow	The Entity, with an ACME order, for the first issuance or for a re-issuance	—	The authentication of the Entity in the Proximity Flow
Registration Trust Mark Issuance	The completion of the federation registration of the Entity	Invoked by the Entity Registration, and by the Entity Update where the change affects the data the Trust Mark carries	—	The recognition of the Entity as a registered participant of the National Trust Framework, and the reading of its authorization data where it has no record in the Register

Table 8.10 Process Map of the Attestation Onboarding Processes

Process	Preconditions	Started by	Activates	Enables
Claim Registration	—	Invoked by the Authentic Source Registration, by the Schema Provisioning or by the Credential Type Registration, if a claim is missing	—	The Schema Provisioning and the Credential Type Registration that use the claim
Schema Provisioning	The claims that compose the schema are available in the Claims Registry	Invoked by the Credential Type Registration, if the schema is missing	Claim Registration, if a claim is missing	The activation of a Credential type, as one of its conditions
Credential Type Registration	The definition and the availability of the applicable Attestation Rulebook; the Authentic Source Registration, or a parent Credential type, as the data source	The Attestation Scheme Provider, which requests the registration	Claim Registration, if a claim is missing; Schema Provisioning, if the schema is missing; Credential Type Activation and Deactivation	The declaration of the Credential type by a Credential Issuer at its Entity Registration
Credential Type Activation and Deactivation	Credential Type Registration	No explicit request. The versioned entry is re-evaluated whenever one of its three conditions changes	—	The issuance of the Credential type by the Credential Issuers listed in the versioned entry
Credential Type Update	Credential Type Registration	The Attestation Scheme Provider, which publishes a new version	Credential Type Registration for the new versioned entry; Credential Type Activation and Deactivation	—

The processes that act on the lifecycle of an entity or of a Credential type are governed as described in Lifecycle Management, and the effects of each event on the registries and on the Trust Artifacts are given in Events, Registries and Trust Artifacts.

8.3.2. Entity Onboarding

This section describes the processes that manage the lifecycle of the entities and of the Authentic Sources. Each process is described with its Input, its Outcome and its Process, while the governance of the corresponding events, that is who is entitled to decide and within which conditions, is given in Registration Events and Their Governance.

8.3.2.1. Entity Registration

Entity Registration process takes as input the registration data of an Entity. The process verifies the registration data, records it, and registers the Entity in the National Trust Framework. Where the role and the declaration of the Entity require it, the process registers the Entity in the EUDIW Register. The process is parameterized by the registration profile of the role, and its outcome is the transition of the Entity to the REGISTERED state. It enables the Certificate and Trust Artifact Issuance processes, that bring the Entity to OPERATIONAL, and, for a Credential Issuer, the Credential Type Registration. The issuance of the certificates and of the registration Trust Mark, and the governance of the states, are described in the referenced processes and in Lifecycle Management.

8.3.2.1.1. Entity Registration: Input

The input is the registration data of the Entity, following the profile of its role defined in Registration Data Model and in Registration Profiles. The data is organized in the three categories of registered data defined in Lifecycle Management, and for each category a part is provided by the Entity and a part is derived by the Onboarding System.

• Identity Information, provided by the Entity:

  • legal_name,

  • identifier,

  • legal_nature,

  • contact_information,

  • service_policies,

  • data_protection_authority.

• Technical Configuration, provided by the Entity, in particular the federation_entity_identifier and the federation_entity_key of its Entity Configuration.

• Authorization Information, provided by the Entity, i.e.:

  • entitlements,

  • relying_party_services,

  • intended_use,

  • provided_attestations for a Credential Issuer,

  • intermediary_relationship where applicable,

  • conformity_assessment for the categories that need it.

The signed record, the certificates and their Trust Anchors are not an input but are derived from the registration. In particular, the certificate_signing_requests are not a direct input of this process but of the Certificate and Trust Artifact Issuance processes. For a PID Provider and a Wallet Provider the signing_trust_anchor derives from the National issuance. For a QEAA Provider and a PuB-EAA Provider the signing_trust_anchor is provided within the eIDAS Trusted Lists. The Entity does not provide the signing_trust_anchor as an input.

The eligibility and the compliance of the Entity are a precondition and not a part of this process, and they are described in Eligibility and Compliance Preconditions.

8.3.2.1.2. Entity Registration: Outcome

The outcome is the Entity in the REGISTERED state, that is the moment in which the registration record exists and has been verified, as defined in Lifecycle Management. The registration is recorded across the two Trust Frameworks according to the role and to the declaration of the Entity.

• In the National Trust Framework the Entity is registered in the federation, and its Subordinate Statement, that carries the registration Trust Mark, is published by the National Federation Management.

• In the EUDIW Trust Framework, for the Wallet-Relying Parties, a signed record is written in the Register, and it drives the later issuance of the WRPAC and the automated issuance of the WRPRC.

The National Trust Framework is always the registration layer, while the EUDIW Trust Framework is added for the notified categories and for the Entities that declare the cross-border operation, as described in Overview. The Register and the notification dataset are kept separate, as described in Trust Artifacts Registration Outcomes.

8.3.2.1.3. Entity Registration: Process

1. The eligibility and the compliance of the Entity MUST have been verified, including the identity proofing and the verification of the entitlements, as described in Eligibility and Compliance Preconditions. This verification is the precondition of the registration.

2. The Onboarding System collects the registration data of the profile, validates it, and routes each part to the component responsible for it.

3. The National Federation Management registers the Entity in the federation. The National Federation Management validates the Entity Configuration published by the Entity, given by the federation_entity_identifier and the federation_entity_key. The National Federation Management prepares the metadata policy that binds the protocol metadata of the Entity to the values approved at onboarding. It then invokes the Registration Trust Mark Issuance to obtain the registration Trust Mark, and it publishes the Subordinate Statement about the Entity, that carries the metadata policy and the Trust Mark. Then, the Entity MUST include the received Trust Mark in its Entity Configuration, that points to its immediate superior through the authority_hints. During the same registration the Federation Trust Anchor public keys are made available to the Entity out-of-band, through the contact channel of the registration. This availability bootstraps the trust of the Entity in the Trust Anchor, see Federation Trust Anchor Distribution and Validation. The structure of the Entity Configuration and of the Subordinate Statement is defined in National Trust Artifacts.

4. Where the role and the declaration of the Entity require the EUDIW Trust Framework, the EUDIW Registration Management verifies the Entity and writes its record in the Register, and the Registrar signs or seals it. The record drives the later issuance of the WRPAC and the automated issuance of the WRPRC, and its data model and its public API are defined in Register of WRPs. For a Credential Issuer, the provided_attestations declared at registration add the Credential Issuer to the issuers field of the versioned entry of each declared Credential type, as described in Credential Type Registration. The same declaration is carried in the record and in the WRPRC.

5. Where the Entity belongs to a category subject to notification, the Notification Dataset Management collects its notifiable information in the notification dataset, as described in Notification and Publication.

6. The registration produces the registration event, that the Federation Authority publishes on the Federation Subordinate Events Endpoint as described in Registration Events and Their Governance. At the end of the process the Entity is REGISTERED. The record enables the Certificate and Trust Artifact Issuance processes that bring the Entity to OPERATIONAL. For a Credential Issuer, the declaration can activate the declared Credential types, as described in Credential Type Activation and Deactivation.

Note

The Register is the National register of the Wallet-Relying Parties that each Member State establishes under Article 3 of [CIR2025/848] and operates through the Registrar. It is distinct from the semantic components of the Registry Infrastructure, that hold the Credential semantics and the discovery data, and it is documented as Register of WRPs.

8.3.2.2. Entity Update

Entity Update process changes the registered information of an Entity, in its Identity Information, its Technical Configuration, including the rotation and the request of keys, and its Authorization Information. The Entity is responsible for the accuracy of its information and updates it without undue delay. This process describes what the Entity submits and which steps the components execute, while the relationship between the categories of registered data and the Trust Artifacts is given in Entity Updates and Their Effects on Trust Artifacts.

8.3.2.2.1. Entity Update: Input

The updated registration data defined in Registration Data Model. For a change of the Identity Information the input is the new legal_name, identifier, legal_nature, contact_information, service_policies or data_protection_authority. For a change of the Technical Configuration related to the new key material, the federation_entity_key and certificate_signing_requests are provided respectively for the federation identity and for the X.509 certificates. For a change of the Authorization Information the input is the new entitlements, relying_party_services, intended_use, provided_attestations or intermediary_relationship, depending on the role.

8.3.2.2.2. Entity Update: Outcome

The updated registered information of the Entity. A change that affects the Authorization Information triggers the re-verification of the eligibility, because a new entitlement is not self-declared, as described in Eligibility and Compliance Preconditions.

8.3.2.2.3. Entity Update: Process

1. The Entity submits the change of one or more categories of its registration data.

2. For a change of the Identity Information or of the Authorization Information, the EUDIW Registration Management updates the record in the Register. The National Federation Management updates the Subordinate Statement and the registration Trust Mark. The Entity requests the re-issuance of the X.509 certificates that carry the changed data, as described in Certificate and Trust Artifact Issuance. The Provider of WRPRC revokes the affected WRPRC. The Provider of WRPRC MUST re-issue the WRPRC automatically where the registration remains valid. Where the Entity belongs to a notified category, the Notification Dataset Management updates the notification, as described in Notification and Publication.

3. For a change of the federation_entity_key, the National Federation Management performs the rotation specified in Federation Entity Key Rotation. The rotation of the keys of the X.509 certificates is a re-issuance. That re-issuance is handled by the Certificate and Trust Artifact Issuance processes. The Entity provides the new certificate_signing_requests in the ACME order.

4. A change of the Authorization Information is subject to the re-verification of the eligibility by the Supervisory Body. For a Credential Issuer, a change of the Credential provision capabilities adds the Credential Issuer to, or removes the Credential Issuer from, the issuers field of the versioned entry of a Credential type, as described in Credential Type Registration.

5. The update produces the corresponding event. A metadata_update covers a change of the Identity Information or the Technical Configuration. A jwks_update covers a key rotation. The event is published on the Federation Subordinate Events Endpoint as described in Registration Events and Their Governance.

Note

The informational parameters of the federation_entity metadata, with the exception of the organization_name, are not included in the metadata_policy and can be managed autonomously by the Entity in its self-signed Entity Configuration. The protocol signature keys (jwks), the service endpoints and the request, response and redirect URIs are instead bound by the metadata_policy of the Subordinate Statement to the values approved at onboarding, as defined in National Trust Artifacts, then a change of them is an Entity Update that re-issues the Subordinate Statement.

Note

A change of the registered identity attributes of an Entity is an Entity Update, including a change of its legal_name, of its legal_nature or of its identifier, where the legal person stays the same. Where the legal person itself changes, such as in a merger or in a demerger, the registration of the previous Entity MUST be cancelled and the new legal person MUST be registered as a new Entity, because the identity proofing is bound to the legal person.

Note

The rotation of a protocol key, the one provided within the protocol metadata, is carried out through the update of the metadata_policy. The rotation of a protocol key MUST follow Federation Entity Key Rotation. The coexistence covers the validity window of those Trust Chains, so that a verifier that still relies on a Trust Chain with the old key can validate until it rebuilds it.

8.3.2.3. Entity Suspension and Removal

Entity Suspension and Removal process suspends, reactivates or cancels the registration of an Entity. The request comes from a Supervisory Body, from the Entity itself, or from another external party entitled to the request as described in Registration Events and Their Governance. The process applies across the two Trust Frameworks. This process describes the steps that the components execute, while who is entitled to trigger each event, on which normative basis and within which conditions, is given in Registration Events and Their Governance.

8.3.2.3.1. Entity Suspension and Removal: Input

The request of suspension, reactivation or cancellation, from the competent authority or from the Entity, with the reason for it.

8.3.2.3.2. Entity Suspension and Removal: Outcome

The Entity changed the status to SUSPENDED on a suspension, returns to its previous state on a reactivation, and moves to CANCELLED on a cancellation, as described in Lifecycle Management. A suspension and a cancellation revoke the Trust Artifacts of the Entity and, for a Credential Issuer, deactivate its Credential types.

8.3.2.3.3. Entity Suspension and Removal: Process

1. The request of suspension, reactivation or cancellation is received from the competent authority or from the Entity.

2. On a suspension, the EUDIW Registration Management suspends the record in the Register where the Entity is a Wallet-Relying Party. The National Federation Management withdraws the valid Subordinate Statement of the Entity. The Trust Artifacts of the Entity are no longer relied upon. The Entity moves to SUSPENDED.

3. On a reactivation, once the condition that caused the suspension is removed, the same party that decided the suspension restores the registration, and the Entity returns to REGISTERED.

4. On a cancellation, the EUDIW Registration Management cancels the record in the Register where the Entity is a Wallet-Relying Party. The National Federation Management withdraws the Subordinate Statement. The Trust Artifacts of the Entity are revoked. The Entity moves to CANCELLED.

5. For a Credential Issuer, a suspension or a cancellation deactivates the Credential types of the Credential Issuer. The Credential Issuer notifies the Authentic Sources. The Authentic Sources can then withdraw the corresponding authorizations within PDND, as described in Authentic Source Lifecycle and PDND Alignment.

6. After a suspension, a reactivation or a cancellation, where the Entity belongs to a notified category, the Notification Dataset Management updates the notification. The status of the Entity in the corresponding List of Trusted Entities is updated accordingly, as described in Notification and Publication.

7. Each event, a suspension or a revocation, is published on the Federation Subordinate Events Endpoint as described in Registration Events and Their Governance.

8.3.2.4. Authentic Source Registration

Authentic Source Registration process writes Authentic Source information into the AS Registry so that Credential Issuers can discover which data is available and through which e-Service. An Authentic Source is neither a Wallet-Relying Party nor a Federation Entity, so it does not go through the federation registration nor the Wallet-Relying Party registration, and it obtains no Trust Artifact. The trust, the authorization and the operational aspects of an Authentic Source are governed by the PDND framework, see e-Service PDND. IT-Wallet does not define a lifecycle of the Authentic Sources. This process does not produce a state transition. It enables the Credential Type Registration, as the data source a Credential type references, and it can activate the Claim Registration when a declared claim is not yet in the Claims Registry.

8.3.2.4.1. Authentic Source Registration: Input

The input is the registration data of the Authentic Source, following its profile in Registration Data Model and in Registration Profiles, that is the base registration data and, in addition, the provided_claims_purposes and the visual_identity. The Authentic Source selects from the Claims Registry the standardized claim identifiers it provides, and from the Taxonomy the purposes it serves. An Authentic Source does not provide the federation data nor the certificate_signing_requests, and it has no entitlements. From this data the Authentic Source Management composes the entry of the Authentic Source in the AS Registry, whose structure is defined in Authentic Source Registry, and it generates the registry-level fields, i.e. the identifier of the registry, its version, its last-modification time and its localization configuration. The eligibility of the Authentic Source, that validates its legal standing and its data authority and classifies it as public or private, is a precondition and is described in Eligibility and Compliance Preconditions.

8.3.2.4.2. Authentic Source Registration: Outcome

An entry in the AS Registry, that makes the Authentic Source discoverable by the Credential Issuers, with its organization information, its declared data capabilities, its integration method and its intended purposes. The registration of the Authentic Source is complete and independent of the integration of any Credential Issuer, because an Authentic Source declares its capabilities before any Credential type exists. The process does not produce a state in IT-Wallet. The trust, the authorization and the operational aspects of the Authentic Source stay within the PDND framework. The effects that the PDND lifecycle produces inside IT-Wallet are described in Authentic Source Lifecycle and PDND Alignment.

8.3.2.4.3. Authentic Source Registration: Process

1. The eligibility and the compliance of the Authentic Source MUST have been verified by the Supervisory Body, as described in Eligibility and Compliance Preconditions. The Supervisory Body validates the legal standing and the data authority of the Authentic Source. The Supervisory Body classifies the Authentic Source as public or private. This verification is the precondition of the registration.

2. The Authentic Source declares its registration data.

3. The declared claims are verified against the Claims Registry and the declared purposes against the Taxonomy. A claim that is not yet in the Claims Registry activates the Claim Registration.

4. The Authentic Source Management writes the entry in the AS Registry, whose structure is defined in Authentic Source Registry. The Authentic Source becomes discoverable by the Credential Issuers.

The entry enables the Credential Type Registration, as the Authentic Source is the data source that a Credential type references.

Note

The integration between an Authentic Source and a Credential Issuer takes place within PDND and is a precondition for the activation of a Credential type, not a process of the Onboarding System. Its effect on the lifecycle of the Credential type is described in Authentic Source Lifecycle and PDND Alignment.

8.3.2.5. Authentic Source Update

Authentic Source Update changes the entry of an Authentic Source in the AS Registry, with the effect on the versioned entries of the Credential types that depend on it. An Authentic Source has no lifecycle in IT-Wallet, so the effect that a change produces on the Credential types is the one described in Authentic Source Lifecycle and PDND Alignment.

8.3.2.5.1. Authentic Source Update: Input

The changed registration data of the Authentic Source, that is a change of its provided_claims_purposes or of its visual_identity, following its profile in Registration Data Model.

8.3.2.5.2. Authentic Source Update: Outcome

The entry of the Authentic Source in the AS Registry is updated. When the change reduces the availability of the data on which a Credential type depends, the condition for the activation of that Credential type is no longer satisfied. The Credential type moves to INACTIVE, as described in Authentic Source Lifecycle and PDND Alignment.

8.3.2.5.3. Authentic Source Update: Process

1. The Authentic Source, or the notification through PDND of the change of an e-Service, submits the change of the entry.

2. The Authentic Source Management updates the entry in the AS Registry, whose structure is defined in Authentic Source Registry.

3. The Credential types that depend on the Authentic Source are updated, and a Credential type that loses the availability of the data it depends on moves to INACTIVE, as described in Authentic Source Lifecycle and PDND Alignment.

8.3.2.6. Authentic Source Removal

Authentic Source Removal process removes the entry of an Authentic Source from the AS Registry, with the deactivation of the versioned entries of the Credential types that depend on it.

8.3.2.6.1. Authentic Source Removal: Input

The request for removal of the Authentic Source.

8.3.2.6.2. Authentic Source Removal: Outcome

The entry of the Authentic Source is removed from the AS Registry. The Credential types that lose the Authentic Source as their data source move to INACTIVE. Those Credential types stay registered so that they can be activated again if the data source is restored, as described in Authentic Source Lifecycle and PDND Alignment.

8.3.2.6.3. Authentic Source Removal: Process

1. The request of removal of the Authentic Source is received.

2. The Authentic Source Management removes the entry from the AS Registry.

3. The Credential types that depend on the Authentic Source lose their data source and move to INACTIVE. Those Credential types stay registered and can be activated again if the integration is restored, as described in Authentic Source Lifecycle and PDND Alignment.

8.3.3. Certificate and Trust Artifact Issuance

This section describes the processes that issue the Trust Artifacts. Each process covers both the first issuance and the re-issuance, for example after a key rotation or a request for additional keys, and it is described with its Input, its Outcome and its Process.

8.3.3.1. Issuance of the X.509 Certificates through ACME and OpenID Federation

The WRPAC, the Signature/Seal Certificate and the National Authentication Certificate are issued through ACME RFC 8555 with the OpenID Federation profile of [ACME-OIDFED].

The Entity authenticates to the Certification Authority with its Federation Trust Chain, through the openid-federation-01 challenge. The authentication reuses the trust evaluation of the National Trust Framework, so the validation of the Trust Chain and the authentication of the Entity follow Trust Chain Validation and Federation Entity Authentication.

Once the Entity is authenticated, the Certification Authority applies its policy. The Certification Authority reads the entitlements and the profile values first from the record of the Entity in the Register, through the Register Open APIs. When the Entity has no record there, the Certification Authority reads them from the registration Trust Mark included in the Resolved Metadata of the Trust Chain. Both sources provide the authorization data with the same logic of [ETSI TS 119 475].

The issuance of these certificates is a process on its own, separate from the registration and performed machine-to-machine. The Entity presents its certificate_signing_requests in the ACME order only after the registration process has been successfully completed.

A distinct ACME service is provided for each purpose, so the type of the certificate is determined by the service, and the profile of each certificate is fixed by its type.

Within IT-Wallet the lifecycle of these certificates is kept separate from the lifecycle of the Trust Chain. A certificate has its own notBefore and notAfter and it is governed by the X.509 revocation. The loss of the federation membership of an Entity is reflected by the revocation of its certificates, see Entity Suspension and Removal. That loss is not reflected by the expiration of the Trust Chain.

The Wallet-Relying Party Registration Certificate and the registration Trust Mark do not certify keys, so they are not issued through ACME. The registration Trust Mark is issued during the registration of the Entity. The Wallet-Relying Party Registration Certificate is issued automatically as defined in Wallet-Relying Party Registration Certificate Issuance.

Fig. 8.2 Issuance of an X.509 certificate through ACME and the OpenID Federation profile.

8.3.3.2. Certificate Signing Request Profile

This section defines the profile that the certificate_signing_requests MUST follow, see Registration Data Model. The Entity provides one Certificate Signing Request for each X.509 certificate it needs. Depending on the role, that certificate is the WRPAC, the Sign/Seal Certificate or the National Authentication Certificate. The Entity presents each Certificate Signing Request in the ACME order of the corresponding service. The Wallet-Relying Party Registration Certificate and the registration Trust Mark do not certify a key, so they are not requested through a Certificate Signing Request, see Wallet-Relying Party Registration Certificate Issuance and Registration Trust Mark Issuance.

A Certificate Signing Request carries the public key to be certified, proves possession of the corresponding private key, and requests the values of the certificate fields supplied by the Entity. The Certificate Signing Request does not determine the content of the issued certificate. The Certification Authority MUST validate the requested values against the registration data and the applicable certificate profile. The Certification Authority MUST add or determine the issuer-dependent values required by that profile.

The Certificate Signing Request MUST be a CertificationRequest as defined in RFC 2986 (PKCS #10), DER-encoded, and it is carried in the ACME order as required by RFC 8555#section-7.4.

Table 8.11 Certificate Signing Request Fields

Field	Description	Reference
certificationRequestInfo	REQUIRED. It contains the version, subject, public key and attributes of the request.	RFC 2986#section-4.1
version	REQUIRED. It MUST be 0, which denotes a PKCS #10 version 1 request.	RFC 2986#section-4.1
subject	REQUIRED. Its attributes MUST be consistent with the registration data of the Entity and with [ETSI EN 319 412-2] for natural persons or [ETSI EN 319 412-3] for legal persons. The subject is not authoritative, so the Certification Authority MAY replace it with the value derived from the record of the Entity in the Register or, in its absence, from the registration Trust Mark.	RFC 2986#section-4.1, [ETSI EN 319 412-2], [ETSI EN 319 412-3]
subjectPKInfo	REQUIRED. It carries the public key to be certified. The key MUST use one of the public-key algorithms defined in Cryptographic Algorithms. It MUST be distinct from the Federation Entity Key, and a distinct key MUST be used for each requested certificate.	RFC 2986#section-4.1
attributes	REQUIRED. It MUST contain exactly one extensionRequest attribute. Other attributes MAY be included only when supported by the applicable certificate profile.	RFC 2986#section-4.1, RFC 2985#section-5.4.2
extensionRequest	REQUIRED within attributes. It MUST have the object identifier 1.2.840.113549.1.9.14 and a single value of type Extensions. The requested extensions MUST be consistent with the applicable certificate profile and the authoritative registration data.	RFC 2985#section-5.4.2
signatureAlgorithm	REQUIRED. It MUST be compatible with the private key corresponding to subjectPKInfo and it MUST be one of the signature algorithms defined in Cryptographic Algorithms.	RFC 2986#section-4.2
signature	REQUIRED. The request MUST be signed with the private key corresponding to subjectPKInfo, which proves possession of that key.	RFC 2986#section-4.2

The following table defines the extension values requested by the Entity and the extension values determined by the Certification Authority. The criticality of each requested extension MUST follow the applicable certificate profile.

Table 8.12 Certificate Signing Request Extension Fields

Extension	Description	Reference
extensions	REQUIRED as the value of extensionRequest. It MUST contain the requested extension fields as a DER-encoded Extensions sequence. It MUST include keyUsage and subjectAltName and, when required by the applicable certificate profile, certificatePolicies. Extensions whose values depend on the issuing Certification Authority SHOULD be omitted from the request.	RFC 2985#section-5.4.2, RFC 5280#section-4.2
keyUsage	REQUIRED. It MUST be marked critical and MUST contain exactly one of the key-usage settings permitted by the applicable certificate profile. For a WRPAC, National Authentication Certificate or Registrar Sign/Seal Certificate, it MUST contain one (and only one) of Type A, Type B or Type F. For an Entity Sign/Seal Certificate, it MUST contain one (and only one) of Type A, Type B, Type C or Type F. For a WRPAC, Type A SHOULD be used as per LEG-4.3.1-4 in Clause 4.3.1 [ETSI EN 319 412-3].	RFC 5280#section-4.2.1.3, Wallet-Relying Party Access Certificate (WRPAC) Profile, Registrar Sign/Seal Certificate Profile, Entity Sign/Seal Certificate Profile
subjectAltName	REQUIRED. It MUST be marked non-critical and MUST contain at least one GeneralName permitted by the applicable certificate profile. For a WRPAC or National Authentication Certificate, it MUST contain at least one of the following contact values: a uniformResourceIdentifier for a helpdesk/support website, an otherName with type-id set to 2.5.4.20 (id-at-telephoneNumber), or an rfc822Name for a registration/usage email address.	RFC 5280#section-4.2.1.6, Wallet-Relying Party Access Certificate (WRPAC) Profile

Extensions not applicable to, or not listed in, the applicable certificate profile MUST NOT be included in the issued certificate, regardless of any value requested in the Certificate Signing Request.

Note

The Certificate Signing Request certifies a key that is separate from the Federation Entity Key. The Federation Entity Key is bound to the Entity through the Entity Configuration and the Subordinate Statement, validated through the Federation Trust Chain and not through a certificate chain, see PKI Architecture.

The following is a non-normative example of a Certificate Signing Request for a WRPAC, with test data.

CertificationRequest csr = {
  certificationRequestInfo: {
    version: 0,

    subject: DistinguishedName {
      countryName: "IT",
      organizationName: "Example of Relying Party",
      commonName: "ExampleBank Mobile",                   // serviceTradeName (Reg_34)
      organizationIdentifier: "VATIT-12345678901"
    },

    subjectPKInfo: {
      algorithm: AlgorithmIdentifier {
        oid: "1.2.840.10045.2.1",
        params: "1.2.840.10045.3.1.7"
      },

      subjectPublicKey: "BASE64(SPKI_PUBLIC_KEY_BYTES)"
    },

    attributes: [
      Attribute {
        type: "1.2.840.113549.1.9.14",                    // extensionRequest
        values: [
          Extensions [
            Extension {
              oid: "2.5.29.15",                           // keyUsage
              critical: true,
              value: KeyUsage {
                nonRepudiation: true                       // Type A
                // All other bits set to false
              }
            },

            Extension {
              oid: "2.5.29.32",                           // certificatePolicies
              critical: false,
              value: CertificatePolicies [
                PolicyInformation {
                  policyIdentifier: "0.4.0.194118.1.2",   // NCP-l-eudiwrp
                  policyQualifiers: [
                    CPSuri("https://rpca.example.test/cps")
                  ]
                }
              ]
            },

            Extension {
              oid: "2.5.29.17",                           // subjectAltName
              critical: false,
              value: SubjectAltName [
                GeneralName.uniformResourceIdentifier("https://rp.example.test/support"),
                GeneralName.rfc822Name("support@rp.example.test"),
                GeneralName.otherName(
                  type-id: "2.5.4.20",                    // id-at-telephoneNumber
                  value: "+39100000000"
                )
              ]
            }
          ]
        ]
      }
    ]
  },

  signatureAlgorithm: AlgorithmIdentifier {
    oid: "1.2.840.10045.4.3.2"
  },

  signature: "BASE64(SIGN(subjectPrivateKey, DER(certificationRequestInfo)))"
}

8.3.3.3. Wallet-Relying Party Access Certificate Issuance

Wallet-Relying Party Access Certificate Issuance process issues the WRPAC, defined in the Wallet-Relying Party Access Certificate (WRPAC) Profile, through the mechanism of Issuance of the X.509 Certificates through ACME and OpenID Federation. The WRPAC belongs to the EUDIW Trust Framework. The attributes of the WRPAC MUST always be derived from the Register, as required by clause 5.1.2 of [ETSI TS 119 475]. The fallback to the Trust Mark does not apply to the WRPAC. The Entity obtains one WRPAC. One WRPAC per registered Service, and a separate set of WRPACs for each intermediated Relying Party, are deferred as specified in Register of WRPs.

8.3.3.3.1. Wallet-Relying Party Access Certificate Issuance: Input

The certificate_signing_requests of the Entity for the WRPAC, and the Federation Trust Chain used in the openid-federation-01 challenge. The attributes of the certificate come from the record of the Entity in the Register.

8.3.3.3.2. Wallet-Relying Party Access Certificate Issuance: Outcome

The WRPAC, issued by the WRPAC Certification Authority, that the Entity uses to authenticate towards the Wallet Units.

8.3.3.3.3. Wallet-Relying Party Access Certificate Issuance: Process

1. The Entity requests the WRPAC to the ACME service of the WRPAC Certification Authority, presenting its certificate_signing_requests and authenticating with its Federation Trust Chain, validated as in Federation Entity Authentication.

2. The Certification Authority checks that the Entity has a record in the Register and derives the attributes of the certificate from that record.

3. The Certification Authority issues the WRPAC and the Entity retrieves it.

8.3.3.4. Wallet-Relying Party Registration Certificate Issuance

Wallet-Relying Party Registration Certificate Issuance issues the WRPRC, described in the Wallet-Relying Party Registration Certificate (WRPRC) Profile. The Provider of WRPRC MUST issue one WRPRC automatically and without undue delay, without a request from the Entity. The Provider of WRPRC does so once the Entity has a record with a valid registration status in the Register and a valid WRPAC. This is required by [EIDAS-ARF] RPRC_09 and RPRC_13 and by Annex V, point 3(c) of [CIR2025/848] as amended by [CIR2026/1730]. The Provider of WRPRC monitors the Register, according to [CIR2025/848], revokes the WRPRC when the registration of the Entity changes, and MUST re-issue a new WRPRC automatically where the registration remains valid.

A separate WRPRC for each combination of intended use and Relying Party Service, and a separate WRPRC for each registered Service of a PID or Attestation Provider, are deferred as specified in Register of WRPs. A Relying Party Intermediary that does not declare intended uses does not receive a WRPRC of its own. The Wallet Unit relies on the WRPRC of the intermediated Relying Party.

8.3.3.4.1. Wallet-Relying Party Registration Certificate Issuance: Input

The signed record of the Entity in the Register and its valid WRPAC. The attributes of the certificate come from that record.

8.3.3.4.2. Wallet-Relying Party Registration Certificate Issuance: Outcome

The WRPRC, signed by the Provider of WRPRC with its Sign/Seal Certificate and issued to the Entity, that the Entity presents to the Wallet Units together with its registration data.

8.3.3.4.3. Wallet-Relying Party Registration Certificate Issuance: Process

1. The Provider of WRPRC is invoked without a request from the Entity when a valid WRPAC becomes available, or when the Register record changes after the previous WRPRC has been revoked.

2. The Provider of WRPRC verifies that the Entity has a record with a valid registration status in the Register. The Provider of WRPRC verifies that the information the certificate carries is consistent with that record. The Provider of WRPRC verifies that the WRPAC of the Entity is valid, as required by Annex V, point 3(c) of [CIR2025/848].

3. The Provider of WRPRC builds the WRPRC from the record of the Entity in the Register and signs it with its Sign/Seal Certificate, issued by the WRPRC Sign/Seal Certification Authority.

4. The Provider of WRPRC issues the WRPRC to the Entity.

5. The Provider of WRPRC monitors any change of the Register in an automated manner. The Provider of WRPRC revokes the WRPRC where the registration of the Entity is modified, suspended or cancelled, or where the content of the certificate is no longer consistent with the record, as required by Annex V, point 3(d) of [CIR2025/848]. The revocation is published through the Token Status List (WRPRC Profile). Where the registration remains valid, the Provider of WRPRC MUST re-issue a new WRPRC without undue delay.

8.3.3.5. Signature and Seal Certificate Issuance

Signature and Seal Certificate Issuance covers the certificates issued by the National PKI. Those certificates are the Sign/Seal Certificate of the PID Provider, of the Wallet Provider and of the EAA Provider. Issuance uses the mechanism of Issuance of the X.509 Certificates through ACME and OpenID Federation. The Sign/Seal Certificate of a QEAA Provider and of a PuB-EAA Provider is a qualified certificate issued by a Qualified Trust Service Provider. That certificate is outside the National Root and outside this process. Its qualified status is evaluated in the eligibility, see Eligibility and Compliance Preconditions.

8.3.3.5.1. Signature and Seal Certificate Issuance: Input

The certificate_signing_requests of the Entity for the Sign/Seal Certificate, and the Federation Trust Chain used in the openid-federation-01 challenge. The attributes of the certificate come from the record of the Entity in the Register or, in its absence, from the registration Trust Mark.

8.3.3.5.2. Signature and Seal Certificate Issuance: Outcome

The Sign/Seal Certificate, issued by the Certification Authority of the role of the Entity, that the Entity uses to sign or seal the Attestations it issues.

8.3.3.5.3. Signature and Seal Certificate Issuance: Process

1. The Entity requests the Sign/Seal Certificate to the ACME service of the Certification Authority of its role, presenting its certificate_signing_requests and authenticating with its Federation Trust Chain, validated as in Federation Entity Authentication.

2. The Certification Authority applies its policy, reading the attributes from the record in the Register or, in its absence, from the registration Trust Mark.

3. The Certification Authority issues the Sign/Seal Certificate and the Entity retrieves it.

8.3.3.6. National Authentication Certificate Issuance

National Authentication Certificate Issuance process issues the X.509 certificate that a Relying Party uses to authenticate in the Proximity Flow, through the mdoc reader authentication of [ISO18013-5]. The certificate follows the same profile of the WRPAC, and it is issued by the National Authentication Certification Authority, through the mechanism of Issuance of the X.509 Certificates through ACME and OpenID Federation.

8.3.3.6.1. National Authentication Certificate Issuance: Input

The certificate_signing_requests of the Entity for the National Authentication Certificate, and the Federation Trust Chain used in the openid-federation-01 challenge.

8.3.3.6.2. National Authentication Certificate Issuance: Outcome

The National Authentication Certificate, issued by the National Authentication Certification Authority, that the Entity uses to authenticate in the Proximity Flow.

8.3.3.6.3. National Authentication Certificate Issuance: Process

1. The Entity requests the certificate to the ACME service of the National Authentication Certification Authority, presenting its certificate_signing_requests and authenticating with its Federation Trust Chain, validated as in Federation Entity Authentication.

2. The Certification Authority applies its policy, reading the attributes from the record in the Register or, in its absence, from the registration Trust Mark.

3. The Certification Authority issues the National Authentication Certificate and the Entity retrieves it.

8.3.3.7. Registration Trust Mark Issuance

Registration Trust Mark Issuance issues the registration Trust Mark, defined in Trust Mark registration-entity. The Trust Mark is issued during the registration of the Entity and not through ACME, and it is invoked by the Entity Registration at the completion of the federation registration.

8.3.3.7.1. Registration Trust Mark Issuance: Input

The authorization data of the Entity: its entitlements and, where applicable, the Credentials and the attributes it is authorized to issue or to request, following the logic of [ETSI TS 119 475].

8.3.3.7.2. Registration Trust Mark Issuance: Outcome

The registration Trust Mark, issued by the Federation Trust Anchor and carried in the Subordinate Statement about the Entity. It makes the Entity recognizable as a registered participant of the National Trust Framework, and it is the source of the authorization data when the Entity has no record in the Register.

8.3.3.7.3. Registration Trust Mark Issuance: Process

1. At the completion of the federation registration, the National Federation Management builds the registration Trust Mark with the authorization data of the Entity.

2. The Federation Trust Anchor signs the Trust Mark, which is carried in the Subordinate Statement, as described in Entity Registration.

8.3.4. Attestation Onboarding

This section describes the processes that manage the claims, the schemas and the Credential types. Each process is described with its Input, its Outcome and its Process.

8.3.4.1. Claim Registration

Claim Registration adds a standardized claim definition to the Claims Registry, when a claim that an Authentic Source or a Credential type needs is not yet available. The Claims Registry is maintained by the Supervisory Body and it provides semantic definitions of the Credential attributes, such as their data type, their validation rules and their interoperability mappings. The claim definitions are aligned to the Catalogue of Attributes. This process enables the Schema Provisioning and the Credential Type Registration that use the claim.

8.3.4.1.1. Claim Registration: Input

The input is the definition of the claim to register, following the Claim Entry Parameters of the Claims Registry: the canonical name of the claim, its description, its type (string, boolean, array or object), the format and the encoding used when a string carries a qualified value, the aliases that map the alternative names used in other standards to the canonical claim, and the nested structure of an object or an array claim. The canonical name and the aliases are aligned to the Catalogue of Attributes. A claim is a semantic definition and not an Entity, so the input is not registration data and it does not follow a profile of the Registration Data Model. The registry-level fields, meaning the identifier of the registry, its version, its last-modification time and its localization configuration, are generated by the Claims and Schema Management.

8.3.4.1.2. Claim Registration: Outcome

The outcome is the claim definition in the Claims Registry, which the Authentic Sources, the schemas and the Credential types can reference. A claim is never removed from the Claims Registry, because the Credentials already issued keep referencing it, so a deprecated claim is superseded by a new version, as described in Claims and Schemas Lifecycle.

8.3.4.1.3. Claim Registration: Process

1. An Attestation Scheme Provider, during a Credential Type Registration, or An Authentic Source acting as Attestation Scheme Provider, during its Authentic Source Registration, request a new claim not yet in the Claims Registry.

2. The definition of the claim is established with its canonical name, its type, its format, its aliases and its nested structure, aligned to the Catalogue of Attributes and without conflicts with the claims already registered.

3. The Claims and Schema Management registers the definition in the Claims Registry.

4. The claim becomes available and it enables the Schema Provisioning and the Credential Type Registration that use it.

8.3.4.2. Schema Provisioning

Schema Provisioning makes the schema of a Credential type available in the Schema Registry, either by generating it from the data model for the Credentials defined at national level, or by registering it in alignment with an external Rulebook or standard. The schema is one of the requirements for the activation of a Credential type, so this process is a precondition of the Credential Type Activation and Deactivation.

8.3.4.2.1. Schema Provisioning: Input

The schema of the Credential type is a SchemaMeta registered through the Catalogue of Attestations: its version, the supportedFormats, the format-specific schema document at schemaURIs[].uri, and the rulebookURI. The format-specific document follows Section 4.3.4 of [EUDI-TS 11]. Integrity, when used, is the #integrity suffix of that URI as defined in [W3C-SRI]. The schema is provided by the Attestation Scheme Provider together with the definition of the Credential type, and it is composed of the claims defined in Claims Registry. A claim still missing activates the Claim Registration.

8.3.4.2.2. Schema Provisioning: Outcome

The outcome is the schema in the Schema Registry, for at least one of the supported formats, that the Credential type references. This satisfies the schema requirement of the activation of the Credential type, as described in Credential Type Activation and Deactivation.

8.3.4.2.3. Schema Provisioning: Process

1. The claims that compose the schema are available in the Claims Registry, otherwise the Claim Registration is activated for the missing claim.

2. The schema is generated from the data model for a Credential defined at national level, or it is registered in alignment with the external Rulebook.

3. The Claims and Schema Management registers one SchemaMeta in the Catalogue of Attestations, covering every supported format.

8.3.4.3. Credential Type Registration

Credential Type Registration process creates a versioned entry of a Credential type in the Digital Credentials Catalog, in the INACTIVE state, with its data source and the reference to the applicable Rulebook. The versioned entry is the pair given by the credential_type and the version, which MUST be unique in the catalog. The process is requested by the Attestation Scheme Provider of the Credential type, and it is independent from the registration of the Credential Issuers, which are added to the entry afterwards.

8.3.4.3.1. Credential Type Registration: Input

The definition of the Credential type, provided through the credential_type_declaration, the credential_technical_specification, the credential_policies, the rulebookURI, the bindingType, the attestationLoS and the trustedAuthorities of the Credential type definition data defined in Registration Data Model. It carries the credential_type, the User authentication methods and the minimum Level of Assurance, the reference to the schemes and the formats, the reference to the Rulebook, and the data source, given by one or more authentic_sources or, when another Credential type provides the data, by one or more parent_credentials. The structure of the versioned entry is defined in Digital Credentials Catalog Structure.

The input is provided by the Attestation Scheme Provider, which owns the Attestation Rulebook of the Credential type and takes the values from it, see System Actors and Roles. The definition of the Rulebook is external to the Onboarding System and it is a precondition of this process, as listed in Process Dependency Map, so this process records in a structured form what the Rulebook already defines in a human-readable form.

8.3.4.3.2. Credential Type Registration: Outcome

A versioned entry of the Credential type in the Digital Credentials Catalog, in the INACTIVE state when it has no issuers yet. It enables the Credential Type Activation and Deactivation, the declaration of the Credential type by a Credential Issuer at its Entity Registration and, for the notified categories, the Notification and Publication.

8.3.4.3.3. Credential Type Registration: Process

1. The Attestation Scheme Provider requests the registration of the Credential type and provides its definition taken from the applicable Rulebook, together with the reference to its schema in the Schema Registry and its data source (its authentic_sources or its parent_credentials).

2. The Supervisory Body verifies the request and approves the Credential type, as described in Eligibility and Compliance Preconditions.

3. The Catalog Management creates the versioned entry in the Digital Credentials Catalog in the INACTIVE state, and the Federation Trust Anchor publishes the signed catalog.

4. The versioned entry is activated when the conditions of the Credential Type Activation and Deactivation are satisfied.

The versioned entry therefore exists before any Credential Issuer is listed in it, and this makes the identifier of the Credential type available. A Credential Issuer MUST declare the Credential types it intends to issue at the time of its Entity Registration, and this declaration adds it to the issuers field of the versioned entry.

Note

The issuers field is never provided as an input of this process. Each of its elements derives from the provided_attestations that a Credential Issuer declares in its registration data, so a Credential type is registered independently of the Credential Issuers and it stays registered when they change. The provision of the whole versioned entry is summarized in Digital Credentials Catalog Usage.

8.3.4.4. Credential Type Activation and Deactivation

Credential Type Activation and Deactivation process verifies the conditions for the issuance of a Credential type and changes its versioned entry between the ACTIVE and the INACTIVE states. A Credential type can be issued from a versioned entry only if that entry is ACTIVE, and only one versioned entry of the same credential_type MUST be ACTIVE at a given time.

8.3.4.4.1. Credential Type Activation and Deactivation: Input

The state of the three conditions of the versioned entry, i.e. its issuers, its data source and its schema.

8.3.4.4.2. Credential Type Activation and Deactivation: Outcome

The versioned entry is ACTIVE while all the three conditions are satisfied, and it changes to INACTIVE as soon as one of them stops holding, as defined in Digital Credentials Catalog Structure. The deactivation prevents a new issuance from the versioned entry, but it does not revoke the Credentials already issued from it, which keep their own status, as described in Digital Credential Lifecycle.

8.3.4.4.3. Credential Type Activation and Deactivation: Process

1. The Catalog Management verifies the three conditions of the versioned entry, consulting the corresponding registries.

   • At least one Credential Issuer is listed in the issuers field, and each of them holds the entitlement corresponding to the legal_type of the Credential type.

   • The Authentic Source that provides the data, or the parent Credential type, is registered and available. For an Authentic Source integrated through PDND, the e-Service is published and the enrolment of the Credential Issuer is approved, as described in Authentic Source Lifecycle and PDND Alignment.

   • The schema of the Credential type is registered in the Schema Registry for at least one of the supported formats.

2. The versioned entry becomes ACTIVE when all the three conditions are satisfied, and it returns to INACTIVE as soon as one of them stops holding. The state follows the conditions and it is not an explicit action.

8.3.4.5. Credential Type Update

Credential Type Update publishes a new version of a Credential type, activating the new versioned entry and deactivating the previous one. A Credential type is never modified in place, so a change of its definition becomes a new versioned entry, with a new version.

8.3.4.5.1. Credential Type Update: Input

The updated definition of the Credential type, provided by the Attestation Scheme Provider as for the Credential Type Registration, with a new version.

8.3.4.5.2. Credential Type Update: Outcome

A new versioned entry of the Credential type, activated when its conditions are satisfied, while the versioned entry of the previous version MUST become INACTIVE. The Credentials already issued from the previous version keep their own status and are not revoked by the versioning, and the Credential Issuer can drive their re-issuance, as described in Digital Credential Lifecycle.

8.3.4.5.3. Credential Type Update: Process

1. The Attestation Scheme Provider publishes a new version of the Attestation Rulebook, or the definition of the Credential type changes for another reason.

2. The Catalog Management registers a new versioned entry, with the new version, as in the Credential Type Registration.

3. The new versioned entry is activated when the conditions of the Credential Type Activation and Deactivation are satisfied, and the versioned entry of the previous version changes to INACTIVE.

8.4. Notification and Publication

This Section describes the notification to the European Commission of the entities that are subject to it, and the resulting publication in the Lists of Trusted Entities. The submission is an act of the Member State (through the Single Point Of Contact). The publication is an act of the European Commission. The notification is not one of the Onboarding Processes. The Onboarding System handles only the collection and the maintenance of the notifiable information.

Within IT-Wallet the Supervisory Body is the National Single Point Of Contact with the Commission and it relies on the Registrar for the entities the Registrar registers. Its outcome is the inclusion of the entity in the List of Trusted Entities of its type, whose structure and signature are described in Trusted List, Lists of Trusted Lists, and Lists of Trusted Entities.

The categories subject to notification according to Articles 4 and 5 of [CIR2024/2980], adopted under Article 5a(23) of [EIDAS], are the following:

• Wallet Providers.

• PID Providers.

• Providers of WRPAC.

• Providers of WRPRC, where applicable.

• Registrars of the Wallet-Relying Parties, together with the registers.

The PuB-EAA Providers are notified under Article 45f(3) of [EIDAS], and the detailed rules are laid down in [CIR2025/1569]. The Wallet-Relying Parties that do not belong to a notified category are not notified individually, and they are made available through their register.

8.4.1. Notification and Publication: Input

The input is the notifiable information of the entity. That information is the subset of its registration data that applies to the category. The subset is defined by Annex II of [CIR2024/2980] and, for the PuB-EAA Providers, by Annex III of [CIR2025/1569]. The information is a projection of the Registration Data Model:

• legal_name.

• identifier.

• contact_information.

• service_policies.

• signing_trust_anchor.

• conformity_assessment.

For a PID Provider and a Wallet Provider the Sign/Seal Certificate is issued by the National PKI. The signing_trust_anchor is not provided as an input by the entity. The signing_trust_anchor derives from the issuance described in Signature and Seal Certificate Issuance.

For a PuB-EAA Provider the Sign/Seal Certificate is a qualified certificate issued by a Qualified Trust Service Provider, and its Trust Anchor is conveyed by the eIDAS Trusted Lists that are outside of this process. Therefore, the Sign/Seal Trust Anchor is not required as an input for a PuB-EAA Provider. The qualified status of its certificate is evaluated in the conformity assessment required for eligibility and compliance, see Eligibility and Compliance Preconditions.

The notifiable information is collected in the notification dataset, that is kept separate from the Register as described in Trust Artifacts Registration Outcomes. The dataset is written and kept up to date by the Notification Dataset Management during the Entity Registration, the Entity Update and the Entity Suspension and Removal.

Note

The Sign/Seal Trust Anchor is not the certificate the entity uses to sign, whose public key is conveyed by the certificate_signing_requests.

8.4.2. Notification and Publication: Outcome

The outcome is the inclusion of the entity in the List of Trusted Entities of its type. The inclusion is the assertion, at EU level, of the role and of the authorization of the entity. The inclusion allows a Wallet Unit or a Wallet-Relying Party of another Member State to validate the entity.

8.4.3. Notification and Publication: Process

1. The entity MUST have completed its Entity Registration. For the notified categories the conformity assessment MUST have been verified as described in Eligibility and Compliance Preconditions. The completion of the registration is the precondition of the notification.

2. The Onboarding System collects the notifiable information of the category from the notification dataset, following Annex II of [CIR2024/2980] or, for the PuB-EAA Providers, Annex III of [CIR2025/1569].

3. The Supervisory Body, as the National Single Point Of Contact, submits the information to the secure electronic notification system that the Commission makes available. The submission MUST be made at least in English. The system and its requirements are defined in Annex I of [CIR2024/2980].

4. The Commission may request additional information or clarifications to verify the completeness and the consistency of the notified information.

5. The Commission publishes the List of Trusted Entities that compiles the notified information. The entity appears in the List of Trusted Entities of its type, whose data model, format and signature are described in Trusted List, Lists of Trusted Lists, and Lists of Trusted Entities.

6. Where the registration of the entity changes, in particular where it is suspended or cancelled, the Onboarding System MUST reflect the change in the notification dataset.

Note

The Lists of Trusted Entities defined by [CIR2024/2980] and the Trusted Lists defined by [CID2015/1505] are described in Trusted List, Lists of Trusted Lists, and Lists of Trusted Entities.

8.5. Lifecycle Management

After the registration event, an Entity can be updated, suspended, reactivated or cancelled. A Credential type can become issuable or stop being issuable. These changes reflect on the Trust Artifacts and on the registries.

This section describes the states and events that cause an entity or Credential type to change state. It also maps each event to the registries and trust artifacts impacted by the event, see Events, Registries and Trust Artifacts.

The formats, the parameters and the states of the Trust Artifacts are defined in Trust Artifacts Lifecycle State Machine, and the revocation mechanisms are defined in Revocation Mechanisms. The lifecycle of the single Digital Credentials issued to the Users is a different matter and it is defined in Digital Credential Lifecycle.

8.5.1. Entity Lifecycle State Machine

This section applies to WRPs and WPs as they are directly involved in the operational phases. As shown in Fig. 8.3, an Entity has five distinct and mutually exclusive states: UNREGISTERED, REGISTERED, OPERATIONAL, SUSPENDED and CANCELLED. Each state determines the authorization level and the operational capabilities of the Entity.

Fig. 8.3 Entity Lifecycle States.

8.5.1.1. Transition from UNREGISTERED to REGISTERED

• UNREGISTERED: the Entity does not hold a valid registration within the IT-Wallet ecosystem. This is the default baseline state. Entities in this state are outside the trust boundary and MUST NOT participate in any operation.

• REGISTERED: the Entity has completed the registration process and its identity has been verified.

  • EUDIW Trust Framework: WRPs are in REGISTERED state when their information has been added to the Register. Wallet Providers become REGISTERED when the certification and the onboarding records have been collected and verified.

  • National Trust Framework: WRPs and Wallet Providers are in REGISTERED state when the onboarding records have been collected and verified.

8.5.1.2. Transition from REGISTERED to OPERATIONAL

OPERATIONAL indicates that the Entity has been authorized to perform the operations related to its role.

• EUDIW Trust Framework: WRPs are OPERATIONAL if they were REGISTERED and they obtained a WRPAC, the corresponding WRPRC(s), and, depending on the role, a Sign/Seal Certificate. The signing Trust Anchor of that certificate MUST have been added to the LoTE or to the EUMS TL. Wallet Providers are OPERATIONAL if they were REGISTERED and they obtained a Sign/Seal Certificate whose signing Trust Anchor has been added to the LoTE.

• National Trust Framework: WRPs and Wallet Providers are OPERATIONAL if they were REGISTERED. They obtained the Sign/Seal Certificates and the registration Trust Marks. Their Subordinate Statement has been published by the Federation Authority.

8.5.1.3. Transition from OPERATIONAL to REGISTERED

An Entity goes back to REGISTERED when it no longer holds valid Trust Artifacts. This can be triggered by its expiration or revocation following an update of the Entity. To return to OPERATIONAL a new issuance of the Trust Artifacts is required.

8.5.1.4. Transition from REGISTERED or OPERATIONAL to SUSPENDED

SUSPENDED indicates that the registration is temporarily not valid. Differently from the cancellation, the suspension is reversible. A WRP whose registration is suspended MUST NOT issue Credentials to Wallet Units. That WRP MUST NOT request attributes from Wallet Units. The Credentials that WRP issued are not accepted by the Relying Parties, as described in Section 4.6.5 of [EIDAS-ARF].

The events that lead to this state, and the parties entitled to decide them, are listed in Registration Events and Their Governance.

8.5.1.5. Transition from SUSPENDED to REGISTERED

The suspension can be lifted by the same party that decided it. Because the Trust Artifacts affected by the suspension have been revoked, the Entity returns to REGISTERED and not directly to OPERATIONAL. A new issuance of the Trust Artifacts is required to become OPERATIONAL again.

8.5.1.6. Transition from REGISTERED, OPERATIONAL or SUSPENDED to CANCELLED

CANCELLED indicates that the registration has ended. The state is the same whether the cancellation was requested by the Entity itself or decided by the competent authority, and only the triggering event differs.

• EUDIW Trust Framework: for WRPs the cancellation results in the revocation of the WRPAC, the WRPRC and, where applicable, the Sign/Seal Certificates. The cancellation results in the removal of the entry from the Register. The cancellation results in the update of the status of the signing Trust Anchor in the LoTE or in the EUMS TL. For Wallet Providers it results in the update of the Wallet Providers LoTE.

• National Trust Framework: for both WRPs and Wallet Providers it results in the removal of the Subordinate Statement and of the registration Trust Mark, and in the revocation of the National X509 Certificates.

An Entity MUST reject new interactions or transactions started by a CANCELLED Entity. All the cryptographic keys, the active attestations and the operational capabilities associated with the Entity MUST be revoked. Entities MAY however continue to validate historical data, signatures and Credentials generated before the cancellation timestamp, subject to local risk policies. An Entity in CANCELLED state that wants to participate again in the ecosystem MUST complete a new registration.

Note

Section 4.6.5 of [EIDAS-ARF] describes for PID Providers and Attestation Providers the states Registered, Suspended and Cancelled. Within IT-Wallet the Registered state is split into REGISTERED and OPERATIONAL, to distinguish the moment in which the registration record exists from the moment in which the Entity holds all the Trust Artifacts it needs to operate.

Note

The lifecycle of the Authentic Sources and of the Trust-infrastructure Entities, such as the Registrar and the Providers of WRPACs and of WRPRCs, is not defined in this section. The Authentic Sources follow the PDND framework, and the effects that their lifecycle produces inside IT-Wallet are described in Authentic Source Lifecycle and PDND Alignment.

8.5.2. Registration Events and Their Governance

Every transition of the state machine of the Entities is caused by an event. For each event, this section states who is entitled to trigger it, who is responsible for it, and, when applicable, on which normative basis and within which conditions. The events that concern the Credential types and the Authentic Sources are described in the dedicated sections below.

Table 8.13 Registration Events

Event	Trigger	Responsible	Normative reference	Condition
Registration	Request of the Entity, after the verification of the eligibility conditions applicable to its role.	Registrar, for the Register entry. Federation Authority, for the federation registration.	Articles 5 and 6 of [CIR2025/848].	Not defined.
Update	Change of the registered information. The WRP is responsible for the accuracy of its information and updates it.	Registrar, for the Register entry. Federation Authority, for the Subordinate Statement and the registration Trust Mark.	Article 5(2) and 5(3) of [CIR2025/848].	Without undue delay.
Suspension	Request from a Supervisory Body, request from the WRP itself, or initiative of the Registrar in the cases listed after this table.	Registrar for the EUDIW Trust Framework, Federation Authority for the National Trust Framework.	Article 9(1), 9(2), 9(3) and 9(5) of [CIR2025/848].	Information of the WRP and of the Providers of its certificates within 24 hours.
Reactivation	Removal of the condition that caused the suspension.	The same party that decided the suspension.	Section 4.6.5 of [EIDAS-ARF].	Not defined.
Cancellation	Request from a Supervisory Body, request from the WRP itself including when it no longer intends to rely upon Wallet Units, or initiative of the Registrar in the cases listed after this table.	Registrar for the EUDIW Trust Framework, Federation Authority for the National Trust Framework.	Article 9(1), 9(2), 9(3) and 9(5) of [CIR2025/848].	Information of the WRP and of the Providers of its certificates within 24 hours.

Two roles carry out an event, one for each Trust Framework. Within the EUDIW Trust Framework the Registrar acts on the Register and notifies the Providers of the affected Trust Artifacts. Within the National Trust Framework the Federation Authority acts on the Subordinate Statement and on the registration Trust Mark, and publishes the event on the Federation Subordinate Events Endpoint. The decision that triggers the event is the same for both, and it is described below with reference to the Registrar, as the obligations are set on the Registrar by [CIR2025/848].

The Registrar MUST suspend or cancel the registration of a WRP where the suspension or the cancellation is requested by a Supervisory Body, and where it is requested by the same WRP. The Registrar MAY suspend or cancel the registration on its own initiative where:

• the registration contains information which is inaccurate, out of date or misleading.

• the WRP is not compliant with the registration policy.

• the WRP is requesting more attributes than the ones it registered.

• the WRP is otherwise acting in breach of Union or National law in a manner related to its role.

Before suspending or cancelling a registration on its own initiative, the Registrar MUST conduct a proportionality assessment. The assessment takes into account the impact on the fundamental rights, the privacy, the security and the confidentiality of the Users of the ecosystem. The assessment takes into account the severity of the disruption caused by the measure and the associated costs, both for the WRP and for the User.

The Registrar MUST inform the WRP and the relevant Providers of WRPACs and of WRPRCs without undue delay. The Registrar MUST inform them not later than 24 hours after the suspension or the cancellation, as set by Article 9(5) of [CIR2025/848]. The information MUST include the reasons for the suspension or the cancellation and the available means of redress or appeal. After the notification, the Providers MUST revoke the affected certificates without undue delay, where applicable, as set by Article 9(6) of [CIR2025/848].

The Registrar MUST keep the records of the registration, of the issuance data and of the changes for 10 years. Within IT-Wallet the same retention applies to the Federation Authority for the records of the National Trust Framework, by analogy.

Note

The obligations described above are set by Articles 9 and 10 of [CIR2025/848] and apply to the Registrar and to the registration of the WRPs. Within IT-Wallet the retention obligation is extended by analogy to the Federation Authority for the records it keeps for the National Trust Framework, since [CIR2025/848] does not address the National Trust Framework. Wallet Providers are not registered as WRPs, so the suspension and cancellation of a Wallet Provider follow from the certification of its Wallet Solution and from the notification, and not from Article 9.

Beyond the Supervisory Body, the Registrar and the Entity itself, a suspension or a cancellation of an Entity MAY also be requested or triggered by other parties external to the Onboarding System. Examples are a judicial authority, an administrative authority competent for the Entity, and an authority competent for cybersecurity. Further examples are a conformity assessment body that withdraws a certification, or the Member State that withdraws a notification. In every case the suspension or the cancellation is carried out through the mechanisms described above. The Federation Authority that registered the Entity acts on its Subordinate Statement and on the registration Trust Mark. The Trust Artifacts of the Entity are revoked. For an Entity registered through a Federation Intermediate, the Subordinate Statement is served by the Intermediate. The Intermediate withdraws the Subordinate Statement to suspend or cancel the Entity. The registration Trust Mark remains issued by the Federation Trust Anchor. The Federation Trust Anchor is responsible for any effects on the lifecycle of the registration Trust Mark. The suspension or the cancellation of a Federation Intermediate MUST propagate to its affiliated Entities, whose Trust Chain runs through it, as described in Federation Trust Chain.

Independently of the notification described above, the Providers of WRPACs and the Providers of WRPRCs monitor the changes in the Register on a continuous basis. Those Providers revoke or reissue the certificates when the changes require it. For a WRPRC the re-issuance is automatic, as defined in Wallet-Relying Party Registration Certificate Issuance. This is set by Annex IV of [CIR2025/848] for the Providers of WRPACs and by Annex V of [CIR2025/848] as amended by [CIR2026/1730] for the Providers of WRPRCs.

Within the National Trust Framework the events that change the registration of an Entity MUST be published by the Federation Authority as signed events on the Federation Subordinate Events Endpoint (federation_subordinate_events_endpoint). Other participants can then track the lifecycle of an Entity over time. The endpoint and the format of its response are described in Federation API Endpoints.

Each event of the state machine MUST be published as an object of the federation_registration_events array, using the event types defined in [OID-FED-SUBORDINATE-EVENTS]. The table below gives, for each event, the value of the event parameter and how the parameters of the event object are populated.

Table 8.14 Mapping of the Lifecycle Events to the Subordinate Events

Lifecycle event	event	iat	event_description
Registration	registration	Time the registration is related to.	Not used.
Update of Identity Information or Technical Configuration	metadata_update	Time the update is related to.	MAY be used to provide further details about the update.
Key rotation/update of a Federation Entity Key	jwks_update	Time the key rotation/update is related to.	Not used.
Suspension	suspension	Time the suspension is related to.	MAY be used to provide further details about the suspension.
Cancellation	revocation	Time the cancellation is related to.	MAY be used to provide further details about the revocation.

When a registration event is present, the metadata_update and jwks_update events MUST NOT be provided at the same time. The registration is assumed to configure the initial state of the Entity, as specified in [OID-FED-SUBORDINATE-EVENTS].

8.5.3. Entity Updates and Their Effects on Trust Artifacts

Entities are characterized by three main categories of registered data.

• Identity Information: the name of the organization, the contact information and the organizational policies.

• Technical Configuration: the cryptographic material, meaning the signature and seal keys and the authentication keys, and the technical endpoints necessary for the interactions in the ecosystem.

• Authorization Information: the entitlements of the Entity, the Credential provision capabilities, the attribute request capabilities, the Intermediary use permissions, the intended uses, the embedded disclosure policies and the compliance with the certification schemes.

The Trust Framework infrastructure MUST propagate these changes to the relevant Trust Artifacts. The specific effects depend on the role of the Entity and on the Trust Artifacts it uses.

The procedures that carry out an update, meaning what the Entity submits and which steps the Registrar, the Federation Authority and the Certificate Authorities execute, are described in the Entity Update process. This section provides the relationship between the categories of registered data and the Trust Artifacts that contain them.

8.5.3.1. Registered Data and Associated Trust Artifact

The table below provides the relationship between the categories of registered data and the Trust Artifacts in which they are contained, for each type of Entity.

Table 8.15 Entity Data and Trust Artifacts

Entity Type	Data Category	EUDIW Trust Artifacts	National Trust Artifacts
WRP (all)	Identity Information	Register, WRPAC, WRPRC, LoTE (only for PID, PuB-EAA and notified non-qualified EAA Provider)	Entity Configuration, registration Trust Mark
WRP (all)	Technical Configuration (Authentication key)	WRPAC	Entity Configuration, Subordinate Statement
WRP (all)	Authorization Information (Entitlements, Intermediary, Service descriptions, Supervision information)	Register, WRPRC, LoTE (only for PID, PuB-EAA and notified non-qualified EAA Provider)	Entity Configuration, registration Trust Mark
Credential Issuer or Wallet Provider	Technical Configuration (Signature/Seal key)	X.509 Sign/Seal Certificate	X.509 Sign/Seal Certificate
Credential Issuer or Wallet Provider	Technical Configuration (Metadata, Signature/Seal Trust Anchor)	LoTE	Trust Anchor Entity Configuration
Credential Issuer	Authorization Information (RP permissions)	EDP in the Credential Issuer metadata	n/a
Credential Issuer	Authorization Information (Credential provision capabilities)	Register, WRPRC	Subordinate Statement, registration Trust Mark
Relying Party or Relying Party Intermediary	Authorization Information (Attribute request capabilities)	Register, WRPRC	Subordinate Statement, registration Trust Mark
Wallet Provider	Identity Information	LoTE	Entity Configuration, registration Trust Mark
Wallet Provider	Authorization Information (Service status)	LoTE	Subordinate Statement, registration Trust Mark

Note

The inclusion of Wallet Providers and Credential Issuers in the LoTE is an implicit assertion of their role and of their authorization within the ecosystem. In particular, their inclusion is the result of the successful completion of the registration and notification procedures as defined in [CIR2025/848] for the registration of the WRPs and in [CIR2024/2980] for the notification of WRPs and Wallet Providers. Similarly, the ability to fetch the Subordinate Statement of an Entity means that the Entity is currently part of the National ecosystem.

Note

QEAAs are provided by Qualified Trust Service Providers. Their identity, technical and authorization information are available in the dedicated EUMS TL.

The identity, technical and authorization information of Registrars, Providers of WRPAC and Providers of WRPRC are available in dedicated LoTE.

8.5.4. Credential Type Lifecycle

A Credential type is registered in the Digital Credentials Catalog as a versioned entry. The union of credential_type and version MUST be unique in the catalog, as specified in Digital Credentials Catalog Structure, so different versions of the same Credential type exist in the catalog as separate entries.

For this reason the lifecycle applies to the single versioned entry, meaning the pair given by credential_type and version, and not to the Credential type as a whole. Each versioned entry has two states, ACTIVE and INACTIVE, whose semantics is defined in Digital Credentials Catalog Structure. In short, a Credential type can be issued from a versioned entry only while that entry is ACTIVE.

Note

The state of the versioned entry is a different thing from the state of the single Digital Credentials issued to the Users, which is defined in Digital Credential Lifecycle.

Within IT-Wallet, a versioned entry is ACTIVE only while all the following conditions are satisfied, and it moves back to INACTIVE as soon as one of them stops holding.

• At least one Credential Issuer is listed in the issuers field of the entry, and each of them holds the entitlement corresponding to the legal_type of the Credential type.

• The Authentic Source that provides the data, or the parent Credential type, is registered and available. For an Authentic Source integrated through PDND, this means that the e-Service is published and that the enrolment of the Credential Issuer has been approved.

• The schema of the Credential type is registered in the Schema Registry for at least one of the supported formats.

Only one versioned entry of the same Credential type is ACTIVE at a given time.

8.5.4.1. Versioning

A Credential type is never modified in place. When its definition changes, a new versioned entry is registered and activated, and the entry of the previous version is moved to INACTIVE.

The Credentials already issued from the previous version keep their own status and are not revoked by the versioning. Where the Credential Issuer needs the Users to obtain the new version, the Credential Issuer can drive the re-issuance through the 0x03 (UPDATE) or the 0x0F (ATTRIBUTE_UPDATE) status of the single Digital Credentials, as described in Digital Credential Lifecycle.

The registration of a Credential type and its versioning are described in the registration processes, and the structure of the catalog entry in Digital Credentials Catalog Structure.

Note

Registering the Credential type first, in INACTIVE state and without Credential Issuers, makes the identifier of the Credential type available before the registration of the Credential Issuer, as it MUST declare at registration time the Credential types it intends to issue, and this declaration ends up in the Register and in the WRPRC.

Moreover, changing a versioned entry to INACTIVE prevents any Wallet Unit to request a new issuance from that entry. It does not revoke the Credentials already issued from it, which keep their own status. Where the reason that caused the deactivation also requires the revocation of the Credentials already issued, the revocation is a separate decision, taken by the Credential Issuer as described in Digital Credential Lifecycle.

8.5.5. Claims and Schemas Lifecycle

As described above for updating the Credential type, claims and schemas registered in the respective registries are not removed. The Credentials already issued keep referencing them. Removing a claim or a schema would make those Credentials impossible to interpret.

When a claim or a schema is deprecated, a new version of it is registered, and the Credential types that use it move to a new version as described above.

8.5.6. Authentic Source Lifecycle and PDND Alignment

An Authentic Source is not a WRP and it is not a Federation Entity. Its trust, authorization and operational aspects are governed by the PDND framework, as described in e-Service PDND. IT-Wallet relies on PDND for all of them. Within IT-Wallet an Authentic Source is only registered in the Authentic Source Registry, described in Authentic Source Registry, so that the Credential Issuers can discover which data are available and through which e-Service.

For this reason the IT-Wallet specification profile does not define a lifecycle of the Authentic Sources. What this section defines is the effect that the PDND lifecycle produces inside IT-Wallet, because Credential types and Credential Issuers depend on it.

When an Authentic Source stops providing, through PDND, the data on which a Credential type depends, the condition for the activation of that Credential type is no longer satisfied. Examples are an e-Service that is no longer published, or an enrolment of the Credential Issuer that has been withdrawn. The Credential type MUST be moved to INACTIVE. The Credential type stays registered and its identifier remains valid, so that the type can be activated again when the integration is restored.

The alignment process is not automatic and it works in both directions.

• From PDND to IT-Wallet, an Authentic Source that changes the availability of an e-Service used by a Credential type MUST notify the change, so that the state of the Credential type can be updated.

• From IT-Wallet to PDND, a Credential Issuer whose registration is suspended or cancelled MUST notify the change to the Authentic Source which may then decide to withdraw the corresponding authorizations within the PDND framework.

Warning

The suspension or the cancellation of a registration in IT-Wallet does not produce any effect inside PDND. Until the authorizations are withdrawn on the PDND side, a Credential Issuer whose registration is no longer valid can still obtain a Voucher and access the e-Service of an Authentic Source, even if it can no longer issue Credentials to the Wallet Units. Within IT-Wallet the notification is therefore an obligation of the Credential Issuer and of the Authentic Source.

8.5.7. Events, Registries and Trust Artifacts

The table below summarises, for each event, which registries and catalogs are impacted and where the effects on the Trust Artifacts are described. It covers both the initial registration and the subsequent lifecycle events. The relationship between an Entity update and the Trust Artifacts it affects is given in Entity Updates and Their Effects on Trust Artifacts, and the technical mechanisms that publish the status of a Trust Artifact in Revocation Mechanisms.

Table 8.16 Events and Impacted Registries

Event	Decided by	Impacted registries and catalogs	Effects on Trust Artifacts
Registration of an Entity	Registrar, Federation Authority	Register (new entry). Notification to the Commission for the notified categories.	The Entity obtains its Trust Artifacts, see Entity Data and Trust Artifacts.
Update of an Entity	Registrar, Federation Authority	Register (updated entry).	Depending on the updated data category, see Entity Data and Trust Artifacts.
Key rotation of an Entity	Certificate Authority, Provider of WRPAC, Federation Authority	No registry is impacted, unless the key is a Trust Anchor key, in which case the LoTE.	Revocation and re-issuance of the certificate holding the key, see Entity Data and Trust Artifacts.
Suspension of an Entity	Registrar, Federation Authority	Register (registration status no longer valid). Update of the LoTE or of the EUMS TL for the notified categories.	Revocation of the affected WRPAC, WRPRC and registration Trust Mark, and update of the Subordinate Statement.
Reactivation of an Entity	Registrar, Federation Authority	Register (registration status valid again). Update of the LoTE or of the EUMS TL for the notified categories.	New issuance of the Trust Artifacts revoked at suspension time.
Cancellation of an Entity	Registrar, Federation Authority	Register (entry removed). Update of the LoTE or of the EUMS TL for the notified categories.	Revocation of the WRPAC, WRPRC and Sign/Seal Certificates, and removal of the Subordinate Statement and of the registration Trust Mark.
Registration of a Credential type version	Supervisory Body, published by the Federation Trust Anchor	Digital Credentials Catalog (new versioned entry, INACTIVE). Schema Registry, for the schema of the new version.	None.
Activation or deactivation of a Credential type version	Supervisory Body, published by the Federation Trust Anchor	Digital Credentials Catalog (state of the versioned entry).	None.
New version of a Credential type	Supervisory Body, published by the Federation Trust Anchor	Digital Credentials Catalog (new versioned entry ACTIVE, previous versioned entry INACTIVE). Schema Registry.	None.
Registration of a new claim or of a new schema	Supervisory Body, published by the Federation Trust Anchor	Claims Registry or Schema Registry (new entry). Alignment towards the Catalogue of Attributes or the Catalogue of Schemes.	None.
Registration of an Authentic Source	Supervisory Body, published by the Federation Trust Anchor	Authentic Source Registry (new entry).	None.
Change of availability of an Authentic Source	Authentic Source, through PDND	Authentic Source Registry. Digital Credentials Catalog, for the versioned entries that depend on it.	None.

Note

The cancellation of a registration is the event, while the complete exit of an Entity from the ecosystem, which covers both Trust Frameworks, is the Entity Removal process described in the onboarding processes. The obligation of the Registrar to keep the records for 10 years survives the cancellation, so the removal of the entry from the Register is not a removal of the records of that registration.

Note

The Register is a set of records per WRP, so an event impacts only the record of the Entity concerned. The Authentic Source Registry, the Claims Registry and the Taxonomy are single signed documents, so every write requires a new signature and a new publication of the whole document. The Digital Credentials Catalog is served as independently signed responses, as specified in Digital Credentials Catalog Retrieval. The Catalogue of Attestations is served as independently signed responses, as specified in Catalogue of Attestations.