Riley Hughes: Accepting One Digital ID Is Harder Than It Looks

Our CEO, Riley Hughes, recently joined Filip Verley on Liminal's Friday Five, a five-question format for people building in identity. One question asked what trade-off buyers in our category still underestimate. Riley's answer was not adoption, or privacy, or standards. It was integration.

That deserves more room than a rapid-fire answer allows.

One wallet is four decisions

Consider what sounds like the simplest possible version of accepting a digital ID: taking a mobile driver's license from Apple Wallet.

Requesting that credential from an iOS app is a different integration than requesting it from a web browser. There is an approval process from Apple before you can do either. And you apply through two separate portals, depending on which surface you are building for.

None of this is unreasonable. Apple is managing a credential with real legal weight, and the review exists for good reasons. But it is work, it lands on your engineering team, and it produces exactly one wallet on one platform in one country.

Then multiply it

21 US states plus Puerto Rico now issue a standards-based mobile driver's license. Those credentials live across Apple Wallet, Google Wallet, Samsung Wallet, and roughly a dozen state-operated apps. Coverage differs by state. Platform support differs by state. Which presentation methods a given implementation supports differs, too.

No single wallet covers the United States. And the United States is one country running one type of digital ID.

Widen the frame to EUDI wallets across the EU, bank IDs in the Nordics, national ID schemes across Asia and Latin America, and the number of distinct integrations required to say "we accept digital IDs" stops being a number anyone wants on a roadmap.

Why the browser layer matters, and why it is not enough

Some of this is genuinely improving. The digital credentials api now shipping in browsers gives sites a standard way to request a credential from a wallet without building against each one separately. It is a real step, and it removes a category of work that used to be unavoidable.

It also does not solve coverage, trust frameworks, assurance mapping, or the commercial relationships behind each scheme. A standard request mechanism still leaves you deciding which issuers you accept, what assurance level each meets, and what happens to the vast majority of your users who do not yet hold a digital ID.

That gap between "technically possible to request" and "operationally ready to accept" is the part buyers discover after signing, which is precisely what Riley was pointing at.

The questions worth asking

When any vendor tells you they support digital IDs, the claim is close to meaningless on its own. The useful questions are narrower. Which wallets? In which jurisdictions? From which surfaces, app or web? And what does the fallback path look like for everyone not yet carrying one?

A flow that works beautifully for an Apple Wallet user in Arizona and breaks for everyone else is not acceptance. It is a demo.

Absorbing those differences so businesses do not have to is the problem Trinsic exists to solve. But whether you solve it with us or without us, the integration work is the real cost, and it is worth pricing honestly before you commit to a launch date.