TL;DR: NIST’s draft mobile driver’s license guidance reframes identity verification around cryptographic proof and selective disclosure instead of document uploads, with the verifier receiving only the attributes needed for a transaction, according to 1Password’s analysis of the draft. The important shift is that identity proofing becomes standards-based and privacy-preserving, which changes how IAM teams think about trust, consent, and downstream authentication.
NHIMG editorial — based on content published by 1Password: analysis of NIST’s mobile driver’s license draft and its implications for digital identity
Questions worth separating out
Q: How should organisations use mobile driver’s licenses in identity proofing?
A: Use mDLs for high-assurance proofing events where the organisation needs cryptographic evidence and minimal data exposure, such as onboarding or regulated enrollment.
Q: Why do mDLs matter for privacy and data minimisation?
A: They matter because they let a verifier request only the attributes needed for a decision instead of collecting an entire identity document.
Q: What should security teams evaluate before adopting digital wallet identity flows?
A: They should evaluate whether the wallet, issuer, and verifier roles are clearly separated, whether consent is visible to the user, and whether the workflow relies on open standards rather than custom invocation logic.
Practitioner guidance
- Reduce identity data collection to transaction-specific attributes Review proofing workflows and remove fields that are not required for the decision being made.
- Separate issuer, wallet, and verifier responsibilities Document who issues credentials, who stores them, and who verifies them, then reject integration patterns that blur those boundaries.
- Standardise high-assurance identity flows before broad rollout Prioritise use cases like account opening, digital enrollment, and other high-risk transactions where cryptographic proofing adds clear value.
What's in the full article
1Password's full article covers the operational detail this post intentionally leaves for the source:
- How the W3C Digital Credentials API changes request visibility and reduces opaque wallet invocation patterns.
- The standards ecosystem behind mDLs, including ISO 18013-5/7, W3C Verifiable Credentials, and OpenID flows.
- Why CTAP-based proximity protections matter for cross-device verification.
- How the draft connects high-assurance proofing to later use of passkeys for everyday authentication.
👉 Read 1Password's analysis of NIST's mobile driver’s license draft and digital identity standards →
Mobile driver’s licenses and selective disclosure: what changes for IAM?
Explore further
mDLs expose how much of today’s identity proofing still relies on oversharing. A scanned document is treated as proof even though it transfers more personal data than the transaction needs. The selective-disclosure model in mDLs shows that many verification flows are built on convenience, not necessity. For identity leaders, the practitioner takeaway is to treat data minimisation as an access control decision, not just a privacy preference.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
A question worth separating out:
Q: How do mDLs fit with passwordless authentication?
A: mDLs are best treated as a proofing mechanism, not as everyday sign-in on their own. Once trust is established, organisations can provision a separate stronger authenticator such as passkeys for routine access. That keeps high-assurance identity verification distinct from ongoing authentication.
👉 Read our full editorial: mDLs shift digital identity from uploads to cryptographic proof