Decentralized Identity Fundamentals: A Technical Overview

[00:00:00]Hello everyone. Uh my name is Agna Count, a product owner here at Doc Labs.

[00:00:06]I'd like to welcome you all to our uh live event. Today's topic is introduction to decentralized identity.

[00:00:13]And it's just going to be me and our head of product, Richard Esplain. And I will let him introduce himself shortly.

[00:00:20]To our new listeners, our regulars have definitely heard from him before. And before we start, I would like to encourage everyone to say hi in the chat and let us know where they're listening from. It makes us feel more responsible to stick to the topic knowing that there is an actual live audience listening. We will send out uh the recording after the event. So do not feel obliged to take notes or even listen very closely. Do however feel free to ask questions throughout the session. We'll have time for Q&A at the end and I think I might even pick some questions as we go along.

[00:00:58]This uh session is meant to educate our listeners about the decentralized identity and it's an abbreviated version of our first training session that we offer to our customers. So normally we like to make it as interactive as we can. So we'll see what we can do uh in this webinar as well. So with this short introduction, I will now pass it to Richard to take it from here.

[00:01:23]>> Excellent. Thank you. You hear me? Okay.

[00:01:26]>> Yes.

[00:01:26]>> Excellent. So, as Agy said, I'm Richard Esplan. I'm based in Western US. Uh see Agy's got beautiful Greece sky in Hershey Windows. So that's fantastic.

[00:01:37]And uh we've enjoyed working together for three years at two over two years at Doc. I've done decentralized identity for eight years now and we put together a training plan that we give to our customers where we try to go through everything needed to be experts in and deliver a a a decentralized identity project successfully. Now this session we're going to tackle the first one of these and uh usually we would be already know the customer. We'd go into great detail. We'd adapt it to their needs. So here we're going to do an abbreviated version uh set for that web format. But uh I appreciate Agy will be able to cut in when I go too fast to be able to slow us down and make sure we cover things adequately and also uh handling the questions. I really appreciate that. So today we're going to talk about a little background on decentralized identity in a in a holistic way. Then we're going to talk about a specific concept called the trust triangle that comes from the W3C standard for verifiable credentials. And then we'll talk about the actual technologies used to build this. And uh when we do this live, we we do a demo and we do a we give you a homework assignment uh when we do this in person.

[00:02:45]But uh for this for this process, we'll we'll spend that time doing Q&A. So let's talk about digital identity models.

[00:02:53]When we started with network systems in the 80s and 90s, we followed a centralized identity model and we said look everybody uh the access to this computer has to have a username and password and that was great. It allowed us protect our system and as long as you only had one system that was fine but when you start dealing with dozens and hundreds of systems it becomes a huge pain. uh usernames, passwords of course can be easily hacked these days and even when you use more uh secure mechanisms to log in having a different account for every system requires the user to keep a a password manager a database of of pass keys and it just gets really complicated and you can't take that that identity from one place to another. uh every system has to be managed independently and administered independently which doesn't scale very well and those these systems become targets.

[00:03:47]Everybody wants to break in and and get what they can out of these individual systems.

[00:03:52]So we realized in the late 90s that we could federate that we could have an identity provider who shares identity with relaying parties and each of those websites that rely on the identity that comes from the identity provider gets the same identity information. So when the user needs to update something they update in one place and all the websites benefit and this becomes much easier for for the user uh but it becomes much easier for the administrator to maintain that identity provider instead of maintaining a 100 different servers.

[00:04:24]However, it's still fairly complicated for the administrator because you've got to build this integration with every single relying party. And these integrations get fairly complicated.

[00:04:34]They they can be fragile. Uh you have to do firewall connections. uh manage uh ma decide on common standards keep every keep SSL certificates updated across all these sites and this federated system is now an even bigger target because it's got everybody's data for all the different websites and so hackers find that to be very juicy and we we hear about a new hack it seems like every day of somebody breaking in and stealing from one of these federated systems.

[00:05:02]Interesting little digression. uh we've seen in the news three times in the past month I believe at least twice where people have broken into an IDP and gotten all the authentication tokens for all the relying parties and been able to get into Salesforce accounts for instance so it it definitely it's not theoretical it's it's a real risk what we found over the last 10 years is there is a better way instead of having one big identity provider that serves all these different websites you can have lots of different databases one database for every user, but we store that database on the user's device uh in their identity wallet. It can be in the cloud, it can be on their phone, but the user, the the person who wants to access the website, they're going to carry their data with them to these different sites. Now, you still need to trust that data. So, that data has to be signed by a trusted issuer, by an identity provider, using the old term. And each of these relying parties become verifiers of that signature to make sure the data is trusted. And so the holder, the user we see at the bottom here, they go to the to the identity database and say, "I am who I am. Please tell everybody." And they get a credential into their wallet and then they they go to the website and say, "Please get the credential out of my wallet." And this is great because uh it it's more flexible. It the wallet is automatically untrusted outside of the firewall. So when you integrate with the wallet you it the protocol builds in the need to to access external but when the data comes in we authenticate it at that time and so you still have the same trustworthiness of the data. There's no honeypot to steal all the data from. Uh you have to hack thousands or millions of individual uh wallets to to get significant data and you get that portability once you're moving data through in this method. you can put any data in that credential you want and so you can adapt to new uh use cases in a much easier way than trying to change a centralized identity provider and then get all the integrations to use the new the new schema. So this is the decentralized identity model that that makes it easy to pull the data directly from the users. So it solves by by looking at the problem differently by saying how do we get the data from the user who's connecting these different services then the architecture becomes fundamentally easier to manage. When we develop a centralized identity systems there are a lot of different ways to do this but there's really a few key principles that each system needs to honor uh to be able to provide the benefits that are expected. The first is by putting the user in control of that data. You get user consent, you get better privacy, but you also get confidence that the data applies to that user. Uh in traditional identity systems, you you get their name, you get their email address, you get their phone number, and you get 99% confidence that you that this data applies to the same person. And with some names like Richard Ewin, it's pretty high because there's not a lot of Richard Ewins in the world.

