[MINUTES] Data Integrity 2025-05-30

W3C Data Integrity Credentials Community Group Meeting Summary - 2025/05/30

*Topics Covered:*

   - *Quantum-Safe Crypto Suites:* The group reviewed a pull request adding
   quantum-safe crypto suites (MLDDSA, SPHINCS+, DSA, Falcon, and Sphincs+) to
   the specification. Discussions focused on modularizing the specification to
   reduce duplicated text and parameterize algorithms for easier maintenance
   and future expansion. The decision was made to merge the PR, then raise
   issues to address remaining tasks (adding examples, modularizing algorithms
   further). Agreement was reached to align suite names with the IETF's naming
   conventions where possible.
   - *Post-Quantum Secure BBS Pseudonym Work:* Greg Bernstein provided an
   update on the progress of work on post-quantum secure BBS pseudonyms,
   focusing on ensuring everlasting privacy. The main outstanding issues are
   finalizing the challenge computation update and determining how to bind the
   length of the pseudonym vector to prevent civil attacks. Two approaches
   were discussed: binding the length in the signature and making it a
   constant system parameter. The group will continue discussing the best
   method for handling the length parameter in the W3C spec, potentially
   offering a selection of pre-defined values to mitigate correlation risks.
   - *Community Updates:* Manu Sporny announced a planned two-month break
   for the Verifiable Credentials Working Group (VCWG) over the summer, with
   work on existing CCG specifications (confidence method, render method,
   credential refresh mechanism) to continue. Rechartering the VCWG to
   incorporate this work is planned for August.

*Key Points:*

   - The quantum-safe crypto suites PR will be merged, followed by issue
   creation for outstanding tasks.
   - Algorithm modularization is a priority for maintainability and future
   expansion.
   - The length of the pseudonym vector in the BBS pseudonym work needs
   careful consideration to prevent civil attacks; binding it within the
   signature is the preferred approach.
   - Further analysis is needed to determine optimal parameter values
   (e.g., length of pseudonym vector, number of HMAXs for anonymizing blank
   note identifiers).
   - The VCWG will take a break this summer, with the CCG continuing work
   on various specifications. Rechartering of the VCWG is planned.

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

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

Dave Longley, Denken Chen, Geun-Hyung Kim, Greg Bernstein, Hiroyuki Sano,
John's Notetaker, Manu Sporny, Parth Bhatt, Will Abramson
*Transcript*

Manu Sporny: Right, let's go ahead and get started. Welcome everyone to the
call. this is the data integrity credentials community group call. It is
May 30th, 2025. our agenda is on the screen. what we plan to cover today is
mostly we're going to focus on the quantum safe crypto suites. and then any
updates to the postquantum secure BBS pseudonym work. Greg, if you have
anything. Ying Tong mentioned that she's not going to be able to make the
call today. but she'll be here next week. and we will cover some of the
zero knowledge circuit stuff that she's looking at there. all right.

Manu Sporny: That's the proposed agenda. Are there any updates or changes
to the agenda? Anything else we want to cover today?

Will Abramson: I'd just like to touch on I mean, I wasn't here last week. I
don't know if you guys touched on it, but I'd like to touch on the content.

Manu Sporny: No, We were waiting for you. So, that is the call today is
we're going to focus on the postquantum stuff.

Will Abramson: Great.

Manu Sporny: Yep,…

Will Abramson:

Will Abramson: I missed that. Yeah. Poet.

Manu Sporny: no problem. Any other updates or changes to the agenda? All
right, then let's go ahead and get into it. Denin, many of us know you,
but, you're new to this call. Would you mind, doing a quick introduction to
yourself and what your, interest is and, that sort of thing?

Manu Sporny: Denin Chen, you might be muted, but it's okay if you don't
want to introduce.

Denken Chen: Okay.

Manu Sporny: There you go.

Denken Chen: Hi. Hi.

Manu Sporny: Yeah. Great.

Denken Chen: Hi, everyone. I've been involving in DNVC for a while.
particularly responsible surface as staff for Taiwan's government's digital
identity w project here. So, I also presented that project in May sometime
in the CCG poll as So happy to join here as well. Thank you.

