Search every question across sub-FAQs

An electronic attestation of attributes is a regulated way to prove facts about a natural or legal person through the eIDAS trust-service framework. eIDAS covers electronic attestation of attributes alongside signatures, seals, timestamps, electronic documents, registered delivery, website authentication, archiving, and electronic ledgers.

The important distinction is the type of attestation. A non-qualified EAA can still have legal effect and evidentiary value, but a QEAA must meet Annex V requirements and be issued by a qualified trust service provider. A separate category covers attestations issued by, or on behalf of, a public sector body responsible for an authentic source; those must meet Annex VII and the additional Article 45f requirements.

A QEAA is issued by a qualified trust service provider and must be able to show, in machine-processable form, that it is a qualified electronic attestation of attributes. eIDAS also requires Member States to make measures available so qualified trust service providers can verify certain public-sector attributes electronically, at the user's request, against authentic sources or recognised intermediaries.

A public-sector authentic-source attestation is different: it is issued by, or on behalf of, a public sector body responsible for the authentic source. The Member State must ensure those bodies meet a reliability and trustworthiness level equivalent to qualified trust service providers, notify them to the Commission, and make the public list available through a secure signed or sealed channel.

For wallet use, eIDAS requires providers of electronic attestations of attributes to let EUDI Wallet users request, obtain, store, and manage attestations regardless of the Member State where the wallet is provided. Providers of QEAAs and public-sector authentic-source attestations must provide an interface with EUDI Wallets.

For relying parties, the practical check is not only whether a credential verifies cryptographically. The EUDI Wallet Architecture and Reference Framework describes an ecosystem in which wallets let users request attestations from trusted issuers, store them, and present them to relying parties with user control, selective disclosure, relying-party authentication, issuer authorisation checks, and revocation/status checks.

An eIDAS Trusted List is evidence of supervised qualified status for a specific trust service provider and service, not a general approval of every certificate, product, or business process the provider offers.

Article 21 links the start of qualified service provision to the qualified status being indicated in the trusted list. Article 23 also connects the EU trust mark to the relevant trusted list, so a trust-mark claim should still be checked against the list entry.

The Commission makes Member State trusted-list publication information available, and ETSI TS 119 612 describes the Commission's central List Of Trusted Lists as a set of links to national trusted-list locations.

A useful audit record should therefore preserve both the list-discovery route and the actual service-status result, so a reviewer can distinguish a stale supplier assertion from a reproducible trusted-list check.

Trusted-list status is necessary for qualified-status checks, but relying-party validation still has to connect that status to the actual signature, seal, timestamp, certificate, or website-authentication certificate being relied on.

DSS validation material illustrates the practical split: a validation process may need certificate-chain validation, revocation data, timestamp or long-term validation material, and a qualification determination based on trusted-list interpretation.

A relying party is the service provider side of a wallet interaction: a public or private organisation that requests data from a user's EU Digital Identity Wallet before granting access to a service, verifying a customer, enrolling a student, checking a professional mandate, or receiving a digital document.

For Article 5b, the trigger is the intention to rely on the wallet for public or private services by means of digital interaction. Once that trigger is present, the relying party must register in the Member State where it is established before operating the wallet request as a recognised service provider.

Article 5b requires the relying party to register in the Member State where it is established. The registration must include information needed for the party to authenticate to EUDI Wallets, contact details, and the intended wallet use, including the data the relying party will request from users.

The same rule limits the live request: relying parties must not ask users for data beyond what they indicated during registration. That makes the registered purpose and attribute list a control boundary for product, legal, privacy, and engineering teams.

The relying party should authenticate and identify itself to the user, request only the registered data needed for the service, and let the wallet present the specific requested data before the user confirms. Article 5b also makes the relying party responsible for authenticating and validating the person identification data and electronic attestations of attributes it requests from wallets.

The ARF adds a useful technical control point: the wallet can use relying-party registration information or certificates to help verify whether a request fits the registered attributes and warn the user if it does not. That technical model supports the legal purpose, data-minimisation, and transparency checks, but the binding obligation remains in eIDAS and applicable data-protection law.

A useful relying-party evidence record should prove that the live wallet request matches the registered purpose and data list. It should also show that the user saw who was requesting the data, what data was requested, and which validation procedure the service applied to the wallet response.

Avoid storing more wallet transaction content than the service needs. The ARF highlights relying-party linkability risks from unique fixed attestation elements, and Article 5b specifically says intermediaries acting for relying parties must not store data about transaction content.

An AdES is the eIDAS signature level defined by the four Article 26 requirements: signer linkage, signer identification, signer-control of creation data, and data-integrity linkage. It can be strong evidence, but eIDAS does not give it automatic equivalence to a handwritten signature.

