The Last Refuge of Accidental Privacy

In the United States, we are accustomed to our digital data being sold, traded, and generally existing outside of our control. Our data protections are fragmented at best, and we’re not surprised when companies face no repercussions for handling our data recklessly, resulting in countless data breaches. (On the bright side, I’ve racked up about $54 this year from compensation related to data breaches, plus multiple simultaneous FREE subscriptions to identity theft monitoring.)

Yet for all this digital recklessness, proving our identity in the physical world has remained surprisingly private. When we flash our plastic driver’s license to a bartender, hotel clerk, or security guard, something remarkable happens: no trace is left behind. This is thanks to an analog relic: the humble plastic driver’s license.

To be clear, plastic licenses have their own problems–they’re easier to forge, reveal too much information, and pose challenges in online contexts. Digital alternatives could address these legitimate issues.

At the same time, Americans use driver’s licenses for many activities beyond driving, so this accidental privacy in many in-person contexts protects a large swath of our lives, offering a rare sanctuary in a pervasively-surveilled world.

A shift to mDL would affect Americans disproportionately. Our broad use of driver’s licenses, plus lack of comprehensive data protection like GDPR, risks comprehensive surveillance–and ultimately, control–of our daily lives. We must be intentional about these tradeoffs; digitization doesn’t have to equal surveillance.

The #NoPhoneHome movement has highlighted this principle, advocating broadly rather than targeting any specific technology. But mDL has received significant attention due to its “server retrieval” capabilities. In those discussions, I’ve felt we’ve been operating from different assumptions. It clicked for me when I realized many of the most vocal proponents don’t live in the US—we use driver’s licenses so differently. Understanding this difference is crucial. In this blog, I’ll explain why mDL poses unique risks in America.

How Americans Actually Use Driver’s Licenses

In the mDL discussions, we’ve been operating from different assumptions because most of the world doesn’t understand how Americans actually use driver’s licenses. Unlike many countries that have widely-used national ID cards for identification and separate licenses for driving, the United States uses driver’s licenses as the de facto national identification for countless daily activities:

• Age verification: Buying alcohol at dinner, picking up cold medicine
• Basic commerce: Hotel check-ins, large purchases, picking up packages
• Healthcare: Prescription pickup, doctor appointments, insurance verification
• Building access: Office buildings, schools, apartment complexes
• Financial services: Opening bank accounts, mortgage applications, investment accounts
• Employment: Job applications, workplace access, background checks
• Government services: Voting, federal buildings, social services

Mobile driver’s licenses are being rolled out in some states, but most of us still exclusively use plastic cards. In many cases, the attendant simply looks at the card, and no record is kept. Believe me, I now watch like a hawk. Recently confirmed fully offline verifications include: picking up packages at the post office, checking into a hotel, picking up a prescription.

What We’re Losing: From Anonymous to Tracked

What stands out about current American driver’s license usage is how often no record is kept at all. A bartender glances at your birthdate and hands the card back[1]. A security guard checks your name and waves you through. A hotel clerk looks at your ID and returns it without scanning. These everyday interactions—the bulk of our daily ID usage—leave no digital trail whatsoever.

mDL eliminates this category entirely. Every transaction, no matter how mundane, now creates digital records in both the mDL reader and your phone. Every “flash” of your license now creates two distinct receipts, each of which survive the other being deleted.

Guaranteed for ALL Transactions:

Transaction logs enable detailed records of:

• Where you went (GPS coordinates, venue identifiers)
• When you went (precise timestamps)
• What you accessed (which data elements were requested)
• How often you visit locations (pattern analysis)

The Corporate Surveillance Risk: Without enforceable restrictions, wallet providers could sell “anonymized” transaction logs to data brokers. But location and time patterns make re-identification trivial, especially with the granular data mDL provides.

The Government Surveillance Layer: AAMVA recently announced a ban on server retrieval, but this represents “privacy by policy”[2]—an organizational rule that could be nuanced, exempted, or fully reversed at any time. If this policy changes or states ignore it, the government gets notified of ALL transactions, making buying beer equivalent to opening a bank account in terms of government surveillance.

Your phone becomes a surveillance database that:

• Stores verbose transaction logs on your device
• Stores rich metadata about your movements, habits, and associations
• Is accessible to wallet providers for commercial purposes (e.g. building ad profiles or even serving ads)
• Is searchable by authorities (potentially without warrants under current law)
• Offers no easy way to delete or control this data

This dual threat—guaranteed corporate tracking plus potential government monitoring and control—becomes uniquely dangerous when applied to American ID usage patterns.

Why This Is Uniquely Dangerous in America

Because Americans use driver’s licenses for everything, and because we lack federal comprehensive privacy law like GDPR, the mDL standard in its current form enables comprehensive life tracking in a way that wouldn’t happen in countries with:

1. More limited driver’s license usage, or
2. Better data protection frameworks

In the United States, this creates a perfect storm of surveillance risks.

Fragmented Protection

While Europe has GDPR’s comprehensive protections to help counter corporate surveillance, America has a patchwork of state laws with huge gaps—no federal privacy law, wildly different state protections, and limited enforcement compared to European regulators. In the US, this mDL spec becomes a leaky boat of privacy risks.

Universal Usage Amplifies All Risks

Since Americans use driver’s licenses for everything from mundane use cases like buying beer to more privacy-critical ones like voting, both corporate and government surveillance become comprehensive life tracking systems. A European who uses a digital driver’s license occasionally faces limited exposure; an American using mDL faces total behavioral monitoring.

Consider this: count how many times you show your license in the coming month, then imagine each of those interactions being logged by the government, the business you’re showing it to, and your own mobile wallet app—potentially making that data available to other vendors as well.

Mission Creep Guaranteed

The surveillance infrastructure built for basic ID verification will inevitably expand beyond in-person transactions. Already proposed extensions include online age verification for websites and social media account verification through browser APIs[3] like the W3C Digital Credentials API. This would extend mDL surveillance from physical locations into web browsing, linking your government-issued identity to every online interaction that requires verification[4]. Each additional use case amplifies the surveillance risks exponentially..

The Window Is Closing

Mobile driver’s licenses are already rolling out across American states with varying levels of privacy protection. A spec dealing with digital identity needs to meet a higher bar and deserves more scrutiny—this makes the standard stronger.

The question isn’t whether America will get digital identity systems—it’s whether we’ll demand American-style privacy protections that account for how Americans actually use identification in daily life, and whether we’ll build privacy-by-design protections rather than relying on flimsy and easily-changeable policies.

This type of context-specific analysis would strengthen international standards. Identity solutions will never be one-size-fits-all. We do not need to accept a “take it or leave it” framing! Americans need not adopt the mDL standard as-is because other nations do. As I’ve laid out here, everything about our use of driver’s licenses is different.

The tragedy is that none of this surveillance is necessary for the legitimate benefits of digital IDs. We can have fraud reduction, convenience, and better security without comprehensive life tracking by multiple parties.

We have one chance to get this right. The choice is ours: adopt standards designed for different privacy contexts than ours, or demand privacy protections that account for how Americans actually use driver’s licenses in daily life and preserve the accidental anonymity we currently enjoy.

Thanks to Juan Caballero, Sharon Leu, Steven McCown, Timothy Ruff for the helpful suggestions and revisions.

Footnotes

[1] For those interested in the details, whether a trace of the identity verification is left behind varies based on whether documentation is required for compliance purposes, state ID scanning mandates, and whether transactions happen in-person or remotely. Some states require ID scanning for alcohol or restricted substance purchases, but such in-person transactions leave no record in most states. By contrast, higher-stakes transactions like opening bank accounts create audit trails. mDL transforms all categories into tracked events with mandatory digital logs.

[2] We’ll discuss privacy by policy and how this can be improved in the next blog.

[3] See for example https://developer.chrome.com/blog/digital-credentials-api-origin-trial

[4] I encourage you to read Brave’s concerns about the Digital Credential API, including that content and services would increasingly be gated behind digital ID requirements, transforming the open web into an “attributed web” where anonymity disappears.

We’ve been told that the “phone home” server retrieval feature is optional, that no one really implements it, and so we’re done, right? Unfortunately not yet. The stakes are high. We’re talking about critical digital identity infrastructure, so let’s dig in.

Let’s also be generous and skip the question of why leave a feature no one uses in a specification. (Even though unused features could present a security risk and should be removed promptly if unnecessary.)

Can’t We Just Not Use Server Retrieval?

In his IIW sessions, Steve McCown posed this question: can’t we just not use server retrieval? Leave it in the spec but never use it?

The conclusion from those IIW sessions—which I’ll correct subsequently—was that mDL readers were required to implement server retrieval mode. Even implementers and spec contributors (in that session and afterward) were under the impression that a server retrieval “instruction” is mandatory; i.e., if the mDL reader receives the server retrieval token in the mDL data, then they must perform server retrieval.

The reason for this conclusion was this diagram from the ISO specification showing the mDL transaction flow.

But that conclusion wasn’t right; we need to supplement the above diagram with other parts of the spec.

Let’s Dig In

Because I’d heard assurances from implementers that SR is essentially unused, the IIW confusion suggested I needed the authoritative source. So I forked over $300 USD to get the actual ISO specification and settle this definitively. It did, and it introduced new questions.

What the Specification Actually Says

Indeed ISO 18013-5 says that server retrieval is optional. Let’s look at two areas.

Section 6.3.2.1 says “If the mDL reader receives the server retrieval token and URL from the mDL, either during device engagement or device retrieval, it may either use device retrieval or server retrieval.”

This implies that the mDL reader can effectively ignore the server retrieval token and use device retrieval. That’s good for our immediate question, in that an mDL reader can just not implement server retrieval.

Next we have this table, which clearly shows it’s not required for mDL readers. It’s also not optional, but recommended.

The mDL Reader Does What?

Those assurances from the spec brought up more questions:

1. The mDL reader can ignore a server retrieval token and just use device retrieval? What would an issuer think about that? Would they find another mDL reader that will obey its instructions? Are these even the right questions?
2. What is the mDL reader’s decision making process? Is this covered by the spec?
3. How do mDL reader implementers interpret “recommended”?

