From the outside, becoming an EUDI Wallet Relying Party can look straightforward: a wallet presents the data you need, you verify it, and your business processes move on. It’s easy to assume the Relying Party job in the EUDI Wallet ecosystem is just existing data verification in a different form. However, in practice, you have to comply with a range of ETSI specifications. In this article we summarize all ETSI standards relevant for Relying Parties, and discuss how they are relevant to your operations.
In practice, that “verification” step sits on top of a broader trust and interoperability layer, and many organisations underestimate the effort involved. You, as a Relying Party, do not only check whether a credential is technically valid. You have to build an interoperable way to (1) identify and authenticate yourselves as a Relying Party to the wallet, (2) express what you are allowed to request and why, (3) validate certificate chains and the meaning of what’s inside those certificates, (4) consume trust status information (e.g., trusted lists / trusted entities), and (5) produce validation evidence that still holds up afterwards in audits, disputes, or compliance reviews.
That is why Relying Party implementations in the EUDI Wallet ecosystem quickly touch a range of ETSI standards. ETSI publishes many of the technical specifications and European Norms that underpin trust services and interoperability in eIDAS/eIDAS 2.0-related ecosystems. These ETSI specs are very practical engineering constraints: they define profiles, policies, formats, and protocol expectations that Relying Parties need to support for cross-border interoperability to actually work.
The tricky part is not complying with any single spec. It is that the ETSI standards span multiple layers at once: wallet presentation flows, PKI policy and certificate profiles, trusted lists, reporting formats, and (increasingly) privacy-preserving techniques like selective disclosure and ZKPs. Cross-border interoperability only works if those layers line up.
Below is the complete ETSI set we mapped to the Relying Party usecase, grouped by the part of the Relying Party stack they serve.
Wallet presentations
The first part of that stack is about the presentation itself. ETSI TS 119 472-2 defines profiles for wallet presentations towards Relying Parties, while ETSI TS 119 472-1 helps ensure that Electronic Attestations of Attributes are interpreted consistently across issuers and wallets. For Relying Parties, this is foundational: before you can trust anything, you need to reliably understand what the wallet is actually sending.
Relying Party identity & authorization context
The second part is about the Relying Party’s own identity and authorization. In the EUDI ecosystem, trust is not only about issuers. Wallets also need to know who is requesting data, under what authorization, and how that should be shown to the user. That is where standards such as ETSI TS 119 411-8 and ETSI TS 119 475 become important. They shape how Relying Parties are identified and how certificate-based attestations support access and registration flows. Not every product team needs to become deeply specialized in certificate policy, but the platform absolutely needs to process these inputs correctly, because they can determine whether a wallet interaction is accepted at all.
Validation procedures and validation evidence
Then there is validation. In a regulated trust environment, a simple yes-or-no result is rarely enough. You need validation that is consistent, reproducible, and explainable. ETSI EN 319 102-1 and ETSI TS 119 102-2 are central here, with ETSI TS 119 441 and TS 119 442 becoming relevant when validation is provided or consumed as a service. For Relying Parties, this matters because verification is not only about getting an outcome, but also about being able to show later why that outcome was reached.
Trust status infrastructure (Trusted Lists / trusted entities)
Trust status information is another important layer. Even when signatures and certificate chains are technically correct, a Relying Party still needs to know whether the relevant trust anchors and entities are trusted at that moment. Standards such as ETSI TS 119 612, TS 119 615, and TS 119 602 help structure that part of the ecosystem. In practice, this is often more operationally demanding than it first appears: it is not just about reading a list once, but about keeping trust information up-to-date, monitored, cached, and compatible with evolving ecosystem expectations.
PKI policy foundations, crypto, signatures and certificate policy requirements
- ETSI TS 119 312
- ETSI TS 119 182-1
- ETSI TS 119 152-1
- ETSI EN 319 401
- ETSI EN 319 411-1
- ETSI EN 319 411-2
- ETSI EN 319 412-3
- ETSI EN 319 412-5
- ETSI TS 119 412-6
There is also the interoperability layer around cryptography, signatures, and certificate profiles. ETSI TS 119 312, ETSI TS 119 182-1, and ETSI TS 119 152-1 together with broader certificate policy and profile standards such as ETSI EN 319 401, EN 319 411-1, EN 319 411-2, the EN 319 412 series, and ETSI TS 119 412-6, all influence what a Relying Party stack will encounter in real wallet flows. Relying parties may not need to study every one of these standards in isolation, but their software does need to handle their consequences correctly and consistently.
An evolving ecosystem with evolving expectations
At the same time, this should not be seen as a fixed or exhaustive list. The EUDI Wallet ecosystem is still evolving, and ETSI standardization is evolving with it. Some standards are still maturing, some become more relevant as operational models are finalized, and others are newly published and may become important in adjacent or future flows. ETSI EN 319 486, for example, points toward Relying Party registry and ecosystem operational APIs, while ETSI EN 319 482-2 addresses deletion-request interfaces. Other work, including developments such as privacy-oriented standards, like ETSI TS 119 476-2, around selective disclosure and zero-knowledge proofs, shows that the landscape is still moving.
So in practice, becoming a serious EUDI Wallet Relying Party is not about simply adding the technical functionality to verify EUDI based digital credentials. It is about implementing a standards-driven trust stack that can interpret wallet presentations, validate trust and certificate inputs, support Relying Party identification and authorization, and remain interoperable as the ecosystem develops.
What Paradym handles for you
That is exactly the complexity Paradym is built to abstract. Paradym provides infrastructure for issuing and verifying digital verifiable credentials, including EUDI Wallet-related flows, that is aligned and up-to-date with the relevant ETSI standards and implementation expectations. When you define a presentation template in Paradym, you are not starting from raw protocol mechanics every time. And when a wallet presents data, Paradym handles the heavy lifting around integrity checks, trust validation, certificate processing, and structured output. What your application receives is what it actually needs: verified data in a usable format, ready for business decisioning.
Relying party verification, then, is not just a technical check. It is part of a broader ETSI-backed trust and interoperability model. Paradym turns that model into ETSI-aligned infrastructure, so teams can focus less on the plumbing and more on building reliable EUDI Wallet use cases.
To start with Paradym now, make an account, to discuss your use case or the ETSI requirements in depth, join our Community Slack!
