Product Overview

Digital Identity Wallet Gateway (DIW Gateway) enables a bank to act both as a service provider requesting attributes from EU Digital Identity Wallet (EUDIW) — the Relaying Party (RP) — and as a Trust Service Provider (TSP) issuing Electronic Attestations of Attributes — the EAA Provider.

This supports consuming and issuing wallet-based credentials across digital and in-person channels, enables online and offline EUDIW utilization (including branch/proximity scenarios), and integrates with existing onboarding, authentication, and signing journeys while remaining aligned with the EUDIW Architecture and Reference Framework and the broader eIDAS 2.0 regulatory direction.

Key features include:

• Use Case profiles - Ready-made profiles for specific banking use cases, defining required data sets and helping you align wallet data with your business logic.
• Data mapping and normalization - Map decentralized and country-specific PID formats to your internal data models.
• Standard attestations format - Issue correctly formatted attestations to the Wallet app for internal and third-party use.
• Post-quantum cryptography - Issue quantum-safe attestations using NIST-endorsed post-quantum cryptography algorithms.
• RESTful APIs - Integrate smoothly into existing backend systems using standardized APIs.
• Regulatory and standards expertise - Benefit from continuous monitoring of ARF, implementing acts, and wallet interoperability requirements.

High-Level Architecture

Wultra’s solution consists of backend components and web and mobile SDKs. These components work together to provide seamless integration with the EUDIW ecosystem. The backend components are loosely coupled, and depending on requirements, only a subset can be used.

Backend Components

The backend infrastructure for the solution consists of the following components:

DIW Verifier

The component verifies received Verifiable Presentations (VP). It communicates with all necessary Trust Anchors to ensure that trusted parties cryptographically sign the received VP, and that the parties are entitled to issue the Verifiable Credentials (VC) contained in the VP. A configurable static transformation is applied on the verified VC to ensure seamless integration with a client’s canonical data model.

OpenID4VP Connector

The component constructs an Authorization Request to the EUDIW Unit and ensures the request is authorized correctly. The components support the Digital Credentials Query Language (DCQL). All modes of providing (i.e., direct and via the Request URI) and receiving response modes (including direct_post) are supported.

DIW Issuer

The component constructs and signs the requested Verifiable Credentials (VC). Configurable static mapping helps integrate the client canonical data model with the syntax and VC Rulebook of the EUDIW ecosystem.

OpenID4VCI Connector

The component serves as an Authorization Server supporting the OpenID4VCI extension. The component is intended to fully leverage the EUDIW authentication mechanism and enable a smooth user experience. Pre-authorized flows and pushed Attestation-Based Client Authentication are provided.

Web and Mobile SDKs

The SDK libraries ensure that the integration process with the EUDI Wallet is straightforward and flexible across different platforms (mobile, web, and front-office).

The SDKs support the roles of the Relying Party in receiving data from EUDIW and the EAA Provider for issuing verifiable credentials.

• In RP mode, SDKs convert proximity and remote same-device and remote cross-device flows via QR Codes, NFC Tags, and deep links.
• In EAA Provider mode, the SDKs help construct QR codes and links to advertise Credentials Offer for Issuer-initiated flows.

Third Parties

Third Parties acting in EUDIW ecosystem.

Registrars

Member states appointed bodies that register Relaying Parties and EAA Providers.

Trusted Lists

Each registrar maintains a list of registered entities (Relaying Parties and Attestation Providers) with their trust anchors and links to the Providers’ Revocation List Mechanism.

Registrar Certification Authority

Registrar appointed Certification Authority or Authorities. EUDIW Verifier and EUDIW Issuer integrate with the CA to issue the required Access and Registration certificates.

Common Trust Infrastructure

The EU Commission provides a list of trusted lists for all entities to find all Trusted lists in the ecosystem.

EUDIW Verifier and EUDIW Issuer integrate with the Common Trust Infrastructure (CTI).

Providers

General terms for entities issuing attestation to the EUDIW Units.

There are several types of Providers:

• Personal Identification Data (PID),
• Qualified Electronic Attestation of Attributes (QEAA),
• Non-Qualified Electronic Attestation of Attributes (EAA),
• and an Electronic Attestation of Attributes issued by or on behalf of a public sector body (PuB-EAA).

System Architecture

Technical Architecture

Deployment

The components are delivered as specialized services in OCI-based images and follow a cloud-agnostic, container-agnostic approach. SaaS version available.

Integration Patterns

The primary integration pattern is via exposed RESTful services – this pattern fully covers all required scenarios, including management.

The Issuer and Verifier components actively communicate with Trust Registries and Registrar CA.

For specific events, such as issuing Verifiable Credentials or verifying a Verifiable Presentation, REST Webhooks can be parameterized.

Scalability and Availability

The solution is fully horizontally scalable. Multiple application containers can be used to facilitate load requirements. The components are scalable independently.

All containers are stateless, and synchronization communication is required – i.e., deploying the solution in multiple zones provides High Availability and Disaster recovery capabilities. External dependencies – database, and optionally HSM, must support deployment in multiple availability zones to achieve HA-DR.

Security and Trust Model

Private APIs of components support OAuth 2.x and Basic Authentication for communication, authentication, and authorization control.

The trust model is based on internal permissions (specified per API) and Role-Based Access Control (RBAC) to map identities to specific permissions.

The role management is either external, in the case of the OAuth framework, or internal in the case of Basic authentication.

Access management is possible via the administration API.

Operational Capabilities

Monitoring and Alerting

Components provide standard structured application logging to a container system. Each container also provides a standard Prometheus monitoring endpoint. Containers can be instrumented to produce metrics and traces in multiple standard formats (e.g., OpenTelemetry).

Overall, the solution is agnostic to the Observability platform used.

Auditing

Each component provides a complete audit trail and an API for reading and exporting the audit records. The audit structure and format follow the recommendations of ISO 27001, ISO 27002, and ISO/IEC 17799:2005.

Data Retention

The data retention policies are configurable for audit logs, Verifiable Credentials (attestations) storage, and storage for received Verifiable Presentations.

As part of our data protection and privacy-by-design approach, we apply a consistent storage pattern: we store VP/VC data separately from the cryptographic material included with the VP/VC (e.g., proofs and related key material).

Where only hashes are retained, they are treated as anonymized data and do not require separate storage. This separation enables the integrity of the stored record to be verified even after the original content has been deleted.

Configuration and Secrets Management

The technical related configuration is managed by container environment variables. For secrets - secret manager (like Azure Key Vault or HashiCorp Vault) is expected. Parameterization of the system is stored in an underlying database and managed via the administration API; sensitive data are protected by additional application encryption.

Core Functions

Functionality	Description
User Identification and Authentication	Enables secure user identification and authentication through the digital wallet. Supports PID retrieval and validation, multiple authentication methods (QR, NFC, application handshake), and authorization of sensitive operations.
Issuing Attestation to the Wallet Unit	Allows organizations to issue and manage their own attestations into the digital wallet. Issued credentials can be used in internal processes or shared with third parties, with support for revocation and status verification.
PID Mapping	Helps interpret and standardize Personal Identification Data (PID) received from different countries and providers, enabling consistent use of identity data within business processes.
Verifiable Credential Mapping	Maps data from received Verifiable Presentations (VPs) and issued Verifiable Credentials (VCs) to the organization’s internal canonical data model through configurable credential mappings.
Profile Concept	Supports business-specific data collection through configurable profiles that define required credential types and related metadata. Profiles aggregate, process, and verify the required data provided by EUDI Wallets.
Utilizing Qualified Electronic Signatures	Enables users to sign documents with Qualified Electronic Signatures (QES) through their EUDI Wallet. The DIW Gateway manages communication between the EUDI Wallet and the QTSP.

Testing

DIW Gateway can be deployed in test mode for integration testing with national sandboxes. The solution also offers testing tools to simulate traffic of presentations and issuing flows to support clients’ automated testing and performance testing.