The idea that the mDL reader has a decision making role here was baffling. To make it crystal clear, here’s the full flow:

I don’t have an answer for the “What happens here??” diamond, and how an mDL reader decides, upon receipt of a server retrieval token, whether to perform server retrieval or device retrieval. There are no details about that in the spec.

So how do you, as an individual mDL holder, know what choice it will make? We have to look at what implementers are actually building. But first, let me address the claims I keep hearing about server retrieval being unused.

The Reality Check

I won’t link to these sources because my goal is not to shame, just to promote clarity. If you need sources for correctness or investigative reasons, please reach out and let me know

Implementers and contributors to mDL have been telling us that server retrieval is not a problem—that it’s rarely implemented and shouldn’t be a concern. Since the spec isn’t publicly available and implementation details are opaque to users, we genuinely need their expertise to understand what’s actually happening in practice.

When these questions are raised, we are overwhelmed with responses like: “you cite server retrieval from 18013-5, an optional feature of the standard rarely implemented…Details matter here and your criticism’s[SIC] of ISO 18013 as a whole continually lacks this” and “And what alternative do you propose? (That does not involve your personal commercial interests?)”

These are pretty spicy, but what’s needed is detailed explanations. If server retrieval really is rarely implemented, help us understand: under what conditions do readers implement it? How do they decide when to use it? What should users expect?

The only other resource we have at our disposal is public github implementations, to see what is actually being built. In my quick search, I found at least 7 different public implementations that include server retrieval.

What’s happening here? My guess is that they are likely incentivized to implement it, in case not doing so excludes their solution from procurement.

The problem with ambiguous specifications is that implementers may err on the side of completeness. When in doubt, they build everything the spec mentions rather than risk non-compliance later. After all, the spec said it’s recommended.

And remember, all of this is completely opaque to users.

The Real Issue: Two Critical Implementation Questions

The server retrieval problem boils down to two key implementation decisions:

1. Will the issuer use it? Will they include server retrieval tokens in credentials?
2. Will the reader implement it? Will reader software be capable of server retrieval?

Here’s what we know:

For issuers: It’s optional whether to use server retrieval tokens at all. If they use it, they also choose whether to include them in individual credentials.

For readers: The spec says it’s “recommended” to implement server retrieval capability. And as my quick GitHub search revealed, readers are implementing it.

Prohibiting issuers from using it at all is clearly an option, and it’s a great start.

But if mDL readers have implemented server retrieval capability, we’re left with latent surveillance infrastructure. We’re just one policy change away from that trap door.

The Implications

This ambiguity has already created problems. Vendors are confused. Companies building mDL systems are making different choices based on their interpretation of unclear requirements.

There is some hope on the horizon. Organizations like AAMVA have recognized these concerns and decided to prohibit issuer use of server retrieval in their guidelines. But this highlights a fundamental problem: we’re building surveillance infrastructure first and hoping policy will protect us later. That’s backwards.

Individual policy fixes aren’t enough when readers are still implementing server retrieval capabilities, creating trap doors for surveillance that could be activated with a simple policy change. This approach is particularly troubling because server retrieval is just one of many broader linkability problems with mDL (and other digital identity systems, to be clear).

Since implementers claim no one uses server retrieval anyway, the solution is clear: remove it entirely from the specification and address the remaining privacy issues.

Read part 3: The Privacy Americans Are About to Lose

Mobile Driver’s Licenses (mDLs)—digital versions of your physical driver’s license accessible through a smartphone app—are rolling out across states and countries right now. Based on the ISO 18013-5 standard, mDLs promise greater convenience for individuals and reduced fraud for businesses and government agencies. Surely we all understand what we’re getting into, right? Well, a group of identity experts were surprised to discover what some are calling “latent surveillance by design” embedded in these systems.

The revelation came at the Internet Identity Workshop, where digital identity experts gather to discuss the future of identity systems. Steve McCown’s presentation about mDLs seemed routine at first. But his straightforward approach, showing excerpts from the official specification, revealed tracking capabilities that even the people designing and building these systems hadn’t fully grasped.

What happened next sparked conversations across the digital identity community and beyond, leading to much-needed awareness and the beginning of progress. Much more work remains, as we’ll explore throughout this series. This part focuses on Steve’s session and the immediate response it triggered.

The Setting

It was the 40th gathering of IIW — a biannual “unconference” where participants set the agenda each day. IIW attracts a largely technical audience of people who write standards, build identity systems, and advise governments on digital ID policy. Most sessions focus on specialized protocols and implementation details, so it probably goes without saying that many sessions are somewhat dry, but not this one.

Steve McCown, a Digital Identity Architect and Utah Privacy Commission Advisor, had systematically reviewed the ISO mDL specification, discovering potential surveillance implications many hadn’t fully appreciated.[1] As a white hat hacker with years of experience identifying vulnerabilities in computer systems and networks, Steve has an eye for potential security and privacy risks that others might miss.

Steve teamed up with Chris Bramwell (Utah Privacy Officer) and Timothy Ruff to hold an IIW session presenting his findings, combining perspectives from industry, government, and privacy advocacy.

Steve’s presentation turned out to be exactly what was needed. Using excerpts from the ISO specification, he showed the audience what the standard actually enabled. No interpretation, no spin—just the technical details from the spec presented in black and white—that made the surveillance implications undeniable:

1. The ISO mDL standard includes latent “phone home” capabilities that enable targeted tracking
2. If these capabilities are activated in your mDL, you won’t necessarily know it
3. Issuers can remotely enable or disable this tracking without your knowledge

For an audience of technical experts who thought they understood digital driver’s licenses, these revelations were eye-opening, and somewhat embarrassing.

See the slides here.

How mDLs Work: The Two-Path System

Before diving into the concerns, let’s understand how mDLs work. The ISO mDL standard (18013) describes three roles:

1. mDL Holder (“holder”): A person with an mDL stored in an app on their mobile device
2. Issuing Authority (“issuer”): The organization that creates the mDL. Typically a government, such as a state DMV, or their contractor
3. mDL Verifier (“verifier”): Anyone who needs to check your ID. Examples include bartenders, TSA agents, pharmacy staff, etc.

The tool used by the verifier to read and verify your mDL is called an mDL reader. Refer to Figure 1 (excerpted from the standard):

The standard includes two methods for retrieving your license data:

1. Device Retrieval: The mDL reader retrieves your mDL data directly from your phone via Bluetooth or NFC, requiring no internet connection. Like showing a physical ID, the data exchange stays between you and the verifier[2]. (Interface 2 in Figure 1)
2. Server Retrieval: The mDL reader contacts the issuing authority’s servers to retrieve your mDL data, which is referred to as “phone home”. (Interface 3 in Figure 1)

Steve’s Key Discoveries

Steve’s presentation highlighted several concerning implications of the specification that weren’t widely understood:

Breaking the Three-Party Model with “Phone Home”: Many emerging digital identity architectures are built on a three-party model that’s foundational to decentralized identity—the issuer issues credentials to the holder, and the holder shares credentials directly with the verifier, but verification events do not “phone home” to the issuer.

Many in the audience were familiar with server retrieval—where the mDL reader contacts government (or their contractors’) servers to fetch credential data instead of getting it from your device—but had been assured by others in the identity community that “no one implements it” or “it’s going away” for many years. So they were surprised when Steve showed that server retrieval was prominently featured in the specification.

This “phone home” functionality breaks the three-party model by creating a direct line of communication between verifiers and issuers during every verification event. When active, server retrieval enables a record of when, where, and potentially why your ID was checked. These individual retrieval events can be centrally logged, recorded, and over time aggregated to build a detailed profile of your activities—creating a “funhouse mirror” representation of you that lacks context. The capability to systematically track and profile citizens’ daily activities is, by definition, surveillance.

The idea that mDL verification could effectively resort to a centralized architecture, even for just some users, ran counter to this foundational assumption that had guided many digital identity experts’ work for years.

Stealth Updates Without Transparency: But it gets worse. Steve showed how an issuer can remotely switch between these modes for any user or groups of users without their knowledge or consent:

1. An issuer starts with device retrieval for all users
2. Later, they can remotely add server retrieval “tokens” to some users’ mDLs during regular updates (typically every 30 days)
3. When those users’ IDs are scanned, the mDL reader detects the token and retrieves credential data from issuer servers instead of the user’s device
4. The user has no way to know that server retrieval has occurred

This enables targeted tracking and data collection where some users’ activities are tracked while others aren’t—and users have no way to know which group they’re in or that their data is being collected without their knowledge or consent.

Latent Surveillance Capabilities: Steve’s reading of the specification suggested that mDL readers must implement both device and server retrieval modes. This interpretation wasn’t challenged by session attendees, including contributors to the specification. As the audience discussed, this seemed to imply that the mDL reader had to be “complicit” in enabling surveillance by allowing phone home functionality even if it remains initially inactive.

After Steve’s presentation, I purchased my own copy of the specification to investigate whether server retrieval is required. What I found was more complicated but no less troubling: the ambiguity may lead implementers to understandably “go ahead and implement it.” This doesn’t resolve the privacy concerns; it makes them worse by creating uncertainty about what systems actually do.

This question proved sufficiently complex that it deserves its own deep dive, which we’ll explore in Part 2 of this series.

A Community Divided

The IIW community reaction revealed something unexpected: they were reading from different playbooks. Steve presented his findings in two separate sessions at IIW, and the responses were starkly different.

The Concerned Voices

The more alarmed response came from attendees in the first session. These were digital identity experts who understood that phoning home during verification goes beyond typical ‘linkability’ risks—rather than simply leaving traces that could be connected later, it directly transmits your identity and location to the issuer in real-time, enabling comprehensive centralized tracking by issuers, and unknown future consumers, across all interactions. Since avoiding this privacy problem has well-established technical solutions, they assumed community consensus against building it into new systems. Finding it embedded in the mDL specification demonstrates the difficulties of comprehensive privacy review when technical standards are not freely available to researchers, advocates, and the broader technical community.

