The Worldviews behind Digital Identity Standards

Thank you, I think you already saw my cover slide in the previous talk. And so, this is going to be a bit of a continuation of something that Ned Sakimura and I did last time, last year I see. Ned Sakimura, he had written an article called The Fallacy of Decentralization, where he explored different aspects of centralization and decentralization in different technologies and argued that some things are not always as decentralized as they seem. And then based on that, at EIC last year, we had a conversation about the worldviews and values that are sometimes built into digital identity standards.

And then we specifically referenced the terms liberty, equality, fraternity, so the values of the French Revolution, which have then influenced the European era of enlightenment and European societies. And last year in our conversation, we found it useful or interesting to relate these terms and these worldviews and these values to digital identity standards. And there are many standards now, right? So if we're talking about digital wallets and UDI and verifiable credentials and things like that, there are a lot of technical choices.

And one thing I find interesting to explore is not just what are the actual features and the technical pros and cons of these things, but what are the values that you sometimes find behind different technical choices in digital identity standards. I'll do a few examples. So one thing we need when we build a wallet is a way of exchanging verifiable credentials, right? We have an issue, we have a holder, a verifier, and then the community, different organizations, there are different ways of doing that. There are different technical standards.

For example, you could build this either with the OID4VC stack, which is very popular and very successful, or you could build this with a protocol called DitCom. And don't worry, I'm not going to go too much into technical details, but you can use both for issuing and verifying credentials and for exchanging credentials between wallets. If you do it with OID4VC, it kind of looks like this, right, you have a resource server, you have clients, you have authorization servers, the traditional roles in OID, and this is a very mature, very successful protocol, right?

So you can build wallet communication, verifiable credential communication with this protocol. You could also build it with DitCom, which is a less well-known protocol, but it theoretically allows the same things. It allows an issuer to issue a verifiable credential to a holder, and the holder to present it to a verifier. Now what are the differences, right? You can argue for a long time about the technical pros and cons, about the features that you have in OID4VC, the features that you have in DitCom.

For example, a lot of people would say that let's use OID4VC because it's very mature, it's very successful, it's well understood, it's easy to integrate with what we have already, whereas other people would say let's use DitCom because it's a more general purpose protocol, right? And you can argue about the technical pros and cons for a long time, but if you just look at the picture, at the concepts behind the two choices, I would argue that in the bottom case, you have a lot of asymmetry, right?

You have a server, you have a client, whereas in the top choice, DitCom, you have peers that talk to each other. And so I would argue that you have this symmetry in one protocol and you have asymmetry in the other protocol, and in one of the protocols, DitCom, you also have a concept of ongoing relationships. It's not just request and response pattern, but it's a way of establishing peer-to-peer connections between participants. So the value that I see in one of them is that of fraternity, right?

Brotherhood, or being brothers and sisters and being connected on an equal basis rather than a client-server philosophy that you have in the other protocol. Sorry if this is a bit controversial, maybe, but I find it interesting to apply these values to the technical choices. Let's look at another one. Let's look at credential formats, right? If we build digital identity wallets with peers and driver's licenses and digital diplomas and things like that, we need a data model for expressing what's in the verifiable credential.

Typically, they will all have these fields, right? There's an issuer, there's a type, is this a driver's license, is this a diploma? Then there are some claims, and then there's a proof.

And again, in the community and in different organizations, there are a number of different technologies for building that, right? There's the ISO-MDL standard, there is the W3C verifiable credential data model, there is the SDGOT-VC, there are also other things like ACDC.

And again, you could argue for a while what's the difference, right? The pros and cons of the technologies. If you build this with SDGOT-VC, it will kind of look like this. You have the basic elements, you have a type, you have the claims, you have issuance date, and so on. And whereas if you build this with, let's say, W3C verifiable credential data model, then again, you have, it also looks similar, right? You have the same kind of elements on a high-level basis. You also have an issuer and a type and the claim values, name, date of birth, things like that.

And again, if we compare that, and there have been a lot of discussions about this, in different communities, we could again try to argue what's the difference, what are the technical pros and cons. And a lot of people would say, for example, in one of the choices, the W3C verifiable credential data model, you have something like a graph, a semantic graph. It's relatively complex, there's something called a context that's hard to understand, hard to implement.

On the other hand, you have, if you use SDGOT-VC, which is based on JSON web tokens, are again a very widely deployed, very mature, well-understood technology. It's just a simple JSON, right? And so in our communities and working groups, we have a lot of discussions like this. What are the pros and cons of these technologies?

But if we look a little bit behind that, at the values and the assumptions and the views of the world, then one difference between the two, and again, I apologize if that's controversial, but one difference is that in the top example, you have something called an open world data model, which is built into this standard called JSON-LD. And what that means is that the meaning of the data in the credentials can come from different places, right? The semantics, the definitions, what does it mean to have a name? What does it mean to be a member of a family or to work for a company?

What does it mean to have a certain religion? And these kinds of claims. So I'm not talking about the values, but about the definitions of the terms, of the attributes. And so in the top example, you have this open world model where anyone can define the meaning of what goes into the credential, whereas in the bottom example, with SDGOTVC, which is based on JSON Web Tokens, you traditionally have more centralized registries where you register the meaning of certain attributes.

