[MINUTES] Data Integrity 2025-06-20

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

*Topics Covered:*

   - *Community Updates:* Significant progress reported on a lightweight
   self-asserted skill credential tool (demo upcoming). Broadening adoption of
   verifiable credentials noted, particularly within the UN and World Bank for
   vital records and social services in developing nations (Open CRVS platform
   mentioned). Collaboration opportunity identified between this tool and the
   UN/World Bank initiative.
   - *Quantum-Safe Crypto Suites:* A pull request was merged, incorporating
   multiple quantum-safe crypto suites (MLDSA, hash-based, Falcon, and SQI).
   Next steps include renaming, addressing data duplication, and finalizing
   spec markup. August presentation planned.
   - *Everlasting Unlinkability (Anna's Paper & BBS Pseudonyms):*
   Discussion centered on a new paper proposing "everlasting anonymous
   rate-limited tokens," offering a similar but not identical solution to the
   group's goal of everlasting unlinkability in pseudonyms. The existing
   vector of secrets approach was deemed the most practical for current
   standardization efforts due to the complexity and lack of standardization
   of alternative cryptographic techniques presented in the paper. Further
   work needed to determine acceptable vector size based on threat modeling.
   Progress on getting BBS pseudonyms into Last Call was also discussed.
   - *Query over Credentials (Circuit-Based Implementation):* Collaboration
   with the Berkeley cryptography team on a circuit-based implementation for
   querying over credentials was discussed. Key design decisions regarding max
   input size, query complexity, and data types/operations needed to be
   prioritized for production. A consensus emerged to focus on transforming
   input data for efficiency with existing cryptographic mechanisms rather
   than inventing new signature schemes. Concerns were raised about the
   potential for unintentional privacy leakage through overly correlated
   queries.

*Key Points:*

   - There's significant and expanding real-world adoption of verifiable
   credentials, particularly in social services and vital records management.
   - While promising, advanced cryptographic techniques for everlasting
   unlinkability (like those in Anna's paper) introduce complexities and
   require further standardization work before being suitable for immediate
   integration. The existing vector of secrets approach remains the most
   viable short-term solution.
   - For query-over-credentials, the focus should be on efficient data
   transformation to utilize existing cryptographic infrastructure rather than
   developing novel signature schemes. Careful consideration of query
   complexity and attribute correlation is crucial for maintaining privacy.
   - Defining acceptable limits for the size of the vector of secrets and
   clarifying the number of joins and attributes needed in queries are
   essential next steps.

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

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

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

Manu Sporny: All right, let's go ahead and get started. I think it might be
a little bit of a light call today. We've got multiple people out on paid
time off vacation. but we want to keep kind of the momentum up. So not much
of an agenda today. Apologies for that. I've been traveling did not get
back until earlier this week. but I think we've got a couple of items to
touch base on today.

Greg Bernstein: Perfect.

Manu Sporny: One of them is I think Greg you finished a preliminary
analysis on Anna's paper on the everlasting u unlinkability portion of the
vector of secrets thing. they tried a different approach from the one that
we had before based on some kind of really fresh new research done by Anna
Lassinskia and friends. So we'll get a little bit of an update on that.

Manu Sporny: I've got a small update on the quantum safe crypto suites. the
pull request that will put in that got merged down and I've got some
questions kind of on next steps there. and then Jesse, I know that you
asked a couple of questions that I still have not been able to get around
to answering in the W3C data integrity Slack channel. And so I thought we
might use some of the time today to talk about that. so that's the proposed
agenda. are there any other changes or updates to the agenda? Anything
additional that people would like to discuss today? if not, let's go ahead
and kind of jump into things. Are there any community updates?

Manu Sporny: anything else that we should be aware of that's happening
anything of that nature. And the expectation is it's the summer so things
are going to slow down quite a bit. I will note that I've been contacted by
a number of people deploying verifiable credentials in areas that I was
completely unaware that there was movement. but the United Nations is
starting to verifiable credentials for things like marriage certificates in
developing nation primarily using open- source software for vital records
type stuff.
00:05:00

Manu Sporny: So places like Nepal Cambodia Zambia and some other places are
starting to deploy verifiable credentials for kind of core social services
things. So I unfortunately don't have the link on me but every day they're
new kind of interesting uses of verifiable credentials and they're using
data integrity as a part of that. the projects are kind of multifaceted at
the UN it's World Bank as well.

Manu Sporny: So, World Bank, United Nations, economic development funds,
out of Germany, I forget where else, Sweden, forget where else, but they're
covering vital records. they're covering farm worker, kind of like farm
output in, these nations, food reserves. they're tracking benefits that
individuals would receive including education benefits like paying for
schools and textbooks and things like that. as well as disability benefits
if someone has a disability of some kind.

Manu Sporny: and so it's been interesting to kind of see and they're also
looking for solutions that not only work in digital form but paper form as
well. So the verifiable credential barcode stuff and the ultra compact
signatures and things like that are of interest. So, that's kind of a heads
up that the work is kind of broadening and there's some interesting new
groups. and these are not small groups. The meeting groups are 40 to 50
people on a call at any given time. So, it's a large effort that I was
completely unaware of. and of course, I'm unfortunately forgetting the name
of the effort right now.

Manu Sporny: I'll try to find a link for that later on. Any other updates
from anyone else?

Phillip Long: Manner, this is Phil.

Manu Sporny: Hey Phil

Phillip Long: Just as an update for everyone, we've been working for a
while on a lightweight self asserted skill credential tool that essentially
is launched into your browser and allows you to create a self- asserted
credential and then request through a recommendation pathway for an
endorsement to that work is basically finishing up. We're doing a final
demo of it on this coming Wednesday to the funders which have been
primarily Walmart and through the T3 US Chamber of Commerce Foundation.

Phillip Long: in addition to that there has been a version of it that has
been built for small businesses which allows for an employment verification
with a quas two-factor approach. it's pretty flimsy but it works. and then
the create and then a credential for performance review for volunteering
and of course skills as well that a supervisor is endorsing on that has
been that from the creation of the credential by the individual employee.

Phillip Long: And finally, a P for building a verifiable credential-based
resume. that allows you to have a narrative section that has links into
other credential elements of the resume. so that you have a story you can
tell backed up by individual C VCs that are associated with the data behind
that and shows it as a PDF if you wish but also creates what we're calling
a compound credential similar to a CLRV2 so that it verifies by typical
verification methods and…
00:10:00

Phillip Long: that's almost all done so we are going to demonstrate that at
bad sum in July. Thanks,

Manu Sporny: That's excellent news,…

Manu Sporny: Really excited to see those things progress as well. some
overlap with the kind of self asserted workforce skills or the kind of
witnessed workforce skills thing. this is one of the projects that looks
like it's going to be adopting verifiable credentials.

Manu Sporny: is open CRVS I forget it's something vital records but it's an
open source platform and this is what I wanted to kind of point out Phil is
the way they have approached this source product is that it is a tool set
that a government or region county state federal would give its population
and then you effectively onboard people in the community to witness certain
events.

Manu Sporny: These are births and deaths and marriages and things like
that, and so this kind of endorsement process It's very decentralized. it
starts with somebody going out to a village to collect data on a birth.
They do a bunch of interviewing for example, the child's name from the
parents. they talk to potentially the midwife to get other kind of vitals
information if the birth didn't happen in a hospital.

Phillip Long: What? Yep.

Manu Sporny: And then they kind of submit it to the country's vital records
or the county's whatever level the vital record services are run they
submit it there and then you have kind of government officials endorse that.

Manu Sporny: And so I thought that that was really interesting because it's
aligned with kind of what you were talking about as well, this endorsement
style workflow and they started back in 2015. They ran the first set of
pilots in 2017 through 2019. And the field feedback that they got in these,
countries where this stuff was deployed was that it was very effective.
meaning they had a 50% gain in recorded births between,…

Phillip Long: Right.

Manu Sporny: not having the system in place and having the system in place.
and so I mean, 50% jump in, the number of, events that you're recording is
significant. and I would imagine that it would kind of apply to workforce
training skills as well, right?

Manu Sporny: Because again a lot of the workforce and training stuff that
happens in some of these countries is I mean quite literally village and
family based.

Manu Sporny: It doesn't necessarily go through community colleges and
universities and things like that. So, yeah, there's Yep.

Phillip Long: Right. Do…

Phillip Long: if you have a contact for me to follow up and I'd love to
give them access to our repo and they can take whatever they want and vice
versa.

Manu Sporny: Yeah, that sounds good. I'm just u reaching out to them. I'll
follow up an email and put you in touch.

Phillip Long: Thank you.

Manu Sporny: But here's the website if you want to copy it.

Phillip Long: Yeah, I've already opened it on my machine.

Manu Sporny: Okay, great.

Manu Sporny: And I'll put it and…

Phillip Long: Got it.

Manu Sporny: they're just one of the platforms.

Manu Sporny: there, 15 or 20 other platforms that are looking at this, but
there they are adopting kind of verifiable credentials for it. And so, it
feels like it's very complimentary to the stuff that you're doing in the
education workforce training sector.

Phillip Long: And there's a variant of this that I think is likely to be
funded which is a registry for notaries that the notaries can endorse the
identity of a person…

Phillip Long: who is claiming various things and that could be used as a
way of strengthening the credibility of the individual self- selfisssued
credentials.

Manu Sporny: Yep.

Manu Sporny: Absolutely. okay, good stuff. any other community updates? Any
other comments?

Manu Sporny: all Let's go ahead and jump into the agenda. I don't have any
particular order, but maybe here, I'll do it. Quantum safe crypto suite
updates, then Greg, your updates on the everlasting unlinkability, and then
Jesse, maybe we can tackle your questions towards the tail end of the call.
any objections to that order? real quick, the, Quantum Safe, Crypto Suites,
had a pull request that, Will had put in in April. We finally merged it a
month and a half later. but a lot of it just had to do with kind of getting
the commit order correct.
00:15:00

Manu Sporny: so we have the quantum safe crypto suites kind of broken up
right now. The naming's a bit awkward. We need to fix that. There's quite a
bit of duplication of data, but you can see here that we've got MLDDSA
stateless hashbased one Falcon and SQI. I think we do need to rename those.
but for each one like MLDDSA we've got the create proof we have the
instantiation algorithms fully documented here.

Manu Sporny: We've got, what you do for the proof values, creating
verifying the serialization, of the verification of the proof, that sort of
thing. so, that's good. I think there's kind of common transformations or
common algorithms are broken out for transformation hashing a proof
configuration that sort of thing. so it was a good step forward.

Manu Sporny: the proof representations are also provided here and big
signatures because theyre key formats are here. We haven't picked the
varant u identifiers yet except for MLDDSA. and then their e values that
we're going to have to kind of update here as and large it's in there.
We've got some spec markup bugs that need to be cleaned up, but I think
we're good other than that. Okay, so that's moving forward. that's good.

Manu Sporny: Unfortunately u Andrea and Yarm were going to present on the
quantum safe crypto suites last Tuesday, but unfortunately there's a mixup
and they ended up on the wrong channel unfortunately. so they're scheduled
for an August presentation on this stuff. okay, I think that's it until we
get the next set of PRs in. things that we need to do here. Select the
multi key things. select the crypto suite names and then a little more
clean up of the spec text.

Manu Sporny: Anything else on the quantum safe crypto suites before we move
on? if not, the second item up is the updates on the everlasting
unlinkability stuff that Greg has been working Greg, over to you for the
update.

Greg Bernstein: Thanks.

Greg Bernstein: So, recently published, oops, let me drop a link to the
paper. There's a new paper published by Anna Stefano Taro, University of
Washington, Brown University and University of Washington, plus their grad
students and, some folks in Germany.

Greg Bernstein: by the way, I stick that link into Here's the chat. So,
this is a paper on what they call everlasting anonymous rate limited
limiting tokens. and this is a similar problem, but not exactly the same as
ours.

Greg Bernstein: What they'd like to do, and this is a privacy pass type of
thing, is an issue where would hand like a holder, a user, they call them,
something to generate up to K tokens that they can use N at a time,
meaning, you could use it in kind of quickly batches of N uses. but not
more than that within a specific period of time.
00:20:00

Greg Bernstein: So, that's an extra thing on top of what we'd like to do
with pseudonyms where we'd like to allow people up to pay uses where they
never could lose having this everlasting anonymity, be anonymous for up to
K uses even in the presence of a quantum computer that could break discrete
log or whatever. ever. Okay, so that's the everlasting meaning that even if
a quantum computer comes up, you still can preserve up to some number of
times that you use the thing. they use some interesting techniques, from
ZKP and other places.

Greg Bernstein: one of okay on the same thing let me just give a quick
update with BBS so BBS the workg groupoup chairs are pinging some of the
reviewers because the questions from the cryptographic review have been
answered a while back but we never got feedback from the reviewers and so
over at CFRG the workg group chairs Oops is that the wrong times out.

Manu Sporny: The site's down. Unfortunately, Greg, I just checked. Yeah.

Greg Bernstein: I left my browser up on the page, so I didn't realize it
gone down.

Greg Bernstein: so progress is being made towards getting the reviewers to
doublech checkck the feedback and see if the corrections or their questions
have been answered on the base so some progress on getting BBS. The goal is
to get in the last call and all that stuff. on pseudonyms. That's why we're
looking at this paper because we were asked to get something better in case
in terms of everlasting unlinkability with pseudonyms. And the approach
that we've taken is to use a vector of pseudonyms of secrets to help do
that.

Greg Bernstein: That's the same approach in this everlasting anonymous rate
limited token paper. And so we're pursuing similar goals. they have an
extra complication but they're not tying it to a full set of signature
suite properties. the paper mentions like a BBS scheme but they use a
different scheme tie it with it up with a different signature scheme. So
right now it's not directly applicable to BBS but a technique like this
could be.

Greg Bernstein: The other thing that they bring up which could be useful in
the future with BBS or other schemes is in the ZKP community there's a
difference between what are known as snarks and starks. So these are types
of zero knowledge proofs. One requires what's known as a common reference
string or these parameters that have to be set up in such a way that you
have to have trust or in how these parameters got established.

Greg Bernstein: the secrets behind them need to be either securely kept or
completely destroyed and people not know where they have any way of getting
that otherwise they could forge things which is very important obviously in
the cryptocurrency world. I was under the impression that we could only use
the stark types which are called transparent setup. They don't require that
kind of thing. However, an issuer in our point of view could actually set
up some of those things and we could use some of those techniques. So, for
example, there's one technique that does what's called a commitment like
we're committing to this vector of secrets. Okay.
00:25:00

Greg Bernstein: and that's part of the pseudonym thing. And that, takes a
certain amount of work to prove that. And who does the work and how long
does it take to verify can vary depending on the schemes. for example the
length of the proof and say our case grows with how long the vector of
secrets. So if we wanted to have a thousand used pseudonym so you could use
it in a thousand different contexts.

Greg Bernstein: not That's a thousand different contexts create with
different verifiers. our proof would be proportional or exactly like a
thousand scalar elements. So that's 32 bytes each scalar element. So it's
32k. Okay. And one of these other cases that involve these parameters that
snarks use they're commitment schemes where that proof would be like a 100
bytes and the verifier only has to do what we call a couple cryptographic
pairings.

Greg Bernstein: a rather efficient type of thing. Okay, so that's what this
paper gets at. It says, hey, in this setting, we could use some techniques
that, we hadn't been thinking about and we can reduce the size of the proof
and the verifiers work. In our case though, unfortunately, everything's got
to compromise. nothing is perfect. The work for the holder actually
increases, which we don't want to do in our case right now. the holder is
probably going to be a mobile device or things like that.

Greg Bernstein: and we may be wanting a larger number of uses than their
paper is calling for. I mean, what we wanted was like if we get kind of a
breakthrough and they're able to have a million uses, then it's worth it to
go for this more complicated technique. That doesn't mean it's still not
worth it, but this paper doesn't completely get us someplace where we kind
of want to go for pseudonyms, but it does help open the door. Okay, so that
it's a good paper to kind of review. They have interesting techniques.
Unfortunately, it is a cryptographic research paper which makes it hard to
get out all these kind of different messages. It's like, okay, how are they
doing that? What are the disadvantages?

Greg Bernstein: right now with verifiable credentials, if we had to bring
in one of these snark rather than Stark like techniques, it's like getting
a huge public key that we'd have to keep somewhere in addition to the
issuers's regular public key. So some of these things plus the fact it
didn't help the holder made me in discussions with the other folks on BBS
pseudonym say okay this is some interesting stuff this could be some stuff
for optimate help us maybe do an optimization in the future but it doesn't
hand us a solution right now that wouldn't require a lot of new crypto

Greg Bernstein: photography being standardized too cuz all those techniques
I don't know 10 to 15 years old which not too old not too new but none of
which are standardized KCG commitments another type of signature a
technique for hardening a PRF which could prove very useful. but for the
immediate concern of pseudonyms, we're not quite there. For the future
though, and some of the stuff we've talked with Ying Tong about, there's a
lot of interesting things here and could open up the things for the future.
00:30:00

Greg Bernstein: So, that's kind of a quick kind of little down in the mud
view of it. Like I said, may open up some eyes about some things we could
do, but nothing comes quite for free. any questions or that on BBS
pseudonyms where we're going with them? Manu

Manu Sporny: Yeah. Yeah, that was great, Greg. Thank you for doing that,
in-depth analysis and the implementation. I guess the takeaway here is the
vector of secrets that we were using before is still probably what we want
to standardize because this doesn't necessarily give us any major
advantages and it comes with the added burden of un unstandardized
cryptography we'd have to go into an even larger kind of cryptography
different cryptographic technique standardization thing in ITF

Manu Sporny: and we really, don't have the time to do that in this current
iteration. Were there any and I know that, the burden on the holder was
increased. Do you know by what magnitude? I mean, it feels like everything
else kind of stayed the same.

Manu Sporny: The burden on the holder was increased, but by how much? I
mean are we talking poor I'm and I don't know what the parameters are but
for a vector of a thousand things it bumps the holder calculation up by
multiple seconds five six seconds.

Greg Bernstein: The way R ours is proportional to the length of the vector
K.

Manu Sporny: What? Mhm.

Greg Bernstein: So that we've been calling it N or the L. First of all
let's establish that the paper and the protein pseudonyms are the same and
they say we're going to use a vector of secrets. That's the way to keep
this everlasting anonymity. Okay.

Greg Bernstein: What they do is they apply more advanced cryptographic
techniques. And their problem is slightly more complicated. Now I said some
constant times K. Theirs is K time log squared of K. So for a thousand
what's log of a thousands I figure it's three or if you do it in base two
it's 10 so log squar you take that squared that could either be 100 times
worse or nine times worse depending on the constants involved so it's a
factor of something it's not a square of it or something

Greg Bernstein: But it's a log squared. I mean according to them. now they
have another approach in here which is still more advanced than ours. it
scales as K for the user. the verifier goes to nearly nothing. But we have
this extra set of stuff to carry around known as this common reference
string which grows as about four three to two to three times the length of
the vector itself.

Greg Bernstein: You have to have these constants. You have to throw around
these that can't be generated any other way. So good news we all say you
got to use a vector.

Greg Bernstein: Go ahead mono. Yeah. Plus,…

Manu Sporny: The CRS ends up becoming for a vector of a thousand,…

Manu Sporny: you're saying it ends up becoming four times the vector of a
thousand 4 kilobytes plus.

Greg Bernstein: I think Yeah,…

Manu Sporny: So, we're talking about adding

Greg Bernstein: because it's actually group elements and…
00:35:00

Manu Sporny: Mhm. Yeah.

Greg Bernstein: those are 48 bytes each. So, you'd have 2,000 group
elements. So, yeah, you're getting up to 50 to 100K.

Greg Bernstein: And I was going, if this was really really great, but what
I'm would like one is that shifts the burden off the holder prover a bit, I
mean, it's great. I mean, it made it really nice for the verifier because,
I tried this commitment scheme that was based and, that worked the way you
said. It's like,…

Greg Bernstein: yeah, made it a little worse for the holder. but yeah, the
verifier was real easy or…

Manu Sporny: Yeah, there's a significant speed speed size tradeoff I guess
is…

Manu Sporny: what we're saying here is and…

Greg Bernstein: or who you put the work on too.

Greg Bernstein: And that's…

Manu Sporny: Yeah. Mhm.

Greg Bernstein: where there's all this work happening, in the ZKP
community, Before they really were all pushing to reduce verifier, but Leo
and some of those schemes sacrificed a little bit of size for making it
easier on the prover. So these are nifty things to keep an eye on. And this
is some of that stuff Ying Tong was with these things called polomial
commitments.

Manu Sporny: Mhm. Okay.

Greg Bernstein: However, none of those are standardized yet. And so if we
want something sooner than later for BBS, just going with, a
straightforward vector commitment based on what are known as Person
commitments.

Greg Bernstein: This is the kind of stuff that goes into blind BBS and
underneath even in BBS signatures. it has the same amount of work for the
prover, or a little less. And yes, the verifier is going to have about that
amount of work. Yeah.

Manu Sporny: So it sounds like then back to the previous vector of secrets
better approach which sounds good. and then the analysis that we still
haven't done is what is an acceptable level for that vector size based on
your threat model we still need to do that. I think Wes Smith might take a
shot at doing that. we definitely need to at least document that in the BBS
specification so people know…

Manu Sporny: what to set that vector to if they're concerned around,
everlasting anonymity

Greg Bernstein: Yeah, we definitely need to eluc set there's something to
do in the BBS CFRG pseudonym spec to discuss the issues and…

Greg Bernstein: then try and…

Manu Sporny: Yep. Okay.

Greg Bernstein: take that the next step in the rifble credential the base
cryptographic spec we can say it depends on how many colluding these guys
and this but it would be nice at the verifiable credential level to try and
be a little more helpful right I mean as a raw cryptographic tool we can
say make your choice based on these ideas.

Greg Bernstein: It'd be great if we can do more at the VC level in the spec.

Manu Sporny: Yeah. Yeah.

Greg Bernstein: If we can Yep.

Manu Sporny: Yeah. Yeah. Yeah. Yeah. No. I'm wondering, what we would say
in each spec. but, that's a PR that can be worked out later.

Greg Bernstein: That's yeah that we had had discussion with the BBS folks
because there's only one or so issue left to be thought up through on the
calculation procedure.

Greg Bernstein: Otherwise we're ready to do PRs and update the CFRG
pseudonym spec and…

Greg Bernstein: get that in shapes then roll out the changes.

Manu Sporny: And…

Manu Sporny: then for timeline, Greg, you said that, CFRG, reviewers, the
chairs jumped in and…

Greg Bernstein: The chairs are asking the reviewers to …

Manu Sporny: asked for.

Greg Bernstein: can you please look at the comments that were used to
adjust, the base BBS spec and…

Manu Sporny: Mhm. Right.

Greg Bernstein: what the original authors of BBS did to fix that or
accommodate explain blah blah blah.
00:40:00

Manu Sporny: But the I guess this review hasn't started on pseudonyms or…

Manu Sporny: or blind yet. Is that right? Okay. Yeah.

Greg Bernstein: No, no,…

Greg Bernstein: we have not asked because …

Manu Sporny: It needs to be in a shape that Okay.

Greg Bernstein: yeah, we're going to update pseudonyms. Blinds has not
changed. I don't think anybody has a problem with it,…

Greg Bernstein: but I think we need to double check if we have all the
security and privacy sections written. I can't remember if we did or not,
but Yep.

Manu Sporny: And…

Manu Sporny: and then I think we'll probably have to do another pass on
getting Anna and Sorrow and those folks to write into the CFRG to say that
they've looked at the spec and that sort of thing. So, I think we'll have
to just collect all the previous names that wrote in and…

Manu Sporny: and have them do another set of input for blind and pseudonyms.

Greg Bernstein: Sounds good.

Manu Sporny: All anything else on that, Greg, before we move on?

Greg Bernstein: We're getting there. And there's cool techniques to look
for the future,…

Greg Bernstein: but there's also the practicalities that let's get this
current pseudonym going out the door.

Manu Sporny: Yep.

Manu Sporny: Thank you for continuing to work on that, g. Much appreciated
always. all with that, let's move on to our last item. Jesse, I tried to
write some of these down. you had asked a number of kind of questions in
the Slack channel. I just kind of put them here. do you want to start here
or do you have any background that you'd want to provide before we jump
into the questions?

Jesse Wright: Yeah, I can give context which is Kristoff Braw who wrote the
other paper that we talked about two weeks ago and I are collaborating with
the Berkeley cryptography team and we're doing a circuit based
implementation for query over credentials. There are a number of design
decisions that need to be made there which will affect the trade-off
between performance and how quantum safe the proof is in terms of whether
you can forge the proof in terms of whether you can disclose knowledge from
the proof.

Jesse Wright: So I would like to get an understanding of the priorities for
production so that we can design towards those priorities.

Manu Sporny: Okay, sounds great. so I can provide an opinion on these. I'd
love to hear other people's opinions. I'll try to give some backing
reasoning.

Manu Sporny: So, one of the things is max input size and I think the input
you're measuring as a triple or a quad coming in. Is that typically
identification cards have 35 fields on Driver's license typically has 35
triples associated with it minus the type information. let's say it's 40.

Jesse Wright: Yeah. Heat.

Manu Sporny: one of the things we can look for are regular processes that
require you to provide a set of documents to get another document. So again
looking at kind of a driver's license you have to provide two to three
other documents to prove your identity. so that holds for things like
getting a passport, getting a driver's license, opening a bank account. the
general thing is two to three forms of other ID utility bill and statement
educational bank account information birth certificate things like that.

Manu Sporny: And each one of those documents could have roughly anywhere
from 10 to 40 triples or quads. that said the other thing to keep in mind
is in the future we do want to massively reduce the amount of data each one
of those credentials has. over time and I'm talking 10 to 20 years we would
expect credentials to contain less and less PII and more and more general
statements like the person is over the age of 21, not the person's birthday
is this exact date. but for now I'd say let's say we're talking hundreds of
triples at most in a full calculation.
00:45:00

Manu Sporny: So we're talking about between 10 20 to 40 triples per
verifiable credential and…

Manu Sporny: you're providing between three to four at most verifiable
credentials in this proof. yeah I think so I think that's probably a
acceptable approximation to start with.

Jesse Wright: So at most even it's about 150 160.

Jesse Wright: Okay. Awesome.

Manu Sporny: The only other the place where you might not see that are
things like supply chain credentials which might be like a shipping
manifest which could have thousands of entries on it in 2,000 3,000 triples
but I don't think that's a primary use case yet and they may issue much
reduced credentials for those use cases.

Manu Sporny: One other thing, and, Greg, this is a bit of a sidebar, but
one other thing that we might consider is when doing these BBS signatures
or…

Greg Bernstein: Yep.

Manu Sporny: BBS credentials, that the issuer would actually sign a much
smaller subset of the credential, right? So, let's say it's a shipping
manifest with 2,000 triples in it, but the BBS signature only covers maybe
20 of them, And so if you're going to use BBS and the reason for this is to
optimize the signature size in BBS so that you're not having to hide 2,000
pieces of information and…

Greg Bernstein: Mhm.

Manu Sporny: thus growing the size of the signature by 200 because of all
of the commitments you have to include. So, this is just a random thought,
Greg, but we might want to think about that. for example, the initial base
proof only includes 20 of the 2,000 triples in BBS because the issuer has
decided that…

Manu Sporny: if you're going to do a BBS disclosure of this, really, you're
only going to be disclosing these 20 fields. and for example,…

Greg Bernstein: Yeah, that's yeah and…

Manu Sporny: every single item in the shipment is not something you're
going to want to selectively disclose.

Greg Bernstein: we have time to put in some of those recommend those
discuss that in the section of the BBS VC spec.

Manu Sporny: Yeah, that's right. the only thing we would need is a list of
the JSON pointer paths or whatever that were actually signed over in the
base so going back to Jesse, your question is like, we may be able to tune
this in time by basically saying, yeah, sure,…

Manu Sporny: there are thousands of triples here that could be mixed
together, but really we're minimizing it down to 50 or 100 so that we never
hit the problem of having thousands of trip having to deal with thousands
of triples, if that makes sense.

Jesse Wright: Yeah. And in that line of…

Jesse Wright: since we're talking about signatures, the inclination in this
work is to use new signature mechanisms where so that there's a way of
signing a vector of triples such that you can extract a subset of that
vector to pull into the zero knowledge circuit.

Manu Sporny: Yeah, exactly.

Jesse Wright: I don't know that I'm not kind of specializing on this bit.
that is not a commitment scheme as far as I understand or BBS plus. Is it
just totally out of the question to be going and inventing new signature
schemes for this piece of work as a proof of concept?

Jesse Wright: I.e. they'll never be accepted or just Yes.

Manu Sporny: It depends…

Manu Sporny: what you mean by signature scheme and invent So if there is
math that explains what's being done very clearly and it's very broadly
accepted then technically you're not inventing anything new it already
exists.

Manu Sporny: and as far as signature schemes, what we're talking about here
are really data transformations into a useful form where we can potentially
just use an existing signature scheme like ECDSA whatever. So I think what
we're largely talking about is transformation mechanisms in those we can
invent any new transformation mechanism right and then we transform the
data into a form where then the transform data as input into a
cryptographic circuit or…
00:50:00

Manu Sporny: a digital signature mechanism becomes far more efficient. go
ahead Greg you've got your hand up.

Greg Bernstein: Yeah, one of the prime examples of that Mano is talking
about is we have two different selective disclosure schemes.

Greg Bernstein: ones based on traditional ECDSA and in that case we're
using ECDSA per quad per triple and actually for the credential itself come
up with an ephemeral key and we sign each of the triples separately and
those all become a set of signatures versus BBS where it's one signature

Greg Bernstein: over the whole thing and we do selective disclosure that
way. do you need a new signature scheme or…

Greg Bernstein: do you want to apply it in a different way and that's what
the flexibility we have with credentials is change the way you transform it
but don't try and invent brand new cryptography use that cryptography in a
different way.

Jesse Wright: Yeah. …

Jesse Wright: I've put a link to the paper that we were looking at because
it's better than me trying to explain it. and it's look up arguments that
and actually is this your lab manu or no different matter. so I've not read
This is the Berkeley folks that have come to us and proposed this paper. I
think it is in the data transformation camp.

Jesse Wright: I would need to confirm. Okay.

Manu Sporny: So to be clear creating an actual digital signal al algorithm
is completely off the table like we do not want to do that that is a decade
of work right to get it into production. so we want to reuse existing I
mean BBS is a stretch as it is right and it's been around for 20 years so
we definitely don't want to go down that path. What we want to do in
arguably this new ZK stuff, the Lihero stuff is in that class of new
cryptography. the only reason we're riding that wave is…

Jesse Wright: Nothing.

Manu Sporny: because Google is really excited about it. And when people
hear that Google's working on it, they think it's going to go much faster
than it typically goes, which it could maybe, right?

Manu Sporny: and a lot of the cryptography community is really excited
about the na ZK Stark based approaches and so there's a lot of desire to
push that stuff forward faster than the other raphic circuit stuff is
bleeding edge new cryptography but it has this benefit of we might be able
to use really relatively ancient cryptography techn technology ECDSA but in
a new way that allows us to use these very deployed infrastructure for
doing ECDSA signatures HSA hardware security modules and things like that
but use them in a way that provides

Manu Sporny: unlinkability, which is what the Lihiero, ZK stuff is So,
hopefully that answers your question. it's new signature schemes we really
want to stay away from. But if we can transform input data into a form that
makes it efficient for these Snark, ZK Starks or, traditional crypto, we
can completely do that, because that's way easier to prove that it is much
easier to prove a transformation algorithm than it is arbitrary new
cryptography.

Manu Sporny: Did that answer your question?

Jesse Wright: Yeah, got it.

Jesse Wright: Yes. Thank you.

Manu Sporny: All right.

Greg Bernstein: But those transformation methods can be quite elaborate and…

Greg Bernstein: wellestablished nobody's going to complain about a Merkel
tree these other hashing schemes or…

Greg Bernstein: how you and most of these commitment scheme things have
pretty good roots to them too. So there's a lot that can be done.
00:55:00

Manu Sporny: All right.

Manu Sporny: Any other opinions on max input size? can anyone else think of
a use case where we might be going above a hundreds hundreds of triples or…

Manu Sporny: All right. second question, query complexity. How many joins
do we expect? By joins I'm presuming you mean we have multiple different
types of verifiable credentials and we're trying to join the data in each
one of those to together

Jesse Wright: No, I mean in a sparkle context.

Jesse Wright: text each if you're doing pattern matching. So if you're
getting all triples that match the pattern s name o let's go s a person and…

Jesse Wright: then s age x that would be a join of two triples

Manu Sporny: Got it.

Manu Sporny: I would imagine those stay below 10. but that's just kind of a
gut reaction cuz usually when you're trying to do I mean these verifiable
credentials are usually used to determine authorization access to a
particular resource or social benefit or something of that nature right so
if we look at something like age verification it's probably between 1 to
three the age thing is the core one but you might also want to make sure
that it's a person you're talking about or they have some one or two other
qualities that you're looking for.

Manu Sporny: So for age, let's say it's three at most joins. but for some
other use cases there have been talks of being authorized for credit or a
loan or something like that where you would provide much more information
are you currently employed? what's your salary in some kind of large
bucketed range what tax bracket are you in things like that and those types
of joins could be upwards of 10 to maybe at most 20 I'd imagine because you
share enough of that and you're pretty strongly identified right your dem

Manu Sporny: demographic information narrows you vastly down from,…

Manu Sporny: 100 million people down to one in 100,000, right? any other
thoughts from folks like…

Jesse Wright: Yeah, brilliant.

Jesse Wright: The circuit.

Manu Sporny: how many attributes are we looking for in these queries? can
you give us an idea of how w wildly these kind of change do the joins
result in exponential growth in computation or

Jesse Wright: So that you design the circuit for a given max size of joins
because as far the circuit is …

Jesse Wright: what is it an set of arithmetic constraints that you're
proving to be true.

Manu Sporny: Mhm.

Jesse Wright: So in designing the circuit there is an upper bound that you
are placing on the number of joins that you can do that may not like you
could generate new circuits because generally the query that you're asking
is knowledge to both parties. So there is a world in which you generate new
circuits when you hit a use case where you've got more triples and that's
not really an issue.

Manu Sporny: H. Mhm.

Jesse Wright: But for now what is the max bound that we want to put in
place for the circuits that we're building. I don't have an idea of the
computational cost that comes with making those larger at the moment.

Manu Sporny: Okay, that's fine. That makes sense. my gut feel on this is
that the more the larger the join set the more damaging the privacy the
query ends up becoming to the point where it's like why are you doing this
in an unlinkable way to a degree right me meaning if the join set is
pulling 20 attributes
01:00:00

Manu Sporny: on the individual. sure, cryptographically it might be
unlinkable,…

Manu Sporny: but statistically, you're looking at some fairly strongly
identifying set of attributes.

Jesse Wright: That depends though,…

Jesse Wright: so it might be that you're pulling attributes that are known
to be attributes on everyone in a population. We know that everyone has
parents. We know that everyone has an age. We know all of these things
exist as attributes on individuals.

Jesse Wright: And then for narrowing down to if you're eligible for a
clinical study, you need to have some weird combination of these attributes
that holds that.

Manu Sporny: Mhm. Absolutely.

Jesse Wright: I'm kind of b**** here, but at least if at some of these
attributes hold query rather than all of these attributes hold query,…

Manu Sporny: Yeah. Yeah.

Jesse Wright: that might be

Manu Sporny: Yeah. Yeah. Yeah. Yes. I completely agreed. it's highly
dependent on the use case and the attributes coming in from the credential
and all that stuff.

Manu Sporny: The general thing we tend to get concerned about is there are
going to be people that use this technology that do not have the training
to understand how correlatable certain claims and attributes and things are
and they will inevitably put for example a date of birth and a zip code
into one of these unlinkable queries and…

Jesse Wright: Brilliant.

Manu Sporny: that you as we know is highly correlating, data. Even though
it seems fairly benign, it's not. And, you can get down to a handful of 10
individuals in a population of 150,000 by just doing zip code and Birth
date. okay.

Manu Sporny: So I think we're expecting certainly no more than 20 but on
average I would imagine we're looking at five to 10 10 at most but I'd say
averaging five. what provenence is required in production? yeah.

Jesse Wright: Before that one, there was a second part to the join question…

Manu Sporny: String comparison.

Jesse Wright: which is what on filters and other functional operations,
what data types and what are we needing to support and what operations are
we needing to support? So in states whatever Yeah.

Manu Sporny: So you mean like string and string comparison?

Manu Sporny: I think yeah ideally range proofs if we can get there but
those tend to make things fairly complex which means integer range
calculations. I think dates and datetimes fit into integer range
calculations. So we could probably coersse date times. We'd need to know
that it's a date time. but then for example, no it's a day time but convert
it to milliseconds seconds since the epoch or something like that. what
else? I mean classes but that's probably just a sub type of direct string
comparison.

Manu Sporny: me meaning it would be good to know that this is a person or…

Manu Sporny: a vehicle or something like that. But I think that just is a
subtype of string comparison

Jesse Wright: that wouldn't even be a data type comparison…

Jesse Wright: So if you want to know that there is something that is a
subclass of vehicle in your data set, you disclose in the inputs what a
vehicle is as a string and then in the circuit show that there is a thing
that is a sub like you don't need to do string comparisons of those.

Jesse Wright: You can reveal what the terms are and then prove properties
hold about those terms.

Manu Sporny: Got it.

Manu Sporny: Okay. Yep.

Jesse Wright: Poorly explained, but I'm glad you got it.
01:05:00

Manu Sporny: Yep. Yep. No, that makes sense. I have completely lost track
of the time. My apologies. We're way over. Jesse, we can either cover these
other ones the next time we meet or I'll try to shoot out some quick,
responses to you today on these, and…

Manu Sporny: then we can discuss next.

Jesse Wright: If you can shoot out responses,…

Jesse Wright: that would be useful.

Manu Sporny: All right. we'll do.

Jesse Wright: Thank you.

Manu Sporny: We're at time. Jesse. Really appreciate you looking into this
as thanks everyone for their time today. Sorry I went way over. but
appreciate have a wonderful weekend and we will meet again next week.
Thanks all. Bye.

Jesse Wright: Have a good weekend everyone. Hey
Meeting ended after 01:05:50 👋

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