Jay Stanley of the ACLU, who has raised awareness about this and other concerns in the mDL spec for years, was in attendance and described what he called “inherently authoritarian capabilities.”

Core contributors to the mDL specification were present, and they acknowledged that server retrieval functionality was included as a compromise because some countries require it. They explained that the technical capability exists in the specification, and preventing unwanted data collection requires individual implementers to create appropriate policies or regulations.

This explanation only frustrated privacy advocates in the audience. Joe Andrieu responded, with support from other attendees, “they should rise to our level; we shouldn’t lower to theirs”—referring to the concern that we might be naively building infrastructure with latent surveillance capabilities that authoritarian governments could exploit.

The discussion led to disturbing potential implications, including a pointed question: “Does this mean an implementer of mDL must effectively help foreign governments spy on their citizens, even if it was against local policy or regulations?”

These attendees questioned whether technical standards should enable the lowest common denominator of privacy protection—or aspire to something better, like a default expectation of non-surveillance that authoritarian countries can build something atop if they wish to.

The Pushback

The second session had a more guarded dynamic, but the pushback clarified the stakes. Some attendees seemed less surprised by Steve’s findings, which he repeated—word had apparently spread from the first session, and they came prepared with counterarguments that took several forms:

“Don’t you have to phone home for real-time status checks?” This revealed a common misconception that credential verification requires contacting the issuer for the status of a specific credential. But avoiding this is a basic goal of decentralized identity systems—credentials can and should be verifiable without phoning home.

“But if you’re pulled over by police…” It’s true that police already access extensive data during traffic stops. The real concern is that mDLs are being designed for countless everyday uses such as pharmacy pickups and age verification at bars. Do we want those routine interactions to enable surveillance?

“We just need better policies and regulations.” Yes, and, this misses a crucial point: technical architecture shapes what’s possible. Why build surveillance capabilities and hope policy will constrain their use?

“At least people are building something.” This pragmatic view drew the sharpest response. Timothy Ruff countered: “You’re making a value judgment—valuing expediency over privacy.” The logical next question is, are we comfortable with that trade-off?

Why This Is Different

The discussion, although contentious at times, revealed why the digital identity community had been talking past each other. The debate exposed different comfort levels with embedding surveillance capabilities and trusting policy solutions to constrain their use. But this isn’t just another privacy debate—it’s fundamentally different in several ways:

Not Everyone Knows the Risks: some said the risks were well known and could be addressed through appropriate regulations. But this assumes governments implementing these systems understand the privacy implications and will create protective policies. Do they?

The Rules Can Change: Steve and others highlighted a more fundamental problem. Policies can be ignored, or changed. By embedding surveillance capabilities directly into the technical specification, we’re creating permanent infrastructure for tracking—regardless of current protections.

Beyond Typical Privacy Vulnerabilities: This goes far beyond standard privacy concerns. The server retrieval capabilities in mobile driver’s license standards define infrastructure that enables systematic, centralized data collection across daily activities. This isn’t an unintended consequence—it’s an architectural feature that can trivially enable persistent record-keeping of when and where you use your credentials, creating patterns that can be analyzed long after the original transaction by unknown third parties. Even worse, because verification can require real-time server contact, the issuing authority gains the ability to approve or deny credential use in the moment—effectively enabling digital identity deplatforming.

The Invisibility Problem: Perhaps most troubling, users have no way to detect when they’re being monitored. Unlike a visible camera or an obvious data request, server retrieval operates silently. Users can’t tell if their verification triggered surveillance, or when their monitoring status changes. This violates basic expectations of user agency and informed consent.

Why the US Context Matters: The concerns were amplified by the American context, where driver’s licenses serve as de facto national ID cards used everywhere from TSA checkpoints to pharmacy pickups. Unlike countries with purpose-built national ID systems, Americans use driver’s licenses for countless daily interactions, meaning the surveillance potential extends far beyond driving-related activities. Further, the U.S. lacks comprehensive data protection regulations that might mitigate this.

The fundamental question: Do we accept surveillance capabilities now and hope they won’t be misused later? Or do we design systems that make surveillance technically difficult from the start?

What’s Next

Steve’s presentation sparked questions and soul-searching within the digital identity community. The questions spanned technical and policy concerns: Is server retrieval actually required or truly optional? How do real-world implementations handle this choice? Can policy alone provide adequate privacy protection?

For my part, it launched a deeper investigation into server retrieval-related implementation requirements. This proved more frustratingly complex than expected, and we’ll explore that in Part 2 of this series.

But this also triggered significant reflection: these surveillance capabilities had been hiding in plain sight. Many of us felt we had collectively dropped the ball on a blatant privacy issue, but recognizing that became the first step toward picking it back up. As Timothy Ruff put it, we’re the “last line of defense.” This started uncomfortable conversations leading to hints of real progress. In fact, just three weeks later, AAMVA announced they were updating their guidance to prohibit issuer use of server retrieval—a promising step, though other forms of linkability and tracking risks remain. We’ll talk about this later in the series.

Today’s architectural choices are being embedded into tomorrow’s identity infrastructure. Technical standards and privacy policies can work together—if we’re honest about what we’re building and make surveillance-resistant choices from the start.

Read part 2: Is Server Retrieval Actually Optional? The Investigation That Revealed More Problems

Resources:

• IIW 40 mDL Privacy Concerns Presentation
• ISO/IEC 18013-5:2021 ISO-compliant driving licence, Part 5: Mobile driving licence (mDL) application
• ACLU Digital ID State Legislative Recommendations

Footnotes:
[1] Why did other identity experts miss this? Unless you are directly involved in the ISO technical committee developing this specification, you need to purchase it (around $300 USD). Because it is undergoing updates, it’s also a bit of a moving target. The costs add up, so many rely on summaries, excerpts shared by colleagues, or insights from technical committee participants. I purchased my own copy after Steve’s presentation.

[2] Even this isn’t complete protection against tracking—the mDL reader could still log your information, and your mDL app might record transaction details. The ISO specification provides guidance but doesn’t enforce privacy protections. We’ll cover how that works in a subsequent post.

Twitter has taught us a lot about reputation and identity in a very short amount of time, hence this brief interlude and exploration

Identity and reputation systems are hard. This is becoming increasingly clear…or shall we say, sinking in… for users of the social media network Twitter. Under new management, changes to Twitter’s traditional verification process have been explored in real time.

First, some clarfications. By “traditional Twitter verification process” I’m referring broadly to the method used before November 2022, resulting in a blue “verified” checkmark. The details and requirements of this process are known to Twitter alone, but we do know it strived for “real” identity verification, meaning the identity information (name, photo) claimed in the Twitter profile belongs to the expected individual.

In particular, it attempted to prevent the following from occurring: a “verified” checkmark on a profile appearing to be a famous individual but actually corresponding to an imposter trying to scam people.

Twitter Verification – the “before” state, the proposal, and initial reaction

But that’s jumping ahead. Until early November 2022, this blue checkmark more or less minimized such abuses, and functioned as a visual indicator distinguishing notable “public figures” from imposter accounts.

To be clear, there are valid criticisms of the traditional process: the opacity (no one knew exactly what was required to get it), the fact that a single company has the power to bestow or remove the “verified” marker on a whim. But at least it felt stable and therefore the idea of abrupt changes to this process, including switching to a $20 $8 fee, was met with resistance.

Fundamental concerns were raised, resulting from dependencies on the traditional verification process. Twitter has functioned as a global town square over the last decade, enabling rapid spread of information and misinformation and has been considered to play a role in the outcome of significant world events. So a sudden rollout of dramatic changes to a fundemental feature like identity – especially given Twitter’s scale – was alarming to many.

Journalists expressed concern that the proposed changes could make it difficult for users to distinguish misinformation from fact-checked content from a trusted news organization (as determined by the user). Rolling out such changes immediately before an election further increased anxiety.

Even more confusing, the rationale, timing, logistics, and semantics of the changes were not clear. I’m not sure we were all on the same page about:

1. Why is the change occuring? Is it to increase revenue? To make the process more democratic? (Per Elon’s “power to the people” tweet below) Both?
2. Would existing “verified” users lose their marker if they don’t pay the fee? And what is the
3. Semantics – what is the difference between “verified” vs “official”?

Let’s put that aside for now because it’s not critical to the rest of the discussion.

UPDATE: I only recently stumbled on this. If you want to know more about my questions above, please read what Yoel Roth, former head of trust and safety at Twitter wrote about it.

Why is the “identerati” interested in this?

Real-time experimentation on Twitter verification has an additional draw for me and others interested in decentralized identity. In decentralized networks, including social networks like Bluesky, reputation is an even harder problem than in centralized alternatives like Twiter – this is by design. We are interested in building solutions where it’s not possible for any one company (like Twitter) or organization to target or censor individuals on a whim, thereby limiting access and rights of individuals. We’re interested in building alternative ways to establish reputation and trustworthiness.

At the same time, we also want to prevent abuse by those looking to game the system. The potential risks depend on the type of system, but the following are representative examples:

• For social media networks: a user poses as someone else to achieve a platform to spread misinformation or to trick people into scams Users like Vitalik Buterin are a common target, as in the screenshot below.
• For decentralized digital currencies: spinning up multiple identities to circumvent security controls and perform “double-spends” – spending the same funds twice, effectively stealing from one of the recipients.

There are many methods used (alone or in combination) to prevent or reduce these risks, but two of those are precisely the “before” and “after” Twitter verification methods – i.e., real identity verification (before) and fee-based models (after).

Real identity verification of course gives you high assurance of who your users are, but it’s costly, time-consuming, and not necessarily needed or wanted in all cases.

The idea behind a fee-based approach is to make fraud cost-prohibitive to scammers. However, these solutions are never simple. With a fee-based approach, for example, it’s hard to find a solution that makes it expensive enough to prevent fraud yet not too expensive that other users are deterred. And any solution (including requiring specific identity documents) may introduce new barriers that exclude populations unintentionally.

Imagine if you had to pay money to send email. That sounds annoying, but if, in return, it reduced the amount of junk email you got, would that be more appealing? The idea here is that, if you had to pay a small amount of money per email, you wouldn’t entirely be deterred from using email, but it would be too costly for users that want to send bulk marketing emails.