And I would argue that the top one, because you have the freedom to define meaning in more flexible ways, satisfies the value of liberty, right, in these three values, more than the other one, because you're more decentralized, more free in defining the meaning of what we express about subjects. Final example, in verifiable credentials, we also need a way to have identifiers and public keys, right, this includes something like holder binding.

So we basically need to know what are the public keys of the issuer, we need to know that in order to be able to verify signatures, and we need to model keys also of the holder, who the verifiable credential is about. When it's being presented, right, so the verifiable credentials are often bound to a holder so that you cannot transfer it to someone else. So you need keys, right, you need to identify and have associated public keys for the issuer and the subject and also for verifiers.

And again, there are two ways of doing that that are being sometimes emotionally discussed in different communities. You can do that with decentralized identifiers, so you can do that without decentralized identifiers, which is a W3C standard, and you can accomplish it, the same thing, no matter which choice you have here. If you do it with dits, it looks something like this, where you have a dit for an issuer and a dit for a subject of a verifiable credential.

And if you do that without dits, then it looks something like this, where you have a credential with an issuer that uses something called short VC issuer metadata, right, it's a technical construct that allows the retrieval of a public key from a web server. And in the case of the subject, you have a public key embedded in the verifiable credential.

And again, when we compare that, it's kind of the same thing. In both cases, you can fulfill the requirements. In both cases, you can look up the public keys and establish the public keys for issuers and holders to make all the protocols work and to be able to verify proofs and to do holder binding and things like that. And you can, again, argue what's better on a technical perspective, right?

Some voices that we are hearing in different working groups and mailing lists is that, actually, usually what I hear in this discussion, if dits should be used or dits should not be used, is that it doesn't really matter, right? So a lot of conversations say, it's just a different encoding, it's just a different way of expressing the same thing, where the public keys come from and how they are managed.

But again, I would argue that the values, the assumptions, the worldviews in these two options are a bit different, because a decentralized identifier is more than just an encoded public key, right? The encoded public key is the technical part, but the worldview, the concept behind it, is that of an independent existence, an independent identifier that's controlled by an individual. This goes back a little bit to the self-sovereign identity philosophy, having an independent existence.

And also, if you look at this, you again have the symmetry in one of the choices, and you don't have the symmetry in the other choice, right? If you use dits, it's also very easy to replace the roles, right? It's easy for a holder to become an issuer or to become a verifier, which I think in the alternative is not so easy. So I would argue that here you have more of the egalitate, the equality, the egalitarian relationships, if the way how individuals and organizations and governments are identified in a symmetrical way. I said this would be a bit controversial.

I'll say a few more controversial things in the last few years when we heard about these different technical standards and sometimes competing technical standards and choices between data formats and protocols. Sometimes what we're hearing simple is a feature, right? I believe some people are here with the T-shirts, and I agree with that statement, right?

Simple is good to have simple protocols, but it's not always maybe the most desirable property if it comes with trade-offs and if picking the simplest technical standard with the consequence of them losing certain concepts, losing certain values like the symmetry, the egalitarian relationships, and so on. I looked up presenting overly simple solutions to complex problems. That's what you call a populism, right?

I feel like sometimes in working group discussions when we say, let's just take the simplest option that just works, but we forget all the consequences, then there may be a form of populism that we also see in politics sometimes. Another thing we hear at the last EAC, we were told standards are about making choices, especially making choices that don't matter, and I agree with that too, right? If we're standardizing the form of a USB charger or the measures of a screw, then we make technical choices for interoperability, but sometimes choices do matter, right?

And sometimes choices in technical standards are not only technical and about technical features, but sometimes they have these implications like symmetry, decentralization, egalitarian relationships, open world, data model, and so on. A friend of mine, I remember a friend of mine a few years ago in the context of decentralized social networking said that using more decentralized, more self-sovereign identity technologies is a bit like cooking healthy food and eating healthy, so he had this food metaphor, whereas using Facebook is like going to McDonald's, right?

So he did this metaphor, and it's maybe not the most controversial thing that I'm saying today, but when I implement, let's say, the UDI architecture reference framework, I read those specifications and start implementing that, it feels a little bit like eating at the McDonald's of digital identity standards because those tend to be the simpler solutions that make certain trade-offs that we may not always consider sufficiently. So to conclude, I think all the standards efforts in this community are great. I'm a great fan of the UDI wallet and the different implementations.

I especially like the German initiative, right? The Sprint is an amazing community with its openness and transparency, and the standards that are being built are all amazing and making good progress. I would only ask that we keep in mind that there's a bit more than just PIDs and driver's licenses, right? Digital identity has always been about asking a bit the question of how does real human identity work in the digital world?

And we need to keep this in mind when we select the standards, not only look at the technical pros and cons, but also the values behind that, to keep in mind that technology is not neutral. And that's it, thank you very much. Thank you. Thanks so much, Marcus, and I really like your final quote that technology is not a neutral. With so many competing technical standards rooted in different ideologies that you've been talking about, are we moving towards innovation through diversity or towards dangerous fragmentation? Unfortunately, I would rather see the latter option.

If we look at ARF and UDI Wallet, we see that two different formats for verified credentials are going to be mandatory. Most likely you have the ISO and then you have the other verified credential standard. I think there's no real technical justification for that. I think it's a failure on the political and business levels to some extent to have this fragmentation. And I think it's not a good thing.

Great, thanks so much for joining us and giving us your perspectives. Everyone, Marcus Sabodello. Thank you.