The Technology Powering Digital Identity

Read the first installment in our series on The Future of Digital Identity in America here and the second installment here.

If policy sets the rules of the road, technology lays the pavement. Without strong technical foundations, decentralized identity would remain an inspiring vision but little more. What makes it real are the advances in cryptography, open standards, and system design that let people carry credentials in their own wallets, present them securely, and protect their privacy along the way. These technologies aren’t abstract: they are already running in production, powering mobile driver’s licenses, digital immigration pilots, and cross-border banking use cases.

Why Technology Matters for Identity

Identity is the trust layer of the digital world. Every interaction - logging into a platform, applying for a loan, proving eligibility for benefits - depends on it. Yet today, that trust layer is fractured. We scatter our identity across countless accounts and passwords. We rely on federated logins controlled by Big Tech platforms. Businesses pour money into fraud prevention while governments struggle to verify citizens securely.

The costs of this fragmentation are staggering. In 2024 alone, Americans reported record losses of $16.6 billion to internet crime (FBI IC3) and $12.5 billion to consumer fraud (FTC). At the institutional level, the average cost of a U.S. data breach hit $10.22 million in 2025 (IBM). And the risks are accelerating: synthetic identity fraud drained an estimated $35 billion in 2023 (Federal Reserve), while FinCEN has warned that criminals are now using deepfakes, synthetic documents, and AI-generated audio to bypass traditional checks at scale.

Decentralized identity offers a way forward; but, only if the technology can make it reliable, usable, and interoperable. That’s where verifiable credentials, decentralized identifiers, cryptography, and open standards come in.

The Standards that Make it Work

Every successful infrastructure layer in technology—whether it was TCP/IP for the internet or HTTPS for secure web traffic—has been built on standards. Decentralized identity is no different. Standards ensure that issuers, holders, and verifiers can interact without building one-off integrations or relying on proprietary systems.

Here are the key ones shaping today’s decentralized identity landscape:

• W3C Verifiable Credentials (VCs): This is the universal data model for digital credentials. A VC is essentially a cryptographically signed digital version of something like a driver’s license, diploma, or membership card. It defines how the credential is structured (with attributes, metadata, and signatures) so that anyone who receives it knows how to parse and verify it.
• Decentralized Identifiers (DIDs): DIDs are globally unique identifiers that are cryptographically verifiable and not tied to any single registry. Unlike email addresses or usernames, which depend on central providers, a DID is self-sovereign. For example, a university might issue a credential to did:example:university12345. The DID resolves to metadata (such as public keys) that allows verifiers to check signatures and authenticity.
• OID4VCI and OID4VP (OpenID for Verifiable Credential Issuance and Presentation): These protocols define how credentials move between systems. They extend OAuth2 and OpenID Connect, the same standards that handle billions of secure logins each day. With OID4VCI, you can request and receive a credential securely from an issuer. With OID4VP, you can present that credential to a verifier. This reuse of familiar login plumbing makes adoption easier for developers and enterprises.
• SD-JWT (Selective Disclosure JWTs): A new extension of JSON Web Tokens that enables selective disclosure directly within a familiar JWT format. Instead of revealing all fields in a token, SD-JWTs let the holder decide which claims to disclose, while still allowing the verifier to check the issuer’s signature. This bridges modern privacy-preserving features with the widespread JWT ecosystem already in use across industries.
• ISO/IEC 18013-5 and 18013-7: These international standards define how mobile driver’s licenses (mDLs) are presented both in person and online. For example, 18013-5 specifies the NFC and QR code mechanisms for proving your identity at a checkpoint without handing over your phone. 18013-7 expands these definitions to online use cases—critical for remote verification scenarios.
• ISO/IEC 23220-4 (mdocs): A broader framework for mobile documents (mdocs), extending beyond driver’s licenses to other government-issued credentials like passports, resident permits, or voter IDs. This standard provides a consistent way to issue and verify digital documents across multiple contexts, supporting both offline and online verification.
• NIST SP 800-63-4: The National Institute of Standards and Technology publishes the “Digital Identity Guidelines,” setting out levels of assurance (LOAs) for identity proofing and authentication. The latest revision reflects the shift toward verifiable credentials and modern assurance methods. U.S. federal agencies and financial institutions often rely on NIST guidance as their baseline for compliance.

Reading the list above, you may realize that one challenge in following this space is the sheer number of credential formats in play—W3C Verifiable Credentials, ISO mDLs, ISO 23220 mdocs, and SD-JWTs, among others. Each has its strengths: VCs offer flexibility across industries, ISO standards are backed by governments and transportation regulators, and SD-JWTs connect privacy-preserving features with the massive JWT ecosystem already used in enterprise systems. The key recommendation for anyone trying to make sense of “what’s best” is not to pick a single winner, but to look for interoperability.

Wallets, issuers, and verifiers should be designed to support multiple formats, since different industries and jurisdictions will inevitably favor different standards. In practice, the safest bet is to align with open standards bodies (W3C, ISO, IETF, OpenID Foundation) and ensure your implementation can bridge formats rather than being locked into just one.