[00:08:03]But with my friend Dave Smith, there are a lot of Dave Smiths. And so trying to find this is the Dave Smith that we're trying to talk to. This is who the data is about. That gets very complicated.

[00:08:13]Whereas if Dave hands over his data, then you know this data came from Dave, but you also know it still comes from a trusted issuer. And and then that verifiable capability that that the data comes from the user, but it's got a signature that says here's where the data comes from. And so you're still trusting the same identity provider, but but that you're trusting it because of that cryptographic signature even though it comes from the holder.

[00:08:38]And being able to build privacy by design. That's part of GDPR in Europe is the idea that that you're the technology should be built privacy focused, privacy first. And this this architecture supports that natively. The holder can decide what they disclose. They decide who they're going to disclose it to. And then that portability. If we use standards that come from organizations like the W3C, the worldwide web consortium, uh, as well as the IETF, the Internet Engineering Task Force, then you can have confidence that these same credentials can be used in new use cases or by new relying parties as as needed and as permissioned. And then that security, we want to make sure that having the data decentralized in storage means that there's fewer honeypotss, but also make sure that that you have proper security around each wallet, the way the user authenticates, whether it's a biometric or or any other method you pick. Uh, and as well as having security in in which issuers and verifiers you trust, uh, what's the level of assurance, these ecosystem governance things we we can talk about more. So we have this key paradigm shift from that organization centric view of the world that I as an internet as an I am identity access management professional maintain the system that everybody's going to integrate with uh to instead having a user centric view where I'm going to build a system that all of my users interact with so that their information can be used by the relying parties by the partners that we want them to to verify that information. So we move from the organization holding the data and and having to have separate accounts for each of these data stores to the user holding the data and being able to share the data that applies to them. And we move from having to integrate lots of different websites with a single centralized registry and manage all those firewall rules to every website integrating with wallets. And because you're using standards, you can swap out the wallet you talk to. You can you can add new wallets. You can you can add new schemas, new credential types easily. And we move from the organization saying these are the organizations you can talk to a user to the user saying oh here's where I'm doing business and the information I want to share. Now we at True Vera we have we've extended the standards a bit to give you more control over which verifiers can access which data uh because we find that's important for a lot of use cases. But the standards this paradigm shift is that the users deciding who they're going to share their information with. And I would like to add here to what Richard um just explained about this shift that user centric does not mean that it has to be a burden on the user like user has the right but to get adoption for this type of process like it has to be as seamless and as easy to use as the federated or the centralized model and it can be technology allows that. It just it means that the user has a lot of rights but it doesn't have to have um a lot of complexity or a lot of um decisions to make necessarily.

[00:11:34]>> Exactly. Exactly. And what I found is I've been deploying these for you know nearly a decade is that once you've made that architectural shift to putting the wallet at the center of the identity ecosystem lots of other problems get easier. It's easier to say look it's a zero trust architecture because all the data comes signed and look we already know how to talk to the wallet so we don't have to manage all the firewall rules and you know all these things uh simplify quite a bit now I don't think the organizationcentric view is going anywhere uh when you're in your or in your business it's a closed environment you have one IDP like that that's the right solution for that use case but there are a lot of use cases that we've struggled to meet that the user centric approach is makes it much easier So let's talk about the trust triangle.

[00:12:22]So the the trust triangle the worldwide web consortium the W3C has a standard called the verifiable credential standard. And in that standard they define the trust triangle and it's a very nice uh view uh simplified way to look at the solutions. There's a holder, a person. They want to do business with somebody. And that business, they want to check the identity. They want to verify it, but they have no reason to trust the person. They who's this person? They just walked in. We don't trust them. Uh but they do trust some a third party. And that third party can act as an issuer. So we need to move trust from the issuer to the holder. So the verifier uh builds a relationship with an issuer and then the issuer can identity proof the human and say okay here's a credential and we've signed it with our public key uh sorry we've signed it with our private key and then when the holder goes to the verifier the holder can say uh here's the presentation of the credentials that show that you can trust me and the verifier can look at that and look up the issuer's public key off of a data registry and so the issuer publishes their public key to the data registry and that is what allows the verifier to trust the holder because the credentials signed with the with the same key. So that's the trust triangle.

[00:13:47]Uh so the the key parties are the issuer, the holder, the verifier. Uh the key technologies are the credential that the issuer gives the holder and the holder gives to the credent to the verifier as a presentation and the data registry the verifiable data registry where we can find the keys needed to validate the signature on the credential.

[00:14:07]So this just summarizes that. So after the after the the meeting we can send out the slides for people. Uh so our platform so this isn't a sales pitch but it's a good example of how it works. uh we have APIs for issuing, we have APIs for verifying, we have a wallet for storing, uh it can be on a mobile uh embedded in a mobile app as an SDK or it can be done in the cloud. And then that that challenge of how do you get the verifier to trust the issuer? That piece of governance, we call that an ecosystem. And uh the technology that that's in the standard is called a a trust registry. So the trust registry contains the list of all the issuers and what they're trusted to do and the list of all the verifiers and what they're trusted to verify. Uh I should say the list of all the issuers and what they're trusted to issue and the level of assurance all that kind of thing. And then uh we as I mentioned also have the capability to tie a credential to that ecosystem. So then you can charge ecosystem members uh the verifiers for their usage of credentials. And we do that in a privacy preserving way for the holder. So, so we also have that monetization capability and you'll find other verifiable credential products.