Manu Sporny: And wonderful to see you here as well, Denin. and excited,
that you're interested in this work. okay.

Manu Sporny: any community updates or anything of that nature related to
data integrity or any of that stuff. I'll mention that on this past
credentials community group weekly call we did talk about the work that
this group is doing. The Brent Zundell, the chair of the verifiable
credentials working group came in to present on kind of what's next for the
verifiable credentials working group. the plan is to take a little bit of a
break.
00:05:00

Manu Sporny: we've been working really hard for the pa past, three years to
get those seven global standards done. Now that they're out there, the
group's going to take a little bit of a break over the summer and reconvene
around the August time frame. So, we'll take a little two-month break. but
in the meantime, we will continue to incubate specifications in the
credentials community group. there are three specifications that are within
the current charter of the group. That's like confidence method render
method and then arguably the credential refresh mechanism. those will be
immediately worked on once August comes around.

Manu Sporny: the other things so verifiable credential API the quantum safe
crypto suites all of these things will need to have the W3C working group
rechartered to pull in that work so that is kind of what we are planning
that's what the current plan is but what that also means is the more we
incubate

Manu Sporny: this stuff and the further along we get it, the less work
there'll be to do in the working group. And especially with things like the
quantum safe crypto suites, a lot of that work is mechanical, meaning there
are not a lot of decisions that need to be made. We just need to, document
the algorithms and the type of cryptography that's being used. and then in
theory, we'd be able to turn that around pretty quickly. in the PCWG. okay.
I think so that's kind of the plan. A little bit of a break for the VCWG
until In the meantime, we will continue to incubate specifications in the
CCG to get them ready to hand over the VCWG once they're ready to get going.

Manu Sporny: and then we will also raise a rechartering question at the end
of August once we're kind of in process with those other specifications. I
think that's it as far as plans concerned. The current VCWG charter goes
well out to the year 2026. So I think October late in the year in 2026. So,
we're fine. we're chartered to keep working on a lot of the verifiable
credential stuff. okay. I think that's it for Any other community updates
before we jump in? Okay.

Manu Sporny: if not let's go ahead and jump into the quantum safe crypto
suites discussion. So currently we've got this spec has been working on
adding a set of crypto suites that we had agreed to include. the MLDDSA,
SLH, DSA, Falcon and SQI are the ones that we had picked high level.

Manu Sporny: And then selective disclosure variants of each one of those
and there are a couple of places in the spec where we're kind of like we
have to pick some values here.

Manu Sporny: That's what today's discussion is largely going to be about.
and then anything else will that you want to cover? Mhm.

Will Abramson: Yeah, I will just say I mean there's one comment from Dave
that I'd like to touch on,…

Will Abramson: but really my preference would be to just get this merged in
and then we can raise issues against the outstanding tasks because it's
quite a big PR. I think it gets the big body of the text down. I don't know
if folks have a chance to review it, but there are some outstanding things
like we need some examples. We need to fill in those question marks.

Will Abramson: But I just think it's been out open for a while. It's quite
a lot of changes in there. Unless people feel strongly we should…

Manu Sporny: Okay.

Manu Sporny: That is fine with me. I

Will Abramson: but Dave's comment is somewhere in this and it's this one
and I just didn't know Dave if you had additional changes you were waiting
to see in this that …

Dave Longley: Right.

Will Abramson: because I've tried to simplify right so there's all the
algorithms use common sort of algorithms basically

Dave Longley: Yeah. I didn't intend for my comment to be approve the PR. I
was just noting that I think for each one of the create steps and, proof
transformation steps, whatever they are, I think we duplicate the text for
those in each of the sections still. And it seemed like we could turn those
into a single thing that it's just parameterized and then you just say for
these three algorithms use these parameters and you say that for each of
the different suites.
00:10:00

Dave Longley: It seemed like we could further reduce that text and I know
for a fact that text in our other specs had to keep getting changed for
different suites and…

Will Abramson: Okay, cool.

Dave Longley: we kept accidentally forgetting to do it for this suite or
that suite and there bugs can creep in that

Will Abramson: Makes sense. I'll take

Manu Sporny: Okay. Yeah.