Paid email was just a thought exercise; we enjoy free email and rely on other methods (email filters that look for suspicious words) to avoid swimming in junk email. But that’s representative of the tradeoffs we make in system design. We identify risks, we think of mitigations, and consider potential harms introduced along the way, including intended or unintended consequences. An example of an unintended consequence is if a fee turned out to be too high and resulted in excluding a cset of users.

So how can I help?

All of this is to say that these problems have no easy answers and therefore any lessons learned from Twitter’s rollout stands to benefit decentralized identity systems, Forther, I innocently thought this might be a good opportunity to maybe even help if unintended consequences occurred.

For example, if you were verified as of November 10, but then unexpectedly lost that status on November 11, how would you prove that? These are exactly the sorts of problems we try to address with decentralized identity solutions. Instead of your identity claims being locked into companies, we want to enable you to carry it with you in the form of a portable “Verifiable Credential” (VC) that you carry in your own digital wallet.

The number of verified users is small – roughly 420,000 currently. And it’s not clear a “formerly verified” portable credential would even have any use. But this had several unique advantages as a motivating use case:

1. The relatively small amount of data meant it was actually achievable with Twitter’s API rate limits
2. The timeliness and general interest around “what would happen next” meant that being able to visualize trends and inspect the data would be interesting. Do the numbers dramatically increase? Are certain types of users receiving preferable treatment?

So I picked this as a timely motivational example to show how portable VCs could be “bootstrapped” from a centralized authority. Even if “Twitter verified” isn’t the most interesting use case, this method could be applied to other, more valuable types of attestations.

Enter Verifiend

VeriFIEND is the the verified account verifier. It’s part one of this open source experiment. It collects complete lists of Twitter verified accounts as often as it can (given Twitter’s API rate limits). These dumps will help it serve as a witness, enabling part 2 – VeriFRIEND.

What’s happening so far

The first priority was reliably injesting verified user lists. The quickest method seemed to be dumping the complete set of users the Twitter “@verified” account (https://www.twitter.com/verified) follows. But Twitter’s API rate limits drag this out – it takes about 8 hours to get a complete snapshot of the current list of verified users.

So every ~8 hours I’m getting a complete dump of verified users as of the start of that query and archiving them in S3. When the next 8 hour cycle completes, I can determine “diffs” between snapshots – who was added and who was removed as verified users.

There is also a quick way to get just the raw following count without going through the full 8 hour cycle, so I’m grabbing those every hour to fill out the picture.

Based on this data, we can view trends in verified user counts over time. The Verifiend dashboard shows these counts over the past week and a half (and counting).

The full details and assumptions behind this collection are described in the Verifiend technical README. You can also see the backend source code here.

Roadmap and Rollout

There’s more going on behind the scenes I haven’t rolled out yet. One thing that may not be clear: the count is clearly declining, but some additions are being made. So at almost all data points, the number of de-verified users exceeds the net decline shown in the chart. I have this data, as well as the lists of which users are being added and removed, but am not yet displaying it.

Here is the roadmap from an end-user-facing perspective:

• [DONE] Verified counts over time displayed in Verifiend dashboard
• [IN PROGRESS] Dashboard improvements
  • Overlay above datapoints with +/- counts
  • Rollups/aggregates for better responsiveness
• Exports of raw verified data (as opposed ot just counts).
  • This would enable, for example, drilling in to see which accounts are becoming unverified
  • There are privacy concerns with this, discussed below
• Verifriend! The angel to Veri-fiend’s devil
  • This is the decentralized identity part, where users can get portable VCs stored in their digital wallet

I make no guarantees on timing; this is my weekend / fun project. There are assumptions, nuances, and concerns I want to cover, but before we get to that, let’s catch everyone up to present. Verified collection service running stably, I checked back in on the rollout of the new $8 fee model.

Checking in on Twitter

Twitter users gladly forked over $8 and in return treated the world to novel and creative applications of their newly acquired mark of prestige.

Some of these took the form of obvious parody, perhaps requiring close scrutiny and double-takes because of the verified checkmarks, such as in this exchange between “Ben Shapiro” and “Ted Cruz”.

Others impacted markets, as in this example where a mock Eli Lilly account announced free insulin. While embraced by those with utopian instincts, investors revolted at the idea and dumped the stock.

Ultimately twitter had to suspend this rollout, as advertisers revolted en masse at the outcomes like above. Twitter will now be rolling out the ROCK SOLID version November 29.

But it’s really hard to say. With a relatively small percent of remaining employees, I’d be surprised if they have time to work on new features on top of learning to support new feature areas. But if they find that mythical 7500x engineer, just maybe…

It’s a tale best viewed in storybook form, enabled by this thread.

On to Verifriend

Veri-FRIEND is the dual of the obnoxious goose-led project Verifiend, which will help bootstrap decentralized identity claim techniques via portable VCs controlled by users themselves (instead of a centralizd service).

Trust model

In general, the trust model of what I’m proposing works like this: if someone trusts that I have written software to collect data for this purpose and that my software will issue a VC if and only if the collected data indicates you were in a specific set of (verified, in this case) users at a given point in time, AND if they find this information useful, then they can choose to accept this credential. That’s a stretch, but hey, this is just an experiment and the cost is nothing to you except for the time you’re wasting reading this..

Other concerns

Why are the counts dropping

Looking through the de-verified accounts, many are now blocked or banned from Twitter. In these cases, I can’t see what activity may have been happening leading up to de-verification. However, some de-verified accounts remain. I anecdotally poked around to see why these accounts might have lost their status (e.g., did they post something offensive to new management?). It really was not clear why they were being dropped. So more digging needs to be done.

Limitations and assumptions

It is not clear the answers are in my data sets. I keep mentioning API rate limitations. This is a technique Twitter uses to prevent average users extracting value from Twitter’s data. I can collect at most a small fraction of the overall activity, and anecdotal analysis like I’m doing can introduce bias (or cherry-picking results). Yet rate limits prevent me from getting a meaningful amount of associated data to avoid that.

Other limitations and assumptions:

• No data pre-dating Elon, so it is not clear if these metrics are atypical historically
• It is not clear how new $8 verified would be queryable through APIs
• In determining added/dropped verified users, I’m using “id”, which I’m assuming to be stable

Sharing the details, responsibly

So I would like to open up these data sets, just in case they’re valuable to someone. But I want to do this in a way that doesn’t compromise privacy, for example in the case that a Twitter user doesn’t want others to know they are no longer verified.

Options include:

1. Opening up to researchers upon request with very clear usage guidelines
2. (*) Because this information is public domain, another option is to share this data by default but give people the right to delete upon request.

Researchers I’ve talked to indicate #2 makes sense in this specific case. I also considered approaches involving anonymization, but it’s not clear that would result in a valuable data set (given all of the concerns mentioned above.)

Foundational Concepts

Terms and Definitions

These are my working definitions of core terms, designed to balance correctness and simplicity, not pedantry.

Analogies

Here are (what I hope are) useful analogies for newcomers, or anyone who doesn’t care to get into the technical details. I’ve gone the extra mile and compared/contrasted the analogized entities, thereby beating the analogies into the ground, but hopefully this is helpful for your own mental model.

Verifiable Credentials and Envelopes

Figure 1: Postal envelope for mailing a letter. Photo credit Anne Nygård | Unsplash

A Verifiable Credential is like an envelope (used to mail a letter):

1. It’s a lightweight wrapper around any content
2. It provides functional similarities:
   • “Content integrity”:
     • There is an assumption / convention is that the envelope contents don’t get tampered with
     • But to be more precise, if the physical envelope was tampered with, you would be able to detect it. In VCs (and digital signatures) we call this tamper-evidence
     • In VCs this is achieved through the VC proof – if the contents are modified, the cryptographic signature (or other proof mechanism) wouldn’t match.
   • “Authenticity”:
     • Looking at the envelope, you know who it’s from, who it’s going to
     • In VCs, this is enabled through VC issuer and credentialSubject properties
3. We’ve all steamed open envelopes as a child and therefore know the failure modes. Graphically, you might use a Game of Thrones-looking envelope with a wax seal / sigil (see Figure 2) to make it look really secure but …
4. The analogy breaks down pretty quickly, because:
   • In contrast to physical envelopes, VCs are secured by cryptography – not the act of licking
   • A physical envelope hides its contents (letter), but a VC is not hidden or even necessarily encrypted. VCs provide digital signatures, which is the “content integrity” part described above.

Figure 2: Envelope with a wax seal. Photo credit Svetlozar Hristov | iStock

Decentralized Identifiers (DIDs) and…

DIDs and Web URLs

DIDs are strings that look like this:

did:example:1234

Notice that it looks like a web URL, and actually they are related. Both are types of URIs (Uniform Resource Identifiers). Just as a web browser can take a web URL and render a web page, software that understands a DID can retrieve its associated “DID Document”.

Or visually, just as https://twitter.com/ resolves to a twitter web page:

did:example:1234 resolves to a DID document:

DIDs vs Social Security Numbers (SSNs)

• This analogy tends to be helpful as a contrast, or punching bag, because in the US we know how SSNs can easily be compromised and used for identity theft
• Specifically, it’s shockingly easy for someone to learn your SSN plus a few other tidbits about you, and start hijacking your identity. So instead, we say “imagine it’s a SSN but you (and only you) can use it because you can prove it’s yours”
• The DID/SSN contrast is further helpful when talking to the relative advantages of DIDs because:
  • SSNs are used in a loose way; attributes are associated with them whether the person associated with the SSN is involved or not.
  • In contrast, DIDs are expected to be used in protocols where proof of control is required, so a loose claim assigned to a DID is less valuable to a RP
• Some other notable distinctions:
  • Whereas you have 1 SSN, people are expected to have lots of DIDs for different purposes. Wallets/software help people manage them
  • In contrast to SSNs, people should never be expected to remember their DIDs
  • SSNs are a government-issued identifier whereas DIDs may be self-issued/created. DIDs could be bestowed upon you, but even in this case you’d likely (because they’re not very interesting otherwise) be able to tie them to you through authentication or some means.
    • Note that DIDs are being considered as a data type for some national digital ID systems
  • Whereas an SSN is a flat string, but a DID “resolves” to a DID document which contains data like public keys, services, etc, as shown in Figure 3

DIDs vs Cryptographic Keys (or addresses, like a cryptocurrency address)

One oversimplified shorthand is to think of DIDs as cryptographic keys with built in lifecycle, like you can rotate keys. Because the DID string resolves to a DID document, you can update the document over time.

Pitfalls and Misconceptions

Myths and Facts

Other uncomfortable conversations

A slightly more formal treatment in DIF Presentation Exchange spec (subject/holder binding > proof of identifier control).

At a high level, it works this way:

• A Verifiable Credential (VC) is issued to a subject (e.g., person), and the subject is identified in the VC by an “identifier” (with the property name id).
• The identifier data type is a URI, which is like a web site URL, but can more general. It can be a Decentralized Identifier (DID) in fact
• If that identifier is backed by cryptographic key material (as with DIDs), then you can use standard crpytographic signatures to sign a message proving you control that identifier.
• At verification time, the credential “holder” can use this property to prove they are the same entity as the credential “subject”. They can do this by wrapping a VC in a Verifiable Presentation (VP) and signing the VP with the corresponding private key material.

And this is how a holder proves they are the subject, by demonstrating control of this shared identifier.

Example

Suppose a VC is issued to a subject with the identifier did:example:1234. It would look like this

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  "issuer": "https://example.edu/issuers/565049",
  "issuanceDate": "2010-01-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:example:1234",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  }
}