[00:15:14]They have these same the same uh goals.

[00:15:18]How do we issue? How do we store? How do we verify? Uh how do we connect into a trust registry or an ecosystem? And then and then how do we make sure that that the issuers and verifiers have a business model that makes it worthwhile to put together the solution. Richard, if I uh may stop you for a bit. I saw a few really good uh questions in the chat about the trust triangle and I think it's a good time to to answer those. So maybe we can even go back a few slides just to have it uh visible again. Thank you. So um Don is asking what's the difference between a verifier and a relying party?

[00:15:53]>> That's an excellent question and really the answer to that is the this uh paradigm shift. Uh you'll see I'm using both terms. I do that because traditional IM people they set up an identity provider that shares tokens authentication tokens with relying parties. Uh relying parties are verifying that information. So in the trust triangle uh when we move to this usercentric view the relying party becomes a verifier of the credential.

[00:16:21]Now part of the challenge is that in that IM view the identity provider verifies the user before they onboard them and but that's not verifying the credentials that's verifying the user's attributes in order to add them to the issuing system to the identity provider system. So uh I I'm trying to I apologize for the confusion of the terms because they're used differently by different groups of people depending on whether you're in that you're in that organization ccentric view or the user centric view. So the terminology we prefer to use at truvera is that the issuer identity proofs the holder. Uh so that's when the hold they check the holder's identity go through a document verification process. Uh and once they've uh validated the holder's attributes to the level of assurance required then they issue the credential and the relying party who wants to use that credential verifies that credential. Uh that's the way we try to use the terminology. Hopefully that made sense. We can write it down if if it's still confusing.

[00:17:22]>> And there's one more question about this. Um it's coming from Sushil. I hope I'm pronouncing this correctly. Who is maintaining the verifiable data registry?

[00:17:34]>> Yes. And the answer to that is it depends on the agreement between the issuer and the verifier. So at Truvera uh we support did key which means that the verifiable data registry is our website uh where we just post these and and people are using the API can look it up and we support did checked. checked as a blockchain where uh you can publish this information and then that blockchain has its own governance uh monetized uh you know supported financially by the the token of the blockchain uh where they manage these they make sure it's decentralized and that these keys survive any individual company or any individual issuer. So we support both of those. Uh we do see a lot of other approaches. Uh there's there's approaches that don't require a a blockchain of any sort called did web uh or did carry uh or did uh webks. Uh so all of these approaches we expect will support at different points of time depending on the the the needs of our customers. We also see in the European Union where they have the new European Union digital identity, they're using a traditional SSL certificate infrastructure uh X509 is the standard uh where that's managed by the government. And so that obviously uh can can work quite well in a lot of circumstances too. So the the short answer is it depends on what the issuers and verifiers prefer and our goal is to remain flexible for whatever those needs are.

[00:19:01]>> Thanks Richard. I think we can continue now.

[00:19:04]>> Excellent. So excellent questions. I appreciate that. Okay. One of the key things I've I've tried to emphasize is that anything can go in a verifiable credential. So true, you can hold identity data uh and be able to to confirm that against a back-end database, you know, that entity resolution step, but you can also contain risk insights. What's the geography that this person usually interacts with? Uh what are the signals that their phone might provide? Uh so we can compare that against the current usage. Uh what's your know your customer background? All the legal identity stuff. And we can tie credentials to a biometric. So we can we can prove that the person sharing the credential is the physical human who received it. So this is this makes credentials very flexible because once you're interacting with the protocols with the standards the actual information you pull out of a ver verifiable credential can can change based on your use case and can evolve over time based on business needs and that kind of flexibility. uh we we've had a number of customers say my number one goal with my IM architecture is making sure that we can be flexible as business needs change and verifiable credentials inherently improve that that flexibility >> and Richard if I can add quickly on the previous slide when we're thinking about identity credential we don't also necessarily need to think about human identity because we have uh use cases where organizations they have identity and they need to prove it uh to different relying parties or like a very hot topic now the AI agents they also um have identity and they need to prove it and they need to prove that they have the right to do so. So there's a lot of flexibility in what can go into an identity credential.

[00:20:51]>> That is exactly right. That is exactly right. So the fundamental change as we mentioned that paradigm shift from organization ccentric to user centric that does require some some work because you have to introduce the concept of an identity wallet. Uh but once you've done that once you've found an issuer who issues credentials that are trusted and a verifier who's willing to rely on that credential for the business process and go through the wallet to do that. Once you have this one use case, introducing an additional verifier gets much easier.

[00:21:24]And once you have a few verifiers, getting an additional issuer to produce a new credential gets much easier because you already have a market of verifiers who are willing to use it. And then introducing an entirely new use case is much easier. And so we we recognize you get this ecosystem network effect where it takes some work to set up that that first use case, but then you become the trusted ecosystem for more and more use cases. And so you get this this network effect of of becoming trusted becoming the incumbent party for solving all sorts of of business challenges. So a number of our customers they recognize the current process is working okay but they recognize that as EUDI is coming as mobile driver's license coming in North America is users are are more worried about privacy that they want to be the forefront of building these ecosystems because it creates a moat to their competitors uh so they don't get disrupted and so the basic view here is the issuer needs to onboard the human onboard the holder I I guess it could be an organization. It could be an AI agent, but somebody's going to do that onboarding and you're going to pull that data out of an existing government digital identity or taking a picture of a passport or a driver's license uh or a third party data source like like an older school centralized digital identity or an internal database. We can integrate with any of these. You pull that data out into the credentiing platform and and call the issuance command and that creates the credential. And at that point you can pick what credential format do I want to use? What privacy uh capabilities do I need? Do I need monetization? And then and then it gets issued into the holder's wallet and you need to decide on that holder experience. Is the wallet going to be embedded in an existing app? Is it going to be a standalone mobile wallet? Uh is it going to be a government wallet? Uh is it going to be a cloud wallet? We'll talk about wallets more in a moment. So let's dig into some of the technical building blocks for for making this solution work. As we mentioned the core of all of this is the verifiable credential and that is a W3C standard uh the verifiable credential data model.

