Eric Meyer: Hello and welcome. I’m Eric Meyer. I’m a Developer advocate at Igalia.
Brian Kardell: And I am Brian Kardell, also a Developer advocate at Igalia. And on today’s episode, we have two guests. Guests, do you want to introduce yourselves?
Dmitri Zagidulin: Sure, I’ll go first. So I’m Dmitri Zagidulin. I’m a engineer and standards wrangler in the general field of decentralized identity, access, control and storage, and I suppose decentralized social media.
Juan Caballero: I’m Juan. I go by BumbleFudge online. I consult widely, but I have been working for many years with the Decentralized Identity Foundation, which incubates a lot of DID did and VC products, prototyping, design work, and I also work with the IPFS Foundation, which has been used in a lot of DID and VC prototyping over the years.
Dmitri Zagidulin: And for those of you unfamiliar with VCs, we’re talking about verifiable credentials and not venture capital. The amount of time I have to mentally decode that in conversations, it’s just…
Eric Meyer: Yeah. Every time I looked at the calendar reminder for this, I was like, “Why are we talking to somebody about venture capitalists again? Oh, right. Verified credentials.” And actually, I’m going to throw in a little interesting note. I actually laughed out loud a little bit when I saw who was invited. Dmitri and I knew each other socially like 10, 15 years ago. Dmitri used to live in the same town. I live in Cleveland, and actually I believe he’s been to the house I’m sitting in right now-
Dmitri Zagidulin: Yes.
Eric Meyer: … for a bread and soup party and that sort of thing. But yeah, we used to hang out. We’ve played Rock Band together. But then Dmitri moved away and had other things going on in a whole career and we hadn’t really been in touch, and then all of a sudden, wait a minute. So, hey Dmitri.
Dmitri Zagidulin: Hey, it’s really good to see you.
Eric Meyer: Yeah.
Brian Kardell: Yeah. So today’s topic is a little bit different from what we talk about usually, I think. It’s a thing that we thought was a little bit timely because W3C had some press announcements and things, and I think a lot of people don’t know what it is. And I’ll say that for myself in W3C, I kind of watched from a distance thinking like, “Boy, I don’t know. That seems really a little bit over my head and maybe some of the people in the use cases are working on it or maybe things that put me off a little bit.” And so anyway, it’s had a long time to brew, and we’re going to talk about verifiable credentials. So can somebody maybe give me a brief, who’s got the best 30 second to one minute pitch on what are verifiable credentials?
Dmitri Zagidulin: So there are five credentials. Think of them as a standardized envelope to make any kind of claims you want to stand behind. Right? So specifically for those techies in the room, it’s a JSON object with the digital signature with a couple of required fields for, who is making the claim? Does the claim expire or does it have any sort of time limitation? Who is it about? And everything else is generic. So picture a driver’s license, like a U.S. style driver’s license with the state that issued it, your name and some other claims like whether you’re fit to drive a car, what the limitations are, what your age is, all that stuff, and then the fancy security mechanisms at the bottom, like the holograph, there’s digital signature in the bar, that kind of stuff. Now picture, if world got together and said, “Hey, this is a nice format. We’re going to use this for any sort of claim anybody is making.” But the idea is they are format to make official claims, either high value or low value. From high value, it’s things up to, I don’t know, access to a military base, plane tickets, whatever you can think of. First responder credentials. So for firefighters to get into the building, that sort of thing. To very low value of, here is a raffle ticket or here is a $5 off coupon for your next box of whatever.
Juan Caballero: I would say verifiable credentials are a interoperability format to make a sort of generalized form of any user controlled credential about them, so the most important part is so-and-so sends this about me, me and I choose who gets to see that self-contained export format so I can cryptographically prove it. It’s intended for offline use, intended for subjects to be able to carefully control where it gets shared. So in that sense, the most important part is the lack of phone home, like anyone can verify this credentialized thing an issuer said about the subject, so it empowers the subject to choose which verifiers could verify it without needing any participation or leaking any intel to the issuer issue.
Brian Kardell: There’s a whole lot here to talk about. One quick question that I had is you said that it was JSON. Does it have to be or is that maybe one or the most popular?
Dmitri Zagidulin: Great question. The answer to that question as many things in standards was, oh, at least a five year fight, if not more. Long, drawn out fight. The current state of the art is it’s usually JSON, but it also gets binary compressed and encoded into a couple of other things. But yeah, it’s a structured document, most commonly JSON.
Brian Kardell: Okay. Yeah. It’s a structure. This is a structured document. That makes sense. And within this envelope, when we say envelope, it is hard for me to not think of SOAP. Do you remember SOAP?
Dmitri Zagidulin: Yeah, absolutely. Absolutely.
Brian Kardell: So when we have this envelope full of claims, but it’s full of potentially independent claims, right?
Dmitri Zagidulin: Yes.
Brian Kardell: So you have this, your state issues you a driver’s license. That’s the envelope, right, and inside that is a bunch of things.
Dmitri Zagidulin: Yep.
Brian Kardell: And then the example that I hear thrown about a lot that speaks to me a bit, right, is… So I have a daughter who’s of drinking age and she goes to the alcohol store, or the state store. In Pennsylvania, we have state alcohol stores for hard liquor, and you have to show your ID and maybe there’s some creepy guy behind the counter and she shows her ID and it has her address and stuff on it, and why does he get to see that, right? So what I’ve heard is that you can choose to share the fact that you’re over 21 and that that’s it. So basically the state issued a claim that you’re over 21 and so they can verify those two things. Is that right, or?
Dmitri Zagidulin: That’s right. That’s right. So one of the tools in the verifiable credential toolbox is this idea of if your state or your university or whoever gives you a bag of bundled claims such as your age, your address, whether you can drive a car, your height, all that stuff. When presenting it down the line, you can select and unbundle it. So our jargon for it is selective disclosure, right? But that’s just one of the tools in the toolbox. The other toolbox that we recommend is don’t bundle them in the first place. There’s no reason for the state to not give you a small credential that is just, you can drive a car, and then a separate one, you’re over 21, and then a separate one, your height is over, I don’t know, six foot or whatever. Right? Now, there’s practical and economical and biometric reason why these things are bundled partly so as not to issue multiple cards, partly because you need to bind it to your biometrics, which is fancy way of there’s your photo. So there are good economic and information security reasons to bundle those claims, but we like to remind people that you don’t have to. You can issue these small standalone credentials in addition to being able to selectively disclose things like age and so on.
Juan Caballero: And I would mention also that I always emphasize it as a transition or as an export format because it is not a protocol. It’s not super opinionated about how you do cryptography. It’s meant to be not just crypto agile, but almost like cryptographically neutral. So if your issuer is using a kind of cryptography that lets selective disclosure of parts of redaction or subsetting or variously linkable forms of zero knowledge that you get as fancy as you want the crypto if issuers of verifiers are willing to use that crypto. It’s a verifiable credential regardless of the exact… To drive home the paper envelope analogy, however that envelope is sealed, however it is stamped, however it is delivered, it’s still a verifiable credential if it could be translated, right? Like if it translates to the same JSON, and if the subsets translate to the same JSON, right? So in that sense, there’s some diversity of protocols used, there’s some diversity of cryptography. Selective disclosure has trade offs, so there’s some people who want to use this kind, some people want to use that kind. It varies a bit, but they’re all verifiable credentials because they all translate to the same sort of translation paradigm.
Eric Meyer: And just to be clear, when you say crypto in this context, you mean cryptography, not cryptocurrency? So we’re not talking about VCs and cryptocurrency, we’re talking about verifiable credentials and cryptography.
Juan Caballero: That’s right. That’s right. Yeah. Now that you mentioned it, there are various ZK-VCs that use “zero knowledge” [cryptography], but that’s a pretty niche one. Most of the selective disclosure cryptography used here involves no [cryptocurrency or on-chain computation], nothing like that.
Eric Meyer: Yeah. I imagine that there is a use case for this technology to verify that you own cryptocurrency, but that’s not the core thing here. It’s just much like you could use this for plane tickets, you could also use it for cryptocurrency. For that matter, you could potentially use it for, “I own this bank account that has actual money in it.”
Dmitri Zagidulin: Exactly. Exactly.
Juan Caballero: Right. There’s a lot of use cases about this person whose name you don’t need to know does have a bank account with me or the just identify her, is this private key is held by someone who is a customer. There are lots of payments use cases if you know a lot about the payments or credit card worlds. Visa, MasterCard are both doing a lot of about this stuff. In the credit card world, there’s a lot of confidentiality. No party needs to know everything about you. Each party needs to know a different subset of your data, and lots of parties just need an attestation from another party. So when you really get into fintech, there’s tons of confidentiality. There’s tons of expiring and revocable credentials of attestations for pseudonymous identifiers. The more about fintech, the more obvious of fit it is, so they use it in one way. And in terms of the selective disclosure, I think the stuff that’s going to get to market first is selective disclosure over OIDC, so it’s like fancy JWTs. Like there’s a form of verifiable credential that’s just a JWT that you could redact parts of, and that’s pretty neat. Yeah.
Eric Meyer: Wait a minute. We need expansions of those acronyms.
Juan Caballero: What did I say? JWT? JSON web Token? Oh, OIDC, OpenID Connect, which is the single sign-on system that most people use. Sign in with Facebook, sign in with your bank, sign in with your university credential. So yeah, there is a 30-ish year old technology that is used a lot for partial attestation, partial trust. So somewhere where you only need a few claims from Facebook or Google or the controller of some sort of identity system. If you federate two identity systems, they trust each other’s assertions. That’s the phone home version, right? That’s a little less portable. That’s a little less subject managed. But they have a version of verifiable credentials that phones home less than older forms of OIDC, and that allows redacted credentials. That’s probably the one that most people who work in the web professionally will hear about first and will be widely rolled out first. Microsoft and the Entra system on LinkedIn uses this stuff. There’s a lot of prior art you can play with like toy implementations and the Decentralized Identity Foundation, GitHub repos. If you just need the JSON web token, the sort of older claim structure that federated identity uses, you just want to be able to share half of it with someone that’s sort of the most familiar form of verifiable credentials.
Brian Kardell: I mentioned earlier that I watched this play out from a distance, I don’t know, maybe 2013 or '14, I think. I was at some meetings at W3C and there was a lot of excitement around cryptocurrency really, and then there’s these arms out of that. What do you mean by that? What parts excite you? And so there was a lot of people who were interested in blockchain and then the use cases of blockchain and things. So what is the relationship inherently here to blockchains and cryptocurrency, since Eric had mentioned something about that? Yeah.
Dmitri Zagidulin: That’s a great question. So the cryptography is the relationship, to put it simply. Here’s what I mean. In a lot of ways, the verifiable credential community builds on some of the investment and infrastructure that Bitcoin and other cryptocurrency brought along. Specifically, the public credentials wouldn’t be in as good of a state if billions of dollars weren’t dumped into public and private key formats, signature formats, cryptography libraries, building cryptographic API into the browser itself. Now, a lot of that was also driven by things like Twitter and Google and single sign-on rather than cryptocurrency specifically. But we all use, at the baseline, we all use those libraries. So what do verify credentials and cryptocurrency have in common? They have in common public-private key cryptography, digital signatures, and the hardest thing in both cases is secure key management, right? It’s storing your secrets. “Oh no, I have this hard drive. On it is a billion dollar in Bitcoin, but I forgot the password.” Similarly, I could have a credential wallet, I could have a storage or a mobile app or something that has my passport and my birth certificate and all this stuff, but if I forgot the password to it, if I forgot the keys that make it work, then it’s inaccessible. Although, because it deals with governments and institutions and things like that, there’s a lot more opportunities for recovery and reassurance unlike cryptocurrency. So this is more of a institutional and social aspect of things rather than, I don’t know, purely libertarian.
Juan Caballero: I’d push back on that a little because there’s nothing inherent to cryptocurrency that makes the private keys harder to manage or unmanageable. It’s just a different trust structure, and the cryptocurrency world has to squat semi-permissionèd in the mobile browser, in the mobile operating system, in the Play store. There’s this very uneasy relationship between the Google store and the iOS store and applications that handle something that may or may not be currency, right? Crypto wallets can’t exactly do what they do if they give 30% of every transaction to Apple. So in a way, the relationship, so reframing Dmitri’s answer slightly, I would say there’s no inherent relationship to blockchains just as there’s no inherent relationship to OIDC. But if you need this to roll out quickly, if you need this to be for mass market, if you need this to not be taxed 30% in the app store, your options are either it’s going in the Apple Wallet and Google Wallet or it’s going into an independent wallet that needs to be maintained by an organization the end user trusts a lot like a university or their bank or their government, or it’s in some wallet that they side-loaded because they already needed it to do cryptocurrency things, right? The trust model for a wallet, a wallet’s like a user agent you have to trust a lot. It’s … having a wallet that lives in a browser extension or a wallet that has to be side loaded, or a wallet that is an app that can’t pay 30%. Whether or not you are using a cryptocurrency wallet to sign, hold and present VCs or an Apple Wallet or a web-based OIDC wallet are kind of the three most realistic ways to bootstrap a trust infrastructure that’s already there.
Eric Meyer: Yeah. I was going to say, it seems like, like you say, blockchain is one way you could do this, but if for example, Apple IDs could achieve these verified credentials, a lot of people have set up Apple IDs so they can get access to the music store or Apple TV or whatever. They’ve already trusted that to some degree. They have an account that has access to things. Right? Like I can have access to my Apple TV account, and then that same ID also has access to, if I’ve paid for Apple Music, then I have access to that. And similarly for Google users where they could become verified credential issuers.
Dmitri Zagidulin: That’s exactly it, yes.
Eric Meyer: Yeah. And Amazon, a lot of people use Amazon and have given Amazon a lot of personally identifying information, including usually all of their credit card. And like you say, I live in Ohio, if the state of Ohio decided they wanted to issue these verified credentials or verifiable credentials, I could choose to use that. Or if I’m of a particularly hard libertarian stance, I might completely reject that.
Dmitri Zagidulin: Exactly.
Brian Kardell: Yeah.
Dmitri Zagidulin: Exactly.
Brian Kardell: Can I ask a question about, all of this has to do with trust, right? Trust is tricky. It’s difficult. And a thing that trips me up a little bit is like, well, I don’t know. Can you trust this thing? And why is this thing more trustable than that thing? And I don’t know, forgive me if this gets a little bit loopy here for a second, but I think about, well, today most of this stuff has some kind of, let’s call it a paper receipt that they give me. It might be laminated and holographic or whatever, but there’s a physical object that somebody gives me, and when I go to the bar, historically they just look at it and they say, “I guess. Sure. Go.”
Eric Meyer: Your birth year starts with 19, you can drink. It’s fine.
Brian Kardell: Yeah, basically. Right? Basically. And as a result, maybe you also found somebody to make you one of those before you had a legitimate thing, and it gets tricky because you have Pennsylvania driver’s license is different than Ohio driver’s license is different than a driver’s license in the Czech Republic is different than a driver’s license in Mexico, right? And I think that one of the ideas of why you would want an interoperable, verifiable credential like that is specifically because if I’m on vacation in Spain or Italy, they would like to make sure that I actually am licensed somewhere to drive an automobile, and how do they do that, right?
Dmitri Zagidulin: Yeah. Yeah.
Brian Kardell: So I think that one of the things that I understand really helped give this a necessary kick in the butt along the way was COVID, so do you want to maybe talk about that a little bit?
Dmitri Zagidulin: Yeah. Yeah, I would love to. So you touched on all of the key aspects of it. What’s easy about verifiable credentials? Well, creating structured documents and signing them. What’s hard? Everything else. All of the structure, all of the trust infrastructure that you’re talking about. How do you know the key that signed this belongs to the state of Ohio? How do you know that particular state of Ohio bureau is authorized to issue driver’s licenses in the first place? It’s usually trust infrastructure and turtles all the way down. You touched on a really, really important aspect of standardization, and we see the full range of standardization via monopoly. It’s standardized because it’s Apple providing the infrastructure behind the scenes for all of it, and we’ve got standardization through loose trade associations, and we’ve got standardization through the UN, but more realistically through the European Union. European Union says this is what European driver’s licenses look like. That means all the states there, and then some other countries are like, “Well, they decided on what it is. We’re just going to follow theirs even though we’re not part of the European Union.” So all of that comes into play.
Eric Meyer: Yeah. And like you say, it’s trust and turtles all the way down, but I mean, that’s real life.
Dmitri Zagidulin: Yeah, exactly. Exactly.
Eric Meyer: Here’s my ID, and whoever’s looking at it, if it doesn’t immediately look fake, just sort of has to trust you’re giving them a real ID, and there are varying levels. At the bar is different than what I’m going through the security checkpoint at the airport where they look a lot more closely at whether or not my passport will actually scan and get a verified response from wherever it is that they’re pinging, and I guess the person running the machine, whether they realize it or not, is trusting that the ping they get back is coming from the place that they think the ping comes back from.
Dmitri Zagidulin: Exactly. Exactly.
Eric Meyer: So this does not necessarily solve any of that, but it doesn’t make it worse.
Dmitri Zagidulin: We say that a lot that at least it’s strictly no worse than the current system, but in many cases better. But in many cases better. So the subject of driver’s licenses and age verification is near and dear to my heart. Before coming to work with Juan and coming to work for MIT, I worked for a company called Digital Bizarre who has sort of pioneered a lot of these digital credential standards, and one of the hats that I wore was project coordinator for the True Age Project, which is an age verification project in the U.S. that is run by the National Association of Convenience Stores. Right? So standardization through a trade body, and as part of it, we had to convince a lot of cranky and busy and don’t give a operators of convenience stores and grocery stores and gas stations. Like, “Why are you bothering me with this?” Well, because really excellent usually Chinese made fake driver’s licenses are coming and are here and they’re resulting in a whole lot of fraud and resulting in a whole lot more reliability for you. Here’s an alternative mechanism that the government stands behind that results in fairly significant lower levels of fraud. Here you go.
Brian Kardell: I’m glad that you mentioned the thing about standards there because it being no worse than existing or whatever, it would be helpful maybe to talk about how standards work. When the W3C was formed, I read about it with great excitement and I imagined that it was something like the Supreme Court or the School of Athens for the world technology and that they would hand down a judgment and then that is what the world shall do. But it’s not like that at all, really, and-
Dmitri Zagidulin: I wish it worked like that.
Brian Kardell: Well, I’m not sure that I do in practice. I think there would be good things about it for sure, but I’m also not sure how much worse it would be either. But I think that there’s something good about the competition as well. But it does mean that you have this group, this trade association that is like, “We want to develop this thing and we’re going to use this.” But there are other industry groups that are doing similar things that maybe aren’t doing this. There are other companies that have a lot of tentacles into things that are doing similar things that aren’t this, and how do we navigate that? Juan, do you…
Juan Caballero: I mean, I would say we use a driver’s license example a lot. There are, like my former employer, Spruce in California, is working on verifiable credentials for DMV use cases, and if you think about it [, like,] verifiable credentials (I keep harping on this) they are the more flexible translation standard, right? A different trade association got together and made something just for driver’s licenses with all of the semantics and the variability hard coded. Because they’re a trade association, they already know what the licenses look like in the Czech Republic, and they basically, the driver’s license issuers association of the world worked on this other thing that is a little less translation oriented. It’s a little more hierarchical in the sense that if you issue an MDL, you aren’t issuing a verifiable credential. And then MDL is like it’s really tailored to that use case. You can’t vary it as much. You can’t change the cryptography if you… The cryptography isn’t pluggable. So it’s sort of like a little locked to certain issuance infrastructure. And for things that are really centralized, you don’t want to empower the user too much or maybe not you. The people who issue driver’s licenses don’t always want to optimize for user portability service. They don’t want a completely open market, right? So really foundational documents, passports and driver’s licenses do tend to prefer these X.509 revocable protocols. They don’t always need the strong suits of verifiable credentials in every use case, and there’s plenty of hybrid stuff, there’s plenty of dual issuance stuff, there’s plenty of derivative credentials possible in more flexible formats. But this comes back a little to your point about the dystopian idea of a standards association just laying down [the law] and technologists having to color within the lines. I’ve been at a Local-first conference all week, and Peter van Hardenberg from Ink & Switch was, his sort of talk at the conference was about malleability. Right? Like software that’s flexible enough that users at various levels and developers at various levels can sort of fudge things, can have some flexibility, not hard coding and having this end-to-end everything sort of colored within the lines, semantics hard written. The malleability of verifiable credentials I think is its strong suit, right? There’s sort of the issuers could choose how flexible or how translatable they want their credentials to be, and that sort of is a useful way of looking at them. It’s like they’re optimized for translation and they can work with existing systems. Any two producer and consumer of data that are already using a given blockchain semantic standard rails can make the verifiable credential for the two of them that then translates better to the outside world to future Martian anthropologists, et cetera.
Brian Kardell: You mentioned in there semantics, and one of the questions I have on my list of things to ask you is if I’m making a claim, you have to inherently somehow understand the claim that I’m making. We have to agree on what it means to whatever that claim is. So this is again going to my, when you are in a group like W3C or IETF or whatever, there’s like a bajillion efforts happening and you cannot possibly be involved in all of them. So even when they sound interesting, you find ways to sort of short circuit and say something like, “Well, that thing is about cryptography and I don’t really know anything about cryptography, but those people really do and I trust them, so let them do their work.” Or, like, “Those people are really deeply into semantics and the semantic web and they’re chasing that thing and maybe something will come out of it, but it’s not for me.” And so one of the things I noticed a lot of people who were very into semantics and semantic web were also involved here, and I’m curious, is there a relationship and how do you agree on semantics? I imagine it’s pretty important if you have this generic claims idea, what is the claim that you’re making? Because I can imagine several universes where there’s different kinds of solutions to this.
Juan Caballero: Well, I would say quickly that the… There’s a, like I said, like with MDL, the semantics are a little hard coded because it’s really for one use case. For use cases where there’s never going to be a universal dictionary like educational credentials, there’s always a patchwork of like, well, this European Association said this, and the International Science Foundation said, “We have to agree just for the chemistry degrees,” and for places where it’s always a sort of patchwork mix and match tentative thing, you need something where the semantics can be passed by reference, not by value. You have to have versioning. You have to just embrace that chaos and be able to encode in the credential enough references and breadcrumbs that the Martian anthropologists will be able to find those semantics. So there’s different styles. I think there is a very JSON-LD version of this where if the sender and receiver both want to agree to use JSON-LD credentials, then it’s kind of sorted because each property is already linked to a versionèd, permanent, synthetic web document, ideally.
Dmitri Zagidulin: Agreed. So as a user and a technologist, I come across a new tech. I always want to know what’s easy and what’s hard and where’s the drama. Right? And y’all have sort of hit upon all the important bits of verifiable credentials. What’s hard? Well, managing secrets and keys is hard for regular people. Institutions mostly have it sorted. Running issuer registries is hard, right? Whole idea of digital signatures is that they’re opaque in the sense that all you can verify, all you can machine verify is that this object was signed by this key ID. What that doesn’t give you is who does the key ID belong to? And for that, you need the trust infrastructure, you need the issuer registries. So that’s the second thing that’s hard. Running the trust infrastructure, which really running the white pages and the yellow pages of the world for the old people out there and mapping these opaque key IDs to KYC. And then the third thing that’s hard is what Juan was talking about for developers and for verifiers, which is to agree on the vocabulary, agree on the semantics of this is how we do an age field, this is how we do a name field, this is how we do addresses, this is how we do diplomas and areas of studies and skill credentials and all that stuff, and that is super hard, and the answer is exactly what you would think. Governments, monopolies, trade associations, loose bands of open source folks and industry verticals. So like Juan said, so driver’s licenses, that’s easy. Well, partly because we’ve got the European Union, we’ve got the U.S., and we’ve got monopolists, basically. Essentially all driver’s licenses in the U.S. are handled by a single trade association, a single monopoly and a single technologist that you all know and love is very closely tied to that company. So with driver’s licenses specifically, there is sort of a battle for the soul of the world between mobile driver’s license standard incubated in ISO, which is incidentally, if you want to read the specifications, it’s going to cost you a hundred bucks to read it. It’s open spec, but it costs you a hundred bucks to read it, right? There’s a difference in culture between standards organizations. So we’ve got mobile driver’s licenses over here and we’ve got W3C verifiable credentials over here, which is free to read though it’s got other problems because in order to participate, you have to be either have to be either a member and pay dues or be an invited expert. So there’s always gatekeeping somewhere. I just prefer the gatekeeping on the free-to-read [specs] part. Again, for driver’s license, it’s easy. Governments can just specify the semantics and go. Everything else, it’s hard. So for education there is, like Juan said, a patchwork of… European Union has one schema, actually has two schemas, two fiefdoms that are fighting between each other, but eventually they’ll sort it out and there’ll be one. But we also have a standards task force that does a best practices directory of if you’re going to do diplomas, this is what they can look like. If you’re going to do student IDs, this is what they can look like. Right? Japan has its own similar body, so it’s a patchwork as always.
Eric Meyer: Okay. So I sense that this is an entire series of rabbit warrens, all of which have holes that go very, very deep, and we only have so much time, and one of the things that I actually really want to get to is I am a user of the web. How do I use this in the browser or how does this get brought into my, I guess, everyday experience? Because there is a lot of, like most of us when we’re on the web, we’re doing things that require some degree of trust, whether it’s getting onto a social network or it’s buying something from an online retailer or putting holds on books at the library through their website or watching Apple TV or whatever.
Dmitri Zagidulin: There’s good news and bad news.
Eric Meyer: How does that…
Dmitri Zagidulin: The bad news is, so far with great difficulty. Good news is it’s getting better. At the moment you have to rely on mobile apps, browser extensions or some very early, what are those things called? Polyfills. Browser API polyfills that mimic the UI of what’s going to look like when Apple and Google and Microsoft get around to it. The user interface looks a lot like, if you’re familiar with passkeys and both their convenience and problems. If you’re familiar with storing plane tickets and driver’s licenses in your Google Wallet and your Apple Wallet, it’s that kind of stuff. So the UI and the UX of it’s still very early days. Let me give you a simple example. How do you tell to the user that this digital credential has verified? Right? Just like with browser certificates, we’ve had the long history of how do you tell the user the SSL cert is valid? Well, you’ve got this little green icon over here and the entire weight of technological civilization rests on that tiny little green icon. Right? So it’s like that. What’s the UI look like? This is verified. Well, you got this green check. What does the green check look like? Or rather, what does the green check mean? Well, some implementers are pioneering the fact that it’s not really one green check. It’s a checklist of warnings and it errors and validations like, yes, we know who signed this. Yes, it hasn’t expired, but maybe it’s been revoked and you’re offline and you haven’t checked the revocation registry. Right? So all that stuff still being worked out, but we’ve got some good prototypes to play with.
Eric Meyer: Sorry, sort of the answer so that I understand is either I need to have some kind of app that I’ve installed on my mobile device or a browser extension for the most part, is if I wanted to start to get into-
Dmitri Zagidulin: No, there is a third option. There is what’s called web wallets that use things like similar tech to single sign-on and social sign-on that allow you to switch over to this different website, pick your credentials and present them over to this website. So yes, non-browser extension options are available.
Eric Meyer: Where would I find such a web wallet?
Juan Caballero: I have a great one to recommend. So I work with the Decentralized Identity Foundation, which has been open-sourcing and getting people to collaborate and co-design things that’ll be open-sourced. For years, one of our most active members lately is a organization called ArcBlock. They have a lot of experience with blockchain SDKs and AWS and making things pretty turnkey. Right? So their website, arcblock.io, their website is a great one to just click around for five minutes and see it all happening in browser. So because verifiable credentials are this really cross-platform cross form-factor, it’s more like a verifiable credentials is a set of guarantees. However you interact with it through whatever UX, it’s like a certain level of truthiness, as they say in Elixir. It’s like verifiable credentials are not for the browser. They’re not for one specific subset of the web or one form factor. And in a way, what they’re competing with is the operating system wallet. The wallet that comes pre-installed on your operating system is like a password manager you didn’t choose. And if there isn’t this cross-platform translation standard, no one can compete with the wallet that’s already there, which websites can also pass through the DC API, right? So boarding passes, MDLs a lot of high value credentials, people are just put it in your operating system, only trust the operating system. Right? If you want to just play around with a slick demo where all the parts are on GitHub and all you have to know is TypeScript, check out our blog. It’s a good one. It’s a good sort of end-to-end showcase of ideas that this idea, that this community has been circulating. Coming back to the browser part, so in terms of what… Lots of people have been using polyfills and/or browser extensions for cryptocurrency wallets and password managers to clear examples of where we really need the Web Crypto API to be gaining features that shift the browsers a little faster. The more crypto people could just trust the browser to handle, the better, so a lot of people use more conservative cryptography than they might just so that the green checkmark can happen in any website rather than having to be in a website that runs some library they didn’t choose. So that’s a lot of the stuff that’ll make it to production sooner to rely on Web Crypto so that every consumer doesn’t also have to have a polyfill and doesn’t also have to have these complicated heavy dependencies. Right? So the more crypto gets into Web Crypto, the lighter these packages and polyfills and trust models get. So that’s one sort of light at the end of the tunnel. For a long time it felt like the decentralized identity community, the VC community was front-running the browser a little, but now that there’s a little more crypto already dialed in, it’s a neat… Makes these things more realistic for browser-based things.
Brian Kardell: Maybe we could say, just on the off chance that some of our listeners don’t know what Web Crypto is.
Dmitri Zagidulin: Yeah. Web Crypto is a set of signature and verification and encryption APIs built into the web browser itself. Right? So in the bad old days before, let’s say 2016, if you wanted to do a digital signature on your website, you had to load the JavaScript that actually did the signature soft code and perform it there. Fortunately, browser vendors got together and more or less standardized a couple of key types and a couple of APIs that moved that into the platform itself, so that much like SSL certificate handling, individual app developers don’t have to worry about that.
Brian Kardell: And so part of that is you say which cryptography algorithms you’re-
Dmitri Zagidulin: Exactly. Exactly. Exactly, yeah. Yeah. And there’s three or four, but there’s not that many. As usual, there’s confusion. Yeah.
Juan Caballero: It’s the basics, but it lets you say on a website, “Here’s the signature from this pub key.” Display green check mark if the browser can check the checksum at last mile verification, right, and without the website having to have its own JavaScript, blah, blah, blah. The browser itself could just check signatures in these three or four most common curves. If it has these inputs, the browser just does it reliably and there’s no reason for everyone to be re-implementing it and to be loading a hundred versions of the same logic into everyone’s site. So that’s what I meant about last mile verification. Your verifiable credential can be presented or shown or whatever, and that green check mark or red check mark could be applied by last mile code that doesn’t need to do roll its own crypto. This helps a lot getting some of these things, particularly the lower value [usecases] further from the original issuer and consumer of a credential, right? Like a credential is more verifiable to third parties and Martian anthropologists if it’s all just standard crypto, right? Makes it more portable. We talk a lot at the IPFS Foundation, which by the way supported some of this work on web crypto API. We talk a lot about ambient verifiability. So if you’re using common primitives that are just built into the browser by default, that really gets you to a place where that particular credential signed with these super common curves is almost like verifiable even out of context. It’s just sort of ambiently, it’s as self verifiable as any hash or checksums [that] you can check.
Eric Meyer: You talked about IPFS work and that’s something that Igalia did, actually, or worked on. So yeah, it’s interesting how these things all come together, but.
Brian Kardell: Way earlier in the podcast, like very early you had mentioned that these other solutions maybe don’t work for offline use cases or something like that, I seem to recall. So how does that work exactly? What is somebody needs to be online to verify this? Like somebody needs to be. The verifier needs to be online. Is that right?
Dmitri Zagidulin: Or have a lot in their cache. Right? So it depends on the use case of the verifier. If you’re a driver’s license verifier in the U.S., you really need essentially to cache either one key from the U.S., or more likely a separate key from each state. That’s not that many, right, and they don’t turn over that quickly, so there’s a lot of cases where the caching is useful for offline.
Brian Kardell: Gotcha, gotcha.
Juan Caballero: And it’s also worth mentioning, too, that verifiable credentials, most of the original use cases in the use cases doc that the W3C working group was working on were not always online. Offline wasn’t the best distinction. It was almost like public-private. So it’s like even if it’s online, you might present it over a secure channel and it’s sort of like privacy by obscurity, right? You only give the credential to a consumer that you’re also signing over the envelope to prove control of the key that it was issued against, or whatever. So there were often– that is the most subject-empowering flow, is to say, “I can prove this credential was issued against me. Here is a credential that’s through some secure or ephemeral channel, and so I can prove in a private context that needs no phone home, that leaves no public traces.” Once you start publishing a verifiable credential online, then it sort of is using a chainsaw to open an envelope. It has all these translation properties you don’t really need for public data. Like once something’s online, it’s sort of already, the good guys and the bad guys all got it within seconds. So there’s a lot of VC use cases in finance and in trade where you’re passing along credentials along, like, a supply chain where everyone is verifying it. (And also, ports aren’t the best connected places). They might also need to do some offline private verification of these credentials. They need to check these signatures even if they don’t know what the pseudonyms represent, even if they’re not publishing stuff, because supply chains have a lot of internal confidential… They have complicated privacy/confidentiality requirements, if not privacy requirements. So that wormhole goes pretty deep to say, or rabbit hole. There’s a lot of ways in which verifiable credentials are optimized for non-public channels.
Brian Kardell: Okay. So my last question or thing that made me think of, Eric and I were talking about this the other day and I was talking about the most cited example that I hear is the liquor store example, right, where all you need to know is that the state verifies that I’m 21 or over here, or I guess probably just verifies my birthday. I don’t know exactly how that works because, again, we get into these weird semantics that sounds really good when I say it here, but maybe somewhere else the age is 18, maybe somewhere else it’s 22. These are completely arbitrary lines that we draw in the sand, but that’s not even the question. The question is, this sounds very good in theory, but one of the things that worries me a little bit that I’m curious if there’s been discussion about, and I mean, I’m sure there has because it’s unlikely that I found a critical flaw in something in either the 10 minutes that I spent on it, right? But it seems to me likely that once you have information digitally in a way that sort of at the register they can request information that they will just request too much information.
Dmitri Zagidulin: Great question.
Brian Kardell: And you will give it to them because it is like when you buy a computer or a piece of software or you get in your car now or you turn on your TV, there’s a license agreement that’s 487 pages that says, “Hey, would you like to use this expensive piece of equipment that you just bought or not?” That’s your choice, basically.
Juan Caballero: I would say that a lot of civil liberty organizations, the ACLU and the EFF have been watching hawk-like as digital identity systems get rolled out by government and/or trade associations as powerful as governments. They’re terrified of this Show-me-your-Papers State, where anyone can ask for everything. Right? And I live in Germany. Germany is one of the strongest bear… skeptical member states of the EU on digital identity that has too much oversharing of data or leaks of data. So one of the ways you mitigate this is on the policy level and just every state where the current government and current population cares enough to make it illegal to ask too much or to hold someone liable for asking too much or for being a creepy dude who writes down the address when they see the driver’s license. If you get into the Byron Tau world where private sector’s allowed to amass preposterous amounts of money for advertising purposes and then gets sold to hostile foreign governments for military purposes. It’s like, “Aah.” So obviously you don’t have to be a privacy nerd or an international war/cybersecurity expert to know it’s bad to have strong identification being overused. Like if the person selling you beer knows your address, it’s bad. If the person selling you beer knows some identifiers they could use to track you around the entire web or physical world and get, buy your GPS coordinates on an open market, that’s also pretty bad.
Brian Kardell: Worse. Worse.
Juan Caballero: It’s maybe a little bit worse.
Brian Kardell: Yeah. I mean, to me it’s worse also because it’s efficient. The efficiency is part of why it’s worse. Right? It’s true that the creepy dude behind the counter gets to see my daughter’s address when she goes in there, but unless he’s got a photographic memory or he’s like, “Hold on, let me write this down.” He’s not mass surveilling everybody that comes in there, but the companies, if that’s available to them, there’s no company that doesn’t want that information. Right? There’s no company that doesn’t want to know how to send you mail, or want to-
Dmitri Zagidulin: Absolutely.
Brian Kardell: … know about your purchasing habits, or-
Juan Caballero: Yeah. So there’s two mitigations, right? One, you can mitigate it in meatspace. Your government can go after the person selling data they didn’t have a legal right to have. And there’s sort of the tort strategy like GDPR. Anyone can sue anyone for having too much or asking too much, not being able to justify how much they have. A lot of civil liberties organizations of the Decentralized Identity Foundation don’t think that’s enough. Right? Governments change. From one day to the next, the government might stop protecting its subjects from such abuses. On the technical level, you get into some trade-offs. Like if you really want to have double-blind systems, if you want to have ephemeral things, if you want to have unlinkability, if you want provable ephemerality, that all gets pretty expensive in the engineering sense, right? So I think that those more expensive, slower to roll out, harder to engineer technical ways of making data exchange more auditable, provably ephemeral, et cetera, are worth doing for things like foundational identity. If you can open a mortgage with the information leaked from our transaction, maybe you should be using more complicated cryptography. That’s sort of the current battle is like, can we convince people that something more sophisticated and less prone to these Byron Tau, abuses that Byron Tau has been publishing about the secondary markets for? I think we should be exploring those as much as possible and making sure we don’t pour cement around the simplest, fastest way of doing things and then never make progress.
Brian Kardell: Yeah. Dmitri, we’ll give you the last word on this, then we’ll-
Dmitri Zagidulin: Sounds good. Yeah.
Brian Kardell: … say goodbye.
Dmitri Zagidulin: Unfortunately, verifiable credentials don’t solve difficult power dynamics, difficult social dynamics, right? No matter how sophisticated your crypto, if the company that you’re logging onto your funny video site requires enough claims to open a mortgage before they do anything for you, right? There’s no crypto that’ll save you. Even if it’s all super isolatable, revocable, the power is still often between consumer and provider of the service and so on. So essentially we have to use all of the tools at our disposal, government, trade association, peer pressure, blog posts, naming and shaming. Like Juan said, choosing the tech that at least gives you the option for data minimization, right? Those of us in specs and standards or writing open source software have to make sure that when writing the protocols themselves, we build in the data minimization at the base layer. For example, the age verification, the Tru-Age Project that I was mentioning said, “This credential is only going to have three things. A one-time use, opaque random identifier, your picture, and not even your birthday, your age category.” You’re over X, and that’s it. So yeah, unfortunately no shortcuts and no easy answers. Power struggle still continues, but at least we have some of the tools to enable the conversation to enable the power struggle.
Eric Meyer: Very cool. So before we say goodbye, where can people find out more about this and about each of you?
Dmitri Zagidulin: Yeah. I mean, honestly, just search engine searches. Do a search for W3C verifiable credentials and see if your eyes glaze over. Do a search for our names. What would you say?
Juan Caballero: I’m Bumblefudge.com. That’s pretty easy to remember. The Decentralized Identity Foundation is at identity.foundation. All the W3C groups, you probably know how to find if you’re listening to an Igalia podcast. I think foundational identity use cases, if you’re a policy person, you should just… The right search terms are digital identity, because the debate around this is always when people say digital identity, they’re really talking about these foundational documents, things you could open a mortgage with, not frequent flyer mile tickets.
Dmitri Zagidulin: If you want to talk to us, reach out to us on Fediverse, Mastodon, Blue Sky and LinkedIn, in that order of reference.
Juan Caballero: Yeah, exactly. Same.
Eric Meyer: All right. Sounds good. Well, thank you very much for joining us and for-
Brian Kardell: Answering all of our questions.
Eric Meyer: Yeah, answering all our questions, and taking us down a bunch of rabbit holes.
Dmitri Zagidulin: Yes, lots of rabbit holes. Great talking to all of you. Wonderful questions. Thanks, and good to see you again, Eric.
Eric Meyer: Awesome. Thanks very much. We’ll talk to you later.
Eric Meyer
Brian Kardell
Dmitri Zagidulin
Juan Caballero