How to Use a Digital Wallet: From Issuance to Presentation

The European Union is undergoing a historic shift in how identity is managed. By 2026, every EU member state must offer citizens and businesses at least one European Digital Identity Wallet (EUDI Wallet)  a secure, portable, privacy-preserving tool for storing and presenting identity information.

This isn’t just another app, it’s a fundamental redesign of digital trust. But how do these wallets actually work? And more importantly:

• How do you develop one?
• How do you issue, store, present, and revoke credentials?
• And how do all these pieces fit together?

Let’s walk through the entire journey from setup to selective disclosure with clear explanations, technical guidance, and a real-world example.

The EUDI Wallet Journey at a Glance

At a high level, here’s the user journey supported by EUDI-compliant infrastructure:
[User installs Wallet] 
      ↓ 
[Creates DID (identity)] 
      ↓ 
[Requests Credential from Issuer] 
      ↓ 
[Stores Credential in Wallet] 
      ↓ 
[Presents Credential to Verifier with Selective Disclosure] 
      ↓ 
[Verifier checks revocation + signature + Trusted Issuer]

Behind each of these steps lies a technical component that must be built, integrated, or hosted. Let’s go step-by-step.
 

1. Creating an EUDI Wallet (Holder App)

The wallet is the user’s personal identity vault. It stores credentials, manages cryptographic keys, and enables proof sharing.

How to develop a wallet:

1. Use React Native or Flutter to build a cross-platform app

2. Integrate with open-source libraries such as:
-did-jwt or didkit for creating DIDs
-Support DID methods like did:web, did:peer, or did:key

3. Implement secure local storage for private keys and credentials:
-Android: Keystore
-iOS: Secure Enclave

Wallets must follow the EUDI Architecture Reference Framework (ARF) and support:

• 1. Verifiable Credentials (VCs)
• 2. Verifiable Presentations (VPs)
• 3. OpenID4CI / OpenID4VP protocols
• 4. BBS+ or Ed25519 signature support
• 5. Zero-Knowledge Proofs (ZKPs) for selective disclosure
   

2. An issuer (like a university, government department, or health insurer) issues credentials after verifying a user’s claims.
 

How to build it:

 1.Set up an API backend to:

-Authenticate users (via eID, OAuth, QR code, etc.)
-Validate claims from internal DBs
-Create and sign VCs

2. Implement OpenID4CI or DIDComm for delivery

3. Use libraries like:
-Veramo
-Hyperledger Aries

4. Sign credentials using the issuer’s private key

The issued credential is cryptographically signed and stored in the user’s wallet.

3. Storing and Managing Credentials in the Wallet

After issuance, the credential is delivered to the wallet and stored securely.
 

1. Use encrypted storage: Keychain, EncryptedSharedPreferences, or sqlite + AES

2. Link the credential to the user’s DID and expiration status

3. Implement schema validation using JSON-LD contexts
 

Wallets must notify users about:

a. Expiring credentials

b. Credentials revoked by issuers

4. Building a Verifier App with Selective Disclosure

A verifier (e.g., website, airport, hotel, or bank) doesn’t want the whole credential, just the proof that the required condition is true.

For example, a nightclub doesn’t need your birthdate, only that you’re over 18.

How to build it:

a. Implement OpenID4VP to request a credential proof

b. Present a QR code, redirect URL, or DIDComm message

c. Accept the Verifiable Presentation (VP) from the wallet

d. Use BBS+ or AnonCreds to validate:

-Signature

-Schema

-Revocation status
 

Verifier doesn’t store the credential, it validates and discards.

5. Implementing Revocation Infrastructure
 

Sometimes credentials become invalid, a driver’s license expires, or a diploma is withdrawn.
Issuers must publish this status using revocation registries.

How to implement:

a. Use BitStringStatus (W3C standard) or AnonCreds revocation

b. Each VC links to a revocation URL

c. Verifiers fetch status on presentation

Smart wallets and verifiers automatically perform these checks.

A Real-World Example: EU Health Insurance Credential
 

Let’s say Anna, a German citizen, travels to France and visits a clinic.

Step-by-step:
 

1. Onboarding: Anna installs her country’s official EUDI Wallet. It generates a secure DID like did:peer:anna123.

2. Issuance: Her national health insurer issues a HealthInsuranceVC via OpenID4CI after verifying her policy. It includes:

a. Coverage provider

b. Expiry date

c. Basic policy category

3. Storage: The credential is securely saved in her wallet with expiry checks.

4. Presentation: At the French clinic, Anna scans a QR code from the clinic’s app, which requests proof of coverage.

a. Her wallet constructs a Verifiable Presentation.

b. She consents to share only the insurance provider and coverage status.

c. The clinic’s verifier checks the digital signature and revocation status.

5. Access granted: Without forms or photocopies, Anna is verified and treated, securely, instantly, and privately.
 

Terminology Recap

Why This Matters

The EUDI Wallet isn’t just a technology project, it’s the foundation for a cross-border trust infrastructure. From onboarding users to verifying credentials with precision, the entire ecosystem depends on robust, standards-aligned components.

At smartSense, we help organizations go from blueprint to live deployment, integrating:

• Wallet SDKs
• Issuer services
• Verifier APIs
• Revocation registries
• DID resolution
   

We are proud contributors to the EU trust landscape and 2-time Gaia-X Hackathon winners.

What’s Next?

Next Friday, we’ll show how to implement the Age Verification Use Case using ZKPs, a perfect example of what privacy-preserving, decentralized identity looks like in action.

Interested in co-developing your country’s wallet or credential stack? Let’s talk.