mDLs shift digital identity from uploads to cryptographic proof

At a glance

What this is: NIST’s mDL draft shows how government-issued identity can be verified cryptographically while revealing only the attributes needed for the interaction.

Why it matters: That matters because IAM teams are being pushed toward selective disclosure, stronger proofing, and interoperable wallets that can support both human identity and future high-assurance access patterns.

👉 Read 1Password's analysis of NIST's mobile driver’s license draft and digital identity standards

Context

Mobile driver’s licenses, or mDLs, move identity proofing away from document images and toward cryptographic verification. Instead of asking a user to upload a picture of a licence, the verifier receives a signed result that can confirm only the specific attributes needed for the transaction.

For IAM programmes, the important question is not whether mDLs replace every identity check, but where they change the trust model. They introduce selective disclosure, standardised wallet flows, and stronger evidence at high-risk moments such as account opening and digital enrollment. That is a human identity pattern, but the governance lessons carry into broader identity architecture.

The article’s starting point is typical for emerging identity standards: the technology is framed through one use case, yet the practical implications reach far beyond it. The real issue is interoperability, user consent, and how much unnecessary personal data organisations still collect as a default.

Key questions

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. Do not treat them as a general replacement for every identity step. The right model is selective disclosure, explicit consent, and standards-based verification tied to a clearly defined trust moment.

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. That reduces oversharing, storage burden, and downstream exposure. For practitioners, the key test is whether the workflow can be redesigned so only decision-critical attributes leave the wallet.

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. If those conditions are missing, the flow may create more ambiguity than assurance.

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.

Technical breakdown

Cryptographic verification versus document upload

Traditional identity verification often treats an uploaded licence image as if it were evidence. In practice, it is just a picture that must be processed, stored, and trusted indirectly. An mDL changes that model by using a signed credential issued by a trusted authority, stored in a wallet, and verified by a relying party. The verifier checks authenticity and requested attributes rather than inspecting an image. That shift reduces data exposure and makes proofing more machine-verifiable, but only if the ecosystem follows the standard flow rather than inventing custom wallet handoffs.

Practical implication: replace image-based proofing wherever cryptographic verification is available and the assurance level justifies the change.

Selective disclosure in digital identity flows

Selective disclosure means the user shares only the attributes required for a specific interaction, such as residency or age, rather than exposing an entire identity document. This matters because most verification workflows collect more data than the decision requires, increasing privacy risk and retention burden. mDLs make least-disclosure practical by making attributes individually requestable within a standards-based flow. The architecture does not eliminate trust, but it narrows what must be trusted and stored by the verifier.

Practical implication: map every identity proofing workflow to the minimum attribute set and remove fields that are not decision-critical.

Wallet, issuer, and verifier roles in high-assurance identity

The mDL ecosystem depends on three distinct roles. The issuer creates and signs the credential, the wallet holds and presents it, and the verifier checks authenticity and requested claims. This separation matters because security failures often appear when one role tries to absorb another, such as custom invocation paths or opaque requests that hide what is being asked for. Standards-based interaction keeps consent visible and makes proximity and device-binding controls possible in cross-device flows. In governance terms, the architecture only works when each role stays within its defined boundary.

Practical implication: design identity workflows around explicit issuer, wallet, and verifier responsibilities instead of ad hoc integration shortcuts.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Standards-based digital credentials are becoming a governance problem, not only a UX problem. Once identity proofing moves into wallets and verifiers, the quality of the surrounding protocol matters as much as the credential itself. Ad hoc wallet invocation, hidden request paths, and fragmented implementations create avoidable trust ambiguity. The field is heading toward interoperable identity proofing, and teams should expect more scrutiny on how requests are initiated and consented.

Selective disclosure will narrow the blast radius of human identity data, but only if programmes stop defaulting to full-document collection. mDLs demonstrate that the minimum necessary attribute can be verified without exposing the rest of the record. That is a discipline question for IAM, IGA, and compliance teams alike. Practitioners should rework proofing flows around decision-specific attributes rather than legacy document capture.

