[MINUTES] Data Integrity 2025-06-06

W3C Data Integrity Community Group Meeting Summary - 2025/06/06

*Attendees:* Dmitri Zagidulin, Geun-Hyung Kim, Greg Bernstein, Hiroyuki
Sano, Jesse Wright, John's Notetaker, Manu Sporny, Parth Bhatt, Phillip
Long, Ted Thibodeau Jr, Will Abramson

*Topics Covered:*

   1.

   *Solid Project Overview (Jesse Wright):* Jesse provided an overview of
   the Solid project, a community group specification focused on personal data
   stores ("data wallets") utilizing linked data principles (RDF) and OIDC for
   authentication. The Open Data Institute's role as steward of Solid was also
   highlighted. The integration of zero-knowledge proofs (ZKPs) into Solid for
   querying data while preserving privacy was discussed as a key research area.
   2.

   *Connecting Solid and Verifiable Credentials:* Manu Sporny connected
   Jesse's work with the group's focus on verifiable credentials, emphasizing
   the goal of proving attributes in zero-knowledge without pervasive
   tracking. The shared interest in using RDF for data integration and
   seamless merging of data from various sources was highlighted.
   3.

   *Zero-Knowledge Querying of Verifiable Credentials:* The discussion
   centered on enabling verifiers to ask arbitrary questions (e.g., "Is this
   person over 21?") about a holder's credentials, while protecting the
   holder's privacy through ZKPs. Jesse's proposed Sparkle query interface,
   allowing for queries on RDF data and the generation of proof objects, was a
   key element. Kristoff's work on RDF-native operations for ZKPs was also
   mentioned, aiming for efficient and lightweight proofs without
   zero-knowledge virtual machines.
   4.

   *RDF and Cryptographic Circuit Optimization:* The group discussed how
   RDF's ability to merge data from different sources and its abstract data
   model could lead to optimizations in cryptographic circuits. The potential
   for pre-processing RDF data (n-quads) to create a more efficient input for
   ZKP circuits, resulting in smaller proof sizes and faster verification, was
   explored. The significant performance improvements seen in Kristoff's work,
   using native RDF packages and avoiding zero-knowledge virtual machines,
   were noted.
   5.

   *Polynomial Commitment Schemes (Ying Tong's Work):* Manu Sporny briefly
   covered Ying Tong's IETF draft on polynomial commitment schemes, focusing
   on its role within zk-SNARK mechanisms and its concrete implementation
   using the libarkworks library. The ongoing work on optimizing polynomial
   commitment schemes for verifiable credentials was mentioned.
   6.

   *Performance and Tooling:* The differing performance characteristics of
   various ZKP approaches and libraries were discussed (risk zero, arcworks).
   The group acknowledged the trade-off between ease of use and optimization
   for specific applications like verifiable credentials.

*Key Points:*

   - Jesse Wright's work focuses on building a zero-knowledge query
   interface (Sparkle) for Solid, enabling privacy-preserving access to data
   stored in personal data stores.
   - Kristoff's research focuses on optimizing ZKPs using native RDF
   operations, achieving significant performance gains compared to using
   zero-knowledge virtual machines.
   - RDF's data integration capabilities and abstract data model are
   crucial for efficient ZKP implementation in verifiable credentials.
   - Optimizing the input data format (n-quads) for cryptographic circuits
   is a key research area to improve performance and reduce proof sizes.
   - Ying Tong's work on polynomial commitment schemes is progressing,
   aiming to provide a standardized and efficient building block for ZKP-based
   verifiable credentials.

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-data-integrity-2025-06-06.md

Video:
https://meet.w3c-ccg.org/archives/w3c-ccg-data-integrity-2025-06-06.mp4
*Data Integrity - 2025/06/06 09:58 EDT - Transcript* *Attendees*

Dmitri Zagidulin, Geun-Hyung Kim, Greg Bernstein, Hiroyuki Sano, Jesse
Wright, John's Notetaker, Manu Sporny, Parth Bhatt, Phillip Long, Ted
Thibodeau Jr, Will Abramson
*Transcript*

Manu Sporny: Hey folks, let's go ahead and get started. I just got some
emails unfortunately noting that Jesse and Kristoff and Ying Tong are all
traveling right now during this call. so we may not get any of them and the
whole agenda today was kind of around some of the stuff that they've been
working on. so what we might do for the call today is just process any kind
of PRs that we want to process. and then, Ying Kong did send, a new draft
that she has at the IETF up. We could take a brief look at that. and then
we can probably, close the call down. So, this might be a short call. we'll
see.

Manu Sporny: If we get Jesse said that he might be able to join for a short
time to give us an overview. So that I think is the agenda today. are there
any updates or changes to the agenda?

Manu Sporny: Anything else that we need to discuss? Go ahead, Greg.

Greg Bernstein: One thing that could be helpful,…

Greg Bernstein: I know you and Dave are, kind of, good at helping us
understand RDF graphs because I found it a little difficult to understand
what Jesse and Kristoff were. actually getting done…

Greg Bernstein: because they weren't doing new cryptography. So maybe if
you could brief us a little bit because I know you and Dave are kind of the
RDF experts.

Manu Sporny: Yes. Yep.

Manu Sporny: Happy to do that. let me pull up a couple of those links.
let's see. Let me see if Jesse because they have an iswick paper that Yeah.

Greg Bernstein: Yeah, they had two papers and…

Manu Sporny: And it might be interesting to also cover Anna's new release.
I think it's up on archive.

Greg Bernstein: it's 58 pages long.

Manu Sporny: Let me Yeah,…

Greg Bernstein: I've been Yeah.

Manu Sporny: I try. that was my bedtime reading last night and I got to the
latter part of the thing and I was like, "Oh man, this is a lot of math."
but it'd be good to kind of go over some of the interesting stuff happening
in that paper as well. So, maybe we can do a quick paper review today. I am
struggling to hold on one sec. I'm struggling to find honest paper. Greg,…

Greg Bernstein: I can get a link to it. I got it up.

Manu Sporny: there's Jesse. Maybe he can give us a quick Jesse, I let folks
know that you've got limited time today. and Let's go ahead.

Manu Sporny: Hi, good to see you. let's go ahead and let's cover your stuff
because I know you have to go by 25 past the hour and then we'll rearrange
the rest of the agenda for other stuff. would you like me to share any
particular link Jesse while you talk?

Jesse Wright: I might be a bit hard in my current location, so I'll give an
overview.

Jesse Wright:

Manu Sporny: That's fine. Yeah.

Jesse Wright: I'm glad it's a relatively small meeting by the looks and
that I'm not building this project 30 people. and I apologize for my level
of disorganization. by way of background, I wear two hats primarily. The
first is as a academic where I'm working with the ethical web and data
architectures team at the University of Oxford. my research is generally
around neurosymbolic AI. I come from a semantic web research background. So
I am more coming from the symbolic side than the neural side. and then I
also work for the open data institute and there I'm leading work on the
solid project.
00:05:00

Jesse Wright: I'm not sure if many of you are familiar with the solid
project from the VC working group calls where Hrien and Aaron would have
presented from the inrupt side. maybe just as a question does anyone not
know what solid is so I can give a bit of background on it?

Manu Sporny: It would be good to cover it because this group is not deeply
involved in that stuff.

Jesse Wright: It would be good to cover solid is a community group
specification and there is now a working group specification called linked
web storage that is trying to get a candidate recommendation version of the
solid standards through the work around solid started in 2015 2016 in Tim
Berners Lee's lab at MIT Cale the goal at that point in time was to give

Jesse Wright: a personal data store so that you would be able to log onto
that personal data store using a single sign on type mechanism and then any
personal data that you use on a website gets stored to that personal data
store and you're able to reuse that across all of your web services. The
three things that are primarily being standardized there are your
authentication specifications. The CG spec is based on OIDC. the access
control mechanisms which are on web access control policies and ACP
policies and then an LDP link data platform interface for reading and
writing resources to the server and then it is recommended as a data model
that you use RDF as your abstract data model for storing data in this
personal data store but you can also store arbitrary blobs within there so
it's

Jesse Wright: increasingly, especially on the commercial side, solid pods
have become branded a bit as data wallets. And there is a push from some
entities implementing Solid to have this as the web standard for storing
and managing credentials. In addition to all of the other types of data
that you'll put in a personal data store, the open data institute who I
work for, our role within all of this is as what we're calling stewards of
solid. So Tim Berners Lee who ounded the institute asked the open data
institute 6 months ago to take on stewardship work. That means we're
responsible for looking after a lot of the open source code bases for
applications and for the open source servers. We're responsible for a lot
of the community management around Solid.

Jesse Wright: are responsible for helping make sure that different
application implementers in different organizations have effective means of
communicating and collaboration collaborating with each other including
making sure they're using the same data modeling standards so that their
applications can actually reuse each other's data. so that's a bit of
background on my interest on the joint zero knowledge proof verifiable
credentials and solid side is whether we would add a query interface to
solid that allows you to query for data in your pod and get answers that
have a zero knowledge proof that it is true assuming you trust a given set
of issuers.

Jesse Wright: So that's the kind of background and context on solid. are
there any questions there before I go into the zero knowledge work which is
fairly orthogonal? Many go for it. Yes.

Manu Sporny: Yeah, I thought I'd take a little bit of what you said and try
to connect it for the group here on why we would be very interested in the
work that you're doing. so Jesse certainly, covered the concept here is
that, you have this data wallet. you have basically a wallet that holds a
bunch of digital stuff, And some of the digital stuff that it's holding
could be verifiable credentials. And the question that the people working
on data integrity have been interested in is how do we prove that we have
certain credentials without creating some kind of pervasive tracking
mechanism. Is it possible for us to prove certain subsets of our attributes
in zero knowledge? That's what the BBS work is about.
00:10:00

Manu Sporny: That's what the ZKP and Lehiro stuff's about that Ying Tong's
working on. That's what the BBS stuff that Greg's working on. It's all
about trying to prove these attributes and zero knowledge. Jesse's approach
is in we're trying to solve the same use case but it is a really
interesting kind of a different approach to solving the problem. there is a
lot of kind of shared cryptography shared approaches that are useful.

Manu Sporny: I'll hold off on the rest of the stuff until Jesse, you get
into the sparkle, stuff and not everyone knows this. the whole reason we
used RDF as the basis for verifiable credentials is because it does allow
you to behind the scenes or when you get the data seamlessly merge it
together, And that is what sparkle is about quering these data stores of
attributes and Jesse's work is of particular interest to us because we're
really interested in being able to do that and Jesse's got kind of a
generalized approach to it.

Manu Sporny: What we have currently are pretty specific approaches to,
specifically. And we're kind of like our approach isn't as flexible as the
one that Jesse is working on. so that's the connection here is that in the
verifiable credentials ecosystem we want to be able to ask someone do you
have a particular attribute that we're interested in? Are you over the age
of 21? Do you have a driver's license?

Manu Sporny: without getting other, overly identifying information from
them, such as their home address or which DMV they're with things of that
nature. back over to you, Jesse. I just thought I'd try to connect …

Manu Sporny: what you're working on with what this group's working on.

Jesse Wright: I appreciate it.

Jesse Wright: And just to check, can you hear me? Cuz you were dropping out
a little bit from the way I was listening to you and…

Manu Sporny: Perfectly.

Jesse Wright: I figured that was my connection.

Manu Sporny: You're fine.

Jesse Wright: Wonderful. So, yes, I like the through line that the reason
for picking RDF is to allow you to integrate data. And I would extend that
to say forget about any of the data parts of this, forget about The
important thing that RDF provides from is what's called an abstract data
model that allows us to formally describe and represent knowledge that
helps with the integration because we've got a common way of representing
information that use this abstract data model that allow it to be
integrated.

Jesse Wright: And from a zero knowledge perspective, what it allows us to
do is build circuits and build specific mechanisms at the abstract data
model level that allow us to query for information and infer things that
are much lighter weight than needing to do arbitrary computations for
instance inside a zero knowledge virtual machine. so the work that we've
done is firstly to so I've come in from the perspective of the end goal is
to have the ability to query over all of this signed data in a knowledge
base and get a result to whatever query that's sparkle compliant you want
and prove that that result is true assuming you trust a given

Jesse Wright: set of issuers. The way I've gone about this is firstly to
build a proof of concept interface of what this would look like and I've
built that interface within a zero knowledge virtual machine. So the
interface that I've developed is very slow but shows you what that would
look like and you can if you go to one of the links so is there an appendix
in this version maybe otherwise there's an interface if you go to the query
interface design section manu just above implementing the query interface.
00:15:00

Jesse Wright: Yeah, there we go.

Manu Sporny: Okay, here we go.

Manu Sporny: It's not going there. I'll find it.

Jesse Wright: So, if you follow that URL that was at the start of that
section, you just skip past it.

Manu Sporny: This one, the anonymous for open science one.

Jesse Wright: Yeah. …

Manu Sporny: Okay. Nope.

Jesse Wright: this is just to show what a H link's not working.

Manu Sporny: Got an error. Okay.

Jesse Wright: Yes. Let's not worry too much about that then. I think I
emailed you a GitHub link, but we won't worry about that now because I've
got a drop off, but I can provide the links when I come back. so what I've
done is shown what a sparkle query interface could look like. And that
query interface allows you to do, if you're not familiar with sparkle,
think in SQL right now. It allows you to define a query. And the results
will have the set of bindings that you would get in a normal set of sparkle
query results. So you can go select S where S is a person get the result
set of all the people within your data set and in addition to that set of
query results have a proof object similar to the proof key that you would
see in a sparkle in a verifiable credential.

Jesse Wright: So similar to the proofnamed graph that you get in a
verifiable credential, you have a proof object for this sparkle query that
says these results are true and here's the set of public keys that you need
to take as authoritative in order to consider this result set true. The
work that Kristoff has done is come from the other angle and say what can
we do outside of a zero knowledge virtual machine in particular what
operations can we make native to the RDF data model for query and what is
successfully managed to achieve is allowing you to show that any pattern is
true within a data

Jesse Wright: So if you want to disclose again that s a person exists there
within the data set is able to prove that. If you want to show that s ao
and o a thing exists without disclosing what that intermediate anti ent
entity is. He has also done that work. and now we're working together to
use these RDF native operations that he has built and make that into the
query interface that I have proposed. And we're also working then with the
Berkeley group to see if we can build circuits that take his work and
extend it to full sparkle expressivity. That is the very brief overview and
I'll provide links later.

Jesse Wright: Are there any questions based on that brief overview before I
go into details? Noting I need to jump off in about four minutes and then
come back.

Manu Sporny: I think the high level question I have Jesse is how do you
want to engage with this? This is all really interesting stuff and…

Jesse Wright: So I think the research track can be done in parallel to the
interface design track.

Manu Sporny: very pertinent. So we want to figure out a way to continue to
work with you and Kristoff. How do you see that happening? do you have a
timeline on which you're trying to accomplish this? do checking in every
couple of weeks with us what are you trying to accomplish and on what
timeline?

Jesse Wright: And what I would like to work on with this group is what we
want those interfaces for getting query results or derived credentials
would look like. I have coming from a link data background a very
opinionated set of views around how this could be done. I know we were
talking manu offline around potential options. So one way is having derived
credentials that are verifiable credentials that are JSONLDD
representations and you use this query interface under the hood to derive
these credentials and create that proof object. I would love to talk
through abstractions that we can have in clients.
00:20:00

Jesse Wright: So I've got a lot of tooling in the domain that I come from
where you can have clients take an RDF data set and generate an object out
of it. So I would like to know what interface we can get towards in this
group. That's the first thing I'd like to collaborate on. And then what I
would like to do in parallel is join up all the threads happening on the
research side around what signatures are best to enable this type of query
support. what type of circuits we can build. I think there's a lot of
asynchronous conversation to have and I'm not sure if it's better to set up
a Slack channel in the W3C space where we can just say this is what we're
currently working on. This is what we've found. I think some kind of
channel there would be useful because I know there's other people working
on ZKP that I'm not currently talking to.

Manu Sporny: That sounds great. So, Jesse, all of those options are on the
table and…

Manu Sporny: we can figure out the details, as the weeks roll on. thank you
very much for coming in, presenting this stuff. I know you've got to go,
but really appreciate your time today.

Jesse Wright: Brilliant. Thank you.

Jesse Wright: I've got to drop hopefully I'll be back for the last 20
minutes if just to more cuz I want to see what this group also talks about
in addition to this but also because I'd love to chat more. So I'll
hopefully see you in 15 20 minutes. Brilliant. Thank you for having me.

Manu Sporny: Okay, sounds good. Take care, Jesse. Bye. Of course. All
right. so just to kind of go back on that and talk about, how this applies
to the verifiable credential working group and the data integrity stuff.

Manu Sporny: fundamentally what Jesse and Kristoff are working on is the
ability for a verifier to ask a fairly arbitrary question is this person
over the age of 21 and then provide any set of issuers that they trust. So
they could provide I trust these 50 different issuers right to make age
statements about someone and that's literally the only question they ask is
are they over the age 21 and I trust these 50 issuers that as the verifier
that is the query that they send and then on the holder side the holder
receives that they have this collection of verifiable credentials

Manu Sporny: they will select all of the verifiable credentials from those
particular issuers. and then they can effectively run this cryptographic,
circuit over, let's say that they've got, three of those issuers or five of
those issuers. and they can run a cryptographic circuit over any one of
them or all of them combined and come up with a data integrity proof and
bundle up into a verifiable credential like we do for BBS and then they can
respond with one verifiable credential back to the verifier.

Manu Sporny: the verifier looks at it, they verify that the proof's valid.
and then they get a thumbs up. Yes, this person's over the age 21 and that
statement came from one of the 50 issuers that you trust. and it is done in
a unlinkable way meaning that it has equivalence to the other somewhat
benefit is that potentially it can work in fully postquantum environment
although I think Greg admittedly that's like it should work in theory but
in practice.

Manu Sporny: So, that is largely the benefit of, I think, what Jesse and
Kristoff are working on is that they're leveraging, the benefits of RDF to
make it easier to do these cryptographic circuits and…

Phillip Long: Oops.

Manu Sporny: and zero knowledge proofs. any questions on any of that? Go
ahead, Greg.

Greg Bernstein: One of the things I was wondering were they mentioning two
different issues linking credentials and…

Greg Bernstein: the other one were they talking about getting more fine
grain then we've have done in the existing selective disclosure both EBS
and…
00:25:00

Greg Bernstein: the EC DSASD I wasn't quite sure when I was reading those

Manu Sporny: Yes. Yes.

Manu Sporny: Yeah. they were so Jesse's work has more to do with how do you
do the query and Jesse's work has to do with again one of the reasons we
picked RDF is that RDF allows you to merge data from vastly different
sources so if you've got five different sources that use the subject
identifier to talk about something you can RDF

Manu Sporny: automatically can merge that data together, you can't do that
with SDOT. They just don't have unless they have, the semantics that come
along with it and they can be converted to, RDF, you just can't do it with
those sorts of technologies. so one of the benefits here is that RDF allows
you to combine of disperate data sources together. just by itself and then
if there are digital signatures on it then you can actually create a
trusted graph of information about a particular subject. you can take
credentials that the subject has and you can combine them together and you
don't have any data conflicts or anything like that. Once you get it into
that form you can run Jesse's work over it which is Sparkle is a query
language that allows you to query a graph of information.

Manu Sporny: So, you took a bunch of verifiable credentials and you kind of
smooshed them together and they're in this little mini database. And then
Sparkle is the query language that you can use to query that database. and
Jesse's work is how do you do that in zero knowledge? how does a verifier
ask that question and know that the query was run appropriately in the
result is not because the holder is asserting it's true.

Manu Sporny: It's because cryptographically there are multiple issuers
asserting a subset of that graph as true they're over the age of 21 or they
have a driver's license right so that's the benefit of using RDF that's why
Jesse's talking about RDF and the abstract data model and the core of it
and all that kind of stuff and Jesse's stuff is about the query language
and how you prove things in zero knowledge with the query language which is
sparkle

Manu Sporny: Kristoff's work is about all right is there stuff we can do
with just the fundamental RDF where we can do even more privacy preserving
things like can we do range proofs on dates can we do range proofs on sets
of enumerations and things like that So Kristoff's work I think is more how
do we optimize things down at kind of like the cryptographic layer. So this
has to do with Greg us trying to figure out what the best input for a
cryptographic circuit would be.

Manu Sporny: you utilizing RDF as the input format for optimizing the
cryptographic circuit what do we need to do to those statements to make
them fit into these cryptographic circuits? Ideally for example using
seabore LD mechanisms being able to compress a big URL down to a number if
you can represent these things as little numbers you get massive amounts of
performance increases I think this is where I completely out of my depth
both in processing time the complexity of the cryptographic circuit and…

Manu Sporny: in the proof size I think Greg, you'd know far better than me.

Greg Bernstein: When I was reading Kristoff's they mentioned using BBS and…

Greg Bernstein: I was going what's he doing there? Yeah. Because that
wasn't completely clear and he had some numbers where he quoted it was
quick and such like that. I was wondering because he referenced both the
old Tobias ori version of the W3CBS and our newer version. So I wasn't
quite sure and so I wasn't quite sure what it was doing.

Greg Bernstein: The other thing is when we combine doing a proof over a
bunch of VCs,…
00:30:00

Greg Bernstein: do we have mechanisms for making sure that these belong to
the same person? Okay.

Manu Sporny: that would be through the subject identifier.

Manu Sporny: So the presumption here is that the issuers have vetted the ID
in some way and that's the thing that allows combination to the So for
example they are the same decentralized identifier. So the issuer issues
like let's say we've got 15 issuers. If they all issued to the same
decentralized identifier,…

Manu Sporny: then that makes merging the graphs really easy because the
subject identifier is the same. And the presumption here is that they would
not have said that that's the identifier unless the issuer had vetted that
each issuer asked for a proof of control over a private key, right? So you
say you're

Greg Bernstein: So kind of anonymous holder binding or…

Greg Bernstein: just a did that we don't disclose via zero knowledge.

Manu Sporny: That's right.

Manu Sporny: So the would be really well known on the issuer side and…

Greg Bernstein: Okay, gotcha.

Manu Sporny: the holder side, but when the holder generates the proof to
the verifier, the DID's hidden in some way.

Greg Bernstein: Yep. Yeah.

Manu Sporny: I don't know exactly how that happens right now, Greg, but I
think that's the presumption. Clearly that has to happen for any of this to
work. yeah,…

Greg Bernstein: But from a ZKP perspective, that's like I know All these
numbers and all these credentials are the same, but I'm not going to show
you the number. That's a classic ZKB.

Manu Sporny: that's right.

Greg Bernstein: Okay.

Manu Sporny: Exactly. Yeah.

Greg Bernstein: You're helping me puzzle this out from the different
pieces. Okay.

Manu Sporny: And what and to be clear, this is my very highlevel, bedtime
reading about this stuff. I have no idea if I'm like some of this stuff is
hasty to me as well. one of the other exciting things is the performance
figures that Kristoff are crazy fast compared to what the Google and the
Obby and Mateo and Google's ECDSA stuff. they're at 1 to two seconds for a
really tiny object.

Manu Sporny: Kristoff is down at 150 milliseconds, order of magnitude
faster. yeah.

Greg Bernstein: Yeah, I thought some of these might have been like BBS
classic numbers,…

Greg Bernstein: I'm using BBS style ZKB. that's where I thought it was
interesting.

Manu Sporny: So that might be the case and that's what we don't quite,
right now. Jesse, we're still talking about your work and…

Manu Sporny: and Kristoff's work. mostly trying to kind of tie it into
where are with the current, state of state of things. and mostly we've been
talking about because this group isn't necessarily down in the details of
RDF or…

Jesse Wright: Okay.

Manu Sporny: Sparkle or any of that stuff that stuff is kind of like an
important implementation detail but certainly this is not like a link data
community and this is not an RDF community, right?

Manu Sporny: this is a kind of a cryptography group that just so happens to
be taking RDF n quads as input into the signing algorithms.

Jesse Wright: That's what Yes.

Manu Sporny: So to us the RDF is kind of like this opaque thing like it's a
string. We don't really care what it is but at this point we do care
because all of a sudden we can do some pretty interesting things if we
break the RDF apart or encode it in different ways and things of that
nature. I think one of the questions that we had, Jesse, was I think one of
the questions that we had was trying to figure out …

Jesse Wright: I'm going to ask him from

Manu Sporny: what your work is focused on mostly and Kristoff's work is
focused on mainly.

Manu Sporny: One of the things we're multiple things here that we're
excited about but one of the things is that it seems like because RDF is
being used we can transform it further to improve the size of the
cryptographic circuits.

Ted Thibodeau Jr: Sorry, Manny.

Manu Sporny: Okay.

Ted Thibodeau Jr: Jesse, if you could mute, please. There's a lot of
background creeping in.

Manu Sporny: One of the things that we're trying to figure out, Jesse, is
we believe theoretically that, because we go to RDF to sign.
00:35:00

Manu Sporny: So what we do is we take a verifiable credential which is in
JSON LD format and then we convert it to N quads which is a fairly simple
RDF data format and then we either sign all the N quads together or we sign
every N quad individually as an independent message. That's how things work
today. what we believe is possible is that we can take those n quads and we
can process them further into a format that is going to be optimized as
input for a cryptographic circuit. Meaning that we can get these
cryptographic circuits we can optimize the cryptographic circuit to be more
efficient, generate smaller proof sizes.

Manu Sporny: maybe all of them. if we can modify the input n quads in a way
that makes that easier to process for the cryptographic circuit. So, it's
kind of like a pre-ompile step for the n quads that allows us to maybe
compress it into a really small binary structure.

Manu Sporny: Which then when fed into the cryptographic circuit results in
much more efficient processing.

Jesse Wright: Yeah. …

Jesse Wright: two thoughts.

Manu Sporny: Yeah, Please go ahead, Jesse.

Greg Bernstein: You're on mute, Jesse.

Jesse Wright: Yeah, my connection's a little bit spotty,…

Jesse Wright: so I came in too early. what I am thinking is a couple of
things. what Kristoff's work does is individually signs terms rather than n
quads which means that a lot of the time you do not need to do any form of
pausing within a circuit to prove certain properties. For instance, if you
want to prove that a certain triple pattern exists, and by triple pattern I
mean show that there is a person in this data set but not reveal the
subject which would be who the person is.

Jesse Wright: Then in Kristoff's work, he will reveal the second and third
term in the array to show that there is the predicate and object a person
in the data set and allow you to omit revealing who the subject is. And you
don't need to pause the string and prove any properties of a string to do
that. He is doing it purely based on the way he's signed this data
structure. You can also then for instance for the proof of age property
prove that for the first three elements in your array the first element is
your identifier the second element is the age predicate and then generate a
separate proof which is the signed numeric value in the third element is
greater than a certain value.

Jesse Wright: So that I think addresses what I saw in your email which was
saying at the moment 80% of our time is spent dealing with deding the base
encoding of these n quads and is spent dealing with other things that are
not proving properties of the graph. and so that's what Kristoff has done.
What I would suggest is valuable research for us to be doing now and
something that I'm starting to look into is when you typically store an RDF
data set in memory, what you will first do is create a set of numeric
identifiers that associate a URI with a particular ID and you create a
diction

Jesse Wright: of these identifiers and then you go and create an index
that's purely based on these identifiers. So separately you can make
statements about here's what the identifiers for nodes and edges in the
graph are and here's how these nodes and edges relate to one another. And
the benefit of decoupling that signature is you can do a proof of
properties of the graph such as for a proof of grandparent this two-step
relationship exists and separately you can selectively disclose what
entities correspond to which ids that you've just done a proof about.
00:40:00

Jesse Wright: So I think there's a lot that can be done in improving the
representation over Seabbor or over JSON LD or over signed end quads to
allow you to prove properties a lot more efficiently. That has not been
done yet. Kristoff's work is just signing individual terms so that you can
prove properties of triples.

Manu Sporny: Yeah, that's fantastic, Jesse. and is along the lines of why
we were excited about the work in the first place. So yes, that's good. to
be clear, this group doesn't have the problem of, the B 64 decoding a jot
or the issues with decoding the JSON within the B 64 decoded payload. Those
are issues that Obby and Mateo at Google are hitting because of the SD J
the MDOC format they've had to write MDOC parsers or JSON parsers as a part
of the cryptographic circuit and I believe that takes up a significant
amount of the size of the cryptographic circuit and I believe the proof as
well.

Manu Sporny: they were saying something about for every level of nesting in
the JSON document there is an n squared relationship or something like that
with the size of the proof of the cryptographic circuit that they have to
generate. so I don't quite understand that at depth and don't know about
the details there but they said that is definitely one of the biggest pain
points is they have to work with these existing data formats that are very
restrictive whereas we as a group don't have that we have because of the
way data integrity is designed there is this transformation step that
allows you to transform the incoming data the JSONLDD

Manu Sporny: into any arbitrary binary format that we want. and in doing
that we believe that we can have much more highly efficient encoding of the
data proof size computation all that kind of stuff. one of the questions
that came out of that is Kristoff at the bottom. So for example, what we
can do is we can naturally break things up into the way Kristoff is signing
them, and potentially we can break things up in a way that makes the query
far more efficient, depending on the Sparkle engine that's being used.

Manu Sporny: so we have a tremendous amount of flexibility and I think that
that's good because that means that the actual science will drive the most
optimal binary representation proving engine all that kind of stuff. we are
not having a data format forced upon us so that then we have to work around
the intricacies of the data format. so one of the things, Jesse, we were
also wondering about with some of Kristoff's work is he's quoting some
pretty, amazing performance numbers, and we were wondering if that was
where that was coming from. is this the actual evaluation of the
cryptographic circuit? prove and verify. I mean, certainly it seems like
that's the case.

Manu Sporny: But yeah, I think we can find that out, late later on. and I
don't know if we lost you, Jesse, but any thoughts on kind of performance?
Yeah, I think we lost Jesse.

Greg Bernstein: I did some checking with that risk zero and…

Manu Sporny: Mhm. Okay.

Greg Bernstein: it is definitely aimed towards optimizing verifier speed
but it's relatively easy to use and to run the benchmark.

Jesse Wright: Hey, speech speech.

Greg Bernstein: So I think that's why Jesse those guys started with that. I
think he is back.

Manu Sporny: …

Greg Bernstein: Nope. Yeah.

Manu Sporny: so I mean I think we can continue to do experiments with the,
risk zero stuff and it'll be interesting to hear about Ying Kong's input on
this because, she's also focused on that sort of stuff. speaking of which,
I want to make sure that we get to Yong's work on this. Jesse, I don't know
if you heard anything that I said. It was basically we were interested in
the performance numbers that exist right now. and…
00:45:00

Jesse Wright: Yeah. So yeah,…

Manu Sporny: I don't know what those are being run over.

Jesse Wright: so the work that Kristoff has done does not involve zero
knowledge virtual machines. that is only the work that I've done that
involves that and I do not expect any of the work that I've done to be
anywhere near production ready.

Manu Sporny: Mhm.

Jesse Wright: That was purely a proof of concept of the interface. all of
Kristoff's work is showing what you can do when you use native RDF with
native Rust packages to do a proof of knowledge of signature on the terms
in the array and use the selective

Jesse Wright: of disclosure properties of BBS when you're doing that proof
of knowledge of signature to disclo so for showing certain patterns exist
it's just doing a selective disclosure proof on that BBS signature when
you're doing relationships it might be you're showing that I have a
grandmother named Betty that's selecting which properties in that array I'm
doing selective disclosure on so that I can show that relationship exists.
So there'll be a proof of knowledge of signature and a proof of things like
term equality without revealing terms. But this is all done using RDF
packages for BBS rather than requiring a zero knowledge virtual machine or…

Greg Bernstein: Okay, that was the BBS club members.

Jesse Wright: a circuit like Halo 2. But it is using I guess Grath 16 hertz.

Manu Sporny: Got it.

Manu Sporny: Got it. and that explains the good performance numbers that
he's hitting. that clears that up. that's good and Jesse, Greg Bernstein
here in this group is the person that is, shephering a lot of the BBS work
through the IETF and is deeply knowledgeable about BBS and is the lead
editor architect of the BBS spec at W3C. okay. Yeah.

Greg Bernstein: But not on the JSON LD that came from Dave Longley.

Manu Sporny: Okay. So, Greg was just saying so he's on the cryptography
side largely,…

Jesse Wright: Sorry, that was quite quiet,…

Jesse Wright: so I didn't hear what you

Manu Sporny: not the JSON LD RDF side. yeah.

Greg Bernstein: Yeah, that came from Dave Longley. So how we do some of
those things. Yeah.

Jesse Wright: Touch it.

Manu Sporny: Okay. we've got four minutes left. I want to make sure that we
get to the update from Ying Tong can't join us today. she is traveling but
she was able to publish this ITF independent draft on polomial commitment
schemes and the interfaces. This is what we've been talking about with Ying
Tong over the past couple of months. this should look familiar to everyone.

Manu Sporny: This is kind of what she had been presenting but this is the
generic interface for a polinomial commitment scheme. this is talking about
where this fits in this diagram talks about where polinomial commitment
schemes fit into a zk snark mechanism. So you need to do all of these
things and this spec is kind of talking about the bit in the middle. she
talks about kind of the generic interface what do you need to do the setup
the commitment the open the verify and then as we had suggested she has a
concrete implementation of the polomial commitment scheme in an appendex or
in a second section for liarero specifically I think the one that Obby
wrote up and

Manu Sporny: then using arc works to implement it. So this is the specific
hero parameters what the commitment looks like what the open and verify
look like and as you can see there's still some work to be done there on
stuff but that's great because this is defining a polinomial commitment
scheme and she's making good progress so hopefully we'll be able to hear
from her in two weeks on… where things are. go ahead, Greg.
00:50:00

Manu Sporny:

Greg Bernstein: One thing to note,…

Greg Bernstein: because I was talking with Ying Tong and we were looking at
the arcworks library and some of those things and it seems like we're kind
of covering things from two different manners from both lowlevel and high
level which is good because I looked at the risk zero stuff and it was
definitely easier to use. But when I was building some of the examples and
running the benchmarks under work were underneath they were using some of
the arc works open source code.

Greg Bernstein: So these different optimization criterias so risk zero
definitely aimed towards one thing which may be different from what we want
for credentials and while at the same time some of the polomial commitment
schemes is like I'm still learning out how we're going to assemble those to
do something more optimal So, we're kind of hitting these things and we're
getting folks with the knowledge from a bunch of different areas,…

Greg Bernstein: which I think is really good on trying to figure out how to
best use ZKP with the credentials.

Manu Sporny: Plus one to that.

Manu Sporny: I think it's nice. I mean, as everyone is experiencing,
there's been an explosion of interest and engagement in this area and there
we're finding a lot of people that are kind of working on this stuff and
hopefully connecting all of them together. okay, I think that's it for the
call today. Thank you Jesse for joining us. I know he had to drop, but
thanks to Jesse for joining us.

Manu Sporny: I'm sure we'll be chatting with him and Kristoff in the Yep.

Ted Thibodeau Jr: Just before you shut down,…

Ted Thibodeau Jr: …

Manu Sporny: Yep. Okay.

Ted Thibodeau Jr: a couple links up there. You pasted a link from
overleaf.com and that goes to permission block.

Manu Sporny: We'll try to get that opened up with Jesse. that's Jesse's
he's got a control permissions on it.

Ted Thibodeau Jr: I didn't know this yet. Okay. Thanks,

Manu Sporny: Thanks for the call today. we will not be having calls next
week. I'm on the road. but we will meet the following week. we don't know
what the agenda is yet. but if you have ideas for the agenda, please please
let us know. if not, we will continue to process pull requests specifically
on the postquantum schemes and try to get that going. I know was able to
redo the history on his pull request. So we'll try to get that in soon.

Manu Sporny: thanks Have a wonderful weekend and we will chat again in two
weeks. Take care. Bye.
Meeting ended after 00:53:06 👋

*This editable transcript was computer generated and might contain errors.
People can also change the text after it was created.*