[00:23:35]And you can see on the right sometimes people are like well what exactly is a credential? Well a credential is a text file. It's just JSON. It's like any other any other uh uh API uh artifact.

[00:23:47]It's a text file, but at the bottom we have a signature on the attributes and you can pick the kind of signature you want based on the capabilities that you need. Uh some signatures are very simple and therefore they're widely supported by other uh relying parties if you want interoperability. Uh some signature methods incorporate advanced cryptography like BBS signatures and zero knowledge proofs and selected disclosure. BBS signatures that give you zero knowledge proofs and selector disclosure. And so uh each of these credentials though they have a few key components. You have the issuer information. So we see at the top the context. So this is JSONLDD which is the the the current W3C standard. And then and then we have the type of credential it is. And then we have the issuer information and when it was issued. And then we have the attributes and and information the the information about the holder. Uh you know their their attributes and the the content of those attributes uh the claims I guess is the term we often use for the content. And uh and then you have the proof at the bottom. So depending on the type of cryptography you use determines what this proof section is going to contain.

[00:25:03]and what privacy capabilities it supports. So these verifiable credentials, the schema is the blueprint for a credential. So it says these are the attributes and this one's a date format and this one's a date time and this one's a boolean. Yes, no. Uh this one's a text file, this one's an integer. That that's the kind of sche that's what a schema lays out. And again, it's just JSON. And then the claims is the information for each one of those. Uh the birthday is a date and the claim is, you know, January 1st of 2000. Uh the the uh income amount is an integer and the claim is $50,000 or whatever. Uh so those are those are schemas and claims. And then the proof is signing each of these with the issuer key. Normally you the depending on the format you pick that it'll determine whether you're signing each claim individually or whether you're signing the credential as a whole and if you sign a credential as a whole then you have to share the credential as a whole but if you sign each claim individually then you can share just pieces of a credential. We call that selective disclosure and depending on the kind of signature you use uh you could be able to share what we call a range proof.

[00:26:16]Instead of saying income's $50,000 a year, you can say income's over $20,000 a year and and having that range requires advanced cryptography, but our our SDK makes that very straightforward to do. Oh, sorry, I forgot. We have a whole slide on that. So, uh depending on how you sign the credential gives you access to these advanced features of selective disclosure and zero knowledge proofs. Now credentials can also be bound to either the wallet or to the human and we need to be careful when we bind a credential that the way we bind it doesn't become uh an attribute that can be tracked through an ecosystem. We want it to be a privacy preserving binding. Uh so uh we call that um the link secret or the binding secret if we do it to the wallet. uh but we can also embed uh a biometric attribute uh not necessarily the thumbrint itself but but something that can only be recreated in presence of the thumbrint and that allows us to check the holder. We'll talk about that more in a moment.

[00:27:17]Now the other key building block here is the decentralized identifier. So again this is a W3C standard. uh but the did is where we find the keys that are used to prove that the the entity we're interacting with. So as an issuer, you need to publish your did so that you can find that issuance key and be able to confirm that the public key matches the key that was used to sign the credential, the private key that was used to sign the credential. But these are also really useful for for private interactions. Uh, if I'm messaging Agy, Agny can share her DID out of her wallet and then I can send her a message and she knows it comes from my DID and anytime she gets a future message from the same DID, she knows it was me because it's the it has that key in my wallet and when she receives it, I know she's the only one that can decrypt it because I sent it to her DID and so you can have this private communication.

[00:28:13]Makes it much easier to manage the these these private communications. We call that DIDCOM DID communication. And that's a that's a evolving standard of the decentralized identity foundation.

[00:28:23]So DIDs have to be globally unique uh and resolvable. Uh but we also want to have flexibility in the details that goes into a DID. So at the beginning we say look it's a protocol called DID. Uh you know just like HTTP is a protocol or FTP is a protocol or SMTP is a protocol for email. Uh DID is a protocol. So if we see that we know oh we're we're going to look up a DID. Then the second is the did method. And so it might be checked for the blockchain or it might be uh did key for a private key that's not stored anywhere else or it might be did peer uh for a private conversation or it might be did web. Whichever did method is there's a specification published that we're going to use to resolve that did.

[00:29:09]So the next piece the last piece is that did specific identifier. So if we're on the check blockchain, then if we put in that string, checked will return the information we need. And that information comes back in a different uh format called a did doc. And that did do specifically says, okay, for this did, here's my key. And and so you can trust that key. And it might have other attributes, other DID linked resources in terms that check uses. that says here's where you find a revocation registry we use or here's uh here's the different controllers or the life cycle of this DID all that can be embedded into a DID doc and the key is uh the the key concept is that this is cryptographically verifiable uh the DID doc tells us the verification key so we can know uh how to decrypt things that are signed by this DID and that storage can be stored in any of a variety of formats so it can be decentralized So the did method then uh we talked about a few of them did check did key did web and we recognize that that you're going to pick that method based on your use case. Uh how who what interoperability features are important?

[00:30:21]What uh what's the cost of creating a DID? You know if you publish it somewhere then somebody has to be paid to host that and what are the privacy concerns uh and capabilities of that DID method. And then uh every did you can create a DID, you can resolve a DID, you can update a DID, you can deactivate a DID. So your normal CRUD capabilities here.