Manu Sporny: Plus one to that. I think what we're hoping to do is do that
refactoring that we weren't able to do in the VCWG in this iteration. and I
think with the current VCWG charter we can refactor the data integrity the
version 1 crypto suites to include that as well. And so we might be able to
move we'll refactor in this spec and then once we get it refactored nicely
we'll just move it into the core data integrity spec or something like that
and then we can update all the specs to reuse as much of the language as we
can. okay so what I'm hearing is let's just merge this and then we'll raise
issues.

Manu Sporny: So, I guess we will spend today raising those issues on the
things we'd like to see done differently. would there be any objections to
proceeding in that way? And I see a couple out of place commits here. I'll
do a rebase, but we might want to go through and reword we don't want to
see these kinds of commits in here. but we can go in and kind of reward
them so we don't lose the history here.

Will Abramson: Sure.

Manu Sporny: All right.

Manu Sporny: Let me go ahead and All right. So, let's do a rebase and
merge. conflicts.

Manu Sporny: You'll have to rebase your branch will and maybe you can
rewrite some of the history while you're doing that and clean up the
commentary so it's a little cleaner.

Will Abramson: Okay. Yeah.

Will Abramson: Right. Right. Right.

Manu Sporny: And then once you do that we'll merge.

Will Abramson: Okay.

Manu Sporny: I'll merge over the weekend. So the second you get that done,
just ping me maybe even you can merge. I don't know. great. Thank you very
much for doing all of that work. let's talk about the issues that we want
to raise. So this will be said that they is working on it which one is this
ads slda. All right.

Manu Sporny: Pick and use multi key names and prefix values.

Manu Sporny: Let's see. And I'll try to I think I added a comment here.

Will Abramson: I mean,…

Will Abramson: yeah, I think actually already raised that one.

Will Abramson: Number two, but maybe actually no, that's different. Sorry,
it's just MSA.

Manu Sporny: Yeah.

Manu Sporny: Yeah. I guess I'll just do the entirety of this thing.
00:15:00

Manu Sporny: All right. So, there's that one. And then what was the other
one? We want to where is this? And then we want to modularize following
algorithms duplicate text where the friends between text seems to be

Manu Sporny: These are used following algorithms could be organized.

Manu Sporny: Which ones

Will Abramson: so in the current PR I have abstracted out the
transformation I think I've abstracted out like the three middle ones right…

Will Abramson: where transformation hashing and else but Dave is saying the
multibase encoding could be transformation, hashing and proof configuration
now go into a common algorithm section and that are called by the
respective algorithms right and…

Will Abramson: then just pass in okay this is my parame like amma I'm going
to use this cryptographic algorithm sort of thing

Manu Sporny: Yep. Okay.

Manu Sporny: So some of those are already done. eventually Are there any
other algorithms? to a general

Will Abramson: Yeah. Yeah. Yeah, I mean it's sort of like transformation,
hashing and roof configuration could all be in data integrity but maybe
hashing just needs to be passed in the parameter of the hash function which
people might change and…

Manu Sporny: Mhm.

Will Abramson: also transformation people might be using different
transformation algorithms.

Dave Longley: Yeah. …

Manu Sporny: Yep. Okay.

Dave Longley: I am taking a look at the preview for that that's going to be
merged and if you take a look at I don't know if I want to I mean I can put
whatever link I'm looking at. Yeah, if you bring up and share screen on
that each one of the individual crypto suites more or less completely
replete repeats all those steps like create proof that that's there for
MLDDSA 44 and…

Dave Longley: you go click on the SHs 2025, it's going to repeat all those
steps and everything's identical except for the parameters. And that's true
for all of these algorithms.

Dave Longley: And I think we could clean that up.

Dave Longley: So all you do is say these are the parameters that go into it
and then the steps are all in one place.

Manu Sporny: Mhm. Okay.

Will Abramson: Mhm. …

Manu Sporny: Create proof. yep.

Will Abramson: so then if we put that into data interpretive to define a
crypto suite, all you'd be doing is selecting these parameters, right?
Which makes sense. Yeah.

Dave Longley: Yep. what we might want to do and we took a more functional
approach and we wanted to clean this up even more with our data integrity
selective disclosure functions. We might even want to start defining these
as functions because it's easier for developers to look at that.
00:20:00

