Your organization just committed to verifiable digital credentials. The board wants mobile driver's licenses accepted for account opening. Product wants seamless onboarding. Legal wants privacy guarantees. You're now responsible for integrating technology that most of your team learned about three weeks ago.
This is where things go sideways.
Why These Mistakes Keep Happening
Verifiable digital credentials operate at the intersection of cryptography, identity management, and user experience. Your team knows IAM and PKI, but VDCs introduce a new vocabulary (issuers, verifiers, trust services) and a new architecture where your relying party systems must cryptographically verify credentials without contacting the issuer. The learning curve is steep, standards are evolving, and the pressure to ship is constant.
The mistakes below aren't about negligence. They're about mental models that worked for SAML and OAuth but break when you're verifying cryptographically signed credentials stored in digital wallets.
Mistake 1: Treating the Verifier as Just Another API Endpoint
Why it happens: Your team thinks of the verifier as middleware that sits between the wallet and your identity management system. It receives a credential, sends back a token, and your IDMS handles the rest. Simple, right?
The consequence: You build a verifier that can't distinguish between cryptographic verification (confirming the credential's authenticity and integrity) and business validation (assessing whether the claims meet your requirements). When a mobile driver's license arrives, your system either accepts everything the issuer signed or rejects valid credentials because you're conflating technical verification with policy decisions.
The fix: Separate your verifier logic into two distinct layers. The first layer performs cryptographic operations: it obtains the issuer's public key (often through a trust service), verifies the digital signature, and confirms the credential hasn't been tampered with. The second layer evaluates claims against your relying party requirements. Does this credential prove age over 21? Does it contain a current address? This separation lets you accept credentials from multiple issuers with different schemas while maintaining consistent business rules. Document which claims you require and which are optional before you write verification code.
Mistake 2: Hardcoding Issuer Public Keys
Why it happens: During proof-of-concept, you're working with one state DMV. You download their public key, embed it in your configuration, and verification works perfectly. When you expand to support credentials from other issuers, you copy the pattern.
The consequence: Every new issuer requires a code deployment. Key rotation becomes an operational nightmare. When an issuer updates their cryptographic keys (which they should do regularly), your verifier fails until someone manually updates the configuration and pushes a release. You've created a brittle integration that doesn't scale beyond a handful of issuers.
The fix: Integrate with a trust service from the start. Trust services act as centralized hubs that maintain current public keys from multiple issuers. Your verifier queries the trust service when it needs to verify a credential, retrieving the appropriate key dynamically. This architectural choice transforms key management from a deployment problem into a runtime lookup. When evaluating trust services, confirm they support the credential formats you'll encounter (ISO/IEC 18013-5 for mobile driver's licenses, W3C Verifiable Credentials for other use cases) and understand their availability guarantees. Your verifier must handle trust service failures gracefully, with appropriate logging and fallback behavior.
Mistake 3: Ignoring the Wallet-to-Verifier Protocol Stack
Why it happens: You assume that if your verifier can parse the credential format, presentation will work. The actual exchange mechanism (how the wallet and verifier establish a connection, negotiate protocols, and transfer data) seems like an implementation detail.
The consequence: Your web application generates a QR code that works with one wallet vendor but fails with others. Mobile app integrations require custom code for each operating system. Users scanning your QR code see error messages you can't reproduce because you're testing with a different wallet. You've built verification logic that can't actually receive credentials in production scenarios.
The fix: Choose your presentation protocols deliberately based on your use cases. For in-person verification (a user standing at a kiosk), ISO/IEC 18013-5 defines device engagement and data retrieval over Bluetooth Low Energy or NFC. For online verification (a user at home on their laptop), OpenID for Verifiable Presentations defines how browsers and mobile wallets coordinate using redirect flows. Test with multiple wallet implementations early. If you're supporting mobile driver's licenses, verify against wallets from Apple, Google, and at least one third-party provider. Document which protocols and transport mechanisms you support, and provide clear error messages when a wallet attempts an unsupported flow.
Mistake 4: Treating VDC Data Like SAML Assertions
Why it happens: Your IDMS is built around SAML assertions or OIDC claims. When the verifier extracts data from a credential, you map it directly into your existing user attributes and call it done.
The consequence: You lose the privacy advantages that VDCs offer. A mobile driver's license can selectively disclose attributes (proving you're over 21 without revealing your birth date), but your system demands full credential presentation because that's what your IDMS expects. Users see your service as just another entity collecting unnecessary personal data. You've implemented VDC support without capturing any of the privacy benefits.
The fix: Redesign your data collection flows around minimal disclosure. Before you request a credential, determine the specific claims you need for each transaction. Account creation might require name and address. Age-restricted purchases need only age verification. Implement request protocols that ask for specific attributes rather than entire credentials. Update your IDMS to handle partial attribute sets and null values for unrequested fields. This requires schema changes and business logic updates, but it's the difference between VDC theater and actual privacy-preserving identity verification. Document your Data Minimisation decisions for privacy impact assessments and regulatory compliance.
Mistake 5: Skipping Trust Service Redundancy Planning
Why it happens: You integrate with a trust service, verification works, and you move on to the next sprint. The trust service is someone else's infrastructure problem.
The consequence: When the trust service experiences an outage or network partition, your verifier can't obtain issuer public keys. All credential verification fails. Users can't open accounts, complete transactions, or access services. You have no fallback mechanism and no cached keys because you treated the trust service as infinitely available.
The fix: Implement defensive caching and fallback strategies. Cache issuer public keys with appropriate time-to-live values based on the issuer's key rotation schedule. When the trust service is unreachable, use cached keys while logging the degraded state. Define maximum cache age policies (7 days is reasonable for many use cases) beyond which you reject credentials rather than risk accepting credentials signed with revoked keys. Monitor trust service availability and establish SLAs with your provider. If you're building enterprise-critical flows, evaluate operating your own trust service infrastructure or maintaining relationships with multiple providers. Test your failure modes: disconnect from the trust service in staging and confirm your verifier behaves correctly.
Mistake 6: Forgetting That Wallets Are User Devices
Why it happens: You think of the wallet as part of your authentication infrastructure, like an authenticator app or hardware token that you control.
The consequence: You build flows that assume the wallet will always be available, that users won't uninstall wallet apps, and that credential recovery is someone else's problem. When users lose their phone or switch devices, they can't access your service because you didn't design account recovery flows that work when the VDC is unavailable. Your support team has no runbook for "user lost wallet."
The fix: Design account recovery and fallback authentication methods from day one. VDCs should enhance your authentication options, not become a single point of failure. Maintain traditional identity proofing paths for users who can't or won't use VDCs. Implement step-up authentication that lets users with verified credentials access sensitive functions while providing alternative paths for credential recovery. Document the user journey when a phone is lost, stolen, or factory reset. Work with your issuers to understand their credential reissuance processes and build your account recovery flows accordingly. Your IDMS should track which accounts were verified using VDCs and maintain that verification status even when the credential itself is no longer accessible.
Prevention Checklist
Before you deploy VDC verification to production:
- Your verifier separates cryptographic verification from business validation in distinct code paths
- You're using a trust service for dynamic key retrieval, not hardcoded public keys
- You've tested credential presentation with at least three different wallet implementations
- Your data collection requests only the specific attributes each transaction requires
- You've implemented and tested trust service caching with documented TTL policies
- Your account recovery process works when users lose access to their wallet
- You've documented which protocols (ISO/IEC 18013-5, OpenID4VP) and transport mechanisms you support
- Your error handling provides actionable messages for users and diagnostic data for your team
- You've confirmed that your IDMS schema supports partial attribute sets and selective disclosure
- You've tested failure scenarios: trust service outage, unsupported wallet, expired credential
VDCs represent a fundamental shift in how users prove identity claims. The mistakes above stem from trying to fit new cryptographic primitives into old architectural patterns. Fix them early, before they become production dependencies.