[00:30:40]>> Richard, if I can interrupt uh a little bit again with a few questions about dids this time. So Don is asking, is uh did more like a URL than HTTP?

[00:30:52]>> Well, a a universal resource locator is any way you look up a piece of information. So HTTP contains URLs. uh SMTP uh has an email address that allows you to look things up. So yeah, a DID is a a URI, a univers universal resource indicator, I think. I always forget what URI means. But anyway, URI URL is that kind of of concept. It's telling you where to look something up in order to get the the DID doc, the additional information about that did.

[00:31:21]>> Thank you.

[00:31:21]>> So the next big concept is the credential wallet.

[00:31:25]So again, we need to store this information somewhere. We need to make it easy for the the entity, the human, the AI agent, the organization to be able to use these credentials and keep them safe. And so that credential wallet has to store the DID of the of the individual. It doesn't have to be a public DID. It's a private DID in a lot of cases. Uh and it makes it easy to store and manage these credentials, be able to approve sharing credentials with relying parties. and you need some secure way to get into the wallet so that you can keep control of your own credentials. Today there are a lot of different identity wallets on the market. Uh when I started this this working in decentralized identity, most people had never heard of a wallet and nowadays most people use a wallet. Uh they they have the the keychain in Mac OS or the keychain on on on an iPhone uh the Google wallet uh or the Apple wallet uh on their phone. They have you can have event passes or government credentials in there. These native wallets are really convenient because they already exist. You already have one. You don't have to do anything and your operating system already knows how to access it. However, these big tech wallets, they're least common denominator. They only do one thing. You have to get their permission to change anything. You have to be approved to to access the information out of those wallets. So, as a business, a lot of our customers really struggle with the native wallets because, you know, it can it's like trying to publish an app to the app stores. You're all ready, it's ready to go, and now you have to go through five days of arguing with some faceless person who's checking before you get your business case live. And that kind of delay doesn't make a lot of sense in in in many circumstances.

[00:33:10]So, that that limited customization. We also find in many geographies that these native wallet OSS, they're they're controlled in the the United States and that creates a geopolitical risk. Now, I'm an American, but I recognize that a lot of people struggle with with saying we're going to put our use case in the hands of Google and or or Microsoft or Apple. And so, uh being able to have an independent wallet can be very helpful for those kind of use cases.

[00:33:41]Uh the other kind of wallet we see getting broad adoption are government sponsored wallets. Uh while governments have issued identity wallets now for quite a while uh almost a decade over a decade in some jurisdictions and specifically in Europe every European citizen uh should have access to a government sponsored identity wallet by the end of next year. And that's pretty exciting. Hundreds of millions of people will have an identity wallet. And this is going to be really important to interoperate with. So, oh, I should I should pause and say for those native mobile OS wallet uh credentials, uh our strategy is to make sure we can verify out these credentials. And there's a standard for that called the digital credentials API. It's a W3C standard that Apple and Google both support. And so, we want to make sure we can consume the credentials that are in a native mobile OS wallet. And when it makes sense, we can look at issuing in.

[00:34:33]But we recognize that a lot of times it doesn't make sense because of the restrictions on those wallets. So, we have a similar story about these government wallets. The fact that the government sponsors them uh gives citizens a lot of confidence that they're they're not that they're serving the interests of the community of the public rather than of of a specific company uh of a tech giant. Uh and that they'll probably be privacy privacy respecting. Uh it it's they'll be broadly supported in the jurisdiction of the government who mandates that they're used.

[00:35:04]However, the the user, the holder has to download know about this wallet and download it. Uh that's going to get easier over time, but it's a it's a hurdle today. And as with anything else the government does, uh it takes a while to evolve. And so if my business requires capabilities that aren't in the government wallet, I can lobby the government to change the wallet or I'm going to have to go with a third party approach because it has that similar limited customization. So, in the same way as we mentioned with the native mobile wallets, uh we want to make sure we can verify information out of the government wallets. Uh we can do that with mobile driver's licenses. We're working to do that with European Union digital identities and we'll issue into those wallets as it makes sense uh is as people become qualified trust service providers to have permission from the government to issue into those wallets.

[00:35:51]But we recognize there's a need for customizable wallets. So, we also have our wallet offering. Uh we recognize that a lot of use cases require custom experiences, custom workflows, uh being able to change credential types quickly based on business needs, uh being able to have the business control who accesses the wallet instead of having the government or uh Google or Apple control it. And so in these cases, you can use the Truvera mobile SDK and embed that into an existing app or or build your own standalone app. uh or you can use the Truvera cloud wallet APIs to be able to store the store these credentials in the cloud.

[00:36:32]And now the downside here is you've got to convince your holders to use that wallet. Now if they're employees, you can say use the wallet just like you do with Microsoft authenticator or something like that. Uh similarly, if it's a business flow, uh you can make that required as part of being able to sign a digital signature or being able to interact uh receive a loyalty program. Lots of lots of people download their loyalty app, right? But the other challenge is that the more customized it is, the more siloed it is and that's just that is the trade-off. So you can pick between uh fully customizable or the government mandates how it works and we we try to support everywhere on that spectrum based on the use case.

[00:37:14]So as I mentioned, we have those three separate solutions. Uh the mobile wallet uh so you can give that mobile experience. Uh this is great for portability, being able to move between ecosystems, uh mobile workflows, uh having everything local stored at the edge, making sure that PII is not stored anywhere else. And then we have that cloud wallet, a set of APIs. Our customers can host that cloud wallet. Uh we don't necessarily have to host it. Uh we support a again a decentralized identity foundation, a diff standard called the encrypted data vault for the for that mobile wallet uh hosting.

