Biometrics and Verifiable Credentials: Balancing Security and Privacy [Intermediate]

Excellent. Thank you. Thanks for attending the talk. It's a little bit of a change of pace, as was mentioned, from artificial intelligence, because we're going to talk about how to securely identify the humans that we're doing business with. And to do that, we'll be balancing security and privacy. As mentioned, I'm Richard Esplin. I'm Head of Product at DocLabs. I'm responsible for the Truvera Platform for Decentralized Identity. And at this conference, I'm happy to be listed as a member of the Decentralized Identity Foundation.

I've learned a lot at the Decentralized Identity Foundation's working groups that have improved our product strategy, and I encourage you to look into what DIF can do for your organization. As identity practitioners, we help our organizations to solve some important identity challenges. And the biggest one is trying to get our information out of a trusted system of record, whether it's because of acquisitions or different business goals or rogue teams that set up their own identity server. Many identity architects have gone crazy trying to get everything into a single platform.

And what makes it even more complicated is that we often have to share that information across organizational boundaries. Whether we're providing services for our employees or we're contracting our employees to other customers or we're helping a customer to complete their journey with us through one of our business partners, we end up having to move identity information from our internal system to another organization's internal system. And the result is we end up building difficult, complicated integrations that are hard to maintain.

And this is an environment where the bad guys are well-funded, often nation-states. They have the latest tools, and they get AI tools in order to figure out how to break our systems. The identity information we're trying to collect is very sensitive. It's frequently regulated, and the biometric piece of information is often under very strict regulation. And because we're tracking identity information, we're tracking information about people, and people are complicated.

We as consumers, as people, as citizens, we want to do business with organizations, and it requires them to have our information, and we want them to trust us. But they have no reason to trust us. They want to get our information from a data provider that they already trust. And we don't like that. We want to know our information is being used for our benefit, not against our goals. And nobody likes to be gossiped about. We want to know what's going on. We also have incentives to covertly allow other people to use our identity information.

How many of us have found our lives get easier when we let a co-worker do something on our behalf, or a family member pretend to be us to get something done? And in an era of artificial intelligence agents, it can be hard to identify whether we're talking to the person we think we're talking to, or whether we're talking to an artificial intelligence tool that's acting on their behalf. And when we're doing business with people, we're using our devices to share that information, and those devices aren't terribly trustworthy either. How many of us have reused a password?

How many of us have left a cell phone unlocked or gone to the break room while our computer's unlocked or shared a device with a child or a family member or a co-worker? And so when we try to do business with people, those organizations, the other party, can be sensitive, can be concerned about where that information's coming from. Fundamentally, we can summarize this problem by looking at two organizations, and both of them have a Janet Doe in their system of record. How do we know it's the same Janet Doe?

And how do we know that this Janet Doe is the person who's in front of us at the shop or using our website? It can be hard to do that matching.

Now, verifiable credentials is an important tool to help with this. Because we give the information to the user, to the citizen, to the identity subject or identity holder, we take it with them as they do their business. And as they do that and they share that information, they've chosen to share it. It's got consent. But because it's a credential, it came from an issuer. So we retain our trust relationships. We're still getting the information signed by the issuer we trust, but we understand that it's tamper-proof.

We can detect if that user's done anything funny or somebody on their device has done something funny. Because verifiable credentials are a standard, when we use verifiable credentials to transfer information, we get very flexible integration. So it changes our identity architecture. We can easily add or remove attributes that we're asking for. We can easily change issuers. We can change use cases without changing our architecture. And because the user's carrying the data around, fewer systems have to get access to our internal data store.

And that all makes it easier for us to secure those honeypots of data from people who want to get in. Biometrics are another important tool. That's what allows us to know the person we're talking to that's giving us information is, in fact, the person that received the information. And it's not somebody else using their device or using a stolen device. But when we do this, we want to make sure the biometric template remains under the user's control. So verifiable credentials are going to help with that.