The following sections detail (in a vastly oversimplified way, some may argue) the strengths, weaknesses, and best fit by credential format type.

W3C Verifiable Credentials (VCs)

A flexible, standards-based data model for any kind of digital credential, maintained by the World Wide Web Consortium (W3C).

• Strengths: Broadly applicable across industries, highly extensible, and supports advanced privacy techniques like selective disclosure and zero-knowledge proofs.
• Limitations: Still maturing; ecosystem flexibility can lead to fragmentation without a specific implementation profile; certification programs are less mature than ISO-based approaches; requires investment in verifier readiness.
• Best fit: Used by universities, employers, financial institutions, and governments experimenting with general-purpose digital identity.

ISO/IEC 18013-5 & 18013-7 (Mobile Driver’s Licenses, or mDLs)

International standards defining how mobile driver’s licenses are issued, stored, and verified.

• Strengths: Mature international standards already deployed in U.S. state pilots; supported by TSA TSIF testing for federal checkpoint acceptance; backed by significant TSA investment in CAT-2 readers nationwide; privacy-preserving offline verification.
• Limitations: Narrow scope (focused on driver’s licenses); complex implementation; limited support outside government and DMV contexts.
• Best fit: State DMVs, airports, traffic enforcement, and retail environments handling age-restricted sales.

ISO/IEC 23220-4 (“Mobile Documents,” or mdocs)

A broader ISO definition expanding mDL principles to other official credentials such as passports, residence permits, and social security cards.

• Strengths: Extends interoperability to a broader range of credentials; supports both offline and online presentation; aligned with existing ISO frameworks.
• Limitations: Still early in deployment; adoption and vendor support are limited compared to mDLs.
• Best fit: Immigration, cross-border travel, and civil registry systems.

SD-JWT (Selective Disclosure JSON Web Tokens)

A privacy-preserving evolution of JSON Web Tokens (JWTs), adding selective disclosure capabilities to an already widely used web and enterprise identity format.

• Strengths: Easy to adopt within existing JWT ecosystems; enables selective disclosure without requiring new infrastructure or wallets.
• Limitations: Less flexible than VCs; focused on direct issuer-to-verifier interactions; limited for long-term portability or offline use.
• Best fit: Enterprise identity, healthcare, and fintech environments already built around JWT-based authentication and access systems.

Together, these standards create the backbone of interoperability. They ensure that a credential issued by the California DMV can be recognized at TSA, or that a diploma issued by a European university can be trusted by a U.S. employer. Without them, decentralized identity would splinter into silos. With them, it has the potential to scale globally.

How Trust Flows Between Issuers, Holders, and Verifiers

Decentralized identity works through a triangular relationship between issuers, holders, and verifiers. Issuers (such as DMVs, universities, or employers) create credentials. Holders (the individuals) store them in their wallets. Verifiers (such as banks, retailers, or government agencies) request proofs.

What makes this model revolutionary is that issuers and verifiers don’t need to know each other directly. Trust doesn’t come from an integration between the DMV and the bank, for example. It comes from the credential itself. The DMV signs a driver’s license credential. You carry it. When you present it to a bank, the bank simply checks the DMV’s digital signature.

Think about going to a bar. Today, you hand over a plastic driver’s license with far more information than the bartender needs. With decentralized identity, you would simply present a cryptographic proof that says, “I am over 21,” without revealing your name or address. The bartender’s system verifies the DMV’s signature and that’s it - proof without oversharing.

Cryptography at Work

To make this work, at the core of decentralized identity lies one deceptively simple but immensely powerful concept: the digital signature.

A digital signature is created when an issuer (say, a DMV or a university) uses its private key to sign a credential. This cryptographic signature is attached to the credential itself. When a holder later presents the credential to a verifier, the verifier checks the signature using the issuer’s public key.

• If the credential has been altered in any way—even by a single character—the signature will no longer match.
• If the credential is valid, the verifier has instant assurance that it really came from the claimed issuer.

This creates trust without intermediaries.

Imagine a university issues a digital diploma as a verifiable credential. Ten years later, you apply for a job. The employer asks for proof of your degree. Instead of calling the university registrar or requesting a PDF, you simply send the credential from your wallet. The employer’s system checks the digital signature against the university’s public key. Within seconds, it knows the credential is genuine.

This removes bottlenecks and central databases of verification services. It also shifts the trust anchor from phone calls or PDFs—which can be forged—to mathematics. Digital signatures are unforgeable without the private key, and the public key can be widely distributed to anyone who needs to verify.

Digital signatures also make revocation possible. If a credential is suspended or withdrawn, the issuer can publish a revocation list. When a verifier checks the credential, it not only validates the signature but also checks whether it’s still active.

Without digital signatures, decentralized identity wouldn’t work. With them, credentials become tamper-proof, portable, and verifiable anywhere.

