Product Overview

Digital Identity Wallet Gateway (DIW Gateway) enables a bank to participate in the EUDIW ecosystem both as a Relying Party (RP) requesting and verifying attestations presented by Wallet Units and as an Attestation Provider issuing attestations to Wallet Units.

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

DIW Gateway consists of loosely coupled backend components and web and mobile SDKs that provide integration between client systems and the EUDIW ecosystem.

The backend is composed of DIW Verifier, DIW Issuer, and DIW Connector. Depending on the required use cases, only the relevant components need to be deployed and used.

DIW Gateway also integrates with the EUDIW trust infrastructure for trust and certificate validation, while client applications and backend systems integrate with DIW Gateway through its APIs and SDKs.

Backend Components

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

DIW Verifier

DIW Verifier provides the backend capabilities for receiving and verifying attestations presented by Wallet Units. Its responsibilities cover Relying Party management, cryptographic key and certificate management, attestation verification, and management of received attestations.

• Relying Party Management: Manages the lifecycle of Relying Parties, including their registration and registration certificates.
• Keys and certificates: Manages the cryptographic keys and access certificates used for communication with Wallet Units.
• Attestation Verification: Handles the verification process and validates attestations received from Wallet Units.
• Received Attestation Management: Maintains records of received attestations and provides APIs for accessing them. Verification processes and received attestations can be associated with external identifiers, such as Correlation IDs, enabling integration with external business processes.
• Attestation Status Verification: DIW Verifier verifies the current status of received attestations using the applicable status or revocation mechanism, such as a Status List.

DIW Issuer

DIW Issuer provides the backend capabilities for issuing and managing attestations. Its responsibilities cover Attestation Provider management, cryptographic key and certificate management, attestation issuance, and management of issued attestations.

• Attestation Provider Management: Manages the lifecycle of Attestation Providers, including their registration and registration certificates.
• Keys and Certificates: Manages the cryptographic keys and certificates used for attestation signing and communication with Wallet Units. Cryptographic keys can optionally be protected using an HSM.
• Attestation Issuance: Handles the attestation issuance process, including the verification steps required by the applicable trust model.

• Issued Attestation Management: Maintains records of issued attestations and provides APIs for accessing them. Issuance processes and issued attestations can be associated with external identifiers, such as Correlation IDs, enabling integration with external business processes.

  For attestations with longer validity periods, DIW Issuer can also verify the status of the Wallet Unit to which the attestation was issued, depending on the configured policy.

DIW Connector

DIW Connector provides the public protocol interface between DIW Gateway and Wallet Units.

Its responsibilities cover OpenID4VP and OpenID4VCI communication and the authorization flows required for credential issuance.

• Wallet Communication: Provides the public OpenID4VP and OpenID4VCI interfaces used for communication between DIW Gateway and Wallet Units.
• Presentation Flows: Handles the OpenID4VP protocol communication required for presenting attestations from a Wallet Unit to DIW Gateway.
• Issuance Flows: Handles the OpenID4VCI protocol communication required for issuing attestations to a Wallet Unit.
• Authorization: Provides the OpenID authorization capabilities required for credential issuance, including Authorized Flow and Pre-Authorized Flow.

Web and Mobile SDKs

DIW Gateway provides SDKs that simplify the integration of EUDIW interactions into client-facing applications and channels.

The primary role of the SDKs is to facilitate communication with Wallet Units from client applications, including communication through the Digital Credentials API (DC API) and QR code generation.

The SDKs work together with the DIW Gateway backend components to support integration with the EUDIW ecosystem. Depending on the required use cases, only the relevant components need to be used.

Third Parties

DIW Gateway interacts with external entities and trust infrastructure that form part of the EUDIW ecosystem.

Registrars

Registrars are responsible for registering entities participating in the EUDIW ecosystem, such as Relying Parties and Attestation Providers.

Registration establishes the entity’s role and the information required for its participation in the applicable trust framework.

Trusted Lists

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

DIW Gateway uses relevant EUDIW Trusted Lists to validate the trustworthiness of counterparties and their certificates. Trust information is processed by DIW Gateway and used during technical validation of EUDIW interactions.

Registrar Access Certification Authority

DIW Gateway works with the relevant Registrar Certification Authorities as part of the EUDIW trust infrastructure.

For registered Relying Parties and Attestation Providers, DIW Gateway supports the preparation of certificate signing requests (CSRs) and configuration of issued 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.

DIW Gateway integrates with the relevant Common Trust Infrastructure and Trusted Lists as part of its trust validation process.

Attestation Providers