At issuance time….

Before issuing that credential, the issuer would have authenticated the subject in their usual means, and asked the subject to provide a DID that their wallet generated. In this case, the subject’s wallet generated did:example:1234. The issuer could also asked for proof of control along with the DID at this time (this can be done with an empty VP, with DID auth, etc).

The issuer generates the VC, issued to credentialSubject.id = did:example:1234, and sends it back to the subject to store in their wallet. Let’s call it VC(*)

At Exchange / Verification Time

Later, a relying party could ask credential holders to prove they are the credential subject.

The subject retrieves the VC they want to share, VC*, generates a VP, and signs the VP with the private key corresponding to did:example:1234 (or the private key corresponding to a specific public key authorized by did:example:1234). The relying party should also include a “challenge” to prevent replays (i.e., this requires the holder to generate a fresh signature).

This allows the relying party to trust that the original VC hasn’t been tampered with and the subject of the credential is really the intended recipient (possibly with additional levels of identity assurance, as required by the relying party).

## About the wallet and its dependencies

There are 3 objects shown near the subject/holder, called “wallet”, “identifier vault”, and “credential storage.” What are these?

First, individuals aren’t necessarily expected to know about or interact with these as separate entities. I’m using “wallet” as shorthand for the application or entrypoint that individuals use to interact with their identity data. It might be a mobile app, browser plugin, etc.

There’s no point in being overly opinionated on the wallet architecture and its capabilities, which is why “identifer vault” and “credential storage” are called out as possibly separate entities. Some wallets may implement all of these functions, and some may delegate these functions to other processes or services on or off device.

• “identifier vault”: manages decentralized identifiers for an individual, including creation, retrieval, etc. Here I’ve used them as blackboxes that would perform cryptographic signing, in the interest of minimizing exposre of private keys
• “credential storage”: manages (store, retrieve, etc) credentials

More Details

This post focused on holder and subject binding through proof of identifer control. Read this section of the DIF Presentation Exchange spec for information about other methods of holder and subject binding, including biometrics

When I started that post, I intended to use real real-world credential examples. And driver’s licenses tend to serve as a universally relatable example; others can get caught up in educational milestones or are locale biased.

At the same time, when you start digging into how driver’s licenses are used and verified, it can quickly get locale-specific – just see the previous post’s endnotes. Further, I resorted to sleight of hand when modeling specific driver’s license properties (e.g., expiration date). That’s because the technical details, while informative and entertaining for a select few, distracted from the pedagogical goals. As evidence I offer this collaborative modeling exercise on twitter.

Settle in for a Wild Ride

So let’s get into those details now. Starting with 2 reference images…

Michelle’s New York State Driver’s License:

And a reminder of VC structure:

Question: which fields are VC claims and which are VC metadata?

Build up to the Big Reveal

Before seeing “the answer”, let’s consider why informal, pedagogical modeling might look different from the actual VC modeling. Some fields printed on a driver’s license appear to match VC metadata properties name-wise: “issued”, “ISS”, and variants look like the VC metadata property “issuanceDate”; “expires”, “EXP”, and variants look like the VC metadata property “expirationDate”; “ID” looks like a VC metadata “id”.

When introducing VCs, the focus is providing intuition behind the “claim” vs “metadata” distinction – not beating someone over the head with driver’s license minutia. Without going that far, your real-world intuition can come from having the not-too-uncommon experience of losing a physical driver’s license or updating your address, needing to request a new one, and thinking about which values would be different on the new one. On general, claims would be the fields with values that are clearly about the person (e.g., address) OR fields whose values are unchanged (e.g., expiration date doesn’t change on the re-issued one).

I’ll make a best stab for Michelle’s New York state driver’s license, with a fast caveat that you can’t generalize across all states. Notice the utter mayhem in issuance-related properties, and let’s hope that this gets cleaned up with upcoming driver’s license focused efforts, such as REAL ID, mdl, etc…although, from what I can see, REAL ID may only promote convergence/alignment in minor areas (like setting an upper bound on expiration dates). Baby steps I guess.

The Unveiling

The yellow-highlighted areas are VC claims and the blue-highlighted are VC metadata.

Dispelling your Disbelief

expires is a claim, not metadata

The VC metadata property expirationDate would seem like a natural fit. However, expires refers to the lifespan of Michelle’s license itself, not any particular instance of a digital VC representing this license.

If we had real VC driver’s licenes, you could even imagine a VC metadata expirationDate that expires, say, within 1 year, rather than the full lifetime of the claim (4-7 years) – this is a common digital credential security hygiene pratice.

issued is most likely a claim, not metadata

This is similar to above, but this is where it varies per state and gets complicated. If you start poking around various state license documentation, some seem to imply it’s the original date when the state granted you driving privilege for a specific time interval (say 4-7 years, however long your state’s licenses are valid), but others describe it as a card “processing date”, which sounds more like VC metadata.

And plot twist: some like Missouri don’t even seem to have this field or any variants, per some frustrated TurboTax users.

Next time I run into authors of the Verifiable Driver’s License spec I’ll corner them and get you the answers you deserve.

ID is a claim, not metadata

It seems most states reuse ID, not only on reissuance, but also on renewal.

Bending the Parallels til they break

Tamper-evidence and authenticity

The New York state driver’s license has a lot of “security” features, around 30 in fact. Some you can see from the flattened photo are:

1. Michelle’s first and last name are shown in a swirly pattern on the right hand side, as is her date of birth

2. Her image is on the right hand side embedded in the state of new york

The above could be viewed as helping with tamper-evidence (i.e., if you’re modifying a valid DL, it’s harder to make it match in multiple locations), but also feasibly helping with authenticity, given that these cards look pretty hard to realistically tamper with anyway. In other words, there are markers that are more apparent in real life such as laser etching, heavy/distinctive materials, etc which serve to more quickly identify a license as authentic.

Challenge/Response or proof of control

Michelle’s signature is fun. I guess in the olden days you could think of it as sort of a challenge/response; i.e., if your signature doesn’t match the one on the card, then you’re an imposter. I like viewing this as a proto on-demand challenge/response, but we’ve lost the fine art of penmanship and this isn’t too realistic. I can attest that signature matching is used in Washington state vote-by-mail, but they must have a high tolerance for varationbecause every instance of my signature looks completely different. Let’s replace this with DID auth!

Twitter Reacts

@sgershuni: What if instead of trying to land paper creds onto VC data model, we create new digitally-native credential formats? E.g. everything except for Class and License # is pulled from other credentials. Composable data and transitive trust all the way

me: This is just an educational/informative exercise and not meant as the ideal mapping, so yes, definitely!

@by_caballero: is this a subtweet, or

me: If so, I guess I’m subtweeting how irritating US drivers licenses are. That will be a recurring theme…

The World Reacts

@_nat: Does the ID change when reissued or renewed? If so, it is a claim about the identity document and metadata about the person. If not, it is a claim about the person.

me: ID had more going on than I realized — after talking it through with @jvedi we landed on claim

@_nat: Yeah, I thought so. At least, that’s how it is in Japan. The passport number is the other way round though. It is metadata for a person and a claim for the I.D. (Identity Document).

^^ I just found this interesting

New Yorkers Scandalized

The NY Driver’s License design we see above appears to be a further evolution, rolled out in 2022, on a basic structure was rolled out in 2013, to the horror of locals.

Headlines included:

• Bendy new york drivers licenses killed by no fun dmv
• Behold New York’s Blah New Driver’s License

Driver’s license designs are the target of vitriol you couldn’t imagine – a topic I expect to revisit in the future. For now, make do with this reddit thread titled “When designers give up: Arizona releases some of the ugliest Driver’s Licenses imaginable”, even containing ad hominem attacks on Mr. Jelani Sample, misnaming him “Brah McDouchebag”. Say what you will about Mr. Sample, he looks much younger than his 65 years of age and I thank him for his service.

The term “Verifiable Credential” is formally defined in the W3C Verifiable Credential specification enabling portable, individual-managed identity claims, but you’re not here to read a spec – you want some light, if not entertaining, reading, so let’s sidle on up to VCs through real-world comparisons.

Blogs shouldn’t need tables of content, but here we are…

Table of contents

• Context
• Terms and concepts
• How this maps to your real-world credentials
• How are your real-world credentials verified today? 😕
• Why credential verification is so hard
• Quick takeaways and more grandstanding
• Verifiable Credential verification 🎉
• The VC value proposition, summarized
• End Notes

Context