Dave Longley: we don't want to make strict APIs of course but saying this
is the interface for this again interface is a danger dangerous word here
too but using that sort of structure makes it easy for people to see what
they're going to have to implement and that there are going to be some
functions that they'll create and then there are parameters for those
things. and there's work to be done to figure out how to do that just right
so we don't trip any of the red flags around using web IDL or…

Will Abramson: Mhm.

Dave Longley: having people think we're telling them they have to build
strict APIs or interfaces. but that makes the spec easier to consume.
especially from a developer perspective where developers understand their
functions and parameters for things.

Dave Longley: And you can change all that stuff up and fundamentally we
just have algorithms, but writing it that way in the spec makes it easier
to follow.

Dave Longley: And it's probably how most people will go about implementing
it anyway.

Manu Sporny: …

Manu Sporny: I'm trying to figure out the difference between kind of what
we have here and what you're saying. this is

Dave Longley: So that says proof verification and then it has experimental
Falcon 2025.

Will Abramson: Mhm.

Dave Longley: Instead there should be a single proof verification algorithm
and it takes whatever parameters go into this it says the required inputs
are data proof bytes and proof options and instead wherever falcon is it
should say you call the proof verification thing with these inputs the end
you don't repeat steps one two and…

Manu Sporny: All right.

Dave Longley: three in this section and then also in the SQI section and
the SHs section and so

Manu Sporny: Right. So maybe then this needs to be parameterized. The
Falcon digital signature algorithm is the signing algorithm and…

Manu Sporny: that has to be an input to the proof verification algorithm
yeah. Okay.

Will Abramson: Yeah. …

Will Abramson: I guess the verification algorithm would be in here, And
then signing great proof or proof zero.

Manu Sporny: we will want to specify what yeah, we'll want to do a test
trial on one of these, I'm trying to think of maybe create proof would be
I'm trying to figure out what the easiest one is going to be to do. I guess
we will. Yeah, I mean someone's just going to have to sit down and try to
tease this apart.

Manu Sporny: But I think in teasing in part it's make it so generalized
that we can just put it in data integrity once we're done with it. there'll
be a general algorithm section. We'll just chunk into the data integrity
spec. yes that's always possible.

Will Abramson: And then there should also be the case where I can overwrite
those general algorithms right completely if I so desired.

Dave Longley: Yeah, the idea is to provide common primitives that you can
use when you're writing your spec…

Will Abramson: Yeah. Yeah.

Dave Longley: if it makes sense to do but you can always either not use
them at all or change them in whatever ways you need to in the individual
specs.

Manu Sporny: Okay.

Manu Sporny: All right. So, where I'll just leave it at this. And then
thinking about ECDSA how modularized are the selective disclosure
functions? I mean they're pretty

Dave Longley: Yeah, you can see where those end up getting used. and…

Greg Bernstein: Okay. oh.

Dave Longley: they're given titles that are functions and…

Dave Longley: then somewhere those get referred to.
00:25:00

Manu Sporny: Yeah, it usually tells you when guess that's Yeah.

Manu Sporny: I think there's a way to externalize these. I forget exactly
how, so all of these in theory, we can move to data integrity eventually.
yeah, we can move to data integrity eventually. And then we'll end up
calling those from the postquantum one and these other ones as well, right?
What about these…

Dave Longley: and it calls most of

Greg Bernstein: Yes.

Manu Sporny: what about this thing here? it says it's ECDSASD? Are these
just very specific to ECDSASD?

Dave Longley: They might be and some of it certainly is but we might be
able to abstract some of it further. I'm not sure some of this might just
be reusable if you passed in parameters the header values and so on. If the…

Dave Longley: if the general process that's going on here is going to end
up being the same with the postquantum suites, then I think you could just
parameterize these as well.

Manu Sporny: Okay.

Manu Sporny: That's further work to be done in I think the only reason I'm
bringing it up is that, it is going to be important to have a selective
disclosure postquantum, thing. And because we have four different
postquantum schemes, it's just going to be kind of a pain to have to do a
selected disclosure version for each one of them. If we have to copy and
paste this, four different times, it's not.

Dave Longley: Yeah, we're going to want to generalize it to the greatest
extent we can.