Attestation Providers are entities that issue attestations to Wallet Units.

Depending on their role and the type of attestation they issue, they may act as providers of:

• Person 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.

Multitenancy and Group Deployment

DIW Gateway supports deployment scenarios where the solution is used by multiple entities within an organization.

DIW Gateway can be operated as a shared multi-tenant deployment or as separate deployments for individual entities within an organization or financial group.

Multi-Tenant Deployment

In a multi-tenant deployment, multiple entities can use a shared DIW Gateway deployment. Each entity can maintain its own entity-specific configuration, which remains logically separated from the configuration of other entities.

Entities are logically separated within the system. Access to individual entities is controlled through user accounts and permissions associated with the respective entity.

Single-Tenant Deployment

Alternatively, individual entities can operate separate DIW Gateway deployments. Separate deployments provide separation at both the network and data levels.

This model can be used, for example, for individual entities or countries within a financial group.

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.

Transaction Identifiers and Correlation

DIW Gateway provides transaction identifiers that support correlation and traceability of operations:

Transaction ID

• A Transaction ID uniquely identifies a transaction within DIW Gateway.
• It is used internally by DIW Gateway to correlate operations belonging to the same transaction and allows the integrating system to retrieve and track the corresponding transaction.

Correlation ID

• An external Correlation ID can be provided by the integrating system to associate the transaction with its own business process.
• It allows the integrating organization to associate a DIW Gateway transaction with its own session, business process, or other external context.
• DIW Gateway does not require additional business context to be transferred when the Correlation ID is sufficient for maintaining this association.

Request ID

• A Request ID identifies the request used in communication with the Wallet Unit.
• It is generated as part of the wallet interaction and is used by DIW Gateway for technical correlation of the wallet flow. The Transaction ID is used internally by DIW Gateway and is not exposed to the Wallet Unit.

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

DIW Gateway provides the security and trust capabilities required for integration with the EUDIW ecosystem and the integrating organization’s systems.

The security model covers cryptographic key and certificate management, EUDIW trust validation, access control, secure communication, and protection of transaction and attestation data. In a bank-hosted deployment, cryptographic keys and other security-sensitive infrastructure can remain under the control of the integrating organization.

Trust in EUDIW entities, certificates, and presented credentials is established using the applicable EUDIW trust infrastructure and technical validation mechanisms.

Trust Boundaries

DIW Gateway separates EUDIW-facing communication and technical validation from the integrating organization’s internal integration and business decision-making systems.

The architecture defines separate trust boundaries between the EUDIW ecosystem, DIW Gateway, the organization’s integration layer, and its internal business systems. The integration layer provides a controlled technical boundary between DIW Gateway and internal systems.

Operational Capabilities

DIW Gateway provides operational capabilities for running and managing the solution in enterprise environments.

These capabilities include auditing and structured application logging, monitoring and observability, configurable data retention and system configuration and secrets management.

DIW Gateway can integrate with the organization’s existing operational infrastructure for observability, log management, SIEM and secrets management. In a bank-hosted deployment, the corresponding infrastructure and operational policies remain under the control of the integrating organization.

Core Functions

Functionality	Description
Attestation Verification	DIW Gateway enables Relying Parties to request and verify attestations presented by an EUDI Wallet.
Attestation Issuance	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.
Identity Verification with PID	PID presented from an EUDI Wallet can be used as an identity input for banking processes such as digital onboarding, KYC/AML processes, user identity verification, and access management for existing users.
Authentication and Authorization with SUA	SUA attestation can be used with an EUDI Wallet for user authentication and for authorization scenarios, including electronic payment use cases.
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.
Registered Entity Management	Manages Relying Parties and Attestation Providers and their registration in the EUDIW ecosystem.

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.

Product Roadmap

DIW Gateway is continuously evolving together with the EUDIW ecosystem and related standards. The product roadmap currently includes further development in the following areas.

Offline and Proximity Verification

Support for proximity and offline verification based on ISO/IEC 18013-5 is planned, including data exchange over NFC and Bluetooth.

A dedicated Offline Verifier SDK is also planned to enable local verification on devices without an online connection. The level of verification may be limited in offline mode because online trust information is not available.

Data Protection and Persistence

Further data-processing capabilities are planned, including application-level encryption and a non-persistent mode for attestation issuance.

For longer data-retention scenarios, encryption of PII stored in the database is also planned.

Credential Re-Issuance with New Data

Support for re-issuance with retrieval of current data is planned, allowing credential attribute values to be updated based on data retrieved from the Bank’s systems during the re-issuance process.