Implementing SSI using the existing web infrastructure

Okay. Right. Good. So what is SSI?

I mean, let's clear that up for a start off. This was the definition from drum and Read's book on self-sovereign identity. A personal identity is near dependent or subject to any other prostate.

Well, that's nonsense, isn't it? No, man is an island. Actually I can say sponsor cause I've edited the, the chapter on very Farion in the book.

So I am, you know, author, author in the book, basically what, my definition, which is won't come up. But anyway, basically it's saying a person is in control. That is the definition that a person is in control. You have to rely on other people. You cannot, you're not an island. Now when we take the very far credential standard and we look at what is actually standardized today, it is only a data model.

If we compare that with other standards like open ID connect X 500 LD app, cetera, you'll see they've, they've standardized a whole bunch of things and these other things are not yet standardized. And so the answer is how can we implement SSI and verifiable credentials? When most things are not standardized? Do we wanna throw away what we've got or do we want to actually use existing infrastructure and try and do all these other things? Schema S cryptography, etc. Using existing standards. And so that's what I'm gonna go through today with you.

So let's look at the very far credentials, architecture. People are very famili familiar with this. This is taken from the W3C very far credential data model of which I'm a co-author. And you can see at the bottom, there's a very far data registry. That data registry is the things that holds the schemers and the keys so that everybody's got a common understanding. They understand what the numbers mean and they understand what the schemes are, et cetera, that verify data registry is important, but how it's implemented is not stated in the standard.

Now again, if you look at the, the drum res book, it says, you must implement this over decentralized identifiers in the public blockchain. That is again, fake news. That is not true.

In fact, if you actually look at the details of the standard, it says DDS are not necessary. Verifi credentials, specifically Verifi verify potentials do not depend on DDS. And the IDs depend on verify potentials. So we don't actually need DDS. We can use existings in fact, it's that are needed in the standard. So what other requirements for verifiable data registry, we need to publish metadata about the signing keys, the schemes, etcetera. We could use a blockchain and DLT as, as is suggested in, in, in drum Re's book, or we can use existing infrastructure. We can use the world.

Do I web the DNS X five and nine PPI? We could even use email. We could actually email. If we got a very small Federation, we could actually use email to, to, to share the information between between ourselves. That's what we can use. Okay. Now publishing metadata and keys. There's already well established mechanism by author, an open ID connect using well known registries and the, and you'll find the well known registers. So why don't we use the, the well known registry of I a for publishing all our verifiable credential metadata.

And that's what, that's what I'm recommending that we use the well known me mechanism of I a to publish this information. Now what about protocols? Evolution or revolution? Evolution will be to use open ID connect, which has been enhanced for, for very far credentials. There's a white paper out today, which has just been announced, which I do suggest you read because it's a very good, informative background document telling you how open ID connect has been enhanced for very far credentials. It comprises three different standards.

Open ID connect for very far presentations, C up version two and open ID connect for very far credential issuing. And how successful is OPN ID connect. It's very successful. So it makes sense. Does it not to actually take what's very successful and evolve that to SSI rather than going for something revolution like did come did come is really SMI and Jason with onion rootin. It's not even a complete solution. You need to build protocols on top of DICOM message structure. And I ask you how successful has SMI been. It's not been successful. So I don't think DICOM is going to be successful either.

Now what about cryptography and privacy protection? We're gonna go standardized algorithms or non-standardized algorithms. Standardized algorithms will be things that are based on elliptic curves or our RSN standard asymmetric crypto approved by governments, standardized and internet RFCs, et cetera. That's what we should be using. And you can do selective disclosure with standardized algorithms. You can do selective disclosure by issuing credentials on demand with just the credentials you want in them.

You can issue atomic credentials and then combine them in the, in the way that the relying party wants. Or you can use hash values, which is specified in the ISO mobile, mobile driving license standard. So we can use standard crypto and we don't have to throw away selective disclosure, or we can go for nonstandard crypto, like the combination loans, the anonymous credentials or BBS plus, and then selected disclosure feature of the algorithm. But then it's not approved by governments and it's nonstandard. What about the policy query language?