Manu Sporny: All right.

Dave Longley: I would expect it at the end of the day, unless we're
changing fundamentally how it works, it's just going to be changing
parameters.

Manu Sporny: All right. So, we'll make another pass on That's going to take
months, I mean, it'll take a while for us to get this all sorted out so
it's nice and clean. but this is going to force us to do this because we've
got four different crypto suites in here. Each one of them, we probably
want to select disclosure version of it. yep.

Manu Sporny: Let's see. I think the other thing is we do well. So, are
there any other issues that we want?

Manu Sporny: I mean, I think large This will get addressed with Will's PR.
Yes. Yeah.

Will Abramson: There's just one thing…

Will Abramson: which is like we need to add some examples I think ideally
Okay.

Manu Sporny: And we'd need an implementation to start doing that. So
examples are easy, meaning respspecvc will allow us to generate examples
the second we have a JavaScript implementation of this stuff.

Manu Sporny: And so, I think that's so for folks that don't know, but
there's a thing called respspec VC, which is a plugin for respspec and it
generates digital signatures. You tell it what kind of digital signatures
you want it to generate and it you just give it the crypto suite name and
it'll generates a bunch of other stuff too as well as cyborg and QR code
encoded cyborg and SD jot and…

Will Abramson: Mhm.

Manu Sporny: cozy and all that kind of stuff. so I think we'll just reuse
this right but what we need is an implementation in JavaScript and we tend
to use digar's open source libraries to we just pull those in and do that.

Manu Sporny: I guess this also generates digest multibase values as and
then receive if we look at any one of these examples, let me see if can
find Yeah, here's an example like example three. This is a ECDSA proof
that's automatically generated with respect. Every time you reload when you
reload the spec it generates a new example.
00:30:00

Manu Sporny: It actually does a canonicalization and signature and it does
it for hosy and cozy and sdjot as well, although I don't think anyone
really has figured out if that works. so I think'll in the postquantum
things, we'll have one for, MLDDSASD, and so on so forth, does that work
for you, Will? I mean, the unfortunate thing is it pushes off our being
able to see what this looks like for a bit, but at the same time,…

Manu Sporny: I mean, it shouldn't be that difficult to create the crypto
suite, I think we've got it modularized pretty nicely already.

Will Abramson: Yeah. No,…

Will Abramson: that all makes good sense, I guess. So, the big thing I need
to do is do Any tips on that? I don't really do rebasing very often.

Manu Sporny: you check out the repository. you pull the main branch,
whatever the latest is, make sure it's up to date, and then if you're
working on the command from the command line, you check out the pull
request and then you do a get rebase main and…

Manu Sporny: that will replay.

Dave Longley: First, you back up your branch.

Manu Sporny: Yes, of course. yeah,…

Dave Longley: Make a backup of your branch and then go do surgery on your
current branch.

Manu Sporny: because it's highly likely that things will blow up and you
might need to try it.

Dave Longley: Especially if you haven't done it before.

Manu Sporny: Yep. Yep. Yep. And the way you do a backup is you just do a
get checkout-b to create a new branch on your branch and just rename it
something different and…

Will Abramson: Mhm.

Will Abramson: Mhm. Yeah.

Manu Sporny: just make sure you're working on the non-backup version.

Will Abramson: And can I do that instead I was currently working through it
rebasing upstream…

Will Abramson: which is the W3C CCG repo to my branch. But is it better to
check out the PR

Manu Sporny: You will need to make sure your branch is …

Manu Sporny: we need to just give you access to this repository. okay.

Will Abramson: I probably have it.

Manu Sporny: But I think you've h give me a second.

Manu Sporny: So, here we go.

Manu Sporny: Yeah. You've got it, mineral. So, you could check this
repository out without branching and…

Will Abramson: Okay.

Will Abramson: Okay. Yeah.

Manu Sporny: and do what I mentioned. but…

Will Abramson: Yeah. Yeah.

Manu Sporny: since you've got your own branch, you have to make sure since
you've got your own local copy, you have to make sure that main branch is
updated to the latest one for this one.

Will Abramson: Yeah. Yeah.

