Hi, I'm David Chadwick. Sorry, I can't be with you in person today to, to answer any of your questions. So please email me afterwards. If you want to ask anything. Thank you. There's no computer science definition for self-sovereign identity, but all the ones that I've come across and read have one thing in common, and that is putting the user in control of his or her digital identity. A number of people have been building SSI and VC systems for a year or two long before. COVID 19 started including, including my group at the university of Kent. But once COVID burst on the scene, then the number of people experimenting with COVID 19 certificates seems to have exploded. The reason is that very far credentials are an excellent basis on which to build COVID 19 certificates. In fact, on any type of certificate, because they've got a really nice set of properties, which are, which are listed here, they are really a fundamental building block of self self-sovereign identity because they put the using control, their identity attributes.
However, the VC data model on its own is not sufficient to build into working SSI systems for the reasons given here for a start, no protocols have been standardized, which is why we're currently looking at integrating very fabric credentials with ID connect. But until most of the above, our standardized or resolved, we won't see global sector of SSI or VC VCs. So what is the VC SSI model? This is taken from the W3C standard and it shows there are three roles involved in the system. There's the VC issuer, which issues VCs to holders. There's the VC holder, which holds VCs in its wallet. And there's a VC Verifi, which VCs. And importantly, you will see the holder is the center of the ecosystem. It's in control. It decides which VCs it will pick up and hold and it decides which verifiers it will give them to.
Typically in any system there'll be odds and magnitude, more verifiers than issuers. For example, with credit cards, for a lot more places will accept credit cards than issue credit cards. Now at the bottom of the diagram, you'll see the verifiable data registry. This is where all the meta information is stored. It's important that all the system components have a same understanding of how the system operates. So all the system components have to have this meta information configured into them so that they can operate correctly. I'll say more about the very far data registry later note, what the w three C standard says about DDS. They are not needed. It's important to bear it in mind. They are not needed. However, when you read a lot of the SSI literature, you would wrongly believe that decentralized identifiers and a blockchain are absolutely mandatory for building an SSI infrastructure, but this is not true.
DDS and blockchain are not mandatory. They are one way of building an SSI infrastructure, but they're not the only way. And I, I believe actually, they're not the best way when you take into account all the nonfunctional requirements that are listed above such as total cost of ownership, ease of integration into existing infrastructures, user acceptance, etcetera. So how do we get to believing that D IDs and blockchains were mandatory for building SSI here in my hypothesis for this, I might be wrong, but anyway, they're my best guesses at why we many people believe they're mandatory. First of all, confusion between identifiers and identity. I've come across this a lot in my academic career. And it is quite prevalent. I desire to escape centralized allocation IDs. Yep. Christopher Allen. Who's one of the chief architects of SSIS has said, this is one of his, his objectives misunderstanding.
Yeah. I think this is also true. And I'll show you where, where I think that's the case disillusionment with PKI. Yeah. I'm sure we've all been disillusioned with PKI at some point in time in our careers, blockchain PUA. Well, I'll leave you to be the judge of that one before trying to disentangle, identify from identity. Let's briefly look at what is identity. Now, this is a massively complex subject. So this is necessarily a simplification, but identity is a whole lot of personal information that describes you or characterizes you. And vast majority of it is actually created by other issuers or other people, organizations about you. And then you decide which bits of your identity want to release to other, other people or other entities. So my mom would know a bit about me and the bank would know a bit about me. And when I buy something online that I'd know a bit more about me, but these recipients of my identity, none of them know all about me because I keep that under my control.
So to summarize identity is set of identity attributes, mostly signed by others, but you can solve a certain some yourself with the receiver, trust you to do that. And if you wanna read more about this, then I've written more about it in the very credentials lifecycle document, which you can download from the do three C website, the URLs there, many people confuse identify with identity because in original computer systems, they were the same. Your logging ID was your identifying. It was your identity, but in more sophisticated systems that we have to do, they're not equal. An identifier is a special identity attribute that uniquely identifies the user from all of the users and all issuers create identifiers. They have to, because these are the primary keys in their database, which allow them to determine, differentiate one user from the other. But just because an issuer has an identifier for you in its database, doesn't mean that it has to be released to you in SSI.
So whilst every identity issuer creates identifiers for its own convenience, it doesn't necessarily have to make them available to you. Some systems actually allow you to participate in the creation of the, the identifiers for you. For example, in DNS names and email addresses, you actually create the last component yourself. Finally, users can create their own globally unique identifiers in a distributed manner. For example, when users create their asymmetric key pairs for PKI, then they're all independently creating their own unique identifiers. When some identity providers issue physical identity, token, and such as certificates or ID cards, they may put their centralized identifier on the token, but this is really for their own convenience so that they can actually check in the database that this is a correct a correct, and not a fraudulent token, but it really serves no other purpose, not for the user and not for verifiers that are not linked to the issuer in the physical world.
The user must reveal the identifier and all the identity attributes to the verifier. There's no choice. They're all there. And he has to present them all. But in the virtual world, we've got selective disclosure. So the identifier doesn't need to be revealed. It will only be revealed if the verifier needs it. And under GDPR, this means it must be essential for the transaction. If it's not needed, it won't be revealed. So it will stay back in the issues database and, and not be visible. As this example shows here, it's not there. The only thing the verifier needs to know in the ver in the virtual world is were these attributes issued by the trusted issuer and do they belong to the person who was presenting them to me by own admission? The DDS ideology is to actually get rid of centralized identifiers and to replace them with distributed identifiers.
That's their objective. And Christopher says, this is because of the identifier problem. These centralized identifiers don't belong to us. They can be taken from us and he sees them as our identifiers. But I think this misses the point. They're not actually our identifiers. They are the issuers identifiers, and he need, he needs them in order to differentiate one user from the other. They're the unique keys into their database. So they're not going to get rid of them. They, they actually have to have them for their system to operate. Furthermore, if you don't actually have a driving license, you don't need a driving license number. If you haven't got a passport, you don't need a passport number. If you don't have a telephone, you don't need a telephone number, et cetera. So these centralized numbers are only, only needed. Anyway, if we actually have the service that the issuer is providing, and then more importantly, in the virtual world with selective disclosure, there's no need for these identifiers to even leave the issuer's database unless the recipient needs it.
For example, it's an email address and it needs it to send email to us. So there isn't actually an identify a problem. However, there is a problem with DDS because DDS of persistent, globally unique handles stored on a blockchain that will always uniquely identify you when you alone. So it actually reduces your privacy protection. So this is a, this is a problem. And it's previously shown there's no need for any additional identifiers to be sent along with your identity attributes. The identity attributes on their own are to identify you. And if they, if they need to contain unique identifiers, because recipient requires them, then they can be included along with your identity attributes in Chris, VA's famous seminal work, the path of self-sovereign identity. He specifically, AITs the word identifier for simplicity says and merges the two terms, identifier, and identity into identity. Now this actually leads to confusion.
As I'll show you in the next slide I've written to Chris and said, look, I think it'd be a good idea to update your principles, to separate out identifiers from identity. Here's simple example of why conflating two similar, but different terms together and making statements that are true about one or the other. And combining them clearly, we shouldn't do this. If we want to avoid ambiguity or misunderstanding this, this is why I'm suggesting that the principles of self-sovereign identity ought to be clarified and updated. I think we've probably all been disillusioned with X 5 0 9 and CAS and the PKI infrastructure. At some point in our careers that wouldn't be unusual, but new techniques like RCSP, Stalin and Google certificate transparency are helping a lot to make them more trustworthy. If we go back 20 years, you will see that PKI was the savior of the world. Just like blockchain. Today is the savior of the world. We really we'll need to go 20 years into the future to see how blockchain reality compares to blockchain promise. But unfortunately, we can't do that. However, what we can say is that blockchain has already failed its promise of being unhackable. As there have been many hacks in the last couple of years,
Blockchains may actually be useful for SSI for starting the meta information. And here's a list of all the meta information that could potentially be stored in a blockchain. So let's look at each of these piece ofme information one by one
At context definitions. Well, these are already published on web pages, so there's no need for blockchain for those, the public keys of issuers and the identity attributes that they issue. Well, these are actually the trust store for the fires. So they must be configured out of band because no is going to trust every conceivable VC issuer on the blockchain to issue every attribute that's specified there. So this have to be configured out of band into the, into the verifiers V BC schemers. These should be configured in twin systems as well because you can't have, can't have a system accepting attributes and terms of use that it's got no knowledge about
Finally certificate transparency. Some people have said we should, every, every issuer should publish the, the idea of the VC that it's published on the blockchain. So everybody knows that it's there, but Google already does this for public key certificates. It doesn't need a blockchain. So there's no requirement for that to beyond the blockchain and finally revocation information. Yet that's also been proposed for blockchain, but there's a, a new work item in the CC working group to be AOR and source code for compress revocation list. One bit per verifiable credential that again, won't be published on a blockchain. So whilst the blockchain could be used for meta information, there's no requirement to use it. And in fact, all the pieces of meta information that are needed can actually be handled without using a blockchain. So now we come to the, to the real meat of the presentation, how do we build self-sovereign identity infrastructure without using D IDs and blockchains, the two components that are needed in this there's the VC issuing sub-component and there's the VC verifying sub-component and the user or holder is part of both components.
And is the link between the two first thing user must do is register with each of his VC issuers. And during that registration phase is going to establish a feeder two authentication with each issuer, and that's going to generate key pairs, one key pair for each issuer, and they're gonna be stored in the devices, hardware or in a portable feed, two key store. So this prevents the user's keys from being stolen or hacked. Now that the user has actually got an established link with his issuers, the user can authenticate to the issuer any point in time in the future, by simply signing a challenge with the private key that he's got. And so the, the user is able to get verifiable credentials, freshly minted on demand with just the attributes that the verifier wants. So thereby providing selective disclosure and the issuer stores, the Fidos public key along with the other identity attributes index by centralized identifier. And of course that centralized identifier will never need to be released unless the verifier specifically needs it.
So suppose now the, the user wants to access some protected resource of a very fire stroke line party. Well, the user contacts, the fire theier sends its policy to the user telling it which VCs it wants containing which attributes from which trusted insurers and the user agent now creates a transient key pair for this transaction. So it can prove possession of the verifiable credentials. He contacts each of his issuers with strong authentication, via feed or two. And the issue mitts fresh, short lived, selectively disclosed VCs and attaches it to the transient public key, returns it to the user. The user then collects all the VCs together, signs them into a verifiable presentation with the private key and sends it to the RP. When the, when the verifier receives the VP, it checks the signature on the VP. And that shows that the user possesses the private key and the corresponding public key, the public keys embedded in the VCs, which have been signed by the trusted issuers.
So the verify can see that all the VCs belong to the user and none the IDs are needed and no blockchain is needed. This is a diagram of the verifiable credentials application, independent middleware that we've built based on the D three C feeder, two web authentication standard and w three C verifiable credential data model standard. And it shows the three APIs that we've defined for interfacing with the application layer. Proof of Putin is obviously in the eating. Does this work? The answer is yes, it does work. You can see a video of it. We were actually the first people in the world to create a COVID 19 certificate demonstrator because we built it on our existing, very far credential infrastructure in just a few days. And we published it at the beginning of April this year. So thank you for listening. If you want to ask me any questions, I left my email address on the first slide. So please feel free to email me anytime. Thank you.