Selective Disclosure: Sharing Just Enough

One of the major problems with physical IDs is oversharing. As we detailed in the scenario earlier, you only want to show a bartender that you are over 21, without revealing your name, home address, or exact date of birth. That information is far more than the bartender needs—and far more than you should have to give.

Selective disclosure, one of the other major features underpinning decentralized identity, fixes this. It allows a credential holder to reveal only the specific attributes needed for a transaction, while keeping everything else hidden.

Example in Practice: Proving Age

• A DMV issues you a credential with multiple attributes: name, address, date of birth, license number.
• At a bar, a bartender verifies if your age is over 21 by scanning your digital credential QR code.
• The verifier checks the DMV’s signature on the proof and confirms it matches the original credential.
• The bartender sees only a confirmation that you are over 21. They never see your name, address, or full birthdate.

Example in Practice: Proving Residency

• A city issues residents a digital credential for municipal benefits.
• A service provider asks for proof of residency.
• You present your digital credential and the service provider verifies that your “Zip code is within city limits” without exposing your full street address.

Selective disclosure enforces the principle of data minimization. Verifiers get what they need, nothing more. Holders retain privacy. And because the cryptography ensures the disclosed attribute is tied to the original issuer’s signature, verifiers can trust the result without seeing the full credential.

This flips the identity model from “all or nothing” to “just enough.”

Example in Practice: Sanctions Compliance

Under the Bank Secrecy Act (BSA) and OFAC requirements, financial institutions must verify that customers are not on the Specially Designated Nationals (SDN) list before opening or maintaining accounts. Today, this process often involves collecting and storing excessive personal data—full identity documents, addresses, and transaction histories—simply to prove a negative.

In our U.S. Treasury RFC response, we outlined how verifiable credentials and zero-knowledge proofs (ZKPs) can modernize this process. Instead of transmitting complete personal data, a customer could present a cryptographically signed credential from a trusted issuer attesting that they have already been screened against the SDN list. A ZKP allows the verifier (e.g., a bank) to confirm that the check was performed and that the customer is not on the list—without ever seeing or storing the underlying personal details. This approach satisfies regulatory intent, strengthens auditability, and dramatically reduces the risks of overcollection, breaches, and identity theft.

ZKPs are particularly important for compliance-heavy industries like finance, healthcare, and government services. They allow institutions to meet regulatory requirements without creating data honeypots vulnerable to breaches.

They also open the door to new forms of digital interaction. Imagine a voting system where you can prove you’re eligible to vote without revealing your identity, or a cross-border trade platform where businesses prove compliance with customs requirements without exposing their full supply chain data.

ZKPs represent the cutting edge of privacy-preserving technology. They transform the old equation, “to prove something, you must reveal everything,” into one where trust is established without unnecessary exposure.

Challenges and the Path Forward

Decentralized identity isn’t just a lofty principle about autonomy and privacy. At its core, it is a set of technologies that make those values real.

• Standards ensure interoperability across issuers, wallets, and verifiers.
• Digital signatures anchor credentials in cryptographic trust.
• Selective disclosure prevents oversharing, giving people control of what they reveal.
• Zero-knowledge proofs allow compliance and verification without sacrificing privacy.

These aren’t abstract concepts. They are already protecting millions of people from fraud, reducing compliance costs, and embedding privacy into everyday transactions.

However, there are still hurdles. Interoperability across borders and industries is not guaranteed. Wallets must become as easy to use as a boarding pass on your phone. Verifiers need incentives to integrate credential checks into their systems. And standards need governance frameworks that help verifiers decide which issuers to trust.

None of these challenges are insurmountable, but they require careful collaboration between policymakers, technologists, and businesses. Without alignment, decentralized identity risks becoming fragmented—ironically recreating the silos it aims to replace.

SpruceID’s Role

SpruceID works at this intersection, building the tooling and standards that make decentralized identity practical. Our SDKs help developers issue and verify credentials. Our projects with states, like California and Utah, have proven that privacy and usability can go hand in hand. And our contributions to W3C, ISO, and the OpenID Foundation help ensure that the ecosystem remains open and interoperable.

Our objective is to make identity something you own—not something you rent from a platform. The technology is here. The challenge now is scaling it responsibly, with privacy and democracy at the center.

The trajectory is clear. Decentralized identity is evolving from a promising technology into the infrastructure of trust for the digital age. Like HTTPS, it will become invisible. Unlike many systems that came before it, it is being designed with people at the center from the very start.

This article is part of SpruceID’s series on the future of digital identity in America. Read more in the series:

SpruceID Digital Identity in America Series

1. Foundations of Decentralized Identity
2. Digital Identity Policy Momentum
3. The Technology of Digital Identity (this article)
4. Privacy and User Control (coming soon)
5. Practical Digital Identity in America (coming soon)
6. Enabling U.S. Identity Issuers (coming soon)
7. Verifiers at the Point of Use (coming soon)
8. Holders and the User Experience (coming soon)