It’s easiest to think about VCs in relation to cards, badges, and documents you already use to establish aspects of your identity: your age, where you live, your skills, accomplishments, and privileges – your…“credentials”. Many of these are in physical form, and allow you to gain access to a location or to information.

Some examples, all of which may be represented by VCs in digital form are:

• Driver’s licenses
• Passports
• Student or employee ID cards
• Airline tickets
• Insurance cards, such as medical or auto
• Learning records, including
  • formal ones, like diplomas or transcripts
  • informal ones, like completion of a course
• Proof of purchase or participation in a community[²]

Just as you carry your (physical) driver’s license or ID card in a (physical) wallet, wristlet, belt bag, disco backpack, or other personal carry-all, you can carry VCs around with you in a digital wallet or carry-all.[³]

How is this different?

On the surface, this doesn’t sound innovative and you may ask: haven’t we solved this already? There are already digital versions of many of the above examples plus wallet apps to store them; isn’t it just a matter of time before all are addressed? Well, sort of, but VCs solve a lot of problems lurking right around the corner.

A quick way to visualize one such problem is with this question: Do you carry around multiple physical wallets? One to store your auto insurance card, another to store your driver’s license? Of course not. However, many of your digital wallets were designed with specific data in mind, leading to a many-digital-wallet outcome that will only get harder to manage over time[⁴]. And there are many other limitations that VCs address, such as lockin and dependencies on service providers, but let’s start with the basics.

Terms and concepts

The W3C Verifiable Credential Data Model defines a “Credential” and a “Verifiable Credential”, which are related as follows:

Take a Credential, add a “proof” – a cryptographic seal – and poof you get a Verifiable Credential

We need to go one layer deeper to define the contents of a Credential, but that will be all the formalism we need for now.

A Credential is a set of one of more Claims with associated Credential Metadata:

• a Claim is an assertion (or statement) made about a subject, which you can assume is a person for purposes of this post.
  • Example claim: Jessica (subject) is authorized to drive (assertion)
• Credential Metadata refers to metadata in the usual sense: info about the credential itself, like the issuance and expiration dates, who the issuer is, etc
  • Example credential metadata for Jessica’s driver’s license:
    • Issuer: NY state DMV
    • When issued: March 7, 2022
    • Expires: March 7, 2029

Please forgive the overused driver’s license example – this is only to ground these definitions in (highly likely) familiar real-world credentials, although I’ve introduced US-specific quirks in the “use and verification” section.[⁵] You’ll soon see that there are VC use cases that are far more interesting than driver’s licenses.

How this maps to your real-world credentials

Before spending time on the “verifiable” (proof) part, it’s worth elaborating the credential part, to see how this maps to identity credentials in the wild.

Example: Jessica’s college diploma – she has a B.A. in Communications from a university we’ll call “A University”:

• Claim: Jessica (subject) has a B.A. in Communications (assertion)
• Metadata:
  • Issuer: A University
  • When issued: May 29, 2016
  • Expires: N/A; it should be valid for life[⁶]

But wait, Jessica’s diploma has another claim in addition to “has a B.A. in Communications” – it also says she graduated summa cum laude (with highest distinction)…and it has her full legal name:

If it’s not obvious by now, I’ve changed almost all real-world details about Jessica to protect her privacy. In fact, I used an elf name generator

In general, many of your real-world credentials contain multiple claims – full name, date of birth, residence, etc. In addition to enabling access to locations and services based on identity attributes (e.g., proving you’re over the age of 25 to rent a car), these can be used to corroborate, or reliably enhance, other identity credentials[⁷].

The following table breaks down a few more real-world credential examples to demonstrate the similar structure and metadata.

All of this is to belabor the point: the VC data model was developed with many real-world credentials in mind, and takes advantage of common structure and metadata, such as:

• Issuer: who said it
• Issuance date: when it was issued
• Expiration date: when it expires

As well as more dynamic properties, such as status. In other words, how do you determine if the credential is still valid? How do you know the issuer hasn’t revoked it? And this segues nicely to the verifiable part in the next section.

One benefit of VCs should already be clear: its common data structure makes it easy to read and extract key metadata, simplifying the proposition for “universal” digital identity wallets (or other applications that store and manage credentials), as well as consumers of the credentials, such as individuals or organizations you choose to share your credentials with.

How are your real-world credentials verified today? 😕

Let’s move to why and how you use your real-world credentials in the wild. Very loosely, you use them to prove aspects of who you are, your skills/accomplishments, or to perform a range of activities – enter a location, open a bank account. When required, you share your credentials with a “verifier”, who will determine if the credential is acceptable, or “verify” it.

With physical credentials, and even with many digital credentials in use, how verification occurs can be extremely complicated. So complicated, in fact, that your real-world credentials may be considered too much work to actually verify, as you’ll see in the next sections.

Fraud abounds, capable but under-recognized talent gets overlooked, and everybody loses. And this is the heart of the enormous advantange of VCs, the “verifiable” part.

Case studies

Before talking about how clean VC verification is, let’s get a taste for the extraordinarily weird world of verifying your current real-world credentials.

Case study 1: Driver’s license

Pretend you work at a convenient store, where you assume the role of “verifier” of driver’s licenses before allowing people to purchase alcohol. Think about whether you’d accept McLOVIN’s driver’s license.

You’d be fairly lucky to be handed a forgery this obvious. Some details clue you in to the fact that this may be fraudulent: the single name is not something you’ve seen before, and the age doesn’t appear to match the person standing in front of you. But you, trained verifier, are aware of other nuances confirming your hunch that this is not an authentic id. Perhaps the weight of the card feels flimsy, a watermark or state flag is missing, and so on.

But wait, this is just one U.S. state’s driver’s license. Do you, the verifier, need to memorize the structure and details of all other state driver’s licenses (in addition to U.S. passports, as well as international ID documents…)? This is clearly not feasible, so do you pay for a service or outsource the problem?

The level of diligence required depends on the exact use case, and corresponds to the stakes or penalties for the verifier getting it wrong. Fortunately for this discussion, US driver’s licenses – the strange standard bearer of our identity in the U.S. – have well-documented requirements[⁸]. Let’s explore some different contexts for how Jessica will use her New York state driver’s license, loosely ordered from what we’ll call “low” to “high” stakes, corresponding to the level of diligence that will be applied.

For our non-US friends wondering why identity cards are linked to the ability/privilege to drive, note that state DMVs can also issue non-driving “ID cards”. And we do have passports.

Example uses of driver’s licenses:

• Use Case 1: Jessica proves her age to purchase alcohol
  • Why verification is needed: Federal and state laws preventing sales of alcohol to minors
  • How verification occurs: Bartender or sales clerk, who has received training, inspects Jessica’s ID to ensure it’s current, doesn’t look fake, and that the photo looks like Jessica, who is standing in front of them.
    • Gory details:
      • An inspection includes checking the expiration date, date of birth, photo match, and ID’s unique features, which vary per state.[⁹]
      • While the verifier in this case has an interest in performing their duties, they are not necessarily checking the status of Jessica’s credential – i.e., the Verifier wouldn’t necessarily know if Jessica’s license was suspended.[¹⁰]
      • This reflects that driving privileges are actually unrelated to the use of driver’s licenses as ID cards. And in fact, other forms of ID are acceptable (like passports)
  • What if the verifier does a bad job:
    • If the verifier (bartender or sales clerk) is found to be negligent in their check, they can be fired, sued (if someone is injured or dies), face a criminal charge or jail time.
    • Also, the bar or store may be fined or lose their liquor license
• Use Case 2: Jessica needs to provide identification to open a bank account online
  • Why verification is needed: Financial service providers have a vested interest in preventing fraud to protect the bottom line. Plus, they need to comply with a number of regulations.
  • How verification occurs: The bank probably pays a service to do the work. This involves having Jessica submit digital copies – photos – of her driver’s license and other materials. They may also have her upload a selfie as a simulation of an in-person verifier’s ability to check that the person standing in front of them looks like the photo in the ID.[¹¹]
    • Gory details:
      • As with Case 1, a driver’s license isn’t specifically needed, but it is commonly used in the US to fill the bank’s requirement for a valid government-issued photo ID and other docs that confirm your name, date of birth, address, ID number (social security number of taxpayer ID number) as part of identity verification[¹²]
      • Also as with Case 1, the bank needs to ensure it’s not expired, but they probably don’t care if Jessica’s driver’s license is revoked because she have a ton of unpaid parking tickets, so a status check may not be performed. That said, they do care if she’s on a government sanctions list and will check her name and personal information against, e.g., the OFAC SDN list[¹³]
  • What if the verifier does a bad job: Enormous fines and possible imprisonment[¹⁴]
• Use Case 3: Police pull over Jessica and ask for her driver’s license
  • Why verification is needed: Police wants to ensure Jessica is an authorized driver, and there’s not a warrant out for her arrest
  • How verification occurs: Police “run” Jessica’s license which directly checks a database that is up to date with state DMVs and also compare the photo
    • Gory details: Aha, someone finally cares if Jessica’s driving privileges are revoked because this is their “wheelhouse” 🥁 and that is why they will check state DMV databases
  • What if the verifier does a bad job: I don’t know? Unlike the above examples, this is one of their core law enforcement functions, and if the context is that you’re already pulled over, you tend not to worry about them erring on the side of lenience. I imagine it really depends and could range from internal disciplinary action to criminal penalties. This topic is fraught…
• Use Case 4: Jessica presents her ID to TSA before boarding a domestic flight in the USA.
  • tl;dr: this is like Case 3. Although TSA doesn’t care about your driving privileges, one of their core functions is ID verification to help ensure safe travel. TSA is not messing around with this, and they invest large amounts in specialized systems.

From now on, we won’t be as exhaustive, reflecting (1) that the previous section was overkill and (2) the fact that verifiers aren’t as diligent anyway

Case study 2: College degree

Use case: Jessica applies for a job[¹⁵]