[00:37:48]And but this is really great because you don't have to download a thirdparty app.

[00:37:51]It can be quick onboarding. Uh and and that experience can be I don't know what a credential is. I don't know what a wallet is. I'm just approving my work data to be shared with this HR platform.

[00:38:02]You know that kind of experience and it can be really fast to integrate with that cloud wallet. Now these are not mutually exclusive. You can have the mobile wallet store credentials in the cloud. So you have c a local experience and a cloud experience. Uh that's possible too. And then on our road map is building that web interface. So today to use that cloud wallet, you're integrating into the uh you you have widgets that say I want to pull this data out. Uh but we haven't built out that entire web experience. Uh so that web wallet experience is something we'll we'll provide in the future.

[00:38:36]>> I would like to chip in here as well a little bit. and wallets is my uh favorite part of of this stack. And it's also one of the things that we get asked uh most about and the the misconceptions I think are the the most deep uh because when thinking about identity wallets um a lot of people still imagine those mobile wallets that we had in the in the previous slide. So the the native wallets, the government wallets, they're all mobile. They all store credentials that are shaped like cards. the the same shape that the cards would go in our physical wallets. But a wallet is a a place to to store credentials. So it's it can be uh whatever the use case requires. It can be as um as much managed as it needs to be or as little like in some use case it will make a lot of sense to have the user confirm uh before sharing every credential see every attribute they're going to share because they'll want to have this granular uh level of um permissions. But in some other use cases we will have that the holder just wants to click one button or maybe sometimes uh not do a lot at all and just get have access.

[00:39:49]they will still be the ones holding the data, holding their own data, but they will not have to go through very complicated user experience. So I think uh yes having and understanding different options for credential storage answers these lots of questions like how uh complicated it is to adopt this um technology or to change the existing workflows.

[00:40:09]>> Excellent. Excellent point. Completely agree. And there's only a couple more of these technical concepts before we before we ready for Q&A. So, uh, as we mentioned, it's possible to tie a credential. In a lot of use cases, we want the the relying party, the verifier wants to know, I need proof that the person sharing this credential is the same person that received it from the issuer. And so, it's possible to tie a verifiable credential to that biometric.

[00:40:36]Now, we want to be cautious that we're not sharing biometric data in the entire ecosystem. And so the way we do this is that when the user enrolls their biometric, uh they receive a credential in their wallet that says you've enrolled the biometric and this is the ID that will be shared in the ecosystem.

[00:40:55]So that ID doesn't have to have anything to do with the actual thumbrint or iris scan or face scan. Uh and then when the user needs to prove that who they are, they pass a local biometric check and receive a credential that says you just passed a biometric check and here's the ID. And so I can only produce that ID from a specific issuer if I've passed a local biometric check. And so during verific I pass that local biometric check and that gets shared with the issuer. the issuer embeds into the credential the biometric issuer ID so we know who the check comes from and the that biometric ID and then during verification be the the verifier the relying party sees that credential sees that it contains biometric binding attributes and says oh I'm only going to trust this if you can share another biometric check that's recent that comes from the same issue with the same ID and so that way we know that it's the same person presenting So there's three credentials in this flow. There's that enrollment credential that says here's the ID we're going to use in the ecosystem. And then there's the biometric check credential. I just passed a biometric check. So you can trust this ID came from me. And then there's the biometric bound credential.

[00:42:13]The credential with the attributes that you're interested in that also includes that biometric ID and the issuer the biometric issuer information. So you can compare that with the biometric check.

[00:42:23]I'm going to move a bit quicker so we can get to the Q&A. I realize we're getting out of time. Uh we did talk a little bit about blockchain already, but we find, you know, you need to you need that verifiable data registry. When we go back to the skipping way to the beginning, when we go back to that trust triangle, there needs to be a way for the verifier to get the key from the issuer, the public key. And that verifiable data registry, it can be anything. It could be a website. It can be a pigeon. It could be a email. Uh, however that makes sense. But we find that when you try to make this censorship resistant, operating at scale uh and and uh decentralized in hosting that it starts to look a lot like a blockchain. And so that's why we use checked because it provides those capabilities coming down. So it provides that that anchor for a did for the issue did. uh but we also put on there other information the verifier needs to see.

[00:43:21]So uh I should say if you go back for to the issuer if the if the verifier goes to the issuer for all this information then it becomes easy to leak information about the holder and so we want to have this separation between the the data that comes from the issuer and and the verifier so the verifier can so that I can share my ID with AGY and nobody else needs to know about it because AGY is checking the the registry instead of telling the issuer that they tal that she talked to me and so that's where we put that issuer did. That's where we put the revocation registry. We want a privacy preserving way to know this credential is still valid. It has not been revoked. There's a W3C standard for that called bitstream or bit status list. Uh and then we have a more privacy preserving way uh we that's accumulator based. But that registry it needs to go somewhere uh so so the verifier can check and then that ecosystem information who are the verifiers that we trust uh to access the credentials who have agreed to the privacy policy and who are the issuers that we trust to to give an employee ID or a patient ID or an insurance ID and putting that onto the blockchain can also uh help make sure that it's decentralized uh that if if the solution provider were to go away the data is still preserved. served and that anybody who needs it can access it.

[00:44:41]Now, when we talk about the blockchain, a lot of people get nervous. Wait, I don't want my personal data on the blockchain. Absolutely not. You should not have personal data on the blockchain. That is exactly right. Uh sometimes people say, I'm issuing verifiable credentials onto the blockchain. You're not issuing verifiable credential on the blockchain.

