Well, thank you all for getting yourselves out of bed this morning and joining me for a fun journey that we're about to have in terms of digital credentials. Last year I talked about standards are about making choices. There's a world of choices that we need to make to effectively use digital credentials and we're going to talk about that in a fairly whirlwind way this morning together. So digital credentials are all over this conference and all over Europe and most of the rest of the world. It has great promise.
It in some sense gives people the user control and consent that Kim Cameron wanted to give people 20 years ago. And in fact, that was part of what led me into my identity journey. And like a physical driver's license, the issuer doesn't know when you use it. But unlike the physical driver's license, you don't have to show the recipient everything on the credential, which is great. There's now a myriad of choices that we need to make to build effective systems. Starting with, what do you call them?
They could be digital credentials, verifiable credentials, verifiable digital credentials, credentials, tokens, assertions, certificates. There's probably more. Take your pick. We're all meaning similar things with those terms. So let's just go on. So now there's the choices of what kind of digital credentials we're going to use. And here's a quick guided tour of some of the possibilities. W3C verifiable credentials in some sense started it all. They are JSON-based credentials using JSON-LD.
And as Marcus Sabadello said yesterday, the experience is that developers tend to get the context values wrong. So take that with whatever grain of salt you see fit. There are three versions of these. I worked on the last one. The 2.0. 2.0 is not compatible with 1.0 or 1.1. It's arguably better. There are two classes of signing methods for W3C 2.0. There's the W3C-JOSE-COSE, which I worked on, which uses established IETF specifications as the signing data structures. There's also W3C-DATA-INTEGRITY, which signs over n quads. And if you know what those are, you know more than me.
And alternatively, they can sign over canonicalized JSON. I hate canonicalization. That's a whole talk. But we're not going to do that here. Suffice to say, there's a myriad of choices within this credential format, even if you choose it. ISOM docs are another one that's getting a lot of currency. You've heard about that in many of the talks heretofore. It's a CBOR-based credential, rather than a JSON-based credential.
It supports salted hash-based selective disclosure of claims, which is important to that guarantee that I can just show the bits that I want to show them and not, for instance, my resident's address, if I'm not needing to disclose that. Now, here, as an engineering artifact, the claims come in namespaces. So there's a general MDOC namespace. There's an ISO MDL namespace. There's namespaces for other subcredential types. And then within the namespace, you have the individual claims. Three of them that are defined are family name, portrait.
And actually, there's, I think, 100 of them, which is age over two digits. So MDOCs are used for things other than just mobile driver's licenses. They're used, among other things, as one of the data formats for EU personal identifier documents, or PIDs. They're used for health certificates. And in fact, I looked up on the World Wide Web, where everything is true, that the namespace for COVID credentials is org.mycov.medical.1. Selective disclosure JOTS have a lot in common with the MDOC format, but it's back to being JSON-based, which I've done a lot of work in. I've done CBOR work, too.
It also supports salted hash-based selective disclosure. The claims are not namespace. They're in a flat space. And that flat space is usually taken from claims in the IANA JSON web token claims registry, the JOT claims registry. That's what's used for OpenID Connect and a lot of other things as well. And on top of SDJOT as a data format, there's SDJOT verifiable credential, which adds some processing rules. As if we weren't done, there's selective disclosure CWT, or CBOR web token. I worked on the CBOR web token in IETF. It also has a claims registry. And SDCWTs use it.
And the motivation for that data format comes out of certificates for moving goods across borders, where there may be millions of such credentials, and you want them to be as compact as possible. JSON web proof is another one that I work on. There's advanced cryptography, and even though I have a mathematics degree, I don't claim to understand how the zero-knowledge proofs work. But I do trust that there's people who do. There's one called BBS Signatures that the JSON web proof uses.
And the promise of that is rather than having to have 100 different age-over-NN claims, you could actually have a cryptographic proof that I am in possession of the date of birth. I'm not revealing it, but I can assure you that they're over 21, which is magic. And there's the trusty old X.509 certificate. Not to be forgotten, my friend Tony Nadelin, during the beginning of COVID, was still flying to Brussels every week or two from the United States to work on an EU digital identity system using X.509 certificates as the data format.
It does not support selective disclosure, just like plain old JOTS and CWTs don't. The claims there are identified by this arcane thing called an OID, an object identifier. Those are namespaced such that organizations get the ability to assign subnamespaces. NIST in the United States has an OID prefix. The FIDO Alliance has an OID prefix. I'm sure that many European organizations have an OID prefix. That's all good. There's many different certificate profiles. Most of us are aware of TLS certificates. There's COVID vaccination certificates, goes on and on and on.
So lots of choices of data formats. I haven't even listed SAML tokens. There's choices about how you communicate them and how you use them. So there's kind of two verbs or actions in this space, which almost all of you already know. There's issuance, getting a credential into the wallet that you control, and there's presentation using that credential at what's called a verifier. Now the act of presenting may in fact involve the selective disclosure, like I want to give Stefan this, but not this, right? And there's multiple mechanisms to do each. So let's go on a tour of that.
Credential issuance mechanisms. It is the case today in practice that there's a number of bespoke issuance mechanisms that are deployed. So for instance, while there's the OpenID for verifiable credential issuance protocol that we in the OpenID Foundation are hoping that many people go to, that's not the mechanism that's used, for instance, to load a mobile driver's license into an Apple or Google or wallet today. Some of these mechanisms are credential format specific. In particular, some only work for MDocs. And you know, I understand making choices.
That's a reasonable way to cut off options. And then there's presentment.
Again, there's the OpenID for verifiable presentation spec, which is in review in the OpenID Foundation to become final around the end of June, which is good. There's the mechanism defined by the Australian Roads Authority, Austroads, which is in NXC of a numbered ITU draft, and so on. And there's also two ways of presenting. You can do it in person. Think of having an MDL and wanting to give it to a traffic cop to say, yes, I really do have a license. That's not an internet transaction. That's a tap or proximity transaction. But there's also doing things over the internet.
There's more ways to communicate credentials. And I think I made Andrea, who's our content chair, a little nervous because I kept working on my talk until late yesterday afternoon. Why? I kept listening to what other people were saying in the conference and wanting to reflect on and include some of that in what I was saying. In particular, Marcus, you know, pointed out, you can use DidCom, which you could if things are dids. There's the W3C Digital Credentials API, or DCAPI, which I am in the working group that helps work on that. But there's also the Verifiable Credentials API, the VCAPI.
And no, those are not the same thing. Go figure. How do you choose credentials is another whole choice space.
Well, you can use query languages to say, I would like credentials with this set of characteristics. And there's been two of them that have been in widespread use. The presentation exchange query language that was developed by DIFF, which was kind of a Swiss Army knife of a spec and could do everything. But as such, interop was hard. So I was one of the people who led the charge to replace that with something more purpose built, which is the new Digital Credential Query Language, or DACL, which in German apparently is close to Dachshund, according to Dr. Daniel Fett.
Well, there's user interfaces for choosing credentials. Wallets must implement a way for you to pick, I want to use this one, because sometimes there may be multiple choices.
Platforms, meanwhile, have to potentially implement choosers among wallets, because you may have multiple wallets. And so there's this hierarchy. What you see on the right is the InfoCard credential selector from 20 years ago. I don't know that we'll use exactly that UI, but who knows? So let's just say that the best practices for the user interface is an experience, and the usability are a work in progress, but they're really important. Another choice space, how do you establish trust? Trust is used to decide whether you're going to interact with a party or not.
So there's multiple ways in the ecosystems to establish trust, and that's also very much a work in progress. Well, a simple way is you just have a list of, you know, the seven things you trust. That works, until it doesn't. Some of the trust mechanisms use trusty old X.509 certificates and chains, but these are not the TLS certificates. These are purpose-built certificates for that purpose that are issued through a custom mechanism that's not the ACME protocol or what have you. And it does require still maintaining a list of trusted certificate authorities, just like for TLS certificates.
Finally, there's federation-based approaches. The one that I favor is called OpenID Federation, which we're nearly done with. We had an interop event for that in Stockholm last week. This is scalable. It could potentially enable groups of federations to interfederate and start to interoperate as long as they both play by the same legal and trust framework rules. Being on this stage in Europe, I can't help myself but do a thought experiment with you. Let's assume that the EU digital wallet things wildly succeed, and I hope they do.
At that point, you know, a citizen in Portugal will get used to being able to use their ID and other things in their wallet. In Austria, in Germany, in Greece, in Slovenia, what have you, which is great. But they're going to like this so much that they're going to want to use it exotic places like Canada and Singapore and Kenya that don't have EU digital certificates. Even the UK. So what are we going to do? This is important to build this out internationally. So usability is everything. I talked about this in my keynote two years ago.
Again, I'm going to go back to an info card story. When we did user studies, only 3% of the subjects got through the initial flow. And even those who got through it said, well, how could I have logged in? I didn't type a password. So they didn't have a mental model of what they were doing, why they were doing it. And guess what? If people are confused or don't know why they want to do something, they won't. These usability lessons are as fresh today as they were 20 years ago. Building ecosystems is hard.
A good friend, Andrew Nash, taught me this lesson early on, again, during the info card experience. He pointed out that building ecosystems requires all necessary parties playing all the roles to voluntarily and incrementally adopt the technology. And they will only do so if there's an incentive for them to do it right now.
You know, there's lots of things you can tell the story of, won't the world be great when everybody does this? Which may be true in theory, but you have to get from here to there. Getting from zero to ubiquitous is super hard, and it requires purposeful ecosystem building. Katrina talked about that yesterday, and this is, you know, one of the slides I put in after listening to another good thinker in the space. Some of the things she said that I thought were great enough I wrote down, and watch her talk on the recording if you weren't there.
As global citizens, we're constantly crossing borders. Go back to my thought experiment. There's some pillars for ecosystem success. There's notions of how do you build trust at scale? All of this matters. I talked with my friend Juliana about this. I picked her brain over sushi in Mountain View, California, and then a follow-up call, and she's been doing interop events for the digital wallets, and she kind of expanded my mind. I often think about protocols and data formats. She talked to me about what are the problems we want to solve? Why are we really doing this?
So she said, for instance, online fraud is a terrible tax on society and people and corporations. If we can reduce that a little bit using digital credentials, we've made a positive impact in the world. So she pointed out the verifier is not the end of the journey. The verified digital credential is an input to a business process to make a decision to do something. And so this is not about the protocols and data formats, even though I love creating those with you. It's about solving problems. In closing, standards are about making choices. As I said to you on this stage about a year ago.
This applies to digital credentials, and interoperability requires that those that are going to participate together make the same choices. So there's no substitute for us sitting down together and making good choices together.
With that, I want to thank the Sears Foundation who brought me here. They're the people behind the WW Wallet, which has been in the funky competition. And there's a number of people here, Stefan and I think Stina, that you can talk to or me about this, John Bradley. Thank you very much.
Well, thank you, Michael, and at least you've managed to attract a few more people into the room. So it's looking much more healthy than that. We're already 1 minute 50 into the red, but just a quick question. Do you see any signs of convergence around any particular standard or model, or will fragmentation just persist for the foreseeable future? I think in the protocol space, it's likely that most parties are going to support the pair of OpenID specs, the OpenID for verifiable credential issuance and OpenID for verifiable presentation.
In the data formats, there's a space in which I think MDOC is already won, and it's not going to get displaced. That said, SDJOT is arguably a little simpler and more aligned with most internet kind of use cases, so I think that's going to live in parallel, but I think we're going to be in a multi-credential format world for a long time.
Okay, great. Thanks for giving the opening for us today, Dr. Michael Jones.
