“For the last several years, a great deal of work in digital identity has focused on making wallets and verifiable digital credentials possible.”

That work is paying off. Standards are stabilizing, governments are moving, wallet programs are becoming real, and regulations are starting to create obligations for organizations to accept certain credentials.

Earlier this year, I wrote about the gap between that momentum and the actual maturity of the wallet ecosystem in “Wallets and Credentials Are Here. Maturity Is Not.” My concern then was that the technology was arriving faster than the operational, governance, and business models around it were settling. I still think that is true, but the next part of the problem is becoming harder to ignore: somebody has to actually accept the credential.

That somebody is the relying party, or verifier, depending on which terminology you prefer. It may be a bank, airline, retailer, employer, government agency, healthcare provider, or any other organization that needs some piece of information about a person before allowing a transaction to proceed.

From the verifier’s point of view, “wallet adoption” looks rather different than it does from the perspective of an issuer, wallet provider, standards developer, or regulator. The verifier already has a process, and the important question is whether accepting a digital credential makes that process better.

You can Subscribe and Listen to the Podcast on Apple Podcasts, or wherever you listen to Podcasts.

And be sure to leave me a Rating and Review!

Regulation can create adoption

Regulation is doing an increasingly effective job of creating the stick. Organizations may be required to accept particular forms of digital identification or credentials, and governments can create deadlines, certification requirements, liability rules, and market-access conditions that move adoption along much faster than hoping every verifier independently decides that accepting digital credentials sounds like a good idea.

But regulatory compliance is a fairly low bar for success. If an organization is required to support a wallet flow, it will support one. That does not mean the resulting experience will be particularly elegant, nor does it mean the organization will redesign the surrounding process to take advantage of what the credential can do. The new flow may simply be bolted onto an already complicated identity process.

That is the difference between making something available and making it valuable. A relying party under regulatory pressure is primarily asking, “What do I have to do?” A relying party with a compelling business reason is much more likely to ask, “How quickly can I deploy this, and what can I improve when I do?”

I am much more interested in the second question.

The credential is not the carrot

We tend to describe the benefits of digital credentials in terms of their technical properties. They are cryptographically verifiable. They can support selective disclosure. They can carry information from authoritative issuers. They can be presented from a wallet. In some scenarios, they can reduce dependence on scanned documents or repeated identity proofing.

Those are useful properties, but none of them, by themselves, are necessarily a reason for a relying party to spend money and engineering time integrating a new identity flow. The carrot appears when accepting the credential allows the relying party to stop doing something expensive, slow, risky, or annoying.

Maybe the organization no longer needs to collect and store an image of a driver’s license. Maybe it can replace document upload, OCR, selfie matching, and manual review with a much shorter interaction. Maybe it can reduce fraud, accept a trusted piece of information from another jurisdiction that it previously had no practical way to verify, or ask whether someone is over a particular age without collecting a full date of birth.

Those are business outcomes. That is where the carrot starts to become visible.

The credential itself is plumbing.

What actually goes away?

This is where I think the wallet conversation needs to become much more demanding. It is easy to imagine a new credential flow being added to an existing verification stack while almost nothing else changes.

A customer may present a credential, but the relying party still asks for the same information in a form. The customer may prove an attribute through a wallet, but the organization still collects a document image “just in case.” The verifier may receive an authoritative assertion, but the risk team continues to require the same manual review because nobody has changed the surrounding policy.

In that version of the future, the wallet becomes another front door into an old process. It may satisfy an acceptance requirement, but it does not necessarily create much value.

A more useful test for any credential deployment is therefore not simply whether the relying party can accept the credential. The better question is what existing process disappears because the relying party accepts it. If the answer is “none,” then the business case is probably weaker than we think.

The happy path is only part of the work

A session at the recent Global Digital Collaboration conference made me think about this more deeply. The discussion was primarily about the complexity that relying parties will encounter as European digital identity wallets begin entering the market. tl;dr – it’s a lot.

Different national wallets will arrive on different schedules. Wallets will interact with different operating systems and browsers. Multiple protocols and transport mechanisms are possible, and more than one credential format may need to be handled. Any single successful transaction may look fairly straightforward, but the implementation space around that transaction is not.

The memorable line from the discussion was: “One happy path, eleven potential unhappy paths that must be handled with consistent messaging.”

I do not think the exact number is the important part. Complex systems have failure modes, and any production identity system already has plenty of them. What matters is who owns the experience when something fails.

To the standards developer, a protocol error may be perfectly understandable. To the user, the website asked them to prove something, their wallet opened, something did not work, and now they do not know whether the problem is the wallet, the credential, the browser, the site, or them. The relying party owns that interaction, whether or not the underlying failure originated in its own system.