A QES is an AdES that also uses a qualified certificate for electronic signatures and a qualified electronic signature creation device. eIDAS Article 25 gives a QES the equivalent legal effect of a handwritten signature, while any electronic signature remains admissible and cannot be rejected only because it is electronic or not qualified.

For QES, the signature validation record should prove more than successful cryptographic verification. It should show that the supporting certificate was a qualified certificate at the time of signing, that it was issued by a qualified trust service provider and valid at that time, that the validation data matched what was provided to the relying party, and that the signed data's integrity was not compromised.

Trusted lists matter because eIDAS requires Member States to establish, maintain, and publish trusted lists with information about qualified trust service providers and their qualified trust services. The trusted-list interpretation rules also explain how qualified certificate and QSCD-related status can be represented through service entries, certificate statements, and qualifications.

AdES may be enough where the applicable contract, service design, risk analysis, or law only requires strong evidence of signer identity, signer control, and document integrity. eIDAS preserves the admissibility of non-qualified electronic signatures, but their probative value is assessed from the evidence around the transaction.

Require QES when a law, public-service requirement, customer mandate, procurement clause, or organization risk decision specifically requires qualified status or handwritten-signature equivalence. In that case, a normal AdES audit trail is incomplete unless it also proves the qualified certificate, QTSP, QSCD, and validation conditions.

A provider is a qualified trust service provider only when it provides one or more qualified trust services and the supervisory body has granted qualified status. The check must cover both levels: the legal entity and the exact service, such as a qualified certificate, qualified timestamp, qualified electronic registered delivery service, qualified validation service, qualified preservation service, qualified electronic attestation of attributes, qualified electronic archiving service, qualified electronic ledger, or qualified remote management of signature or seal creation devices.

Do not treat a marketing claim, ISO certificate, ETSI standard reference, reseller statement, or parent-company brand as proof of QTSP status. Under eIDAS, a provider intending to start a qualified trust service notifies the supervisory body and submits a conformity assessment report; the supervisory body grants qualified status when the provider and service meet the eIDAS requirements.

Start with the relevant trusted list, not with the contract. Each Member State establishes, maintains, and publishes a secured trusted list in a form suitable for automated processing, and the Commission makes trusted-list publication information available through a secure channel. The Commission eSignature building block also points users to the Trusted List Browser for searching qualified trust service providers in Europe.

For technical validation, ETSI TS 119 612 explains how trusted-list information can feed certificate path validation and trust-anchor management. A relying party should validate the trusted-list source, select entries under its trust policy, and check regularly for service status changes or new entries.

QTSP status is supervised, not self-declared. eIDAS requires qualified trust service providers to be audited at their own expense at least every 24 months by a conformity assessment body, with the conformity assessment report submitted to the supervisory body within three working days of receipt. Supervisory bodies may also audit or require additional conformity assessment at any time.

The operating evidence should prove that the service still meets the qualified-service requirements after onboarding, certificate issuance, identity or attribute verification, revocation, incident handling, subcontracting, cloud hosting, termination planning, and service changes. Where qualified certificates are issued, eIDAS requires revocation status publication in a timely manner and in any event within 24 hours after receipt of the request.

A certificate for website authentication makes it possible to authenticate a website and link that website to the natural or legal person to whom the certificate is issued. A QWAC adds the eIDAS qualified layer: the certificate must be issued by a qualified trust service provider and meet Annex IV requirements.

For a website owner or relying party, the useful question is not only whether the TLS connection works. The QWAC evidence should show who the certificate identifies, which domain names are covered, which qualified trust service provider issued it, and where relying parties can check certificate validity or revocation status.

Validation should combine certificate checks with eIDAS status checks. First confirm that the issuer and service are qualified for the relevant trust service on an EU trusted list, because eIDAS allows a qualified trust service provider to provide a qualified trust service after qualified status appears in the trusted lists.

Then validate the certificate itself: domain match, certificate chain, validity period, certificate-status endpoint, revocation status, and the QWAC-specific qualified-certificate statements. eIDAS requires qualified trust service providers issuing qualified certificates to publish revocation status and provide validity or revocation information to relying parties.

The eIDAS 2 amendments add browser-facing duties for qualified certificates for website authentication. Providers of web browsers must recognise QWACs issued in accordance with Article 45 and display the identity data and additional attested attributes in a user-friendly way, subject to the small-enterprise exception stated in the Regulation.

That browser rule should not be read as a guarantee that every deployed browser, user interface, certificate store, or relying-party application already presents QWAC identity information in the same way. For implementation work, keep the distinction clear: the certificate may satisfy eIDAS QWAC requirements, while browser support and display behavior are separate deployment and interoperability checks.