We need to figure out how to restrict that biometric information so it's not spread everywhere as we do business. So verifiable credentials plus biometrics is the solution to these identity problems we talked about, or a solution. But when we do this, we have two important goals. The first is that strong guarantee. I want to know that only the person that received the information that was issued the credential can be trusted to share that credential. And I want to know that only the biometric provider can access the biometric information, that it doesn't have to get spread everywhere.

When we're building biometric solutions, the first question we have to ask is, where is the biometric data going to be stored? Traditional biometric vendors stick it in a centralized database. They collect that information from everybody and put it in their big old honeypot. And that can be hard to secure. It can also be hard to trust. And it's very regulated. More modern, innovative biometric providers, they take that biometric enrollment template, the biometric information, and they split it up and put it into a network of computers.

And that biometric information can only be reconstructed in the presence of a valid sample. That's great. It's also fairly complicated. But if we take the biometric information and put it into a credential and stick it on the holder's device, it's signed by the same organization as the issuer. We can read it back off and have the same confidence as if it came out of our database, which can be a much easier approach to modernizing a biometric solution. The other questions we need to ask when we're dealing with biometrics is, what sensors do we use to collect that information?

Can we trust those sensors? And what's the environment where we're going to compare a biometric template against a sample? And so this chart can be a little complicated, but I think you're going to find it's insightful as we go through it. On the left axis, we look at what sensors we use to collect the biometric. And across the top, we're looking at what environment do we do a comparison in. Some of our customers have said to me, I want to only use the device that's at my organization, at the issuer verifier location.

And that's nice because you can post a guard, you can put up cameras, you can secure it in a box, you can make sure it's not been tampered with, you can make sure you maintain it. The downside is that the users who come to that location have to trust that every place they talk to is going to use that biometric information appropriately, going to discard it when they're done, that those devices are well-maintained. The other challenge that I don't think is well-appreciated is that it's not very flexible.

When you want to change biometric providers, when you want to change hardware, you've got to change it at all different sites. Now, there are standards to try and make it so you can move biometric information between systems and vendors, but they're not very mature and they're kind of complicated. You end up locked in with a certain ecosystem or a certain vendor. If we use the sensors in the user's device, that's great for the user. They already trust their device. They've already put their identity information there, so they don't have to extend their trust boundary to manage biometrics.

And it provides a lot of flexibility to the organizations that are deploying the solution. You can have multiple biometric providers in a single wallet. You can have multiple biometrics providers in an ecosystem. And you can pick which one you're going to use based on use case. You can deprecate an old one and roll out a new one, and it becomes very flexible over the life cycle.

However, you do have to recognize that you're trusting the sensors on the user's device, and that does have its risks depending on your risk profile. Now, across the top column, we look at where we do the comparison. If we do it on the user's device, that's great because the data never has to go anywhere else, but it does mean you have to trust the device. If we do it in a cloud, that's great because, you know, it's a secure environment where we're going to do the computation. That reduces some threat actors.

But it does mean the information's left the user's device for processing, not necessarily for storage. So the first box, if we're using the sensor, the issue, or verifier, and we're doing on-device comparison, that doesn't really work in the real world. I have had a customer do it, but it means that the issue and the verifier have to be the same organization because anywhere else you go, you're not going to have access to your biometrics. If we do it in the cloud, that's great.

You can build a solution that works that way, but it does mean that biometric data is starting to get scattered around. Now, if we're looking at the wallet sensors, if we're going to use the wallet sensors, that's great. We're using the user's device. We can make a guarantee the biometric data never leaves the device. We have a partner who does this.

Their system checks the device and tries to figure out if it's been tampered with, rejects the biometric if it looks funny or if the system doesn't look secure, and then it does a secure computation to do that matching on the device, and they can guarantee that biometric data stays on the device. Our other partners, they like to pull that information into the cloud and be able to do a secure comparison in the cloud. And optionally, you can still store that information on the device and just process in the cloud.

Some of our partners also, they store an identifier on the device that points to the enrollment template in the cloud. We do have customers who have done all of these approaches, as I mentioned. I've worked with deployments that take all these, but I favor, we favor the sensor in the wallet. We favor keeping that biometric solution under the holder's control if it's well with the rest of the decentralized verifiable credential solution we're trying to put together. So our approach is to do the user store biometrics.