[00:44:59]A verifiable credential according to the W3C standard is issued into a wallet and but the trust is anchored on a blockchain. So onchain we only have public data. We only have information about the organization that's acting as an issuer, the organizations that are in an ecosystem and that privacy preserving status list. Uh we and the governance framework you know these kind of things the the actual attributes that I have as a human or that my AI agent might have those live in the wallet. They don't go on the on the blockchain. So it's important to recognize. Okay. So that's that's the content we wanted to share today. uh in when we work with our customers, of course, we we go into more details about how you design an ecosystem, how you put together a schema, uh how we design holder experience. We've got a number of different demos to show different wallets, uh what a verifier experience might look like, and then we talk about well, what is the technology that makes this happen? Uh specifically, and then we can talk about how to take this to market, how to how to package it for for a business case. Those are kind of things we t we cover. I'd love to cover these in more detail but it's another eight hours of conversation. So uh with that uh Agy anything else to add?

[00:46:12]>> Sure. So like first of all um after this theoretical part what we usually do um with our um customers after we we learn the concept is that to put these uh concepts into practice. So we usually do an exercise uh where we identify one or two processes in their organization that could benefit from the decentralized identity implementation and then we map the trust triangle and the value proposition of that change. So after listening to the session like all of the listeners they can also do that on their own and if you do that please send us an email with the results and we will respond to you back with uh with our feedback. We don't have to do it straight away. We will, as I mentioned in the beginning, send the recording to you so you can do it at your convenience. So now we have a lot of questions left and not a lot of time. So I will pick a few that I like the most and the rest uh again you see the email here on the screen. So we'll be happy to answer another time. Uh the first one that stood out for me coming from Deepak. Uh what is the incentive for issuers to issue credentials?

[00:47:24]Excellent. And I was trying to think, I don't have my monetization slide handy, but uh there's lots of different places that you can encourage people to pay for the credentials that are getting issued.

[00:47:36]Uh so we do see examples of of holders that pay directly because they see the benefit for that credential. You know, a concert ticket is a credential, right?

[00:47:45]And I pay for that concert ticket so I can get into the concert. Uh we also see a lot of use cases where where the issuer is issuing a credential as part of the rest of their business. Uh a university my students expect me to give them a credential when they graduate.

[00:48:01]They're paying for the for the degree.

[00:48:03]Uh and my incentive is to give them that that credential that gives value to the courses they're taking. Uh and then the challenging part is the relying party who usually gets the most benefit.

[00:48:15]they're getting the the business the workflow uh benefits of having that trusted data. How do they pay the issuer in a way that that uh that incentivize the issuer to fulfill their use case but also doesn't undermine the the privacy of the holder. Uh there are a few different proposals for that. In EUDI they're they're batting around different approaches. uh the approach we take is we have a a a distinct version of the credential format uh that locks the credential to the ecosystem. So then when the issuer issues they can know the cryptography will only allow verification by a trusted verifier and if that's the case then we can build that verifier and then pay the issuer for the credentials that got used and we can do that without without having the holders information. So th those are three places where the issuer can be incentivized because it's part of their business, because the holder is paying directly or because the relying party is paying directly. Uh th that that's that's the general key reasons why you'd also find some use cases where the government might pay issuers for credentials get issued. Uh doctor's licenses for instance might be a government paid scheme.

[00:49:26]>> Yes, exactly. So I think it's a very important question to answer before starting to implement anything like who uh will be paid and how will be paid to make sure that it all uh makes sense from the business perspective. I have another good question here. This one is coming from John. Uh do verifiers have to implement different solutions to support each type of the wallet? This was uh before we're explaining different like the mobile wallets, the cloud wallets, the web wallets, >> the >> and sorry.

[00:49:55]>> Yeah, go ahead. No, I just wanted to I asked the question I wanted to answer it. I told you wallet is my favorite part. So, uh the short answer no. So, from the verifier's perspective, the verifier I talking technically they would integrate with our API and it does not matter uh what the holder experiences or where the holder is sharing the credential. It would be the same implementation. So, as Richard also mentioned in the beginning, it can be also a combination. So a holder might have the same credential in their mobile wallet that they're taking out and about with them and when they're working on their desktop they can have the the same credentials in their cloud wallet. So so there's quite a lot of flexibility. I don't know Richard if you would like to add something more here. The and the goal is one day the standards will be mature enough that everybody can talk to these wallets with a single API. We're getting there. uh open ID uh has their open ID for verifiable credential issuance a verifiable presentation that that tries to get there. Uh but it's only been a it's only been approved for what two months now. So today in practice you often do have to build around a specific wallet. Uh now in European Union digital identity uh they want you to have to certify the wallet to know the wallet is respecting the citizen's privacy. Uh so we do see schemes like that where where you need to to certify the wallet in order for it to be useful for a specific use case. Uh but all this is emerging that's that's where we provide value is trying to make sure we make all this all this pain go away for our customers. We just manage it for you. But uh but today uh you do need to really think carefully about that experience you want your holders to have and what is the right wallet to provide that experience.

[00:51:41]>> Thanks Richard. And if we go even deeper on the conversation about the wallets, there's a question from Nick. As um OS level and governmentisssued identity wallets mature, do you think that custom wallets will become increasingly redundant or do you think that they can still maintain different differentiated value in the ecosystem?

[00:52:05]>> That's an interesting question and uh I don't know if my crystal ball is kind of fuzzy. I'm I'm interested to know what yours thinks, Agny. But two two years ago, we formally said in some webinar, uh, we think wallets are going to get commoditized. We don't want to be in the wallet business. Uh, two years later, after watching EUDI mature, I'm pretty confident there's going to be a need for custom wallets for a lot of these use cases. I just don't see the government being interested in solving most of the problems that businesses want to solve or many of the problems that business want to solve. Uh, will OS wallets get more flexible and more standards compliant over time? Hopefully. Uh, do they have does Microsoft does Apple and Google and Samsung have an incentive to lock out specific use cases? Absolutely.