• Why verification is needed: Employers want to make sure Jessica’s claims about her education and work background are correct. In some cases, a background check may be part of their compliance program.
• How verification occurs: The risks and associated level of effort vary within different phases of the lifecycle
  • Recruiter: initially, they are screening Jessica as a sanity check. They may simply look at Jessica’s resume and her LinkedIn, but probably won’t request proof of her college degree
  • Employer:
    • After Jessica passes the interview, but before extending an offer, they may validate Jessica’s college degree (in addition to other aspects of her identity and experience)
    • If so, validating Jessica’s claim requires contacting the college or a “clearinghouse”, which is an aggregator across many institutions. The employer likely uses a service to perform this check as opposed to contacting the college/clearinghouse directly.
    • But…they may not, and college degree fraud is very common.
• What if the verifier does a bad job:
  • Well, this also depends, and the stakes may be quite high if the employer is a regulated entity. i.e., they may be fined if they are a bank
  • But her college degree is not the key document here. If they’re a regulated entity, they’re actually doing a background check, for which her other ID documents (driver’s license, etc) are most important
  • But otherwise, they’re concerned with ensuring overall Jessica is qualified for the job and it’s a loose calculus based on her work experience, etc.

Case study 3: Online course credentials (or, more generally, lifelong learning and skills)

Jessica is a lifelong learner and her college degree, though impressive, is one of the least interesting things about her. She’s enhanced her skills beyond what’s typical for a communications professional, and recently completed an online program in business administration and operations, for which she has a digital credential (as a PDF). She’s now looking for a new opportunity for which these recently-added skills are needed.

Use case: Jessica uses her online course credentials as part of her application to a job with more responsibilities

• Why verification is needed: Employer wants to ensure she has the skills and qualifications she claims
• How verification occurs:
  • Recruiter: might just look on LinkedIn, but may not take educational credentials other than a traditional 4-year or above degree seriously. The recruiter will also factor in past job titles, but note that it’s easy for someone to misrepresent job titles on their resume and LinkedIn. In sum, credentials establishing non-formal + informal learning and skills might not get her in the door for an interview.
  • Employer: If she’s lucky, she gets through the recruiter and makes it to the employer interview, during which they’ll try to assess her skills. The employer probably won’t put much stock in her online learning credentials beyond their ability to paint a picture of Jessica as a motivated person. The employer might contact her references as a sanity check.

Why credential verification is so hard

What’s going on here? Credentials representing your skills and accomplishments as an adult are largely ignored?

You don’t need to feign surprise; you already know this to be true. But isn’t it weird that credentials attesting to additional learning and skills credentials beyond some arbitrary point in time, maybe when you were a fairly naive early 20-ish person, are largely ignored?

Pivoting to someone without a 4-year degree, the challenges are even more pronounced. A common scenario is this: a person begins a traditional educational program but has to stop a few credits short of, e.g., an Associate’s Degree. Their education combined with work experience may make them more than qualified for a higher-paying role, but they can’t get in the door if the potential employer has an arbitrary requirement for a 4-year degree (or otherwise, doesn’t have a way of admitting non-traditional candidates).

This isn’t to imply that non-traditional credentials are a panacea, or that they could completely remove the need for an interview, but they could help in the following ways:

1. Broaden the candidate pool to people who have evidence of skills needed to perform the responsibilities of a job
2. Enable a more focused interview. If you’re a developer, imagine you had a “can code basic data structures and algorithms” credential. If everyone knows that means you can write a program that reverses a linked list (among other thongs), your interviewer could ask you more interesting and relevant questions.

The problem of discriminatory – or gatekeeping – credentials/requirements applies outside of learning and employment scenarios; we see gatekeeping preventing access to financial products and services, and more. Many of us working on decentralized identity share a passion for unlocking new opportunities by establishing ways for people to prove a much broader range of information about themselves. Continuing in the area of financial products and services, perhaps one day proving reliable payment history could replace the requirement for a certain credit score from one of the “big 3” agencies.

So why is verifying anything other than “high stakes” credentials so challenging?

Reason 1: How to know it’s valid?

First, there aren’t well-established norms around verifying, or determining whether to accept, such a document – specifically ensuring it hasn’t been tampered with and is authentic.

If it’s a signed PDF, at least the recipient can determine it’s not been tampered with in their PDF reader – BUT, it may be hard for them to determine whether it’s issued by the party they expect. How do they know it was Wharton and not some imposter Whart0n? There are solutions, but they vary widely, and that’s why there are specialized vendors and cottage industries – or, in the absence – potential for fraud.

In general, credentials don’t carry with them a first-class notion of tamper evidence, so verification requires contacting the issuer. In other words, your credential is basically a pointer to an issuer that can vouch for it. Knowing the issuer us the expected issuer (or is authentic) is yet another unsolved problems.

Reason 2: What does the credential even mean?

Second, many of the naive digital equivalents of credentials are not natively digital: they either need a human to read and interpret them, or they use a bespoke parser that’s familiar with the structure and meaning of the expected content. So when you send your course completion PDF, the person receiving it may open the file and read it, but they generally has no context about what the “value” of it: how rigorous was the course? what skills did you learn?[¹⁶]

This is a powerful opportunity enabled by verifiable credentials, which can be described as linked data. This lets issuers anchor credentials in rich definitions of what the credential means, which ultimately enables the translation of credentials.

Reason 3: Is it even about you?

Third, difficulty ensuring the credential is actually about you is a tremendous barrier that is generally reserved for high-stakes/high-risk use cases, like opening a bank account. The bank, or verifier, will collect multiple documents, compare that they have the same full name, compare the photo to a real-life person or uploaded selfie, and so on.

This is a lot of work, so, in the case of “lower-stakes” use cases or less critical identity claims, verifiers may know (and are possibly willing to accept the risk) of fraud or forgery.

Quick takeaways and more grandstanding

To summarize, we’ve covered a wide array of identity document and their verification in use cases along a spectrum:

• “Low stakes”:
  • Verifiers decide it’s too much work and they kinda sorta take your word for it.
  • Verifiers don’t put much stock in them. They are more interested in how this weaves into the overall texture of the 4-dimensional you flattened into 2-D identity claims, but it’s not taken too seriously.
  • This results in – on the one hand – fraud, and – on the other – basic mistrust of non-traditional entry points.
• “High stakes”:
  • Verifiers really care and spend lots of money (on services, etc) to check.
  • Verifiers require multiple forms of identity documents, cross-checking them against each other, such as when you obtain a foundational identity document like a driver’s license[¹⁷]
  • They only bother if, directly, it’s their core reason for existing, or, indirectly, if there are financial incentives or penalties
  • They may use a bespoke service or mostly ignore the document you share with them and contact the issuer or authoriative source.
  • Note the implication of this: you, the holder of the credential are fairly incidental. You are carrying a credential that serves as a pointer to someone who is actually trusted.

Verifiable Credential verification 🎉

Why?

Moving back to VCs, what if we didn’t have to leave these lower-stakes claims by the wayside. What if there was a unified model for both.

Imagine a world where your formal and informal learning credentials, including skills gained on the job, are easily verifiable. This might unlock new opportunities for the applicant. For the employer, this could broaden the pool of skilled candidates and sharpen the focus of the interview process

How it works

Verifiable Credential Verification can be viewed in a layered way

Common verification checks

There are certain verification checks you want to perform no matter what the credential type, such as:

• Is the credential authentic; i.e., issued by the claimed entity?
• Has it not been tampered with?
• Is is timely? I.e., is it expired?

The common data model and VC proof, or cryptographic signatures, enable these checks to be performed in a consistent way no matter what the credential

Extension points for different types of implementations and use cases

To enable future proofing and flexibility + extensibility, the VC data model doesn’t prescribe specific methods of performing credential status checks, specific cryptographic signature suites, etc. Instead, it defines extension points enabling different implementation choices, as well as different determinations of fitness of purpose.

The ability for subjects to “authenticate”

The ability to use strong methods to prove the credential is really about you is currently reserved for “high stakes” identity documents issued by centralized authorities. In a VC, credential subjects can be identified by decentralized identifiers (just as the issuer can).

The ability to participate as a peer

But even better, in the context of decentralized identity, “authentication” doesn’t imply subjugation. Issuers, verifiers, subjects/holders are all roles any entity can take on, and they can interact as peer. You might ask an issuer or verifier to authenticate with you, so you can ensure they are who they claim. Immediately, this enables security advantages such as detecting phishing attacks.

This also enables “peer claims”, or provable statements from the many people we encounter in our daily life, attesting to our skills and experiences, which could paint a more complete picture of who we are. For example, a work colleague can issue you a credential attesting to your mentoring strengths.

Open ecosystems

Lastly, VCs were designed for open ecosystems – not dependent on centralized entities. The same VC structure used by an educational provider or DMV can be used by one of your work colleagues or peers, for example to attest to your team leadership skills. A verifier may not accept such a claim, and that’s totally fine! The key point is that VCs allow consistent ways to verify credentials that you directly carry with you.

There is no censorship at the base layer of who can issue, which types of claims are important, etc. It’s up to ecosystems to decide whom to trust and what to accept.

Privacy and Agency