That makes wallet acceptance a product and operational problem, not merely an interoperability problem.

Compliance produces a different kind of deployment

This distinction matters because organizations optimize differently depending on why they are doing something. When the primary goal is compliance, the natural target is the minimum implementation that reliably satisfies the requirement.

That is not a criticism. Businesses do this all the time. If regulators tell an organization that it must accept a particular credential, the organization has every reason to ask what is necessary, what it will cost, and how little disruption it can introduce into the rest of the customer journey.

The result may work perfectly well. But if accepting credentials can demonstrably lower fraud, shorten onboarding, reduce stored personal data, eliminate document-processing costs, or improve conversion, then the incentives change. Wallet acceptance stops being a compliance project sitting beside the customer experience and becomes part of the customer experience.

That tends to produce better systems.

We need a stronger verifier story

The digital credential ecosystem has become fairly good at explaining why issuers should issue credentials and why individuals might want wallets. The verifier case is still much less crisp.

“Digital credentials are coming” is not enough. “Your regulator may require you to accept them” will certainly move the market, but it is not the same thing as demand.

The much more useful story is specific: Accept this credential and

• you can stop collecting this document;
• these manual reviews disappear;
• this transaction becomes possible;
• you can reduce the amount of personal information you retain.

That is where the incentive sits.

Wallets will get deployed without a compelling carrot because regulation can see to that. The more interesting question is whether they will get deployed in a way that makes relying parties genuinely reluctant to go back to the process they had before.

📩 Want to stay updated? I write about digital identity and related standards—because someone has to keep track of all this! Subscribe to get a notification when new blog posts go live. No spam, just announcements of new posts. [Subscribe here] 

Transcript

Over the last several years, a huge amount of work in digital identity has gone into making wallets and verifiable digital credentials possible.

That work is beginning to pay off. Standards are stabilizing, governments are moving, wallet programs are becoming real, and regulations are creating actual obligations for organizations to accept certain kinds of digital credentials.

A few months ago, I wrote about how wallets and credentials were arriving faster than the operational, governance, and business models around them were settling.

I still think that’s true.

But there is another part of the problem that is getting harder to ignore.

As soon as wallets and credentials move out of pilots and into real markets, somebody has to actually accept the credential.

---

The Verifier Is Where Adoption Becomes Real

That somebody is the relying party or verifier, depending on which terminology you prefer.

It might be:

• A bank
• An airline
• A retailer
• An employer
• A healthcare provider
• A government agency
• Any organization that needs to know something about a person before allowing a transaction to proceed

From the verifier’s point of view, wallet adoption looks very different from the perspective of an issuer, wallet provider, standards developer, or regulator.

The verifier already has a process.

The question is whether accepting a digital credential makes that process better.

---

Regulation Can Create a Stick

Right now, particularly in Europe, regulation is doing a pretty effective job of creating a stick.

Organizations may be required to accept particular kinds of digital identification or credentials. Governments can create deadlines, certification requirements, liability rules, and conditions for participating in a market.

That will move wallet adoption faster than simply hoping every relying party independently decides that verifiable credentials sound exciting.

If an organization is required to support a wallet flow, it will support one.

However, that does not mean the resulting user experience will be especially good.

It also does not mean the organization will reconsider all of the processes surrounding that credential and ask whether they are still necessary.

There is a very plausible future where an organization adds a “Present from Wallet” button and keeps almost everything behind that button exactly the same.

That counts as adoption.

I’m not sure it counts as progress.

---

The Difference Between the Stick and the Carrot

This is where the difference between the stick and the carrot becomes important.

A relying party responding to regulation asks:

What do we have to do to implement this?

A relying party that can see real business benefit asks:

How quickly can we implement this, and what does it let us improve?

Those two motivations tend to produce very different deployments.

The problem is that those of us working around wallets and credentials often describe their advantages in fairly technical terms.

A credential can be:

• Cryptographically verifiable
• Capable of supporting selective disclosure
• Issued by an authoritative organization
• Presented from a digital wallet
• Used to reduce reliance on document images or repeated identity proofing

All of that is useful.

However, none of it is necessarily a business reason for a verifier to invest engineering time and money into a new identity flow.

---

What Can the Credential Help You Stop Doing?

From the relying party’s perspective, the more interesting question is what those technical properties allow the organization to stop doing.

Maybe the verifier no longer needs to collect and retain an image of someone’s driver’s license.

Maybe an onboarding process that currently involves:

• Photographing a document
• Uploading it
• Running OCR
• Performing a selfie comparison
• Waiting for a liveness check
• Potentially sending the whole thing to manual review

