You've probably seen the pitch: Verifiable Digital Credentials will revolutionize identity verification, eliminate passwords, and make your existing identity infrastructure obsolete. The reality is more complex. VDCs represent a significant shift in how credentials are issued and verified, but integrating them into enterprise environments requires dispelling some persistent myths first.
These myths persist because VDC evangelism often skips past the hard integration questions. Standards bodies focus on protocols and data formats. Vendors highlight the user experience. Meanwhile, IAM architects are left wondering how a mobile driver's license ecosystem maps to their existing authentication flows, directory services, and access control policies.
Let's separate the marketing from the mechanics.
Myth 1: VDCs Are Just Digital Versions of Physical Credentials
Reality: VDCs are cryptographic proof containers, not scanned images.
When NIST describes VDCs as "cryptographically verifiable, digital representation of a credential," the key word is verifiable. VDCs are backed by public key cryptography. The issuer (your state DMV, your employer, your university) signs the credential with a private key. Verifiers check that signature using the corresponding public key, without contacting the issuer.
This isn't a PDF of your driver's license stored in Apple Wallet. It's a signed data structure that proves three things: the issuer created it, the claims inside haven't been tampered with, and (through additional cryptographic binding) you're the legitimate holder.
For your IDMS, this means you're not just accepting a credential presentation. You're validating a cryptographic signature chain, checking revocation status, and mapping claims from the VDC format into your internal identity schema. That's a different integration pattern than scanning a QR code or accepting a SAML assertion.
Myth 2: Public Key Infrastructure Is Someone Else's Problem
Reality: Your verifier needs access to issuer public keys, and that's your problem to solve.
Here's the integration gap most architects underestimate: before you can verify any VDC, you need the issuer's public key. In federated identity, you solve this with federation metadata or a well-known JWKS endpoint. In the VDC ecosystem, you solve it with trust services.
Trust services act as a centralized integration point for accessing cryptographic keys from multiple issuers. Instead of your relying party maintaining direct connections to every state DMV, university registrar, and health insurer that might issue credentials your users present, you integrate with a trust service that aggregates those keys.
But trust services aren't standardized yet. You'll need to decide whether to build direct integrations with issuers, connect to emerging trust registries, or wait for industry consolidation. Each choice has different operational overhead, key rotation requirements, and trust model implications.
If you're used to OAuth 2.0 where discovery documents and dynamic client registration smooth over these problems, VDC key distribution will feel primitive.
Myth 3: VDCs Eliminate the Need for Identity Proofing
Reality: VDCs shift identity proofing to issuance time, but your risk model might require additional verification.
In the mobile driver's license example, the state DMV performs identity proofing before issuing the credential to your digital wallet. When you present that mDL to open a bank account, the bank relies on the DMV's proofing work.
This is powerful for low-stakes transactions. But if you're granting access to financial systems, healthcare records, or privileged infrastructure, you might need additional verification steps beyond accepting the VDC claims at face value.
Your IDMS still needs to answer: Is this credential current? Has it been revoked? Does the biometric authentication performed in the wallet meet your assurance requirements? Are the claims in this credential sufficient for the access level being requested?
VDCs don't eliminate your identity governance responsibilities. They change the verification boundary. You're still accountable for access decisions, even when the credential comes pre-verified by a trusted issuer.
Myth 4: Wallets Are Interoperable
Reality: Wallet fragmentation is a current blocker, not a solved problem.
NIST notes that "depending on the entity issuing the VDC, users may need to download a wallet application supported by the credential issuer before a VDC can be issued to their phone." This is the opposite of interoperability.
If you're building a relying party application, you can't assume your users have a compatible wallet installed. You might need to support multiple presentation protocols (QR code scans, deep links, proximity-based exchange), multiple VDC formats, and multiple wallet providers.
This gets worse in enterprise contexts. If you issue employee credentials as VDCs, do you mandate a specific wallet? Do you support BYOD scenarios where employees use their personal device's built-in wallet? How do you handle wallet recovery when an employee loses their device?
Standards work is happening to address wallet interoperability, but it's not finished. Budget for complexity here.
Myth 5: VDCs Provide Perfect Privacy
Reality: Privacy depends on implementation choices, not the VDC concept itself.
One legitimate advantage of VDCs: the verifier can validate your credential without "phoning home" to the issuer. In the banking example, the DMV doesn't learn that you opened an account. That's better than many federated identity flows where the identity provider sees every relying party you authenticate to.
But privacy isn't automatic. It depends on:
- Whether the VDC format supports selective disclosure (presenting only the claims needed for a specific transaction)
- Whether the wallet implementation prevents correlation across verifiers
- Whether the trust service architecture creates new tracking points
- Whether your IDMS logs VDC presentations in ways that create audit trails the user didn't expect
If you're evaluating VDCs for privacy-sensitive use cases, audit the entire verification flow. The cryptographic properties of the credential format matter less than the data collection practices of every system that touches the presentation.
What to Do Instead
Start with use cases where VDCs solve a specific integration problem, not as a wholesale replacement for existing authentication.
Candidate scenarios:
- Onboarding contractors who already have government-issued digital credentials in their jurisdiction
- Accepting professional certifications as VDCs during access reviews, replacing manual certificate verification
- Verifying educational credentials during hiring without contacting universities directly
Integration prerequisites:
- Map VDC claim schemas to your internal identity attributes before you accept your first credential
- Establish key validation procedures, including how you'll handle key rotation and revocation checking
- Define which credential types and issuers you'll accept, and document the trust decisions behind those choices
- Plan for wallet diversity; don't assume a single presentation protocol
VDCs aren't replacing your IDMS. They're adding a new credential verification path that requires the same rigor you apply to SAML federation, OAuth 2.0 integration, or certificate-based authentication. Treat them accordingly.
