All righty. Good morning. I'm going to start by saying I agree with the previous speakers.
We shouldn't be talking about digital wallets. It's fundamentally the wrong abstraction
for the development and the standardization layer. It might be good for end users though.
So today I'm going to be talking about verifiable credentials in relation to query and how
we can do zero knowledge over that query. I'm going to start with a bit about myself. So I'm
Jesse Wright. I wear many hats. One of those hats is as a researcher at Oxford where I am working
on Euro Symbolic AI systems and I am trying to build AI agents that faithfully represent human
entities work faithfully with data on your behalf and help you manage your life.
I am also lead of the solid project over at the Open Data Institute, which is a project that
Tim Berners Lee created back in 2014 at MIT to give people back control of their personal data.
So solid is a personal data store solution that allows you to build applications that don't store
data on corporate servers but instead store your personal data in cloud storage such that you
can reuse it as you go across the web. We talk about being able to use digital wallets for things
like sharing your address and proving your address. With solid I have an authoritative source of my
address. So that means that I updated once and my insurance company gets it straight away. My
university gets it straight away. I have authority over my data.
And I have been working on solid in particular for many years. I used to work for Tim's company
in rupt as an enterprise software engineer and data architect over there and solid is already
very heavily involved in the data wallets space. In fact one of the donated open wallet
contributed. Thank you. Came from in rupt. And I work a lot on standards at the moment.
I am in 14 standards bodies through the W3C mainly coming from the semantic web perspective
as is going to become obvious throughout my talk. So what is a wallet? What are we talking about
when we have a digital wallet? My suggestion is that it's a way to prove that someone
said something. Fundamentally that is what we're doing. When I get issued with a credential that has
my driver's license, all that is saying is that a driving authority, the driving authority that
gave you this credential, says that you're accredited to drive. So to me a digital wallet is a way
of saying that someone said something. A generalization of that concept is to say that digital
wallets help supply some evidence to help someone believe something. So when I get my
digital drivers license, that is evidence that I can supply to a car rental company that help them
establish that I am accredited to drive. And this idea has been around forever. We call it
provenance if you've been in semantic web spaces for a while. So if we look at the variable
credentials back from the W3C for instance, there's two core features to it that support this.
The first is signatures. So the signature is the way of having the driving authority prove
that they stated something with their public-private key signatures. And then the other useful
feature that I believe comes from W3C verifiable credentials is this notion of selective disclosure,
which means once I've been issued this digital drivers license, I don't have to tell everyone
everything from it. I can instead just reveal my data birth that's present on this digital
credential. However, only selective disclosure is possible, not derivation of facts. So if it is my
data birth stated in that verifiable credential, I must tell you my birth date. I can't prove that I'm
over 18. I can't prove that I'm a commonwealth citizen. I have to say that I'm Australian.
And that is all the standard support today through these BBS signatures, which I believe the
other group mentioned. So if we look at the use cases where these kind of verifiable credentials
are being used and we want to use them, I put it to you other current standards enough.
So one common use case that we're seeing now is Directs, which is doing a lot of secondary data
reuse in the medical system in places like Luxembourg. But when it comes to health and I'm thinking
about studies that I might want to do, a very naive one might be to get an anonymized data set
that has correlations between ages and BMI as of everyone in a particular country.
Now if I'm doing this for research purposes and I want to publish a study, I want to be sure that
that data is true. I don't want to have to trust some third party to have aggregated it correctly
and then claim to me that they're aggregated it correctly. I actually want proof that all of the
values that I've been given are issued by invalid hospitals throughout the country that I come from.
And what about on-demand data integrity? So I mentioned driving authorities earlier. What if I want
to prove that I'm eligible to hire a car in the country that I've come from? But I only want to
provide that bullying answer. I don't want to tell them anything about my visa status or my driving
credentials in the country that I come from. I don't even want to reveal where I'm born.
Can the current standards make this integration possible so that I can integrate this data and
provide it to a company and can they help make it more privacy preserving?
So this led me to the question of can we support zero knowledge proof over sparkle queries
so that we can base verifiable credential standards around sparkle instead of around fixed
credential structures. Now, as a show of hands, who here has heard of sparkle and knows what the
hell I'm talking about? Okay, half the crowd. Who likes sparkle or somatic web standards?
Ooh, tough crowd. Okay, this is going to be fun. Let's start with why I think
we should be using these kind of standards. So what we've got up here is a set of data in an
emergent RDF standard called RDF 1.2. And what this allows you to do is talk about claims.
So instead of saying that that is my data buff, I'm going to say that the driving authority
claims that my data buff is 6th of April 2000 and instead of just in a database stating that my
citizenship is Australia, I'm going to state that the UK immigration authority claims
that my country is Australia. Now you might be going, well isn't this what the VC standards are
already doing? We have the data in this credential and then we add a signature to it.
One caveat there. Where in there areifiable credential standards at the moment,
actually stating all this data at the top level. So you're saying there's a credential.
Jessie does have this data buff. Jessie does have that citizenship. Oh, and by the way,
here's a signature to prove that. We're not fundamentally modeling the fact that these are all
claims that anyone can make and the data inside those angle brackets is not necessarily ground
truth. That's just stuff claimed by these parties. And then what we want to be able to do is not
have these custom procedures of integrating credentials and deriving proofs. We want to be able
to have standards so that we can write queries like this one. Where I can just ask, is that Jessie's
or is Jessie's data buff over 2006, so I'm over 18, and does he have citizenship of a
commonwealth country? There's a standard to write this. We don't need to write custom business
logic in programming languages of choice. We can do this all in standards.
So I had about half the hands come up for sparkle and idea. So I'm going to very, very quickly
do the breakneck tour of what is a sparkle query. So I'm hoping more of you have interacted
with SQL. But sparkle is just a query language. It's nothing to be scared of that allows you
to query over data on the web in a standardized format. So here we've got a query that's asking
is Rubin. So we're wanting to see all the people that are born in the same place as Rubin
and younger than him. And we're wanting to construct some derived facts that generate the fact
that that person shares the place of birth and is older than. But we're no longer revealing the
data birth and the birth place. And in DBPedia, which is an open data set, there's actually hundreds
of people that share this data birth with, well over what's my mind to say. The share this data
birth was Rubin and younger with him. So we can get this set of query results. And on an open
web of data where I trust that all these facts are true, this works quite well already. Sparkles
being around for decades. But we haven't had ways of talking about facts about facts until now.
And this is where the IDF starry, IDF 1.2 reification that I was talking about comes in.
So now we can talk about statements according to people. So now if we look at that query,
we just tied for Rubin. What we really want to do is say, does is there a way of asserting
that Rubin shares the same birth place as someone and is older than that person,
according to some derived proof. That's what we want to get to.
And moreover, I don't want that just to be any old proof. I want that proof to reveal at most
the fact, uh, reveal at most, which entities stated the ground truth used to derive this fact.
So I want to state that this is true. And all you need to trust is the Belgian government
to get there. Can we do this? Well, when I pitched this talk, I didn't know.
And I can tell you quite confidently the answer now is yes. And remarkably, despite my, I think
someone else here was quite skeptical of blockchain before. Despite that shared skepticism,
they've actually managed to produce in the, the blockchain space, a very useful privacy enhancing
technology, uh, call zero knowledge virtual machines. Risk zero is one of them. It came into major
release, I believe, late last year, but don't quite me on that. And the very naive way you can get
everything I was just talking about working is to take one of these zero knowledge virtual machines,
take a sparkle query engine that's written in rust, and run that inside the zero knowledge
virtual machine. Because this thing can prove correct execution of arbitrary rust code,
and then reveal the outputs of a function. So concretely, uh, if we look at the implementation,
I just need to prove how short the code for this is, and then I'll check the time I've got a few minutes.
72 lines of code. Less than, most of this is just data pipelining, and that's not sharing it because of,
that's eggs of that. There we go. 72 lines of code. Most of it is just converting data and
pausing data. Nothing really interesting happening in here, but we're able to do the zero
knowledge proof, and as I say, 72 lines of code. So that's useful. Um, and it's a very naive approach.
There is one gotcha to this approach, which if we look at the proving time, it did take 62 seconds
to show that I was over 18, which isn't really what we want. Um, so yes, the gotchas, proving time,
secondly, the proof is dependent on this implementation of a query engine, which from a security perspective,
isn't great, because you have to audit the whole query engine. Uh, we can't do standards,
um, uh, based security, uh, audits, and the, uh, modeling of this could be improved, because we've
just chucked an existing query engine in there. We don't have what I was wanting to have at the
start, which is this derived proof as part of a query result. Instead, the derived, the, the, the,
the proof has come outside of the query result. Um, so let's address the 62 seconds first.
Can we make it faster? And I'm going to stop speaking faster, too, because my times running out.
The answer is yes, there's ways of building custom circuits, there's also things like zero
knowledge, uh, theorem proof is where you can implement this, uh, and based on comparisons to other
projects that have implemented in zero knowledge virtual machines, and then in sat solvers,
we can expect a 100 to 1000x speed up, optimistically. So that brings us down to under a second,
perhaps, 200ish nanoseconds, within what's reasonable for a latent, uh, request on the web anyway,
uh, standardization. Yeah. So what we need to do is we need to move from where we've got the zero
knowledge virtual machine, proving stuff over rust code, to instead proving stuff over spark
operations, so that we can have the proof in a standard, a standard manner that can have multiple implementations.
And then the last thing, I had a very small hat, number of hands up when people talked about how much
they love sparkle. I love sparkle. So that is just me. So abstractions are important for both
users and developers, and we can hide most of what I've just been talking about from everyone.
For instance, uh, I'm going to slip that slide. Uh, there's data shape languages like shackle,
where you can define the form of what you want your outcoming credential to be, and just to say,
okay, go to the database, do the queries, get the data, and then just build the credential for me.
And if this is what I want the shape of the credential to look like, this would be a social
security number credential. And that way, you don't have to deal with all the data query layers,
all the provenance and all the stuff that is only fun for people like me.
So where do I want to go from here? Well, this is a very small part of everything I'm doing. So
fundamentally, I'm looking for people also interested in zero knowledge over createable credentials.
If you want to work on the performance optimization or put resourcing into that, please,
if you want to work on the modeling, the data modeling around this, also good. And to ground this
work, I really want to build it out in the context of the Gamma Trust framework in the UK and
IDAS. So if anyone wants to actually build this out in applications, I would love that.
And then in terms of future work. So the other reason I find this all exciting is
with the query engine I just had, you can have some really cool applications come out like
emergent multi-party computation. So we can do things like not revealing my salary to anyone,
but being able to have an aggregate salary of my workplace developed with a proof that that
aggregate salary is true. So we have a lot more privacy enhancing technologies available.
When we turn this infrastructure into multiple query engines and query planning.
And also when we integrate this with things like ODRL, we can start to pull data on demand
in compliance with user consent. We talked about consent before and user data sharing options.
Very nicely. Last thing, someone asked about a reading list before,
that's my recommended reading list. So if you want to take a photo and look that up, go for it
and I'll leave that there while I answer some questions.
Please raise your hand if you have a question, please repeat the question.
Back there, what happened? No, you. Yeah.
And basically, if you have like one of those, then there's also other tools which go for people
that are more festive because of that. So I think that even if you don't like to the blockchain,
you should look at that. Plus one on that. Any other?
Sorry, it was more a comment than a question, but I will repeat it, which was to say that, yes,
the whole zero-knowledge space is a privacy enhancing technology that happens to be used within
blockchain, but is not a blockchain thing in and of itself. And it's used in many other contexts.
The reason I referenced blockchain in my talk is because it is a think of blockchain company
that's developed the zero-knowledge virtual machine that I happen to use. But that's again
just because it's a core technology. They also build tools for caching and web libraries.
I wouldn't, I would use those in the same way. Any other questions?
Maybe a bit of a fragmented question, but if you want to implement this kind of serial knowledge
proof, for example, I want to go into a car in another country. I want to collect the fact that I have a very
Belgian writing license. But I can imagine that in different countries, writing licenses are structured
differently. We have different costs in Belgium, motorcycle, normal car, truck, maybe a different
country doesn't distinguish it. How in this structure that is still allowed, I have a problem with
the structure of the data where different authorities can provide competitive structures for seeing
those in terms of how do we interpret it? There's a few ways to go about it. So my
immediate answer to that is to have the driving authority of each country,
it define in again structured RDF or notation three if you've ever heard of that, which is
less likely, define what the requirements are in a given country for you to be considered a driver
of a class C car or that kind of vehicle. And you can, so that can also be signed. Again,
it's all just about someone proving that statement's a true. So if you have the Australian
government state that a UK class C vehicle is equivalent to an Australian class E vehicle
and publish that and sign that, then you can do the derivations to do that data integration.
I like to live with a slightly amount of optimism. Fair point. But at the end of the day,
you need to trust someone to write the business logic, whether that's an authority, whether that's
a trusted intermediary. So one of the, in the UK with the DVS framework, they're certifying 50 or
so companies as digital verifiers. I see it as quite a valid possibility for those companies to also,
yeah, there's about 50 companies I think that are going to be certified as part of the
Gamma Trust framework. And I see it as quite a valid possibility that those companies are also
trusted for issuing data about how to align certain schemas and how to do that kind of data
integration because they are already trusted within this framework. Any other questions?
Yeah, one thing, the first of the thing that for very interesting talk here is, I've
doubt find it very interesting, but how do you assure that the organizations that hold the data
system have the data system that they put in limitations on what type of first that is allowed
to take out knowledge from the data system that you would otherwise try to find.
For instance, I want to know all people in this data set that is for what the age of this,
nail, living in this area, it's at some point, the return set is so specific that you're
losing, yeah, anonymous. So I'm going to go back, very much, I very much agree, so this is where I
come from the solid perspective. So in the solid view of the world, you have your own personal
data store and within that data store you can put a set of credentials amongst other data,
but you can put credentials in there and what you have living on top of that store is a set of
access in usage control policies. So I, as the data subject, am defining who I, who I permit to
access my data and for what purposes I permit them to use it. So in the context of healthcare,
it might be I, I permit trusted research institutions in the UK and Europe to access my data for
the purpose of aggregate health studies. The, the query then is not necessarily done on the health
NIH's servers. It's a query that's done either through communication between my pod and other pods
or some third party aggregation service that has trusted, it is trusted to access this data
and has a policy engine implemented to ensure that it's only pulling and resharing data within
the bounds of express user consent. Does that answer the question?
Yeah, well, there's ODRL as a policy language, for instance.
Well, that, that's, that's, that's a problem outside of this context if I have
credential about, you know, health data here and a credential about health data here and a credential
about my address here. And I choose to reveal all three to a particular agency they can do exactly the
same kind of correlative analysis you're talking about.
So you get more and more specific data, maybe not the point of specific person, but you can get a lot of
knowledge regarding a very limited to the food of the person.
So I, I, I, I, to make sure I'm understanding your question correctly to take it to an extreme exam.