Lastly but not least, VCs were designed to enable individuals to truly own their identity credentials, share them with parties they choose, and reveal what’s appropriate for a given context. This is enabled by other decentralized identity standards covering how credentials are requested and shared, as well as signature suites enabling zero knowledge proofs (or ZKPs). For example, you can ṕ̶̬̜̩̳͑r̷̹̔́ơ̸̟̙̤̘̎̇̋̇̐v̸̢̤̦̞͛̓̋̔̾e̸͉̔́͌ ̵͔̓͝ỷ̴̡̒̀́͠͠o̸̧̤͈̦̭͗́́̒̆ũ̷͉̿’̸̰̿̋̇͌̓r̵͎̙̫̩̱̎́ͅe̷̢͕̩͉͆ ̸̣̘̦̭͉̼͂o̶̹̫̘̻̯͒ͅv̷̟̞͉̹̙͌e̶̼͗̿̎̄͂͘r̶͎̺͝ ̷͓̓̈́̏2̴̖̹̱̾̉̀̈́̋ͅ1̶̛̰̞͇͕̖͙̓̊̏͌͝ ̴̢̗̀̽͋̀͆w̷͍͎̦̤̱͊̄̏͌̂i̸̡̻̖̼͚͂̚ẗ̸̨̛͈̰͔͎͑̿h̵̛̼̟̭͌̈͊̕͠ò̶̬͓̖̦̀̌̌̌͝u̸̟͌͆t̶̯̒̑̂ ̴̭̌̈́́͝ͅṛ̷̏̾͛͘e̷̲̟̘͑̈́̈́ͅv̸̻̼̒e̸̙̕a̷͔͙̋̆̂̆͑͘l̷̺͉̘̘̦͘̚͜ǐ̸̧̻̹̲͕̱̐͛̈́́͊ņ̸̝͙̮̫̔̃̉̓̔g̵͔̯̬̯̱͆̊̆̈͊̕ ̸͚̣̗̺̖̃̈́̏͘y̶̻̐͝o̸̙̞̝͙͂͛̔̕u̵͉̒̈́̈̽̌̏r̶͔̾͐̐̈́ ̸̠̹͑̏̏͆͘͝ẽ̴̢̧̡̤͓̌ẍ̷́̓͂̍̈́͜à̴̢̨̜̘̤̜c̴͓̍̇̚ť̸͙̔̃̈́̀͐ͅ ̴͈̫͍̄̅͗̆͂̅a̷̡̩̯̻͚͒͂̇̉͜͠ğ̷̼͎͛̃͊e̸̦̎

Status checks can be performed without “phoning home”, which means the life of the credential can outlive the issuer (which is valuable if the issuer goes out of business, especially relevant in post-secondary educational credentials in the U.S.), but also enables reduced tracking that occurs with federated login models.

The VC value proposition, summarized

Verifiable Credentials:

1. Specify a common data model, allowing consistent ways to read it.
   • And as a benefit, allows machine readability and consistent ways of extracting metadata such as the issuer, when it expires, etc
2. Are extensible, supporting a wide range of claims
   • E.g., passports, airline tickets, learning and skills qualifications, and even peer claims
3. Enable consistent ways to interpret the meaning of a credential; someone receiving the credential knows how to interpret the credential in the way the issuer of the credential intended.
4. Specify consistent, but extensible, ways to ensure the credential is valid – hasn’t been tampered with, is current (not expired or revoked), and is authentic. Issuers have control over the lifecycle where needed, but can accomplish this in decentralized, privacy-preserving ways.

   The above makes life easier for verifiers and can help reduce vendor/provider lockin for you. Now moving onto benefits for you, the credential subject…

5. Self-custody (note: beyond a simple pointer to a “trusted” issuer). You can carry then with you and relying parties can confirm they’re authentic and tamper-proof.
6. Trusted interactions in an open ecosystem: mutual authentication, open ecosystem at the base layer, trust overlays enables flexibility and choice
7. Privacy and Agency: avoid tracking, reveal only what you approve of, use your credentials even if the issuer goes out of business

All of this helps break apart silos that exist with traditional identity verification, giving you more control over your data.

End Notes

He’s adorable but don’t be deceived. He’s distracting, and not just because of his good looks. He makes sounds that are unnatural for a dog – sort of between a sqwak and a braying sound – and this flares up during the time I should be writing.

More seriously – but I’m not exaggerating on the sounds – he’s a very sweet special needs senior doggie we adopted a year ago. We recently found a vet that’s much better for him, but this involves a medication transition time that’s rough on him.

Before you worry about him, don’t. He’s better taken care of than you’ll ever be. He’s got a team of professionals, gets weekly massages, and – soon – near-weekly acupuncture treatments.

My originally-planned next post requires intense focus time, which isn’t happening at the moment, so I’ll polish up some of the easier content. Coming soon!

In this post (and this blog in general), the word “identity” almost always refers to your digital identity. We’ll distinguish this from «Identity» with a capital-I, which refers to other ways in which you may be thinking of this word, i.e., to describe the complex, multi-faceted, and beautiful person that you are 🤗, which can never be reduced to digital representations.

Digital identity includes ways you knowingly use it, and ways it is used without your knowledge or consent.

Examples:

• Accessing online services, such as logging into your account on a web site
• Being asked to provide proof of your attributes or state/government official documents, such as a driver’s license
• Data aggregators building a profile of you based on your online activities

That escalated quickly. Let’s focus on the first one, which seems straightforward. When you log into a web site, of course they need to know who you are, right? I.e., they need to know your «Identity»?

Actually, in many cases they don’t, but you are certainly accustomed to service providers requesting (or already possessing through mysterious means) way more information about you than they need.

For now, keep in mind that the word “identity” may set an unfortunate mental model (and acceptance) that you need to provide more information about who you are than is needed to obtain a service. Certainly in some cases, e.g., due to regulations, a lot needs to be known about you. In other cases, you are simply cowed into handing over bonus personal information, which turns out to be a profitable side hustle for your service providers.

In fact, some identity experts are highlighting the need to shift away from “identity” and the baggage it brings along. The refreshingly blunt Steve Wilson declared “Identity is Dead”, underscoring that online service providers rarely need to know who you are.

Evolution of digital identity models

Decentralized identity is often presented as the next step in the evolution of digital identity models. To be concrete, think of logging into your account on a web site. In general, you’re accustomed to logging in with your username and password. (Increasingly sites may require additional confirmation – such as having you enter a confirmation code they emailed – to avoid some security problems touched on below, but that doesn’t affect this overview.)

Centralized identity

In the early days of the web, when sites looked like this…

…and you browsed the web in your pleated, acid-washed jeans, you needed to create a different account for every web site you use. We refer to that as centralized identity.

In this model, each organization you interact with does the work of authenticating you (confirming you’re the user they expect), which includes storing and securing your acccount login credentials.

Each of these organizations further needs you to enter relevant personal data (your shipping address, for example), which they store along with any other data you generate while interacting with them – usage activity and other artifacts.

The end result is that your data, including information needed to verify your login credentials, is stored with every organization you interact with.

If you’re worried about your data being everywhere, good. This data is vulnerable and it’s constantly being breached. Note that this problem doesn’t magically get fixed as we move up the identity evolutionary spectrum. We’ll come back to this later.

Federated identity

Because handling user authentication carries risk, not every organization wants to do it themselves. A way to offer increased security and convenience to users is through federated identity. In this model, identity providers authenticate you as a service to you and other organizations.

You know this very well from the “login with google”, “login with facebook”, etc buttons you’ve seen on some web sites. (FWIW, we call this the NASCAR view.)

But this means fewer organizations have your data, right? Only the identity provider has it?

OF COURSE NOT my sweet summer child. On the one hand, these organizations may need some items to transact with you, like your mailing address. But more importantly, everyone wants your data, that pure digital gold. However, in this model, fewer people are managing securing your login credentials, which is a win.

In sum, the benefits to you in this model are:

• Managing fewer logins
• Ideally these identity providers are better equipped to secure your login credentials

But oh what a fantastically complete view into all your online activities can be built with this model, as you are correlatable across all of these organizations and beyond. This data is extremely valuable to anyone that wants to advertise to you in a more targeted way, and this is sold, aggregated, repackaged, shipped around everywhere.

On the other hand, very little of this data proliferation actually manifests as convenience to you. Companies that control especially valuable data silos are extremely protective of these gold mines and generally have no incentive to make it easy for you to leave their platform for another.

Decentralized identity

Then we get to decentralized identity. At this point in a decentralized identity presentation, you would be told that decentralized identity is intended to fix some of the problems described above. (Suspend disbelief for a minute.)

On offer:

• Portable data you control
• Your consent is required before your data is used/shared
• Service providers only obtain the information they need to transact with you.

In the deccentralized identity model, you interact directly with peers, which includes service providers/organizations from the previous diagrams. (Note the shift in power – in fact you can mutually authenticate.)

In this model, distributed ledgers are often used to anchor data that assists in verification and generally establishing trust. But note that personal data is never stored on-chain, or rather, it shouldn’t be. We’ll come back to this in much greater detail.

So anyway, decentralized identity solves all of your problems through the magic of blockchain and cryptography, and so you switch to this model and your identity is fully decentralized, no one has a copy but you, and we’re done. 😌

No. Sadly, after all that, decentralized identity models do little on their own.

Service providers may keep a copy of your data, and they may sell it to others. This fancy bit of tech has can’t disrupt the data broker industrial complex overnight. So where does this leave us?

Back to the real world

The above was a straw man argument, but that was intentional. The fact is that many representations of decentralized identity (or self-sovereign identity) focus on purely technical solutions to complex problems, scaring away potential partners whose perspective is critical to achieving the goals of decentralized identity. I’ve seen this in education, for example, with experts assuming decentralized identity must be incompatible with educational regulations, such as FERPA in the USA.

This is a good reminder of the limitations of what a technical solution on its own can accomplish, and the nuances of applying decentralized identity architectures, standards, and technologies to the real world.

In practice, while decentralized identity tech may improve some of the problems described above, we still require regulatory frameworks (such as the GDPR) to nudge service providers to obtain your consent to use your data, allow you visibility into data collected about you, etc.

Also keep in mind that sometimes organizations are required to keep data about you (e.g., for compliance with financial regulations). And so the representation that, with decentralized identity, no one but you will have a copy of your data is not realistic.

Broadening our view, and a definition

With this reminder, the goals of decentralized identity require a much more comprehensive approach. For now, we’ll use the following definition to try to capture where the goals of decentralized identity cannot be achieved through tech alone:

Decentralized identity: a set of technical standards and principles seeking to enable a shift toward more individual control over digital identities and personal data.

Advantages and Opportunities

Decentralized id standards do help with some things right away, but other things require a longer view.

Immediately, decentralized identity standards are useful for making your data more portable. You can take your work, education, financial (such as accredited investor status), and other credentials with you, sharing them with others who can independently verify they are authentic and tamper-proof – without needing to cntact the issuer. This aspect can offer immediate efficiencies and ease of access.

In the longer view, we need to consider possibilities unlocked by this new architecture. And this is the exciting part, which won’t happen overnight.

And this would be a good cliff hanger, so bye!