EUDI Wallet relying-party integration: what SaaS providers should prepare

Start with the relying-party role, not the UI

A product that consumes information from a European Digital Identity Wallet acts as a wallet relying party. The integration therefore starts with the legal and technical identity of the relying party, the purpose of the request and the attributes the service intends to request.

For SaaS platforms this becomes more interesting when multiple customer organisations use the same technical product. The software needs a clean separation between shared verifier infrastructure and tenant-specific relying-party configuration.

Registration and requested data need to stay aligned

The amended eIDAS framework requires wallet relying parties to register in the Member State where they are established. Registration information includes the intended use of the wallet and the data that the relying party expects to request.

That makes attribute requests an operational configuration problem as well as an integration problem. A robust platform should make it difficult for a tenant to request attributes outside its registered purpose.

• Store relying-party identity and registration context per organisation.
• Model requested attributes as explicit policy, not hard-coded UI fields.
• Keep environment, tenant and use-case configuration separate.
• Record verifier events in an audit-friendly way.

The verifier layer should be reusable

A verifier has to create requests, authenticate the interaction, receive wallet responses and validate the returned information before the business process continues. Rebuilding that logic separately in every customer application creates unnecessary operational risk.

A shared verifier layer can centralise protocol handling while allowing each tenant to define what it needs, where the result should go and which workflow should continue after successful verification.

Think beyond the first successful wallet flow

Production readiness includes key rotation, configuration changes, failed verification states, observability, audit events and a clear distinction between technical verification and the business decision that follows.

For a SaaS provider, the best architecture is usually one in which wallet-specific complexity lives behind a stable internal API. Product teams can then consume a verified result without having to understand every protocol detail.

Where Adminyra EUDI fits

Adminyra EUDI is being built around this multi-tenant control-plane model: one verifier-oriented integration layer with separate tenant configuration, policy and operational context.

The goal is not to replace the customer's product. It is to give that product a controlled way to request and validate wallet-based identity interactions without rebuilding the shared infrastructure for every implementation.