[00:52:51]So, so I think I think there's always going to be a need for it. And what that ratio ends up being, I think only time will tell, but but I expect there's going to be a lot of use cases where just like I have my authenticator to to interact with my business website, uh I I'll want that same authenticator to allow me to interact with my partners' websites in very well-defined ways. And that'll be a private ecosystem. We won't want to use the OS wallet or the government wallet for that kind of thing.

[00:53:18]>> I I will agree with you here. I think there's definitely places where the the standard the government wallets will um take priority but uh there will always be uh business use cases where we'll uh want to have something customizable like we uh I mentioned before for example with aentic commerce I don't see governments giving us um solutions for that and and and why should they and there will be a lot of different um solutions that will require custom wallets So, I'm I'm pretty sure there's space for for all of these.

[00:53:53]>> I I just opened the chat and uh Tim's point about needing a purse to hold all these different wallets is is humorous.

[00:54:00]I have to laugh because it's absolutely true. But it's also that's that's one of the areas that Agy and I have been pondering the most is how do we make that experience easier that I can have three or four different wallets on my phone and they all interact in clean ways. Uh standards like the digital credentials API will make that easier.

[00:54:17]uh standards like open ID for verifiable presentation to make that easier. But but still that's a that's an interesting UX experience problem. That's I expect that's what we're going to be focusing on in in 2026.

[00:54:28]>> Yes, I have uh another and I think we have time for at least one more question. So we have a question or two if needed.

[00:54:37]>> Okay, perfect. So a question from uh ZG.

[00:54:41]Can you explain holder binding in a bit more detail please? How is that done?

[00:54:48]>> Well, the the two key approaches we see is wallet binding where the the wallet has a secret and during issuance the the issuer incorporates that secret into the credential and so during presentation the verifier can check that the credential came from the trusted wallet and all the credentials came from the same wallet. Uh now that's wallet binding that's not holder binding. So the approach we take is that biometric binding to say during issuance we check your current that you can provide a proof of of of biometric check from a trusted issuer and then we embed into that credential that that biometric identifier as well as the issuer information and then during verification I have to provide a a biometric check that matches but it's also only 5 minutes old or 3 minutes old whatever the the logic is. So doing that biometric binding it gives you a very strong assurance that it is is the same holder. Uh the disadvantage is that a lot of use cases it seems creepy to have to share a biometric in order to share my if I'm saying oh I prefer uh to an aisle seat on the airplane having to provide a a biometric for that seems a little overkill and so that's where the softer wallet binding might make be more appropriate.

[00:56:07]>> Exactly. Thank you Richard. Um let's go straight to the next question. Um Natty is asking, "How do you think users can delete or ask to forgive their data in an immutable system like a blockchain?

[00:56:22]How the system will ensure data security and GDPR with quantum computing coming soon?"

[00:56:28]>> Yes. Uh so those are two separate questions. The first one's really easy.

[00:56:32]Like we said, holder data doesn't go on the blockchain. So that's part of the reason why we never put holder data on the blockchain is because blockchains are immutable and you can't forget. Uh so when I want to forget my credential, I go into my wallet and I hit delete and that credential is gone. The point of the credential is it lives in my possession and I can delete it out of my wallet. Now the second question is is interesting uh which is about quantum uh resilience and there are because the the data is encrypted on my wallet uh being able to do mass uh attacks gets much harder and so that's one benefit. it reduces some of the concerns with with quantum uh quantum processing but we do have see the emergence of quantum resistant verifiable credential uh standards uh so I I'm using the term standards in quotes they've been proposed uh we see that NIST in the United States has accepted five different approaches to quantum resilience and being able to embed a quantum resilience signature alongside or within a a traditional computer Okay, a traditional algorithm is is the most common approach. So I haven't seen any of this in production yet. Uh but we do see that there's a lot of thought going into it and the approach we're taking.

[00:57:53]Sometimes you can make something quantum resistant. Uh but it's still resistant to a classical computing attack. And so the current approach is to have two signatures, one that is quantum resistant and one that is classically resistant. And then the verifier just checks both. The standard is flexible enough to allow it. It's just that we're still figuring out the right standard to what standard is going to get broad adoption.

[00:58:14]>> Nice. Thank you, Richard. I see we're at the time, but maybe I'll squeeze in one last question from Tim. And Tim is saying, "So, the owner of the registry becomes the central authority for remediating issues between uh verifiers, holders, and issuers when the trust is compromised."

[00:58:32]>> Yes. Uh one of the key reasons why we encourage ecosystems or trust registries is so there is somebody to do that. uh otherwise the verifier has to decide who they're going to trust. And some use cases the verifier is the right person to decide who they're going to trust.

[00:58:47]But in many use cases it's much easier to say who are the different uh insurance providers we trust in this ecosystem? Who are the different accredited universities we trust to give diplomas? And so if that's the case then you go to the accreditation body uh to to figure out those things. One of the things I like about verifiable credentials is that you're we're bringing to the digital world the same paradigms we use offline today. Uh when when I want to know which diploma to trust, I go to the accreditation body.

[00:59:17]When I want to know uh which uh which part business partner to trust, I go to the legal team and ask them for the list of business partners. Right. And we're just making it easier. We're we're providing those same kind of tools in that ecosystem.

[00:59:30]>> Great. Thank you, Richard. And uh thank you everyone for listening uh today and learning. Um yeah, we're definitely at at a time here now, but uh as Richard is showing in the slide now, here's our email. So if you have any more questions, do not hesitate um to reach out and hopefully see you again in our future uh webinars.

[00:59:52]>> Love the questions.