So the first step, when the user first installs their wallet or when they first need a biometric proof, it's going to see they're not enrolled. It's going to enroll a biometric into the device, whether it's from a facial scan, a palm scan, a fingerprint reader, all sorts of different ways. One partner we worked with does a little signature thing. And then they're going to issue, the biometric service issues a credential into the wallet that's signed by the biometric service that contains that enrollment data. And then when we need to do a challenge, we do that local biometric check.

The wallet detects somebody's asking for a biometric challenge, and it launches the biometric integration. It takes the sample, and then it reads that credential, checks that it hasn't been tampered with, checks the signature, and does the comparison, and then issues a credential that says you've passed the check. That credential can be verified by an issuer or verifier like any other credential. Any relying party can see that credential seeing a check has been passed.

Now, this is a screenshot from our live mobile app, the Truvera Wallet. It has a lot of stuff that might not matter for this talk, but I want to emphasize this isn't theoretical. We do this in the field today. As I mentioned, there's three credentials we're using. The bottom credential is that enrollment credential. The middle credential is the check credential. And the top credential is the credential that we're biometrically binding, the credential of interest that we're trying to get business done. In this case, it's a bank identity from a made-up bank we use.

Looking at the enrollment credential first, the screenshot on the left is the top half of the credential. We'll go from the bottom. That biometric is signed by the biometric issuer. Then the next, in the middle, we see the biometric data. This is the actual data encoded the way the biometric issuer needs it. Then in the middle, the top label is the biometric ID. This is just a random string. It doesn't have to be derived from the biometric. We don't want it derived from the biometric. But this is what we use to show people that we passed the check. It is correlatable.

When you're moving your identity data, you're going to share the string to show that we passed the check. But there are methods using zero-knowledge proofs or multiple enrollment credentials where we can minimize that correlation. Then on the right-hand side screenshot is the bottom half of the credential. We see that it's signed by our made-up biometric issuer, and it's part of a trusted ecosystem where we can control who accesses those credentials. The second credential, then, is that biometric check credential. At the top, we see the validity.

We can set it to time out after a minute, after five minutes, depending on your trust profile. Then we see that biometric ID. It's a very simple credential. It just has the biometric ID because we don't want the biometric data getting spread around. Then we see it's signed by that same biometric issuer, and it's part of that same trusted ecosystem. Then the credential of interest, the biometric-bound credential, is the bank identity credential. On the left is all our made-up bank ID information. This bottom half of the credential on the right, we see the two nested biometric attributes.

The issuer asks for a sample, asks for a biometric check. They look at that ID, and they put that into the biometric-bound credential. They put in the biometric-bound credential the DID of the issuer so they know if this issuer says this ID got checked, then I can trust it. Now any verifier is going to see the credential and say, I don't want to trust this if you can't also give me a biometric check credential that has the same ID from the same issuer. We see it's from the same trust ecosystem. This credential goes issued by the bank, not by the biometric provider.

So when we present the credential, we present the bank credential, and we do a compound proof, and say here's our biometric check credential, and it's got the same ID they match, and the issuer matches, and so we know this holder recently passed a biometric check with us as a verifier, the same as they did at the time of issuance. In summary, we've shown that we can securely move data between data silos using verifiable credentials, get user consent, while providing strong guarantees to the relying party that they can trust the holder because it's the person that received the credential.

We've shown how this is a more flexible integration, and we can do this with strict control over the user's biometrics so they never leave the device. Now if we had more time, we'd talk about how we can handle multi-factor authentication, multi-modal biometrics. We'd talk about how we can reduce correlation of the biometric checks. We'd talk about how we can pin these credentials in an ecosystem of trust. We could talk about how we manage payment models with a biometric service. If you're interested in these topics, I'd love to explain more.

And so here's my contact information, and we've got a couple of minutes for questions. Sure do.

Thanks, Richard. Any questions? Thank you. Thank you.