Digital wallets are converging with identity platforms, and that blurs old product boundaries. The article’s direction of travel is clear: a wallet is no longer just storage for passwords or tokens, but a control point for high-value credentials and proofing events. That expands the governance surface from sign-in alone to issuance, verification, consent, and credential lifecycle. Security teams should plan for a broader wallet-centric identity model, not just stronger authentication.

Interoperability is the real scaling constraint in digital identity. Global identity ecosystems fail when standards fragment into custom protocol islands. The article points toward a future where browser support, wallet behaviour, and verifier policy must align before mDLs can work at scale. For practitioners, the implication is simple: standards alignment is now part of identity architecture, not an optional integration detail.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• From our research: Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• That visibility gap matters as identity ecosystems expand, because cryptographic proofing for humans and workload identity governance for machines will increasingly need to coexist in one control plane.

What this signals

Selective disclosure should become a design requirement for human identity programmes. As mDL-style flows mature, the baseline expectation will shift from document capture to attribute-level verification. Organisations that keep collecting full identity records for narrow decisions will carry unnecessary privacy and retention risk, while those that redesign proofing around minimum necessary data will be better positioned for wallet-based identity.

The broader signal is that identity architecture is moving toward protocol discipline. The combination of verifiable credentials, browser-aware wallet flows, and stronger assurance at trust moments means IAM teams need to think more like standards implementers and less like form builders. That also makes the boundary between proofing, authentication, and consent more operationally important.

Identity proofing is becoming a lifecycle question, not a one-time event. Once a credential is issued into a wallet, organisations still need to think about verification scope, downstream authentication, and the conditions under which higher assurance is required again. The programme implication is clear: proofing, authentication, and recovery must be designed as linked controls, not separate projects.

For practitioners

• Reduce identity data collection to transaction-specific attributes Review proofing workflows and remove fields that are not required for the decision being made. If a verifier only needs residency or age, do not ask for or retain the full document image.
• 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. This makes consent, trust, and auditability easier to enforce.
• 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. Use standards-based flows instead of custom wallet invocation paths.
• Use mDLs as a trigger to modernise authentication Where proofing succeeds, provision a separate everyday authenticator such as passkeys for ongoing access. That keeps identity proofing and daily authentication in the right places in the lifecycle.

Key takeaways

• mDLs replace document uploads with cryptographic verification, which materially changes how identity assurance is established.
• The biggest governance gain is selective disclosure, because it limits how much personal data a verifier must collect and retain.
• IAM teams should treat standards-based proofing, wallet roles, and downstream authentication as one lifecycle, not three disconnected problems.

Key terms

• Mobile Driver’s License: A mobile driver’s license is a government-issued digital credential that can be stored in a wallet and presented as cryptographic proof. It is designed to support selective disclosure, so the verifier receives only the attributes needed for a specific transaction rather than a full identity document.
• Selective Disclosure: Selective disclosure is the practice of sharing only the identity attributes needed for a specific decision. In credential-based systems, it reduces oversharing, lowers retention burden, and limits exposure when a verifier does not need the full record to make a trustworthy judgment.
• Digital Wallet: A digital wallet is a secure software container used to store, protect, and present credentials or identity attributes. In modern identity flows, it acts as the user-controlled presentation layer between the issuer and the verifier, and its behaviour affects consent, assurance, and privacy.
• Identity Proofing: Identity proofing is the process of establishing that a person is who they claim to be before granting a credential or access path. In high-assurance systems, it depends on trustworthy evidence, clear verification steps, and a defined trust moment rather than ad hoc document collection.

Deepen your knowledge

Selective disclosure, identity proofing, and wallet-based assurance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building identity governance that has to span human and non-human trust decisions, it is worth exploring.

This post draws on content published by 1Password: analysis of NIST’s mobile driver’s license draft and its implications for digital identity. Read the original.