Manu Sporny: And then you do the rebase and all that kind of stuff. And
then when you push your changes to your repository, they will automatically
be updated for this one.

Will Abramson: Yeah. No,…

Manu Sporny: So that should be the process. and if for whatever reason
you're hitting issues, just ping me and I might be able to help.

Will Abramson: no, that's great. And in terms of rewriting some of these
bad commit messages, that is part of the rebase process, right? Okay.

Manu Sporny: That's a different part.

Manu Sporny: So you rebase to fix you can do both of them at the same time.

Will Abramson: Okay. because it's weird.

Manu Sporny: I wouldn't suggest Rebase to fix the merge conflicts first.

Will Abramson: It doesn't say there's merge conflicts there based.

Manu Sporny: When you switch to Yeah.

Will Abramson: Okay, that's why.

Manu Sporny: It'll say and who knows what it is. Sometimes it can auto
figure it out.

Will Abramson: Yeah. Cool.

Manu Sporny: Other times you have to go in and make manual changes to the
commit to unblock it. I don't know so hopefully it'll rebase fairly cleanly.
00:35:00

Will Abramson: That's Yeah. Yeah. Yeah.

Manu Sporny: I don't know what we really did in the like I don't know what
we Yeah.

Dave Longley: You'll find out. It'll be exciting.

Manu Sporny: Yeah. I mean, this thing hasn't been touched.

Dave Longley: So, some kind of conflict will come up. You'll have to
resolve it as you walk through the rebase.

Manu Sporny:

Manu Sporny: Yep. Yep. okay. I think that's it for this thing. and then
once it's in there, we can go and go and redo that stuff. let's talk about
the issues. Greg, how much time do you think you'll need for your update?

Greg Bernstein: Five to 10 minutes.

Manu Sporny: Okay, let's time box this to 45 past the hour and then we'll
spend the last 10 minutes with your updates, Greg. we need to pick multi
names. The last time we had this discussion, we said, let's pick the same
stuff that the ITF is using. but they have not picked names for Falcon or
SQI. And I think the names that they're picking for the other ones are
crazy long. …

Manu Sporny: I'm trying to figure out

Dave Longley: I put a couple links into the chat.

Dave Longley: The first link is what they're doing for MLDDSA over at At
least currently it's all in draft form. they have a draft for Falcon that's
old. just what's the word Falcon in there? And my understanding all the
stuff I've been reading is they're going to use for Falcon.

Dave Longley: So in NIST so maybe we want to it's our provisional names on
that.

Manu Sporny: And this is Mike and…

Manu Sporny: Y. Hey.

Dave Longley: And if you click on the Jose algorithms on the right 8.1.1
and 8.1.7 they have the same string names in both sections. Those are the
names that are there.

Dave Longley: hopefully that is stable. That's what they're going to pick
because I don't think we should pick something that's different from this
group because it just ends up getting confusing. Yep.

Manu Sporny: Okay. So, it's going to be 44. all right. So we are trying to
align with those cozy names which time

Manu Sporny: is you say is it not 65 87 live ML DSA I forget for 87. And so
for a stateless hash are they really using the full name here?

Manu Sporny: No, those are the algorithms. okay.

Dave Longley: I think that's too far out of date.

Dave Longley: And what I've been reading from NIST is they renamed MLDDSA
from Dithium or whatever it was. they're going to rename Falcon to DSA is
my understanding unless they go with FT for their fast for transform but
just under whatever it's doing in the underlying algorithm. I don't know…

Dave Longley: what numbers are going to follow that, but there's a 512
version today and a 1024, but they might map that to something else. But I
think if we're going to guess today, that would be the best

Manu Sporny: I guess you can always change it later.

Manu Sporny: And then for SLH presumption it's going to be two, three. All
right. …
00:40:00

Dave Longley: I put a link to the SLH draft.

Manu Sporny: where's There we go. Jeez.

Dave Longley: So on the right 6.1.1 and 6.1.2 would have the algorithm
names.

Manu Sporny: Those are the algorithms, not the keys. All right. Or is this
one of the key identifiers?

Manu Sporny:

Dave Longley: Yeah, there's a key pair example on AD1.1 and…

Dave Longley: they just reuse the same names. So,

Manu Sporny: No, that's awful.