How does the relying party request specific VCs with selective disclosure from, from the users wallet? Well, this, if presentation exchange V one was specified far too complex, it actually tried to be all things to old people to allow everybody to specify anything. And you know, it just wasn't gonna be implemented. It was too complex. So we started to simplify it with using the Preto principle. You can get 80% of the functionality for 20% of the effort. And now we've got that in diff presentation exchange V two, we've got basic requests with optional additional parameters.

It's still not quite as simple as I think it could be, but it's there, but there's as an alternative as well, which is w three C have got a very valid presentation request specification, which is even simpler. So there are two competing ones there, but open ID connect has gone for the diff presentation exchange V two. Now what about trust? Trust is an important thing. A lot of speakers this week have been talking about trust. There's a lot of research being done on trust, which is not from technical people like us. It's from economists, it's from social scientists and the conclusion.

I've got a couple of papers there that I've referenced on it. The conclusions is that trust is essential and dispensable to most popular businesses. Trust reduces the cost of doing business. And it's the fundamental component of the SSI model is trust. Now what people say use blockchain use DLTs well DLTs if you look at them, they're typically used by parts that do not trust each other. That's the whole point of having a DLT. You don't trust the other person. So you want to copy yourself to add a layer of trust.

Now, swift looked at using DLTs and they reported that it doesn't even provide a level of trust that we need. So my conclusion is blockchain DLTs. They increase the cost of doing business by assuming no trust between parties, and then they don't even provide sufficient trust. And so they are the opposite of what SSI needs. So how is trust to be made scalable, the thousands of issuers and millions of Markies there's the man with no name? Who the hell is this man with no name? How do we know it?

Well, we can't rely on him to tell his own name. Can we, we have to have a third party. It's impossible for two strangers to reliably identify either. It's just a fact. You need a trusted third party. So sorry.

The, the, the trusted third party is needed. Now in the very far credential model, they've already built this in the issuer is the trusted third party. So with the basic Verifi potential model, we've already got our trusted third party issuer. And that will tell the aligned party who the user is.

However, that's not scalable. That's only, it's only use where you can actually list the, the list of trusted issuers in your aligned party. We need something that's more scalable. Several things have been suggested. One's a permission, blockchain. Another is trust lists for federations. And then the other one is trust chains from our IDs for Federation draft. So there's several ways. And there's also been talk about the gain work, which is again, is trying to scale trust.

So this is not a resolved issue at the moment, but there are some, there are some working solutions based on existing existing technologies that we can use. So about a permission bot chain, this has been provided by sovereign named ripple review, et cetera.

Now, if you look at, look at what it is, it's actually very similar to the cab forum, defining rules for X five or nine CAS and browsers. It's just saying, you know, the cab forum says, if you want to put your route CA key in the browser, you've gotta follow these rules. The government authority says, if you wanna put your information on our blockchain, you've gotta follow these rules. So it's really not much different to the way the cab form operates. Also the knowledge of government authority has gotta be built into the VC wallet.

So it knows which blockchains the trust, just like a browser builds in the route, the route PKI certificates. So it's very similar to that, but it lacks usability because the systems I've used, the wallet has got to choose the blockchain to use, which makes the system really unusable.

In my, my opinion. Now it's a trustless on the other hand are already widely in use throughout Europe. They provide the, the name of the, the issuer and the scheme, cetera and list of trust service providers and the EU lists a list of lists, and then the countries list their lists. So this European standard already has good interoperability. And in ESV two, it's been extended to, to put our attribute providers in there. So to my mind, this, this must be the way we go an existing infrastructures. And we actually worked on a project within the SSF lab. It was called the train.

It was run by FN Hoffer, and they specified how you can use actually trustless and store information about the trustless in the DNS by adding pointer records in the DNS. I'm not, I haven't got time to go into this in details today, but I can give you more information about it.

Offline, also written a paper which is going be presented at conference in July, describing in detail about how you can use exit trust list in the DNS. But this is a simple example that shows in the DNS there'll be entries that the trust scheme operate to provide. It will point to the trust list. The trust list will be exit trustless held on the web, and we pointed to by URR record in your DNS. And in that way, we can use the DNS and trustless to actually scale our trust. So that's a very quick cut lightning tour. And I now open the floor to questions.