Working with different wallets
The enterprise service needs to accept and validate data from EUDI Wallet implementations in different countries, rather than supporting only one national wallet.
← Home
EIDAS 2.0 · EUDI WALLET & ATTESTATION
EUDI Wallet integration and electronic attestations of attributes.
Verifiable data from the EUDI Wallet (European Digital Identity Wallet) can simplify customer identification and replace some document requests. We design data acceptance, business validation and use, as well as attestation issuance from your own records. Integration connects the Namirial Wallet Platform to enterprise systems.
Integration services and readiness support for EUDI Wallet adoption
We support EUDI Wallet adoption from defining business use cases to implementing the integration. Wallet data acceptance and attestation issuance connect to existing onboarding, signing and enterprise systems.
Wallet acceptanceThe service requesting and using wallet data is the Relying Party (RP). Integration supports data acceptance and validation.
EAA / QEAAElectronic attestations of attributes (EAAs) and qualified attestations (QEAAs) can prove data, qualifications or entitlements.
Across the EUConnect with wallets from other EU Member States for cross-border data exchange and validation.
Starting point
EUDI Wallet integration spans an ecosystem, not a single application.
Relying parties, wallet providers, PID and attestation issuers, QTSPs, access-certificate providers and business data owners work together.
Selective disclosure
Presentation requests must ask only for attributes needed for the stated purpose.
Evidence and trust
Validate authenticity, issuer, status and presentation proof for PID, EAA and QEAA.
Issuer responsibility
Define who is responsible for the attested data, who issues the attestation, and how validity and revocation are managed. Qualified attestations also require a clear role for the qualified trust service provider (QTSP).
Capabilities
One integration layer for accepting EUDI Wallet data and issuing attestations.
Wallet Gateway
Cross-border EUDI Wallet connection between enterprise back ends and wallet implementations.
Presentation request
Purpose-bound, wallet-compatible requests derived from business use cases.
Technical and business validation
The Wallet Gateway performs technical validation of presented data. Contum middleware applies the client’s business rules and connects additional data sources where needed.
Documenting the checks
The service accepting wallet data (RP) receives records of the data exchange and validation results. These show which information supported the business decision. The client defines how and for how long they are retained.
Wallet Studio
Connect the client’s records to EAA or QEAA issuance workflows, keeping data-owner and qualified trust-provider responsibilities separate.
Signing integration
Connect wallet-based identity and Namirial or other signing components in one journey.
Integration
Namirial EUDI Wallet technology and QTSP services, with Contum solution design and integration.
Contum is not a QTSP. We provide process design, solution architecture, orchestration and integration; qualified trust services come from the selected QTSP.
Business application
Onboarding, customer portal or another enterprise process.
→Contum middleware
Business validation, data enrichment and APIs adapted to enterprise systems. For example, address-data retrieval through KKSZB/SASZ where access is authorised.
→Namirial Wallet Gateway
Wallet connectivity, standards-based presentations and technical validation.
→Wallet · PID · EAA · QEAA
Accept personal identification data (PID), electronic attestations of attributes (EAAs) and qualified attestations (QEAAs), and connect issuance workflows to wallets.
→Data owner and QTSP
The client is responsible for the attested data and the validity and revocation policy. Qualified attestations are issued by a qualified trust service provider (QTSP) authorised for that service.
Journey
Relying-party journey: from data request to business decision.
The user remains in control of data sharing, while the business system receives a validated, purpose-bound result.
Use case and registration
Define which service will accept wallet data, why it needs the data and which attributes are required. The accepting service provider’s registration is prepared accordingly.
Presentation request
Standard, purpose-bound data request sent to the wallet.
User approval
The customer authenticates, reviews and approves disclosure in the wallet.
Validation
Check authenticity, integrity, status, issuer and business rules.
Data and validation results
The business system receives the approved data, validation results and supporting records so it can continue onboarding or another customer transaction.
Use cases
Primary use cases
Customer identification and onboarding
Accept identity data and attestations, enrich missing information and connect to CDD.
Login and strong customer authentication
Prepare wallet-based authentication under the requirements applicable to the service.
Attestation issuance
Potential cases include bank-account and IBAN ownership, representation, income, insurance or professional entitlements. Schemas and availability are checked for each use case.
Signing and Business Wallet
Connect identity and signing, and prepare business-wallet use cases as the ecosystem develops.
Delivery
One digital-identity programme, not separate initiatives.
EUDI Wallet, AMLR onboarding and DÁP should share a target architecture, evidence model and API layer.
Use case and obligation
Relying-party role, purposes, data, legal basis, user experience and acceptance requirements.
Target architecture
Wallet Gateway, onboarding, Signing API, QTSP, DMS and enterprise data sources.
Pilot and interoperability
Presentation requests, wallet tests, validation, exception paths and cross-border scenarios.
Rollout and lifecycle
Registrations, certificates, monitoring, evidence retention and new use cases.
Ecosystem elements
eIDAS 2.0EUDI Wallet ARFPID · EAA · QEAANamirial Wallet PlatformWallet Gateway · Wallet · Wallet StudioContum middleware
WALLET QUESTION
Will you accept wallet data, issue attestations from your own records, or both?
In a use-case workshop we separate relying-party and issuer responsibilities, then create a shared implementation path.
EUDI Wallet workshop↗