---
title: "EUDI Wallet Relying Party Registration Under eIDAS"
canonical_url: "https://www.sorena.io/artifacts/eu/electronic-identification-and-trust-services-regulation/eudi-wallet-relying-party-registration"
source_url: "https://www.sorena.io/artifacts/eu/electronic-identification-and-trust-services-regulation/eudi-wallet-relying-party-registration"
author: "Sorena AI"
description: "What eIDAS Article 5b and the EUDI Wallet ARF say about wallet relying party registration, intended uses, attribute requests, certificates, evidence, and Member State gaps."
published_at: "2026-05-09"
updated_at: "2026-05-09"
keywords:
  - "eIDAS"
  - "EUDI Wallet"
  - "Article 5b"
  - "wallet relying party registration"
  - "relying party certificate"
  - "attribute request"
  - "wallet relying party"
  - "attribute requests"
  - "registration certificates"
  - "electronic attestations of attributes"
---
**[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform

[Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io)

---

# EUDI Wallet Relying Party Registration Under eIDAS

What eIDAS Article 5b and the EUDI Wallet ARF say about wallet relying party registration, intended uses, attribute requests, certificates, evidence, and Member State gaps.

*Artifact Guide* *EU*

## eIDAS Article 5b EUDI Wallet relying party registration

Use this page to scope what a public or private service must prepare before it relies on the European Digital Identity Wallet in a digital interaction.

Grounded in the consolidated eIDAS text and the EUDI Wallet Architecture and Reference Framework, with clear limits where Member State registration procedures are still needed.

A wallet relying party is the public or private service that asks a user to present person identification data or electronic attestations of attributes from a European Digital Identity Wallet. Under eIDAS Article 5b, a relying party that intends to rely on EUDI Wallets for public or private services by digital interaction must register in the Member State where it is established. The registration is not just an identity check: it records who the relying party is, how it can be contacted, the intended wallet use, and the data it plans to request from users.

## What Article 5b requires before a service relies on the EUDI Wallet

Article 5b makes registration the entry point for wallet relying parties. The relying party must register in its Member State of establishment before relying on EUDI Wallets for a public or private service delivered through digital interaction.

The minimum registration package is specific. It must include information needed for authentication to EUDI Wallets, including the Member State of establishment, the relying party name, any official registration number and the official-record identification data, contact details, the intended use of the wallet, and an indication of the data the relying party will request from users.

- Register in the Member State where the relying party is established, not in an arbitrary customer market.
- Describe each intended wallet use in enough detail to explain why the requested attributes are needed.
- List the data to be requested from users; Article 5b says relying parties must not request data beyond what they indicated.
- Keep change control ready, because registered relying parties must inform Member States without delay about changes to their registration information.
- Do not treat registration as a substitute for sector-specific law; Article 5b preserves applicable Union and national rules for specific services.

Sources for this answer:

- [Regulation (EU) No 910/2014, consolidated eIDAS text](https://eur-lex.europa.eu/eli/reg/2014/910/oj?ref=sorena.io) - Article 5b is the binding source for registration location, minimum relying-party information, requested-data limits, change updates, and Member State publication.
- [EUDI Wallet Architecture and Reference Framework](https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/latest/architecture-and-reference-framework-main/?ref=sorena.io) - The ARF explains how relying party registration information is used during wallet presentation requests, including intended uses and registered attributes.

## How intended uses and attribute requests should be structured

The ARF treats intended use as a practical boundary for attribute requests. During registration, a relying party records which attributes it intends to request from wallet units for each service or intended use. If one organisation has materially different wallet uses, the ARF explains that a single relying party may register multiple times and may receive more than one registration certificate.

A single intended use can cover multiple attributes from multiple attestations, but the request should remain coherent for that use. If a relying party has multiple intended uses in one user journey, the ARF says it needs multiple presentation requests, each tied to the relevant intended use.

- Create one intended-use record per service purpose that needs a distinct set of wallet attributes.
- For each intended use, record the attribute name, source attestation type, reason it is needed, and whether the service can work with a less identifying attribute.
- Separate age proof, address proof, professional status, legal-entity representation, and payment or account onboarding use cases when they request different attribute sets.
- Make the user-facing intended-use description match the registration record and the presentation request.
- Record why pseudonyms are or are not accepted; Article 5b says relying parties must not refuse pseudonyms where user identification is not required by Union or national law.

Sources for this answer:

- [EUDI Wallet Architecture and Reference Framework](https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/latest/architecture-and-reference-framework-main/?ref=sorena.io) - ARF section 6.6.3.3 grounds intended-use specific attribute registration, multiple registrations, registration certificates, and wallet checks against requested attributes.
- [Regulation (EU) No 910/2014, consolidated eIDAS text](https://eur-lex.europa.eu/eli/reg/2014/910/oj?ref=sorena.io) - Article 5b requires registration of intended wallet use and the data to be requested, and limits relying parties to that indicated data.

## Provider onboarding, certificates, and what the wallet checks

The ARF describes two preconditions before relying party authentication starts: the relying party registers and obtains an access certificate for each relying party instance, and the wallet unit obtains the trust anchor of the access certificate authority from the relevant list of trusted entities. In each presentation, the relying party instance includes its access certificate and trust chain, signs request data, and the wallet unit verifies the signature, certificate chain, and revocation status before asking the user for approval.

Registration certificates are a separate concept. If the registrar issues them, a registration certificate can list the attributes registered for a particular intended use. The wallet can use that certificate, or contact the registrar if no certificate is available, to compare the requested attributes against what the relying party registered.

- Inventory every relying party instance that will send wallet presentation requests and bind it to the correct access certificate.
- Keep certificate issuance, trust-chain, revocation-check, and key-rotation evidence with the service onboarding record.
- If registration certificates are issued in the relevant Member State setup, distribute the correct certificate to each relying party instance for the relevant intended use.
- If no registration certificate is available, preserve the registrar URL, relying party identifier, and intended-use identifier needed for wallet verification.
- For intermediaries, evidence must distinguish the intermediary's own access certificate from the intermediated relying party's registered intended use.

Sources for this answer:

- [EUDI Wallet Architecture and Reference Framework](https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/latest/architecture-and-reference-framework-main/?ref=sorena.io) - ARF sections 6.6.3.2 and 6.6.3.3 ground access certificates, trust anchors, registration certificates, registrar lookup, intended-use identifiers, and wallet comparison of requested attributes.
- [European Commission library page for the EUDI Wallet ARF](https://digital-strategy.ec.europa.eu/en/library/european-digital-identity-wallet-architecture-and-reference-framework?ref=sorena.io) - Commission publication page identifying the ARF as the specifications framework for interoperable EUDI Wallet solutions.

## User approval, privacy notices, and request evidence

The ARF is explicit that user approval in the wallet means the user's decision to present attributes; it should not be treated as the relying party's lawful basis for processing personal data. The relying party still needs its own GDPR analysis for the requested attributes.

Before attributes are presented, the wallet informs the user about the relying party identity, any intermediary, the requested attributes, the relying party's intended use and privacy policy, and the outcome of checks against registered attributes or embedded disclosure policies where those checks are performed.

- Keep a privacy-policy URL aligned with each intended use, because the ARF expects this information to be shown to the user through the wallet flow.
- Store the presentation-request profile: relying party identifier, intended-use identifier, requested attributes, user-friendly intended-use description, and privacy-policy URL.
- Log whether the request used a registration certificate or relied on registrar lookup, without storing more wallet transaction content than necessary.
- Design rejection and fallback paths for cases where the wallet warns that requested attributes were not registered or registration information could not be retrieved.
- For received attributes, define when unique fixed elements from attestations are no longer needed and should be discarded to reduce relying party linkability risk.

Sources for this answer:

- [EUDI Wallet Architecture and Reference Framework](https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/latest/architecture-and-reference-framework-main/?ref=sorena.io) - ARF section 6.6.3.5 grounds user approval conditions, intended-use and privacy-policy display, and the warning that user approval is not a GDPR lawful basis.
- [Regulation (EU) No 910/2014, consolidated eIDAS text](https://eur-lex.europa.eu/eli/reg/2014/910/oj?ref=sorena.io) - Article 5a requires wallet functions for users to view relying-party connections, request erasure, and report allegedly unlawful or suspicious data requests.

## What cannot be specified from EU-level sources alone

The EU-level sources do not give one universal public form, fee schedule, portal, evidence pack, or approval service-level agreement for every Member State relying party registration. Article 5b says the relying party registers in its Member State of establishment and that Member States make registration information public online in electronically signed or sealed machine-processable form.

For implementation, treat Member State procedure as a separate source gap until the relevant national registrar, registration portal, access certificate authority, or supervisory body has been identified from country-specific material.

- Do not publish a launch checklist that assumes a single EU portal unless the relevant Member State source confirms it.
- Do not assume registration certificates are always issued; the ARF describes their use and also describes registrar lookup when no certificate is available.
- Do not state national fees, penalties, processing times, or evidentiary attachments without Member State-specific sources.
- Do not merge multiple legal entities under one registration unless the national registration process and official-record identifiers support that treatment.
- Do not let an intermediary model hide the relying party; the ARF expects the wallet to display both intermediary and intermediated relying party information where applicable.

Sources for this answer:

- [Regulation (EU) No 910/2014, consolidated eIDAS text](https://eur-lex.europa.eu/eli/reg/2014/910/oj?ref=sorena.io) - Article 5b grounds the Member State registration model and the publication requirement, but does not provide country-specific registration portals or national process details.
- [EUDI Wallet Architecture and Reference Framework](https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/latest/architecture-and-reference-framework-main/?ref=sorena.io) - The ARF grounds the optional registration-certificate path and the fallback registrar-lookup path, which prevents assuming one certificate model for every implementation.

## Evidence checklist for a relying party registration file

A useful relying party file should let legal, product, engineering, privacy, and security reviewers see the same facts: who is registering, what service will use the wallet, which attributes are requested, how the wallet will authenticate the relying party, and what the user will see before approving presentation.

Keep the file scoped to the establishment Member State and update it whenever the registered information changes.

- Legal entity details: Member State of establishment, official name, official registration number where applicable, and official-record identification data.
- Relying party contacts: operational, privacy, security, and incident channels, plus any privacy-related web form, email address, or phone number used in wallet flows.
- Intended-use register: service name, user-friendly purpose text, requested attributes, attestation sources, privacy-policy URL, and pseudonym acceptance analysis.
- Technical onboarding record: relying party instance identifiers, access certificates, trust-chain validation evidence, revocation-check approach, and key-management owner.
- Registration verification record: registration certificate details where issued, or registrar lookup fields such as registrar URL, relying party identifier, and intended-use identifier.
- Change record: what changed, when the Member State was informed, which presentation requests or certificates were updated, and when the user-facing description was checked.

Sources for this answer:

- [Regulation (EU) No 910/2014, consolidated eIDAS text](https://eur-lex.europa.eu/eli/reg/2014/910/oj?ref=sorena.io) - Article 5b supports the evidence fields for legal identity, contacts, intended use, requested data, change updates, and relying-party validation responsibility.
- [EUDI Wallet Architecture and Reference Framework](https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/latest/architecture-and-reference-framework-main/?ref=sorena.io) - The ARF supports the evidence fields for relying party instances, access certificates, registration certificates, registrar lookup, intended-use descriptions, and privacy-policy URLs.

*Recommended next step*

*Placement: before sources*

## Turn Article 5b registration facts into a launch-ready record

Sorena can help structure intended uses, requested attributes, certificate evidence, privacy-policy links, and Member State source gaps before a service relies on the EUDI Wallet.

- [Open Research Copilot for eIDAS](/solutions/research-copilot.md): Ask source-linked questions about Article 5b, relying party authentication, intended uses, and wallet attribute requests using the cited sources on this page.
- [Review a relying party onboarding file](/contact.md): Check whether your EUDI Wallet registration evidence separates EU-level requirements from Member State-specific procedure gaps.

## Primary sources

- [Regulation (EU) No 910/2014, consolidated eIDAS text](https://eur-lex.europa.eu/eli/reg/2014/910/oj?ref=sorena.io) - Binding eIDAS text for Article 5b wallet relying party registration, requested-data limits, change updates, user identification, validation responsibility, intermediaries, and Member State publication.
  - Quote: "European Digital Identity Wallet-Relying Parties"
- [EUDI Wallet Architecture and Reference Framework](https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/latest/architecture-and-reference-framework-main/?ref=sorena.io) - Commission EUDI Wallet technical framework explaining relying party authentication, access certificates, intended-use registration, registration certificates, user approval, and registrar lookup.
  - Quote: "Relying Party authentication"
- [European Commission library page for the EUDI Wallet ARF](https://digital-strategy.ec.europa.eu/en/library/european-digital-identity-wallet-architecture-and-reference-framework?ref=sorena.io) - Commission publication page identifying the ARF as the specifications framework for interoperable EUDI Wallet solutions.
  - Quote: "Architecture and Reference Framework"

## Related Topic Guides

- [eIDAS 2 deadlines and compliance calendar for EUDI Wallet and trust services](/artifacts/eu/electronic-identification-and-trust-services-regulation/deadlines-and-compliance-calendar.md): Calendar of grounded eIDAS and eIDAS 2 milestones for EUDI Wallet delivery, implementing acts, annual supervision reports, QTSP transitions, pilots, and ARF evidence.
- [eIDAS 2.0 vs eIDAS: EUDI Wallet and trust-service changes](/artifacts/eu/electronic-identification-and-trust-services-regulation/eidas2-vs-eidas.md): Compare the original eIDAS electronic identification and trust-service framework with the eIDAS 2.0 amendments for EUDI Wallets, relying parties, attestations, QWACs, and supervision.
- [eIDAS Certificates and Authentication: qualified certificates, QWACs, and validation checks](/artifacts/eu/electronic-identification-and-trust-services-regulation/certificates-and-authentication.md): Grounded guide to eIDAS qualified certificates, website authentication certificates, trusted lists, relying-party checks, and validation evidence.
- [eIDAS checklist and evidence pack for trust services, signatures, and EUDI Wallet relying parties](/artifacts/eu/electronic-identification-and-trust-services-regulation/checklist-and-evidence.md): Build an eIDAS evidence pack for qualified trust services, electronic signatures, trusted-list checks, certificate validation, supervisory records, and EUDI Wallet relying-party controls.
- [eIDAS compliance guide for trust services, QTSPs, signatures, and EUDI Wallet relying parties](/artifacts/eu/electronic-identification-and-trust-services-regulation/compliance.md): Grounded eIDAS compliance guide for trust-service classification, QTSP supervision evidence, qualified signatures, seals, time stamps, certificates, trusted-list validation, and EUDI Wallet relying-party records.
- [eIDAS electronic signatures: SES, AES, QES legal effect and evidence](/artifacts/eu/electronic-identification-and-trust-services-regulation/electronic-signatures-and-legal-effect.md): A grounded guide to eIDAS electronic-signature legal effect: SES, AES, QES, qualified certificates, QTSP trusted-list checks, validation, recognition, and evidence records.
- [eIDAS penalties and fines for trust service providers](/artifacts/eu/electronic-identification-and-trust-services-regulation/penalties-and-fines.md): Grounded guide to eIDAS Article 16 penalties, administrative fine mechanics, supervisory bodies, qualified-status withdrawal, and trusted-list evidence.
- [eIDAS QES validation checks for relying parties](/artifacts/eu/electronic-identification-and-trust-services-regulation/qes-validation.md): How to validate a qualified electronic signature under eIDAS: certificate, QTSP, trusted-list, QSCD, integrity, validation result, and evidence records.
- [eIDAS Qualified Trust Services: QTSP Selection](/artifacts/eu/electronic-identification-and-trust-services-regulation/qualified-trust-services-and-qtsp-selection.md): How to select an EU eIDAS qualified trust service provider: identify the qualified service type, verify trusted-list status, review supervision evidence, and retain certificate-policy records.
- [eIDAS remote signature and cloud HSM controls for QTSPs](/artifacts/eu/electronic-identification-and-trust-services-regulation/remote-signature-and-cloud-hsm-controls.md): Grounded guide to eIDAS remote signature controls: remote QSCD scope, server-side signing, QTSP evidence, signer authentication, certificate validation, and trusted-list checks.
- [eIDAS signature legal effect selector: SES, AES, AES-QC, or QES](/artifacts/eu/electronic-identification-and-trust-services-regulation/signature-legal-effect-selector-workflow.md): Select the right eIDAS signature level by legal effect, risk, qualified certificate status, QTSP evidence, QSCD use, validation result, and cross-border recognition.
- [eIDAS trust service role scoping workflow: TSP, QTSP, validator, relying party, or QTSP customer](/artifacts/eu/electronic-identification-and-trust-services-regulation/trust-service-role-scoping-workflow.md): Classify an eIDAS role by evidence: trust service provider, qualified trust service provider, signature or seal validator, EUDI Wallet relying party, relying party, or customer of a QTSP.
- [eIDAS trusted list validation: LOTL, QTSP status, and evidence](/artifacts/eu/electronic-identification-and-trust-services-regulation/trust-list-validation.md): How to validate EU eIDAS trusted-list evidence: start from the Commission LOTL, confirm QTSP and qualified-service status, check certificate path and revocation data, and retain validation reports.
- [eIDAS vs ESIGN and UETA: EU qualified signatures vs U.S. e-signature laws](/artifacts/eu/electronic-identification-and-trust-services-regulation/eidas-vs-esign-and-ueta.md): Compare eIDAS with ESIGN and UETA for electronic signatures, qualified certificates, trust services, cross-border recognition, validation evidence, and source gaps.
- [eIDAS vs ETSI EN 319 401: legal supervision and TSP policy requirements](/artifacts/eu/electronic-identification-and-trust-services-regulation/eidas-vs-etsi-en-319-401.md): Compare eIDAS and ETSI EN 319 401 for trust services: legal scope, QTSP supervision, conformity assessment, audits, incident evidence, and operational controls.
- [eIDAS vs GDPR for identity data: wallet, trust-service, and privacy obligations](/artifacts/eu/electronic-identification-and-trust-services-regulation/eidas-vs-gdpr-identity-data.md): Compare eIDAS identity, trust-service, and EUDI Wallet rules with GDPR duties for personal-data processing, minimisation, lawful basis, evidence, security, and user rights.
- [eIDAS vs NIS2 for trust service providers: QTSP and cybersecurity obligations](/artifacts/eu/electronic-identification-and-trust-services-regulation/eidas-vs-nis2-trust-services.md): Compare eIDAS trust-service and QTSP duties with NIS2 cybersecurity risk-management, incident reporting, supervision, and evidence duties for trust service providers.
- [Electronic Attestations of Attributes under EU eIDAS: EAA, QEAA, issuers, wallets, and validation](/artifacts/eu/electronic-identification-and-trust-services-regulation/electronic-attestations-of-attributes.md): Grounded guide to electronic attestations of attributes under amended EU eIDAS: EAA, QEAA, public-sector authentic-source attestations, wallet use, issuer checks, relying-party validation, revocation, and legal effect.
- [EU eIDAS Applicability Test for Trust Services, Wallets, and Certificates](/artifacts/eu/electronic-identification-and-trust-services-regulation/applicability-test.md): A grounded eIDAS scope test for QTSPs, trust services, electronic signatures, seals, timestamps, QWACs, EUDI Wallet relying parties, and cross-border recognition evidence.
- [EU eIDAS attribute attestations: EAA, QEAA, wallet, and relying party checks](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/attribute-attestations.md): What electronic attestations of attributes mean under eIDAS, how QEAAs differ from public-sector and non-qualified attestations, and what issuers, wallets, and relying parties should verify.
- [EU eIDAS checklist for signatures, trust services, and wallets](/artifacts/eu/electronic-identification-and-trust-services-regulation/checklist.md): Checklist for eIDAS trust-service and EUDI Wallet controls: qualified status, trusted lists, certificates, signatures, seals, timestamps, validation evidence, and relying-party records.
- [EU eIDAS FAQ: signatures, QTSPs, trusted lists, QWACs, wallets, and validation](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq.md): FAQ on eIDAS trust services and the European Digital Identity framework, covering advanced and qualified electronic signatures, QTSP status, trusted lists, QWACs, EUDI Wallet relying parties, attestations of attributes, and validation evidence.
- [EU eIDAS QTSP authorization and supervision guide](/artifacts/eu/electronic-identification-and-trust-services-regulation/qtsp-authorization-and-supervision.md): How qualified trust service providers obtain and keep qualified status under eIDAS, including conformity assessment reports, supervision, trusted lists, incidents, and evidence.
- [EU eIDAS QTSP Due Diligence Workflow for Trusted Lists, Certificates, and Evidence](/artifacts/eu/electronic-identification-and-trust-services-regulation/qtsp-due-diligence-workflow.md): Check a qualified trust service provider under eIDAS by validating trusted-list status, qualified service scope, certificates, policies, supervision, audits, and retained evidence.
- [EU eIDAS Requirements for Trust Services, Signatures, Seals, Wallets, and Evidence](/artifacts/eu/electronic-identification-and-trust-services-regulation/requirements.md): Grounded guide to core eIDAS requirements for trust service providers, qualified trust services, electronic signatures, seals, time stamps, trusted lists, and EUDI Wallet relying parties.
- [EU eIDAS Trusted Lists FAQ: LOTL, QTSP status, and validation evidence](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/trusted-lists.md): How EU eIDAS Trusted Lists and the Commission LOTL support QTSP and qualified trust-service validation, with practical evidence checks for relying parties.
- [EUDI Wallet readiness for service providers under eIDAS](/artifacts/eu/electronic-identification-and-trust-services-regulation/eudi-wallet-readiness.md): Readiness guide for organisations preparing to request or verify data from European Digital Identity Wallets: roles, registration, ARF alignment, selective disclosure, implementing acts, and evidence.
- [EUDI Wallet Relying Parties under eIDAS](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/eudi-wallet-relying-party.md): What EUDI Wallet relying parties must do under eIDAS: register, declare intended wallet use and requested data, identify themselves to users, and keep request evidence.
- [EUDI Wallet Relying Party Onboarding Workflow under eIDAS](/artifacts/eu/electronic-identification-and-trust-services-regulation/wallet-onboarding-workflow.md): A grounded onboarding workflow for organisations that want to request data from European Digital Identity Wallet users as eIDAS wallet relying parties.
- [EUDI Wallet Technical Architecture Guide under eIDAS](/artifacts/eu/electronic-identification-and-trust-services-regulation/eudi-wallet-technical-architecture-guide.md): Technical guide to the EUDI Wallet architecture: ARF roles, wallet units, PID and attestations, relying parties, trust model, certificates, protocols, privacy, and security controls.
- [QES vs AdES under EU eIDAS: legal effect, certificates, QTSPs, and validation evidence](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/qes-vs-ades.md): Compare qualified electronic signatures (QES) and advanced electronic signatures (AdES) under EU eIDAS, including legal effect, qualified certificates, QTSP status, QSCDs, and validation evidence.
- [QWACs under eIDAS: website authentication certificates](/artifacts/eu/electronic-identification-and-trust-services-regulation/qwacs.md): A grounded guide to qualified website authentication certificates under eIDAS, covering Annex IV data, trusted lists, browser recognition, validation evidence, and QTSP checks.
- [What eIDAS Covers: eID, Trust Services, EUDI Wallet, and QWACs](/artifacts/eu/electronic-identification-and-trust-services-regulation/what-eidas-covers.md): A grounded guide to the systems and services covered by EU eIDAS: notified electronic identification, trust services, signatures, seals, time stamps, registered delivery, website authentication, trusted lists, the EUDI Wallet, and attribute attestations.
- [What is a qualified trust service provider under eIDAS?](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/qualified-trust-service-provider.md): How to verify QTSP status under eIDAS using the qualified service, supervisory body decision, trusted list entry, conformity assessment evidence, and service-specific records.
- [What is a QWAC under the EU eIDAS Regulation?](/artifacts/eu/electronic-identification-and-trust-services-regulation/faq/qwac.md): Plain-language FAQ on qualified website authentication certificates under eIDAS, including website identity, QTSP trusted-list checks, browser recognition, and validation evidence.


---

[Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us)

(c) 2026 Sorena AB (559573-7338). All rights reserved.

Source: https://www.sorena.io/artifacts/eu/electronic-identification-and-trust-services-regulation/eudi-wallet-relying-party-registration