can become substantially shorter.

Maybe fraud drops.

Maybe a business can accept authoritative information from a customer in another country that it previously could not verify without a significant amount of manual work.

Maybe an age-restricted service can establish whether someone is over 18 without collecting their actual date of birth.

These are interesting outcomes.

They’re also much easier to explain to a product owner or CFO than “we can support selective disclosure.”

The credential is just plumbing.

The carrot is what that plumbing allows an organization to make simpler or less expensive.

---

When a Wallet Becomes Another Front Door

I think this is where we need to get much more demanding about the wallet value proposition.

Imagine an organization adds support for a digital credential.

The customer presents it successfully, but the application still asks them to enter the same information in a form.

Or perhaps the organization accepts an authoritative credential but still asks for a scan of the physical document just in case.

Maybe the credential proves exactly what the organization needs to know, but the internal risk policy still sends the transaction through the same manual review process because nobody has changed the policy.

If that happens, the wallet has not replaced the old identity process.

It has simply become another front door into it.

That may still satisfy a regulatory obligation.

But the value proposition is pretty thin.

So instead of asking whether an organization can accept a credential, I think we should ask a much harder question:

What existing processes can go away because the organization accepts the credential?

If nothing goes away, I’m not convinced we’ve made the verifier case yet.

---

The Operational Problem

There is another complication here.

A recent session at the Global Digital Collaboration Conference highlighted the operational challenges European relying parties may encounter as national digital identity wallets enter the market.

There will be:

• Different national wallets arriving on different schedules
• Different operating systems and browsers
• Multiple mechanisms for moving a credential presentation from wallet to verifier
• Multiple credential formats

The details get complicated quickly.

One line from that session captured the operational problem particularly well: there may be one happy path, but there can be many potential unhappy paths that need to be handled with consistent messaging.

The exact number isn’t really important.

Every identity system has failure modes.

What matters is who has to deal with them.

---

The Customer Experiences the Failure

Suppose I’m a customer and a website asks me to present a credential.

I tap the button.

My wallet opens.

Something fails.

From my perspective, that’s the whole story.

I probably don’t know whether:

• The browser failed to invoke something correctly
• The wallet does not support the requested credential
• The credential uses an unsupported format
• The issuer cannot be trusted
• The request timed out

And I shouldn’t need to know.

The standards developer may understand the error perfectly.

The wallet developer may understand it.

The browser team may understand it.

Good for them.

The customer knows that the site didn’t work.

And the relying party owns that experience.

So wallet acceptance is not only a standards integration problem.

It is also:

• A product problem
• An operational problem
• A support problem

---

Compliance Is Not the Same as Value

This matters because businesses optimize around their incentives.

When the primary incentive is compliance, an organization has every reason to identify the minimum implementation that reliably meets the requirement.

That’s normal business behavior.

The team asks:

• What do we have to support?
• What’s the deadline?
• What’s the cost?
• What is the least disruptive way to add this to what we already have?

The resulting system may work perfectly well.

But compare that with a situation where the business has evidence that accepting a digital credential will:

• Shorten onboarding
• Reduce fraud
• Eliminate manual review
• Reduce data retention
• Improve conversion

Now the wallet project isn’t just a compliance requirement.

It’s a product improvement.

And organizations tend to treat product improvements very differently.

They measure them.

They optimize them.

They compete on them.

---

We Need a Better Verifier Story

That’s what I mean when I say we need to find a carrot.

We need a better verifier story.

The digital credential ecosystem is becoming reasonably good at explaining why issuers should issue credentials.

We’re also getting much better at explaining why individuals might want credentials and wallets.

But I think the verifier story is still less developed.

Digital credentials are coming.

That, by itself, is not a business case.

A regulator may require an organization to accept them. That’s certainly an incentive.

But it isn’t customer demand.

The stronger story is much more specific:

• If you accept this credential, you can stop collecting this document.
• This manual review step disappears.
• This transaction becomes possible.
• You no longer need to retain as much personal information.
• This onboarding process becomes faster.
• This experience converts more customers.

Those are the things that make a verifier actually want the technology.

---

Regulation Cannot Mandate a Good Experience

Digital wallets and verifiable credentials can absolutely be mandated into existence.

But regulation cannot mandate a good experience.

It also cannot make an organization enthusiastic about investing in one.

So if we want digital credentials and their wallets to become more than another compliance checkbox in an identity flow, the verifier needs to get something meaningful in return.

That brings me back to the question I think we should be asking.

---

What Old Process Goes Away?

When the credential arrives, what old process goes away?

If we can’t answer that, I don’t think we’ve found the carrot yet.

Something to think about.

We’ll talk about it more next week.