Have you been following the latest efforts within the W3C about digital identity wallets? There is a reason the W3C is increasingly involved in the digital identity credential and wallet space. Here’s why: whether you like it or not, browsers have a role to play in the digital wallet space. People use the web for everything, from online shopping to remote access to government services. Much of the time, they use the web via a web browser. Things start to get interesting, however, when digital credentials enter into the equation. The eIDAS 2.0 regulation in Europe requires that EU citizens and residents are offered digital credentials. Those credentials must be usable in a wealth of digital use cases that cross international borders.
Similarly, in the US, more and more states are offering digital credentials and associated wallets. In all cases, governments require that the credentials they issue be usable independently of any particular platform. In most architectures, the digital credentials are stored in a digital wallet. There is an open question as to how web browsers behave in a wallet world. Are they themselves a digital wallet, or do they act as an interface to help individuals select their wallets? As browser vendors (and the rest of the world) work to answer that question, they need to determine how to manage wallets (either a third party’s or their own) predictably, safely, and consistently. That’s where standards development comes in.
Web and Identity Wallets
In the W3C, where browser vendors and organizations interested in web standards do their thing, standardization generally starts with a less formal, quickly iterative process of incubation within a community group. If the ideas developed in a community group seem viable, they will move into a working group (either an existing one or a new one created for the purpose) to further mature into a standard. What this post is talking about is a new incubation effort within the Web Incubator Community Group (WICG) called the Identity Credential project.
The WICG Identity Credential project is building on an existing API called the Credential Management API. According to the proposed project charter, the Credential Management API is “designed to delegate the user experience to the browser, such as presenting digital wallet(s) from which users can select a requested credential. The specification is designed to be extensible, with comprehensive integration points. Each of these points has customizable security properties, like requiring a user gesture or being callable only from a top-level browsing context, to name a few.”
Keeping Data Private
The trick is to expand upon this work to enable the browser to present the individual’s claims (aka, the statement that a particular person/entity has a particular property). That includes digital credentials and wallets. This is a good thing for both privacy and security; the less the browser knows, the happier everyone is. But it does make things a bit more complicated. If you’ve read anything about digital wallets, you probably have seen words like “issuer,” “verifier,” and “holder.” Those are good words to know, but the work in the Identity Credential project is about what happens on your device.
Deep in Your Device
When someone kicks off a transaction within their web browser that requires a digital credential held within an identity wallet, that requires information sharing between:
- the web browser, also known as the user agent
- the native or web-based application, which is a distinct application or service acting as the digital wallet
- the underlying platform, often the operating system though there are other models possible
These three parts may come from entirely different vendors, and no part fully trusts any other part. In order for them to communicate, they need to have some rules as to what to say and how to say it. That’s what these APIs do: they set the rules for how different components communicate, making it clear what type of information can be requested (and what can’t).
The web platform API’s job is to provide the line of communication between a verifier website and a browser. The browser is then responsible for getting the request into the platform via platform-specific APIs. And finally, the underlying platform is responsible for getting the request to the appropriate identity wallet (also via platform-specific APIs). Lots of hoops to jump through, but that’s how security often works.
Wrap Up
All of this is purely to make sure the different entities know how to talk to the wallet and request only the information required. The information within the wallet itself – the credential in whatever format it takes – is actually a separate thing. The format of the credential simply doesn’t matter for the sake of this specification, just like the postal service does not need to read your physical letters (or bills!) to deliver them.
There are so many questions that still need to be answered. Is this design the right one? Will it provide the privacy and security required by people (and legislation) around the world? Do browsers need to worry at all about the credential format within the identity wallet? How many formats do there need to be, anyway? You are always welcome to help find the answers to those questions by getting involved in the standards process. We would love to have you!
Thank you for reading my post! Please leave a comment if you found it useful. If you’re interested in starting your own blog or improving your writing, check out The Writer’s Comfort Zone.
If you’d like to have me on a podcast or webinar, my media kit is available for your reference.
