Designing the Future of Identity

Digital Identity is a nascent industry that looks a lot like a 3-sided marketplace: issuers create credentials, holders store and present them, and verifiers confirm they're legitimate.

The high-frequency user events are presentation (on the holder side) and verification (on the verifier side). Issuance happens far less often than presentations, so the higher priority in terms of user experience is with the holder and the verifier. I've focused most of my design energy there.

Several things dictate the UX, but the biggest factors are the protocols and credential data formats. They define how credentials can be shared. From the holder's perspective, that could mean showing a QR code to a scanner, scanning a provided QR code, sharing a public link, or using NFC. NFC is the holy grail right now because it's fast, familiar from contactless payments, and takes very few taps.

One of the issues we saw in practice in California was the “Flash Pass,” where a person shows the raw text on their screen instead of going through the digitally verifiable presentation flow. This can happen through lack of education or it could be intentional. Either way, I took the lesson and designed credential detail views that don't surface raw data as the default state.

The California mDL program has been my longest-running project at Spruce. Over the last 2.5 years, I've designed for the CA DMV Wallet, helping grow the program from 600,000 mDL holders to over 3 million. I designed solutions for expanding their credential collection beyond the driver's license and for building out in-app verifier capabilities, working directly with the California DMV and our engineering team.

Identity wallets are intended to be interoperable. Our open-source wallet components, SpruceKit, are built to work with all credential formats agreed on by standards bodies, along with generic credentials. Within my first year at Spruce, I built out an aspirational app map depicting every flow a user might go through, with the convenience I wanted and the security measures required by the protocols. That map became the reference point for product and engineering when scoping new features, and it surfaced gaps in onboarding and recovery flows we hadn't accounted for.

Our concept of an identity wallet and its interfaces have evolved over the last couple of years as protocols and standards get updated, new security measures come into play, and we learn about different use cases outside the mobile driver's license.

Beyond the CA DMV, I've worked on credentials for education and workforce, trade certificates, and lower-assurance credentials like employee and student IDs. These all, in my opinion, warrant different experiences.

Most people encountering digital credentials have never seen or heard of them before. This is a new experience that they have to learn how to use and how to trust, and design can help in a few different ways.

To start off, visually representing a credential in a way that is familiar and reminiscent of the physical world can help people understand what a credential is and how it works. For example, the "Learner and Earner" industry is one of the driving forces behind the development of digital credentials, and it's a great example of a credential that is not traditionally associated with a physical card or document. Some trade skills might come with a card, like a first aid or CPR certification. But they aren't visually recognizable. Something that has to do with someone's educations and skills might look like a resumé or a CV.

So a wallet built to house “learner and earner” credentials for people who want to legitimize skills and lessons not captured in higher education might look more like closer to LinkedIn than it would to Apple Wallet. People can collect skills and experiences to then digitally prove they know what they know. The form factor of the wallet can help contextualize the new experience into something familiar.

On the other hand, a wallet built around the mobile driver's license or passport, what we call "high-assurance" credentials, already has a visually recognizable form factor in the real world. And digital credit cards have been around for a long enough time that people can connect the dots on how the digital license or passport works. Additionally, based on the wallets I've worked on with state agencies, these wallets tend to carry lower numbers of credentials. A learner and earner wallet might have 20-40+ credentials, while a high-assurance wallet might have 2-10. This allows for an experience closer to Apple Wallet, where you see cards in a list and can very quickly engage with one of them.

Beyond visual representation is understanding the flows and restrictions. Again, these are largely dictated by data formats and protocols.

Users need to understand when and why NFC might be available for one credential in their wallet but not another. For public link sharing, they need to know the sensitivity of that link. New users need help navigating multi-step flows they've never encountered. I approach this through three lenses: designing familiar interfaces, reducing technical jargon, and replacing protocol language with plain terms.

I reference digital finance often in my identity work because it's a similar industry that's more mature. The patterns people already trust in banking apps give me a starting point when designing for an experience nobody has had before.

E-commerce checkout flows are transaction patterns most people know by now. They help me show where a user is in a flow, what they might expect next, and when they've accomplished their goal.

Plain language across the consumer-facing app is a high priority for me. Three areas where I've made targeted changes:

• Replacing raw data labels like “Id” with “Wallet ID” or “Issuer ID.” These can be detected by the data value. If it's did:key, it's a wallet ID. If it's did:web, it's an issuer ID. Small label changes that remove a real barrier to comprehension.
• Truncating long, non-human-readable data values like a wallet ID into strings that resemble hidden credit card info or abbreviated crypto wallet addresses. Users don't need to see 64-character hashes. They need to confirm it's theirs.
• Avoiding terms like “credential,” “presentation,” and “engagement” in the UI. These are protocol terms, not user terms. I replace them with plain language that matches what the person is actually doing.

The next major milestone in digital identity is web-based wallets. Most of my work so far has centered on device-bound credentials, but I'm now contributing to designs for secure online sharing. The goal is to let a student applying for financial aid or a person applying for a loan share verified documents through the browser instead of tracking down a birth certificate and holding it up to a webcam. The interaction patterns I've built for mobile are the foundation for this work, and the familiar-interface and plain-language principles carry over directly.