Manu Sporny: Why didn't they just use the security levels? Would have been
so much better.

Dave Longley: I guess there's some I have not implemented that algorithm.
Presumably you need to know something additional there.

Manu Sporny: What is this thing? It's like the Shaw 2 128 shake 128 and…

Dave Longley: It's a hash and then the security level.

Manu Sporny: the F

Dave Longley: I don't know what 28s is unless it's I don't know what it is.

Manu Sporny: What was it? These are impossible to remember.

Dave Longley: SHA 2-128s.

Manu Sporny: Shu and shake 12.

Dave Longley: Maybe that means that the security level matches all the
things there.

Manu Sporny: Then 128F.

Dave Longley: So maybe I don't know what that number is at all.

Manu Sporny: Yeah, it's So, is that They're just three variations. Yep.
Looks like they're just three variations. that means there's only one
security level. If those numbers are what we think they are, that doesn't
match what NIST has published. Yeah.

Dave Longley: Yeah, their spec could be out of date. It could also be that
one matters less. the security of that one is far less in question than the
others since it's all hashbased.

Dave Longley: It might also be the case that we might want to register all
those but we might not care to do the shake one because it's harder to get
implementations on the web for that though maybe that's changing in the
latest web crypto group. I don't know.

Manu Sporny: Yeah. Yeah,…

Manu Sporny: I think this one was the one that had a security level of one
and five and didn't have an intermediate one. I remember. No, that was
Falcon. No, this had three security levels. I mean I'm very loathed to
register something in the multike key in the multi-codec thing that is just
going to be wrong in over time. I think we can go in and change it later
maybe, and…
00:45:00

Manu Sporny: I don't remember if that's already. Okay. let's see. for SQI,
is there anything yet?

Dave Longley: I don't think so.

Dave Longley: Yeah, I don't think so.

Manu Sporny: Just noting that we are at time a little over. we'll have to
come back to this because we'll need to pick some values for SQI or we can
just leave it open for now until SQI gets a little further down the pike.
with that let's go ahead and…

Manu Sporny: switch over to you Greg. how is the postquantum BBS stuff
coming along?

Greg Bernstein: Okay. …

Greg Bernstein: the everlasting privacy of the pseudonyms. There's nothing
post quantum because it's all using discrete log stuff, but it's
everlasting privacy, meaning nobody can figure us out. Not that they
couldn't forge things in the future, So, they can't track couple weeks ago
we went over some different implementation approaches to computing a
pseudonym based on a vector of secrets.

Greg Bernstein: And this gives us if the vector is of length we can use our
pseudonym up to n different contexts in a world where there becomes a
quantum computer that's cryptographically relevant and still not have them
be able to trace us. So that's different contexts, n uses because you can
keep coming back to the same context as many times as you want with a new
proof or not and use that pseudonym that doesn't count that doesn't impact
this.

Greg Bernstein: Now we came up with a one approach that it looks like we're
computing a polomial evaluation. All the methods we discussed still fall
under existing theory of generalized linear relations for sigma protocols.
The reason why they're linear even though we're talking about polomial is
our vector of secrets those end up being like the polomial coefficients not
the thing that gets squared or cubed or whatever. So we're good with
theory. What we're waiting trying to just nail down are two things.

Greg Bernstein: how we update our challenge comp computation that's used in
the proof and the more important one is how we bind the length of the
pseudonym vector because we need to know that and we have to bind that
somehow to the system to avoid civil attacks. We have to make sure every
time the holder uses or creates the pseudonym, they are using the same n
values that they signed. They can't pick and choose subsets of them was the
attack that will allow them to assume different identities from the same
credential. there were two different ideas on that.

Greg Bernstein: mine was to bind it in with the signature. So it had to be
known and not a public parameter but a revealed parameter. The other one
approach was make it a constant for whatever your system is doing. So, we
wouldn't protect that down at the BBS layer. less in favor of that because
I like the idea that people had a little bit of choice with the holder
could have some choice about how long they make it up to limits maybe set
by the issuer or the verifier and such like that. So those are the two
things that are just under review.
00:50:00

