You've allocated budget for verifiable digital credentials. Your team has mapped the use cases. But when implementation begins, you'll face technical decisions that determine whether your system scales or stalls.
The shift from physical identity documents to digital credentials introduces architectural complexity that catches most teams off guard. The ISO/IEC 18013 standards for mobile driver's licenses represent one of the most mature implementations of this technology, and the mistakes organizations make during deployment reveal patterns that apply across credential types and use cases.
Why These Mistakes Keep Happening
Digital credential systems require coordination across three distinct roles: issuers who create credentials, holders who store them in wallets, and verifiers who accept them. Most organizations entering this space have experience in only one role. A financial institution implementing Know Your Customer verification thinks like a verifier. A state motor vehicle department thinks like an issuer. Neither naturally considers the holder's device constraints or the interoperability requirements that emerge when systems must work across all three roles.
The standards themselves compound this problem. ISO/IEC 18013-5 handles in-person presentation scenarios using NFC or QR codes. ISO/IEC 18013-7 supports remote presentation scenarios via the internet. OpenID for Verifiable Presentation (OID4VP) provides protocol options within 18013-7. Teams assume they can pick one path and ignore the others, but real-world deployment requires supporting multiple presentation modes simultaneously.
Mistake 1: Building for Only One Presentation Scenario
Your architecture team designs an elegant solution for in-person credential verification at physical checkpoints. Six months later, business requirements demand remote verification for online account opening, and you discover your wallet implementation can't handle both modes.
This happens because teams treat in-person and online presentation as separate projects rather than complementary modalities of the same system. A wallet that only implements device-to-device exchanges under ISO/IEC 18013-5 can't respond to internet-based presentation requests under 18013-7. Conversely, a verifier built exclusively for remote presentation can't process credentials at a point-of-sale terminal.
The fix: Design your wallet and verifier architecture to support both in-person and remote presentation from day one. Your holder's device must respond to both device-to-device exchanges and internet-based presentation requests. Map your use cases across both modalities during requirements gathering. A retail age verification system needs in-person POS integration. The same credential should also work for online age-restricted purchases. If your architecture can't support both, you're building technical debt.
Mistake 2: Ignoring Protocol Fragmentation Costs
Your team implements ISO/IEC 18013-7 Annex B for online presentation. Then you discover that some wallet vendors only support Annex C. Now you're maintaining two separate presentation protocols to reach the same users.
This mistake stems from treating protocol selection as a one-time decision rather than an ongoing maintenance burden. Annex B and Annex D of ISO/IEC 18013-7 specify OID4VP with different transfer mechanisms (HTTP redirects versus the W3C Digital Credentials API). Annex C builds on the device retrieval method from 18013-5. Each protocol requires distinct implementation effort, testing, and support infrastructure.
The fix: Before committing to a protocol, survey the wallet and verifier vendors in your ecosystem to understand what they actually support today, not what standards they claim to implement. If you must support multiple protocols, isolate that complexity behind an abstraction layer so your core verification logic remains protocol-agnostic. Track the OIDF working group that's chartered to harmonize these protocols and plan for migration when unified approaches emerge. Budget for protocol maintenance as an operational cost, not a one-time development expense.
Mistake 3: Treating Revocation as an Edge Case
Your implementation validates credential signatures and expiration dates, but you don't check revocation status because "credentials refresh frequently enough." Then a compromised credential gets used for three days before the next refresh cycle, and you're explaining the incident to your board.
This mistake happens because teams underestimate the window between credential compromise and effective revocation. Issuers refresh credentials to limit exposure, but latency remains. A credential revoked on Monday might remain cryptographically valid until Wednesday's refresh batch propagates to all verifiers.
The fix: Define your revocation requirements based on transaction risk, not technical convenience. For low-risk scenarios like age verification at point-of-sale, periodic refresh of trusted issuer keys may suffice. For remote financial onboarding or access to controlled systems, implement real-time status checks. Evaluate emerging mechanisms like IETF's Token Status List for balancing security, privacy, and availability. Your verification logic should explicitly handle scenarios where status information is unavailable or stale, including whether to fail open or closed based on risk context. Document these decisions in your risk assessment and ensure they align with your organization's risk appetite.
Mistake 4: Designing Flows That Train Users Badly
Your credential request asks for full name, address, date of birth, and license number when you only need to verify "over 21." Users learn to share everything by default, and you've just undermined the privacy model that makes selective disclosure valuable.
This mistake reflects a failure to apply Data Minimisation principles to credential design. Teams accustomed to form-based identity verification carry those patterns into digital credentials, requesting attributes they don't need because "we might need them later" or "it's easier to collect everything upfront."
The fix: Map every verification scenario to the minimum attributes required for that specific decision. Age verification needs a boolean "over 21" response, not a full date of birth. Account recovery needs proof of identity, not a current address. Design your presentation requests to ask for only those attributes. When your legal team insists on collecting more data "just in case," document the specific regulatory or business requirement that justifies each additional attribute. Review these requests quarterly to ensure they remain necessary. Your user experience team should test whether users understand what they're sharing and why; if they don't, your interface design needs work.
Mistake 5: Assuming Wallet Interoperability
Your pilot works perfectly with the wallet vendor you selected. Production launch reveals that 40% of your users have different wallet apps that implement the standards differently, and your verification flow breaks.
This mistake happens because teams test with reference implementations or preferred vendors rather than the messy reality of a multi-wallet ecosystem. Even when wallet vendors claim standards compliance, they may support different cryptographic options, device-binding mechanisms, or cross-device flow patterns based on their interpretation of draft specifications.
The fix: Identify the wallet applications your target users actually have installed, not the ones you wish they had. Build a test matrix covering at least the three most common wallet implementations in your user population. Test feature negotiation and fallback paths when wallets don't support your preferred cryptographic suite or presentation protocol. Participate in interoperability testing events where wallet and verifier implementations can identify gaps before production deployment. Design your error messages to help users understand compatibility issues without exposing technical details that confuse them. When you discover wallet-specific quirks, document them in your integration guide and share them with the broader implementation community.
Prevention Checklist
Before you finalize your digital credential architecture, verify:
- Your wallet and verifier implementations support both in-person (ISO/IEC 18013-5) and remote (ISO/IEC 18013-7) presentation scenarios
- You've documented which presentation protocols you support and surveyed whether your ecosystem partners can interoperate with those choices
- Your revocation strategy explicitly addresses the latency between credential compromise and effective revocation, with documented risk acceptance for that window
- Every credential presentation request is mapped to the minimum attributes required for that specific verification decision
- You've tested your implementation against at least three different wallet vendors to validate interoperability assumptions
- Your verification logic includes explicit handling for unavailable or stale status information, with risk-based decisions on whether to fail open or closed
- User consent flows clearly communicate what attributes are being shared and why, tested with actual users to confirm comprehension
- You've allocated ongoing budget for protocol maintenance and updates as standards mature and converge
Digital credential systems succeed when you design for the messy reality of multi-wallet, multi-protocol environments rather than the clean simplicity of single-vendor pilots. The technical standards provide the foundation, but your architectural decisions determine whether that foundation supports a system that scales.
