Wallet Instance
technicalFull Name: EUDI Wallet Instance
Definition
A Wallet Instance is a single, activated installation of the EUDI Wallet application on a specific user device, representing the complete runtime environment for the user's digital identity operations on that device. Each wallet instance is uniquely identified by its own cryptographic key pair (generated in and protected by the device's TEE or Secure Enclave during activation), possesses a Wallet Instance Attestation (WIA) issued by the wallet provider that certifies its legitimacy and security properties, and maintains its own secure storage of credentials (PID, QEAAs, EAAs) and associated metadata. The wallet instance is the fundamental unit of trust in the EUDI Wallet architecture: when a credential issuer issues a credential, they issue it to a specific wallet instance (binding it to that instance's key pair); when a verifier receives a credential presentation, they verify it was made by a legitimate wallet instance (by checking the WIA and key binding proof). The hardware binding of cryptographic keys to the device's secure element ensures that wallet instances cannot be cloned, copied, or transferred between devices, maintaining the one-to-one relationship between a wallet instance and a physical device that is essential for the security of the entire system.
Wallet Instance Lifecycle
The lifecycle of a wallet instance begins with installation and activation. The user downloads the EUDI Wallet application from their device's app store (Google Play or Apple App Store) and launches it for the first time. During activation, the wallet application generates a new asymmetric key pair within the device's TEE (Android) or Secure Enclave (iOS), ensuring that the private key never exists outside the hardware security module. The wallet then contacts the wallet provider's backend to register the new instance and request a Wallet Instance Attestation.
The wallet provider verifies the instance before issuing the WIA. This verification includes checking the device's hardware attestation (Android SafetyNet/Play Integrity or iOS DeviceCheck/App Attest) to confirm the device is genuine and has not been tampered with, verifying that the wallet application is the legitimate certified version (not modified or repackaged), checking that the device's security capabilities meet the minimum requirements (TEE certification level, OS version, security patch level), and confirming that the instance's public key was generated within the device's secure element. If all checks pass, the wallet provider issues a signed WIA that the instance stores alongside its key pair.
After activation, the instance enters its operational phase where the user can request and store credentials. The user typically starts by requesting their Person Identification Data (PID) from their national identity authority, which involves identity proofing (verifying the user's real-world identity via existing eID, in-person verification, or video identification) and credential issuance via the OpenID4VCI protocol. The PID credential is bound to the wallet instance's key pair, meaning it can only be presented using that specific instance. The user can then request additional credentials (driving licence, educational diplomas, professional qualifications) from various issuers, each bound to the same instance.
Wallet Instance Attestation and Trust Chain
The Wallet Instance Attestation (WIA) is a critical component of the EUDI Wallet's trust architecture. It serves as proof that a credential presentation originates from a legitimate, certified wallet instance running on a secure device. Without the WIA, a credential issuer or verifier would have no way to distinguish a genuine wallet instance from a software emulator, a compromised device, or a counterfeit wallet application designed to intercept or forge credentials.
The WIA creates a trust chain from the device hardware to the credential presentation. The device manufacturer certifies the TEE/Secure Enclave hardware through device attestation. The wallet provider verifies the device attestation and certifies the wallet instance through the WIA. The credential issuer verifies the WIA before issuing a credential to the instance. The verifier checks the key binding proof (signed by the instance's device-bound key) to confirm the presentation comes from the same instance that received the credential. This multi-layered trust chain ensures that at each step, the participating entity can verify the security and legitimacy of the wallet instance it is interacting with.
The WIA has a defined validity period and must be periodically renewed. During renewal, the wallet provider re-checks the device's security status (ensuring the device has not been rooted, jailbroken, or had its security patch level fall below requirements) before issuing a fresh WIA. If the device fails the re-verification (for example, because the user has rooted their phone or a critical security vulnerability has been discovered in the device's TEE), the wallet provider can refuse to renew the WIA, effectively disabling the wallet instance until the security issue is resolved. This ongoing verification ensures that wallet instances maintain adequate security throughout their operational lifetime.
Multi-Instance Management and Device Migration
The EUDI Wallet architecture supports multiple wallet instances per user, recognizing that people use multiple devices in their daily lives. Each instance operates independently with its own keys, WIA, and credentials. This independence is a deliberate security design: if one device is compromised or lost, the credentials on the user's other devices are unaffected. The trade-off is that credentials must be separately requested for each device, as the device-bound key architecture prevents credential transfer between instances.
Device migration (setting up a wallet on a new phone when replacing an old one) requires activating a new wallet instance on the new device and re-requesting all credentials from their respective issuers. While this may seem inconvenient compared to simply restoring from a cloud backup, the device-bound key architecture makes this approach necessary for security. Cloud backup of wallet credentials would mean the private keys exist outside the device's secure element, fundamentally undermining the hardware security guarantee. The credential re-issuance process is streamlined by the wallet's integration with credential issuers: the user authenticates to the issuer, and the issuer can verify the user's existing identity and re-issue the credential to the new instance without requiring full identity proofing again.
Wallet instance deactivation occurs when the user explicitly deactivates the instance, when the wallet provider revokes the WIA (due to device compromise, security policy violations, or user report of device loss), or when the instance fails to renew its WIA within the required timeframe. Upon deactivation, the wallet provider marks the instance as inactive, credential issuers can be notified to revoke credentials bound to that instance, and the cryptographic keys in the device's secure element can be deleted. The user's identity and credentials on other active instances are not affected by the deactivation of a single instance.