Greg Bernstein: Once we resolve amongst the other authors and any other
entries party I think we're pretty much ready to go because this polomial
evaluation approach where it looks like we're in the case of n equals 1 we
just default it looks like what we originally had. So if people aren't
concerned about the quantum computer aspect of it, it goes back to the
simple version of what we had before without doing anything radically
different between the cases. So it looks pretty good. We just need to
finalize that decision and update the I CFRG draft and test vectors.

Greg Bernstein: So, I think we're in pretty good condition. It's just
grabbing people right at now when some people are involved with teaching
and things like that. and school's ending right this second. it's been a
little hard to get some more inputs to nail these things down, but that's
where we're Notice that this does not this kicks up like the usage
discussion up to maybe RW3C spec rather than the CFRG, right? The pseudonym
spec will allow you to use a vector of secrets, allow you to set how long
you want it to be.

Greg Bernstein: we can give indications of the performance about that but
doesn't include the discussion like we've talked here about what's a
reasonable number Dave

Dave Longley: something if it gets kicked up to us here at W3C, something
we should consider is that number itself can become a correlator that might
result in unwanted correlation. And so if we allow people to configure it
in the VCD DIBBS spec, we might want to say you can choose from different
levels. You can either do n equals 1,…

Dave Longley: n equals 10, 100 or thousand, something like that to try and
help mitigate that. we could always make that a should as well at the spec
if people really need to get more flexible, but we'll want to talk about
that in privacy considerations.

Greg Bernstein: Yeah, it's No,…

Greg Bernstein: it's having it be a thousand and one versus a thousand may
be great for trace trackability, And defeat the purpose. Yes.

Manu Sporny: All so I guess Greg,…

Manu Sporny: do you need any feedback from the group on next steps or does
this feel kind of mechanical from here on out?

Greg Bernstein: We got to get the CFRG draft and…

Greg Bernstein: then finalized with the implement that those pieces. We
know we have this parameter. Then as Dave just said, we got to discuss it
and the appropriate handling of it in the W3C, right? we haven't written
up, this aspect, that'll go into our privacy security section and the BBS
thing.

Greg Bernstein: And if we want to select some of these, three classes of
values, 10, 100, and a thousand or whatever, that would be our job after
the CFRG thing. So I got to get that part down with the CFRG, any inputs
people might have. But like I said, just a couple decisions, I think, now
and to finalize and then we should be all good to go. Yeah. Yeah.

Manu Sporny: Yeah. I'm wondering if we should pull u Wes in to do an
analysis on how to pick the right end. or what the end means. unless you
were going to do that, Greg. I'm trying to take things off your plate so
that you're able to, focus on the other things that need to be done. Mhm.

Greg Bernstein: I mean the higher level. Yeah.

Greg Bernstein: what N should be in that discussion. That's right. That's a
chunk of text.

Dave Longley: Just a reminder we also have another discussion in BCDI BBS
space or another analysis we want to do which is on can you pick the right
number of HMAXs for anonymizing the blank note identifier.

Greg Bernstein: Yes, the Yeah,…
00:55:00

Dave Longley: So that's another thing we want to do some analysis on and
there might be a right number and then we can just put that number in the
spec.

Greg Bernstein: that can help counter some of the u issues that Obby kind
of brought up that I don't know. I mean, we can help just relieve some of
that concern. I think I see.

Manu Sporny: So, I guess that's a reminder to us to ping Wes about those
analyses that also need to be done and…

Greg Bernstein: Yes. Okay.

Manu Sporny: written up, and put in the spec eventually. we are out of time
today. next week we will be meeting and Ying Tong will be giving us an
update on some of the work that she's been doing. we'll be trying to figure
out how to more closely integrate the work she's doing with what we've are
doing. I've got some updates. I was able to speak with NIST kind of
directly about BBS and Google's approach and that sort of thing. so I can
provide some input there next week. and that's it for this week.

Manu Sporny: We'll look for a refactoring or rebasing from you and…

Will Abramson: Yep. Cool.

Manu Sporny: we'll merge that in as quickly as we can. and then we'll keep
moving forward on generalizing those algorithms. All right. hope everyone
has a wonderful weekend and we will see everyone next Friday. Take care.
Bye.

Greg Bernstein: Bye.
Meeting ended after 00:56:47 👋

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