So, where are we Kent? So that's the, that's the picture of where Kent is in the UK. You can see it's very close to Europe. It's only a very short distance from Cali and the paddock. And we are actually a very European looking university. We were actually called the UK's European university and said, don't blame us for Brexit because our town and our universe, we all, we all voted to stay. But unfortunately we were in a minority overall. So what's the challenge. COVID hit Ken particularly badly.
I don't know whether it's because it's the, where a lot of people influx from and they come by boat cetera, and they brought the virus in with them. I don't know, but, but we've been hit particularly badly. And we were the fourth highest in the UK for care home deaths with, with a very high number of, of deaths and care, 425 people died in Kent care homes and one care home that I've been talking to lost 50% of its residents due to COVID 19.
And, and the reason for this is that people were being discharged from hospital into care homes, without any testing done on them. And then they brought the COVID virus into the care homes, where there were many old and vulnerable people.
So the, the testing Kent, and in fact, in the whole country, the NHS was asked to get testing, running and working as soon as possible. And the COVID test database that was built in east Kent was built in little more than a day because everything was really rushed. And all it does essentially is stores the user's mobile phone number, and then the test result. And then they send an SMS message back to the patient to say, this is your result. So the whole database is test centered, not user centered. So if the user has a test a month later, it'd be completely different record in the database.
There'll be no knowledge that this user had a test a month ago. And he's had a different test today. This is actually a picture of the test center at my local hospital, where you're driving and you get, you get a swab done on your throat and, and then you get the results sent.
And, and this is actually my, my wife had to go for test, and this is actually the results that came through on the mobile phone. And she had to click on the URL. And then she, she got a page which said that you can see my wife's called Maggie, that she was actually negative. She was very, very fortunate. We weren't, we weren't infected. So that's the situation today now, while that was all going on.
As I said, in my introduction, you're in 2019, we were funded to develop an application, independent verifiable credential infrastructure.
And when COVID struck, I was actually stranded in New Zealand. That's why there's a picture of Hong Kong airport had gone out to New Zealand to give a talk about the, the research we'd done in very far credentials to the OPA group in New Zealand. And when I got there, I was stuck in fact, in New Zealand for three months as it turned out. And so while we were there, we developed this COVID 19 proof of concept, which we thought might help people.
And then when I got back to, well, in fact, while I was still there, I started talking to the medical staff at the university. See if we could turn this into some sort of application demonstrated for them.
And, and the, and the following use case was proposed to us hospital patients being discharged to care home as because there was such a high number of deaths.
They want the patients to be tested and before they go, and we want them to have a COVID 19 certificate to take with them, because today they have a test, but where their test result goes is not always immediately obvious. And when they go to the care home, when the patient might turn up, they say they have to phone up the hospital or get an email or discharge that or something.
And sometimes they won't accept patients because they don't have the, the knowledge about, about their COVID status. So we hope that if they have a COVID certificate to take with them, when they go, then the care home will be able to prove that their, their COVID status and, and act accordingly. So this is a picture of our application, independent, very far credentials, middleware that, that we developed at the university. So I'll explain the components to you here.
We have a VC issuer. This is the software that issues very far credentials.
There could be an age credential, a right to work degree credential or whatever address. And they are transferred to the holder in his wallet. And then the, the holder will construct them into a, into a verifiable presentation when asked by a relying party over here, and the verifiable credentials will go in a actual verifiable presentation over at the application layer to the verify. And the verify will then call our API and pass the verifiable presentation presentation to it. And it will verify the crypto.
And it will, it will say that this, this user satisfies your policy for access to your resource. And these are the attributes that, that we've verified from the, from the issuers.
Now, the interesting thing in this, this infrastructure is that this link here, we establish with Fido with Fido too, so that when the user registers now look at registration in a minute.
When the user registers a feed, key pair is established along this link, and this allows the user at any time to go back to the issue and get the very latest copy of his verifiable credential and what he holds in his, his app when he doesn't need a credential is what we call a skeleton. It's got the skeleton contents, but it's not actually very far credential. The very far credential is created on demand.
Whenever, whenever a verifier wants one, and we have an API that we've published, we've published our APIs in the W3C credential group. This issue in API is designed to connect to an L app or any other corporate directory service that contains the, the details of the people. So if it's, if it's, for example, the vehicle and driving license authority they'll have details of the cars and the owners.
And so we, we can then pick it up to this API to produce a very far credential about it.
So if it's a local council, it might have your name and address and your council tax details.
Etcetera, if it's a university, we'll have your degree degree awarded under the details already done database. So we've got a nice API that picks it up in Jason gives it to our issuer, which then packages it up as a standard very far credential. So it's quite unique as our cause it doesn't use blockchain's or persistent DDS. Instead it uses Fido two, as I've said to authenticate, and then it issues shortly irrevocable VCs at the time they're needed.
So in other words, it's operating similar to Sam O IDC rather next five or nine and VC blockchain systems, which are long lived, and revocable has a short lived and irrevocable at Sam O IDC. What are the advantage of this?
Well, the advantage user consent, the user, when the user registers, we're getting to consent to the attributes that potentially can be issued so that the, the issuer knows that the user has consented to these attributes been released in verifiable credentials.
So we, now, we now make it very easy for an issuer to comply to GDPR, because it will only issue attributes in verifiable credentials that the user has, has consented to and selected disclosures automatic because the, the verifier says which identity attributes it needs.
And the issue only puts those that are needed inside the very far credential and the user agrees to this and sees it. So again, it's very easy for the verify to conform to GDPR because he can publish his policy. He can say, this is my policy for which attributes I need not to perform this transaction. And then you'd say, yeah, that's totally GDR compliant.
And then on he'll only ever get those, those attributes in the very far credential and no complex, possibly privacy leak revocation with he either no usernames and passwords are needed after the initial authentication, because from then onwards, we use feed or two to talk between the users device and the issuer.
So now we're looking at how do we go about integrating the two systems?
Well, there's clearly gonna, the registration stage is gonna have to be some sort of authentication where the user puts in some sort of private details to authenticate to the test center. And then what comes back.
This is a, the laptop version. What comes back are all the details of the COVID 19 certificate that will, that will be potentially available to him. So he has to consent to these and you notice he can select all of them or individual ones. So for example, if I decide that I don't want my address, whoever ever appear on my COVID 19 certificates, I will not tick address. And then on all that will ever be published will be by my date of birth and name and my certificate details.
The certificate details themselves, that the consultant in charges said he wants three possible values to go in there, whether he's developed any or he or she has developed any antibodies.
And the only response that positive or negative, whether the patient is currently positive to the virus or not, and that we positive or negative, and whether the person's been vaccinated or not. So we're already planning for vaccination certificates because we know that vaccines are going to be available later this year and possibly open to the public next year.
So we we'll be able to publish vaccinated certificates, which say that the person has been vaccinated. This is the, the iPhone mobile phone view where the, the certificate skeleton comes through and the user can tick and accept all the different parts of the certificate that he's prepared to accept. And then you can see at the end, he consents to them being to being released to him.
Now, when it comes to presenting, he will go to a, a website that wants, wants some very credential in order to access it.
And in this case, we, we draw mockup of Nightingale hospital for someone who might want to work on the, on the critical care ward. And in order to work on the critical care ward, you need to show that you are COVID immune or you've been vaccinated, or you're not, you're not, obviously you're not obviously infected at the moment.
So the, when he clicks on submit certificate, what our system does is it authenticates the user to, to the, to the issuer gets, gets the certificate details that the hospital has asked for and then says to the user, choose which ones you want to present. Now, in this case, there's only one. So he is only got one choice to make. And when he makes that choice, it displays the attributes that the hospital has asked for. And this will be a subset of the ones that he previously said are okay.
And when he's happy with that, he can submit it.
And the, and the hospital will get those details. Now what's the disadvantages of this system.
Well, users have got to have electronic device and mobile phone or a PC or something. And most people entering care homes don't have either and some may have dementia, so they can even read our right English properly and some may be foreign cetera. So how can we make our system that works for laptops and works for mobile phones? How can we make it all inclusive?
So our proposal is that we'll create paper based certificates, containing the details along with the QR code, which will have the cryptographically protected VC in it, and a pictorial representation for those who cannot read or write English. So if they've got a paper certificate with a, a symbol or some on they know, and they're asked to present it, they'll be able to present the right one because each certificate will have a different picture on it and they'll know which one is wanted.
And then an optional portrait picture of the patient as well, which you'll look at in a minute and the whole can be printed out. So there's no expensive equipment needed by issuers. They just need a, a laser printer and they can print out these certificates and give them the, the complexity is all in the verifiable credential infrastructure, which will validate the context and the cryptography. And tell the verify that this certificate is, is, is, is correct. It's not fraudulent and it's not been revoked. So this is a proposed paper certificate example.
You can see here, we've got some sort of picture, which the user will recognize as well. This is my COVID certificate. We've then got the details with the QR code that which will actually validate the cryptography on it. And now we've got also a picture of me with another QR code. Now why we've got these separate, the idea is that this is a sort of mini selected disclosure.
So the user can, can decide to disclose just the, just the written details or to disclose the picture as well.
And, and they would be separate. You, you would, you would have to allow the recipient to scan both QR codes in order to validate the, the picture of yourself. So what are the tradeoffs, the cost for tradeoffs? When we go down here, we've got privacy versus all inclusivity. Paper is all inclusive. Everybody can have it, but it doesn't easily allow selected disclosure. So what we've done in our mockup is we've allowed, selected disclosure of, of the main details and of the picture to be a separate, a separate disclosure security. Yeah.
Paper's easily photocopied, long Ling lived and transferable. So there's some loss of security to our electronic version there.
So we, and there's also complexity idea, cuz now we need to build in a revocation infrastructure, et cetera. So there are some tradeoffs there. So what are we still going to do?
Well, we're gonna work with the stakeholders, determine what file design do you want for the paper based certificates and what are these optimal tradeoffs in security, privacy usability, for example, do you want the picture to always be on the credential or not? Is that important to you or not et cetera? So we've gotta do that. So that's where we're at. And I think that's the end of my presentation. Thank you very much.