Data Integrity meeting summary for 2025-03-14

W3C Data Integrity Meeting Summary - 2025/03/14

*Topics Covered:*

   1.

   *Greg Bernstein's IETF Presentation Overview (BBS):* Greg Bernstein
   presented a high-level overview of his upcoming presentation to the IETF
   Crypto Forum Research Group on Blind BBS Signatures and Pseudonyms. Key
   points included: the three-party model used in the BBS specs, updates to
   APIs and test vectors, the addition of explanatory text to clarify
   pseudonyms and their limited linkability (computationally, not
   statistically unlinkable), and the ongoing discussion regarding
   post-quantum resistance. A key discussion point was the difference between
   BBS proofs (with everlasting unlinkability) and pseudonyms (with
   computational unlinkability). Naming conventions within the API were also
   discussed.
   2.

   *Introductions of New Attendees:* Kamal Lakrioui (DT Lab, Canada) and
   Victor Lu (SPDX community) introduced themselves and their interest in the
   work.
   3.

   *Will Abramson's Schnorr Signature Spec Updates:* Will Abramson
   discussed two pull requests related to his Schnorr signature specification:
   one addressing a security concern by changing the hashing process and
   another adding descriptions of multi-signature protocols. The group
   confirmed the security fix, and the multi-signature addition was discussed
   with focus on whether the number of parties involved in a multi-signature
   can or should be hidden. The group also discussed FIPS compliance and its
   implications for the specification's use of SHA-256. The use of SECP256K1
   curves in relation to FIPS compliance for “blockchain-related applications”
   was noted.
   4.

   *Open Agenda Items:* A brief discussion touched on rate limiting in a
   three-party model, and how this might be addressed with pseudonyms. It was
   concluded that the existing pseudonym mechanism potentially covers this,
   and the need to engage with Sam from the Google privacy sandbox team on
   this aspect was noted.

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

Andrea Vesco, Dave Longley, David C, Eddie Dennis, Greg Bernstein, Greg
Bernstein's Presentation, Hiroyuki Sano, Kamal Lakrioui, Kayode Ezike, Manu
Sporny, Manu Sporny's Presentation, Victor Lu, Will Abramson
*Transcript*

Manu Sporny: Hey, good morning. I'm wondering if you would be willing to go
over some of your slide deck today for the ITF meeting just to give
everyone a heads up.

Greg Bernstein: …

Manu Sporny: I think it would serve two purposes. One is bringing everyone
kind of up to speed with where we are and any feedback on maybe not for the
meeting coming up, but beyond there.

Greg Bernstein:

Greg Bernstein: it is. Yeah. and I can indicate what's going on with this
kind of presentation at the IETF because it's not a tutorial.

Manu Sporny: Yeah, I Yeah, of course. Yeah, absolutely.

Manu Sporny: And I'm not asking for a full run through. I'm saying let's
kind of jump from slide to slide and you kind of explain what we're trying
to convey. it doesn't need to be a full presentation.

Greg Bernstein: Yeah, sounds good.

Manu Sporny: Okay. Thank you.

Manu Sporny: We'll start probably in about three minutes as soon as other
people join. Yes. Yeah.

Greg Bernstein: I don't know

Greg Bernstein: if you're going to have the same problem we did earlier
this week with the BBS call because Europe doesn't switch yet. they switch
a week later. So,

Manu Sporny: We'll see.

Manu Sporny: All let's go ahead and get started now. we've got a couple of
new people. We can do some introductions to start. the other, item that
we're going to cover today, is, Greg's presentation to the Internet
Engineering Task Force, crypto forum research group that's coming up, is it
next week, Greg? and…

Greg Bernstein: Yes. Thank you.

Manu Sporny: and then we can go into open items. Anything anyone wants to
discuss about the work in general that we're doing here? so I think we've
introduced most of the folks here, but Kamal, I think you're new and
Victor, you're new. So Kamal, would you mind giving us just a real quick
introduction to yourself and why you're interested in the work?

Kamal Lakrioui: Hi, good morning Yeah, my name is Kamali. I work in DT lab
from Canada. We are in digital identity the nonprofit organization and we
work with government and private sectors to build digital trust solution.
We are more focused on compliance to the standards. do we have done some
testing to some solution if they are compliant to data model 1.1 or 2.0 and
yeah the data integrity is part of that. So this is why I'm here. Thanks.

Manu Sporny: Welcome to the call, Wonderful to have you here. Victor, do
you mind giving us a quick introduction to yourself?

Victor Lu: Yeah, I'm a little based in Tampa, Florida. I actually
participate in another community called SPDX, build a material community.
standard, data integrity is important there as well. And of course, the
critical part is also interesting. That's why I'm here. Thank you.

Manu Sporny: Welcome Victor. Wonderful to have you here. We are very
familiar with all with that let's go ahead and jump into The first item
Greg's going to give us a highle overview of the presentation that he is
giving on BBS to the crypto forum research group. this is not a tutorial.
there's some expectation that you understand BBS at some level,…
00:05:00

Manu Sporny: but of course, we can dive into details. over to you, Greg.
Yes.

Greg Bernstein: Let's see…

Greg Bernstein: how do I make the slideshow format. Can you see that?

Manu Sporny: Thank you.

Greg Bernstein: So this is a presentation to the crypto forum research
group which is part of the IETF which is actually part of the internet
research task force. So they look at longerterm problems and things that a
little bit further out. Somehow the CFRG has become the place to do open
cryptography. Okay, I mean it's not even just for IETF specs. Before it
used to be like cryptography and IETF specs. BBS is being quote
standardized there.

Greg Bernstein: they had some weird language in that group saying we don't
do standard cryptographic standards but they have the weight of
cryptographic standards. So HMAX and things like that have been
standardized there. there are three BBS specs now of that are Getting to a
working group draft is the hard part. You have to have good cryptography in
general and you've got to have an application that people want. the rest is
getting the details right in your cryptographic protocol and such. Okay.

Greg Bernstein: BBS signatures has been around for quite some time and
that's the basis for what we've got in our BC spec. Blind signatures and
pseudonyms add on top of that some nice functionality. Blind signatures
help do what we call holder binding or multifactor holder binding in a
sense providing security more to the holder. S pseudonyms allow for limited
linkability on top of what would otherwise be un unlinkable sign proofs of
signatures. Okay.

Greg Bernstein: One thing is some folks work with a two-party model. And so
there sometimes gets to the confusion. verifiable credentials the BBS specs
all are working with threearty models. So sometimes you'll see something
called BBS sharp or BBS with verified keys or something like that. Those
are two-party models. That's where the verifier and the issuer are the same
people. That's not what we're doing here. And so sometimes you'll hear
people talking about those things and So S here's once again we reminded
people of our threearty model. What's happening with BBS signatures? This
has gone through even crypto panel review. It took a long time to get it
through there.

Greg Bernstein: We have addressed the questions and hopefully we're trying
to get the last call basically is where we're going with this draft.
Everything has been very multiple open source implementations. So we're
trying to get this Blind BBS signatures like I said offers more protection
to the holder. sorry the terms signer would be issuer groover would be
holder ve is in verifiable credential language. This provides once again
protection to the holder prover. Okay. What did we do?

Greg Bernstein: We mostly updated the APIs, mostly naming just to make it
clear, less confusion between BBS signatures and blind BBS. we added a full
set of test vectors. Okay. And we have two implementations that have
verified those test vectors. what we're doing next. We want to get a little
more wider review of the API, particularly with the cryptographic community
to see if there's anything we should change. This is pretty stable. Okay,
here's we summarize the API and the only two things is some changes to the
naming of those APIs.
00:10:00

Greg Bernstein: Okay. Question.

Manu Sporny: Hey Greg, on that more a comment. it might be and this is a
minor thing but you might want to say that changes are in blue here. it was
if we don't have you narrating I was confused about what's the difference
between the blue and…

Greg Bernstein: What's the difference? Okay.

Manu Sporny: gold and the So tiny little text maybe bottom right or
something like that that says hey these are the things that changes in blue
or…

Manu Sporny: something like

Greg Bernstein: Good point.

Will Abramson: It does say API changes though. Is that not what that is?

Greg Bernstein: It repeats Our section over here, API changes, but we could
put them in blue.

Will Abramson: Maybe put that in. So,

Greg Bernstein: And I do work on these slides with my co-author who's a
continent or more away. So sometimes changes into slides and things take a
while. Okay. Pseudonyms which I look at is they help provide limited
linkability.

Greg Bernstein: So they preserve some nice properties about unlinkability
but they give us limited linkability meaning we can come back to the same
verifier and they'll recognize us. They're actually a little bit more
general than that and that's why we're proposing some more explanatory
text. basically what we're doing is binding a secret value known only to
the prover to the signature issued by the signer.

Greg Bernstein: We then combine that secret value with a public value in a
cryptographic way to produce a pseudonym. So the verifier can recognize
that pseudonym and we really know the things that go into producing the
pseudonym via ZKP and that's the pseudonym mechanism. Okay, but it's more
useful. you can do things where you can come up with a pseudonym that you
use across multiple verifiers.

Greg Bernstein: So that's why we have this notion of a context not my
wording I know we have a lot of issues with context and that term is very
loaded for JSON LD but we have the notion of a context we combine that
context with the ruber secret to come up with the pseudonym the question of
who chooses that context depends on the application scenario. If we're
protecting the verifier, they're going to choose the context. If we're
allowing the prover to assume some kind of pseudonym across multiple
verifiers, some kind of proof of personhood, they would probably choose the
context. Okay, so that's why I even put in the issue about, hey, this is
good for personhood credentials. Whoops. Okay.

Greg Bernstein: more details about this fact that this thing known as the
NIM secret which is only known to the prover has two pieces to guarantee
uniqueness per signer. And so we actually do a blind signing of the sum of
these two pieces with some nice cryptographic ways we do that because the
signer only sees the commitment with the prover. The synonym is done with
discrete exponentiation. One thing that to note is unlike BBS proofs which
have everlasting unlinkability, pseudonyms only have computational
unlinkability.

Greg Bernstein: So in the future if there was a quantumly relevant computer
somebody could use this look at those pseudonyms and link them together if
they can crack discrete log. That is not the case for general BBS proofs
because each one is produced with new randomness. question. Yeah.

Manu Sporny: I think it's a question around how we communicate this more
clearly to a general population because it sounds scary it's like no this
is going to be some ter and it is if quantum computer comes around but I
mean BBS itself is not postquantum resistant right so I don't know I'm
trying to figure out a way like yes the pseudonyms are not postquantum
resistant…
00:15:00

Manu Sporny: but BBS itself is not postquantum resistant so there's no real
change to the security properties

Greg Bernstein: Yeah. No,…

Greg Bernstein: it's just that the BBS proofs have this nice everlasting
unlinkability property and pseudonyms don't. Somebody filed a issue on our
repo about that and…

Manu Sporny: Right. Mhm. Okay.

Greg Bernstein: so we do need to put it in the security privacy section
which we haven't written yet. So these are the kind of things
cryptographers jump up and down against if we don't point them out. We do
not want to in the general text diss our own thing about this. This goes in
the security privacy section later on, but if we don't mention this in
front of the cryptographer, somebody might have a little hissy fit or
something.

Greg Bernstein: We just want, …

Greg Bernstein: because it's very nice that proofs have everlasting
unlinkability. And the cryptographic review panel was going, " How can you
have that if BBS isn't quantum safe?" Each proof brings in new random
numbers. That's why. And so they had to do that. So we knew it was going to
come up. So yeah,…

Manu Sporny: All right.

Manu Sporny: Yeah, good point. Dave, you're on the queue.

Dave Longley: Yeah, I think it is going to be asked to have the property of
everlasting unlinkability for pseudonyms and the question is how
challenging would that be? Is that possible? I think that's going to come

Greg Bernstein: I had this discussion. right now the way pseudonyms are
done so if you go back to Anna's paper back in 2000 pseudonym systems they
based it on a one-way functions are all computational. So yeah, you can
come up with a postquantum version which I've talking to people about, but
it's still going to be computational rather than statistical unlinkability.
At least my understanding

Dave Longley: I know that Sam Schleser was mentioning some alternative
approach that might have under everlasting unlinkability.

Dave Longley: I don't know precisely what they're doing over there. There
is a GitHub issue related to his work.

Greg Bernstein: Yeah. What?

Greg Bernstein: Yeah. With the ARC stuff, it's also a two-party model and
they're talking about using pseudo random PRFs, verifiable oblivious random
functions or something. So, it's a two-party model. And so, I was looking
at that going, can they get away with this because they're not quite doing
full pseudonyms? going because if that would be a great thing, but then I
would went back to Anna's paper. It's like here this great general
pseudonym mechanism and all it requires is the existence of one-way
functions.

Greg Bernstein: So, I forgot to ask Anna this on our call the other day,
but we were talking about rainbow creation more, but it'll be a good
question. I bounced this around and Michel or Mik Oruru is a pretty good
cryptographer, so they did not seem to indicate that I have an easy way out.

Dave Longley: Okay, it's good to know and…

Dave Longley: I definitely think it's one of the more important questions
about the spec.

Greg Bernstein: Yeah. …

Greg Bernstein: sorry, another busy slide, but this also shows a nice set
of APIs that are really being nailed down. Okay, we came up with just more
consistent naming.

Greg Bernstein: Thanks Dave for some of the recommendations and it also
shows how much we reuse what's already there. I had some discussions or I
did another email with some authors of a postquantum paper and they were
saying, " our stuff is advancing and here's this new work." And I looked at
their new work and it slotted into their existing stuff nicely and it's
like breaking up these complicated cryptographic protocols into reusable
pieces such as we see here really helps from the point of standards
development because standards take a long time to develop and if one piece
gets
00:20:00

Greg Bernstein: optimized. So it saves us a lot of things. We just replace
that. Yes, I know it alters the test vectors, but that's not too hard to
do, but getting the whole framework. Go ahead. Sorry. …

Manu Sporny: No, no, it's fine. Finish that thought, I had a minor nit on
the naming. yeah,…

Greg Bernstein: we still have plenty of time to change it, but not for the
slides went to the working group chairs already. Those they were due
yesterday. but we're happy to take any comments on the name.

Manu Sporny: the general I think comment is that it's confusing that we
keep going between kind of snake case and Pascal

Manu Sporny: case. Yeah.

Greg Bernstein: Tell me about it. Yeah. boy.

Manu Sporny: I mean, and I know it's a minor nit, but it's kind of like, I
was looking on the left and…

Manu Sporny: I was like, okay, snake case for variable names and Pascal
case for functions, but that doesn't seem to be the case either. Yeah, I'm
wondering…

Greg Bernstein: If there's any sense of some of these is internal only
functions or…

Greg Bernstein: helper routines get the snake case. I wasn't an author on
the core draft so I didn't have inputs on those so it's remember're go if

Manu Sporny: if it's too late to write in and say, "Look, like rename some
of this stuff, if it's internal, start the thing off with internal or
something like that."

Manu Sporny: This is not, it's my Yeah,…

Greg Bernstein: those kind of things all come out and can be addressed and
people taking a deep look at going into last call and it doesn't impact
test vectors. so any of those things I think are good comments.

Manu Sporny: it doesn't change any of the test factors. Yeah, I mean my
concern is largely that someone misunderstands…

Greg Bernstein: I just

Manu Sporny: what some of these functions are and I don't know if there any
security implications for having internal functions not be marked as such
in a library or exporting those or they're just low-level kind of
understanding questions

Greg Bernstein: Yeah, I'm used to Yeah.

Greg Bernstein: Upper case meaning upper camel case being class names lower
camel being the whole thing.

Manu Sporny: Mhm. Yeah.

Greg Bernstein: Yeah. Agree.

Manu Sporny: Yeah. Yeah. I mean, I guess Yeah. it's a consistency thing
because if there's no consistency here or if the consistency is
non-standard, developers are going to have a harder time implementing it
correctly than if not. That's Yep.

Greg Bernstein: What are we going to do? the pseudonyms is the only one
that's really lacking in explanatory text because once again, we went from
just this notion and the name was actually called perverifier linkability
to, wait a second. There's a whole lot of long history for pseudonyms and
the ABC for trust work in 2014 actually came out and said hey we got
certified pseudonyms scope exclusive pseudonymms blah blah blah and kind of
said these are the ways you can use them in different flavors including raw
verifiable which are just kind of saying look you have a secret it's got
nothing to do with a credential

Greg Bernstein: versus ones that are tied to a credential, which we're
concerned with, We're tying a pseudonym to a signature over some other
stuff. So, we need to add some more text. And so, we were going to add in a
short. for folks who want to see more myself, Dave Manu, Kim Duffy put
together this short history of cryptographic pseudonyms. So that's where
this is kind of coming from. And so that's what we're going to add
textwise, and make sure we, explain the BBS pseudonym features nice and
explicitly in a readable way.
00:25:00

Greg Bernstein: If you've ever looked at some of the other crypto specs,
sometimes they leave you scratching your head going, "What's this good for?
How do I use this? What are the secret values? What are the public values?"
I mean, that's been improving, but boy, you look at some of them, you're
going, " And how do I use this properly?" And that's starting to come up
and being more important to write. So, this is kind of what we're planning
on adding as far as explanatory text. but if people want to see more, we're
happy to add. it's sometimes harder than writing the cryptographic formulas
and descriptions of what you're supposed to do and that's what we're going
to be presenting.

Greg Bernstein: If you'll notice, there's not a lot of questions about
changing much of the cryptography because that's not really changing. that
kind of got set as we looked at features. the folks from the verifiable
credential community, Dave in particular, said, "Hey, I want can we do
this?" Was like, " yeah, that seems really important to do." And so we got
some of that feedback. More is always encouraged. And u I'll stop sharing
now. wait. Any more questions?

Greg Bernstein: Otherwise, I can stop the presentation.

Manu Sporny: Yeah, I think we're good on the presentation.

Manu Sporny: Thank you very much, Greg, for sharing that. the only question
I have is on last week's call,…

Manu Sporny: Sam from the, Google privacy sandbox team brought up what is
it, the rate limiting stuff. and I'm wondering how not that I think we
shouldn't start adding features at this point or I'm really concerned about
us adding features at this point. we really need to get at least version
one shipped

Greg Bernstein: We were too and…

Greg Bernstein: So there's going to be a similar draft. Sam didn't get on
the list. I don't think their draft got out in time, but there's a similar
list from Kathy Yun and…

Manu Sporny: Mhm.

Greg Bernstein: Chris Wood who do a lot of work in this area and that's
called anonymous rate limited credentials arc. That's a two-party model. It
uses It uses the same types of ZK proofs that we use discrete log based
proofs. Same with Sam's stuff. And we've been working and we had a call
with Miko Uru who is going to be on after us and the ARC folks because he's
got a draft about standardizing what are known as Sigma protocols in
general and…

Manu Sporny: Mhm.

Greg Bernstein: these are the ZKPs that are underneath BBS and a lot of
other things BOP PRFs which are already standardized and so that helps
unify them in a sense but it doesn't really impact us in the blind BBS and
pseudonym drafts we could use a general function call to do that kind of
proof rather than doing our own proof if

Greg Bernstein: if we want to have, some reuse across between us and the
ARC stuff, but they are fundamentally a two-party model. And so, we kind of
had this discussion with the Apple folks and…

Manu Sporny: No. when you say two-party model,…

Greg Bernstein: we both walked away relieved because it's like, you're not
going to slow us down and we're not a long time ago there was a key
verification, a two-party kind of not BBS sharp quite, but a BBS without
pairings. once again good in a two-party and basillus had that sitting
around and no the folks that came up with EBS Sharp didn't come back to
talk about stuff and it's not useful for us in the credential community so
we did not pursue it and that's why
00:30:00

Manu Sporny: could those two parties be between the holder and the verifier
or does it require two authorities or…

Greg Bernstein: It requires the verifier.

Manu Sporny: the same authority?

Greg Bernstein: It requires a shared secret between the verifier and…

Greg Bernstein: the issuer, I mean,…

Manu Sporny: Okay. Yeah.

Greg Bernstein: so it just doesn't fit a verifiable credential model, a
decentralized model. So that's why it's okay for a privacy pass thing,…

Manu Sporny: Mhm. Okay.

Greg Bernstein: but that's why it also was relieving for us because it's
like, we can help you guys with general sigma protocols. We know about
doing that. We could help with your work, but it's not going to come and
slow down BBS.

Manu Sporny: Yeah,…

Greg Bernstein: That's I mean

Manu Sporny: The thing I'm trying to get to is the benefit of, rate limited
credentials in a three-party model, the…

Greg Bernstein: Yes, that's Mhm.

Manu Sporny: how do we address that thing? and it seems like, that is
covered with the pseudonyms case and the verifier counting interactions
with a particular pseudonym.

Greg Bernstein: Yeah, that's one approach versus throwing a big range proof
in there. also because Yeah, I'll leave it at that so we didn't Yeah.

Manu Sporny: So, we've already got the solution,…

Manu Sporny: I think, what we're saying is we can already do rate limiting
with the three-party model in BBS. Yeah. Okay.

Greg Bernstein: So the only person we have hasn't kind of been involved
with those conversations is Sam. So hopefully we'll be able to get him in
tune, but I think Miko said he might have talked to Sam. So I can't
remember. and he's going to be there live Mico. So me and Pasis are going
to be remote in Bangkok.

Manu Sporny: Okay, got it. I guess the other question is we do have the
rate limiting stuff for the three-party model on a perverifier basis,…

Manu Sporny: but not on a per ecosystem basis. and it seemed like Sam was
saying they had a solution for the ecosystem basis thing, but it also felt
like that might be grasping at straws. meaning this is important with the
proof of personhood credentials where an individual shows up at one
verifier and then clones or multiplies and shows up at a different
verifier. You can't understand if that's the same person.

Greg Bernstein: Yeah. that might be…

Greg Bernstein: where we can do something with some additional proof added
on top of what we do with onym. That's some room. and guys like Andrew
Whitehead and Mik might be able to help this and along with whatever
notions that the ark and it wasn't quite clear to me and Vasilus what the
ARC folks were quite doing and Sam's stuff was a more conventional range
proof.

Greg Bernstein: but I was going yeah so yeah this is still a valid case but
that would only impact pseudonyms would not impact blind and it would be a
supplement to pseudonyms so I still feel good about the trajectory and the
stability of at least so any other questions on BBS and such.

Manu Sporny: All right, I think we're good. Thank you very much, Greg, for
walking us through the presentation to ITF next week. looks great. thank
you again so much for all your work in this area and pushing that forward.
the next item up is just kind of open agenda. if anyone has any questions
around specifications they're working on related to data integrity, any
questions on timelines, any questions on features, functionality, any of
that stuff. Go ahead, Will.

Will Abramson: Cheers. Yeah. So, yeah, I just want to flag some of the
stuff that's been going on with the spec I'm working on for Schnore. We
talked about this a couple weeks ago. there are two poll requests which I
would like at least just a brief sense of is this in the right direction.
The first one is fixing the security concern that was raised. So I was just
concatenating these two chronicized documents and then doing one hash. So
that is just changing it to both documents and then concatenate the h hash
it again. I mean Joe raised some things like I don't know if it's really
like that big a security concern but I agree with you guys.
00:35:00

Will Abramson: I think, it definitely can be a concern maybe it's hard to
see how that would be realized in this setting, but I still think, it's
trivial for us to fix it. So, let's fix it. so yeah, I mean, I think you
probably don't even really need to review this. I just want to check that
I've done what you guys thought I should do, right? I hash both the
documents individually and then I concatenate the hashes and then I the com
hash the thing again. So I'm still getting down to one hash.

Will Abramson: Great. Yeah.

Dave Longley: Yeah. And…

Dave Longley: I expect that to be the case here. if you have fixed hash
width which it looks like you do that would solve the problem. So that
should work just fine.

Will Abramson: Actually I think the BIP 340 where the Schnore algorithm is
defined it it does say that they've extended it to take arbitrary length
messages but then don't precisely define how the hash function that you
should use to get down to that get down to this 32 bytes eventually because
ultimately the algorithm does need 32 bytes. So, I just thought it'd be
better for us to me to specify exactly how you're going to get to those 32
bytes rather than let it up to the signature implementation.

Dave Longley: Yep, that works.

Will Abramson: Great. Yeah.

Manu Sporny: Yeah, I mean this looks good. This is somewhat of a tangent,
but the new FIPS publication allows K1, Am I misremembering Which one was
that?

Dave Longley: the language I remember was it's allowed for quote blockchain
related applications.

Manu Sporny: It was 186. Everything's a blockchain, isn't it? let's see.
I'm reading the AI summary. That might not be the best thing to do.

Will Abramson: Do you think there's been a new announcement from this that
maybe it's a bit more friendly Okay,…

Manu Sporny: There definitely has been a new thing from NIST.

Will Abramson: good. Uh-huh.

Manu Sporny: We had, kind of indirect input on that to try to get them to
include 256K1.

Manu Sporny: And I think as Dave said, it is for quote unquote blockchain
applications. the reason I'm bringing it up is because I mean you're using
SHA 2256 here, which is I think exactly the right thing to do.

Will Abramson: Mhm.

Manu Sporny: I think what that would mean is that the data integrity
mechanism that you're talking about would be FIPS compliant as long as you
can prove that you have a blockchain,…

Will Abramson: All right.

Manu Sporny: based application, right?

Manu Sporny: which is to totally loose language and you can probably drive
a bus through it…

Will Abramson: Yeah. Yeah.

Manu Sporny: which probably means that you're in a really good position to
claim that this crypto suite has FIPS compliance…

Will Abramson: Yeah. That's great, sir.

Manu Sporny: which basically means that…

Manu Sporny: then any government or large enterprise has that box checked
to use it 18…

Will Abramson: What's the fix number again?

Manu Sporny: what is it FIPS 186-3 something like that P26 K1
certification. do you remember what's off the top of your head?

Will Abramson:

Will Abramson: Yeah. Okay. 186-3. I mean the AI summary says included seco.
Great. I'll look into that in more detail.

Dave Longley: It might be all the way up to 186-5 at this point.

Manu Sporny: Yeah. …

Will Abramson: Okay. Okay.

Dave Longley: I'm trying to remember.

Manu Sporny: yeah, that was 2003.

Manu Sporny: superseded. Yeah,…

Dave Longley: Yeah, I think it's five at this point. Yeah.

Greg Bernstein: Yeah, because I think that's where EDDDSA is, right?

Manu Sporny: there we go. Yeah, it's 186-5.

Manu Sporny: That's correct. And we might as well look at it. sack P.

Dave Longley: By the way,…

Dave Longley: I think it's great you could still access these documents.

Manu Sporny: Yeah. Yeah. it's for those that don't know, the NSA got some
of the recommendations taken down. These documents were just disappeared
from the internet.

Manu Sporny: It's not saying anything about SEP in here. maybe it's 140.

Will Abramson: Yeah, it's not serious.

Will Abramson: I'll try and have a look at it separately.

Manu Sporny: Okay.

Will Abramson:

Will Abramson: That's fine. know from let me know.

Manu Sporny: In any case, I think what you have here align as long as we
can find that

Will Abramson: Yep. Yeah. That's great. And then the last one is just a
request if folks are interested maybe if you could review PR12. I think 11
is fine. I just used Greg's library to create some test vectors. 12 I've
just added two paragraphs to describe how multi- signature protocols work
with it currently. I mean I'm not defining precisely how the algorithm is
but I'm saying basically you got to go look at these definitions of these
multi-party cryptographic protocols and implement how they're doing key
generation for example and how they're doing signature generation so at the
start I mean I might add an extra paragraph because basically out of scope
is anything around how does somebody define that this signature was created
00:40:00

Will Abramson: ated by a multi-arty approach or this verification method is
a n ofn signature currently it's just like this is supported already these
keys are the same obviously you've got to do some different work to
generate the signatures and generate the keys but from a verification
perspective it's the same

Manu Sporny: Is it possible to know whether it's a multi-party signature or
not? I thought you couldn't tell.

Will Abramson: I think the way that you would know is you would def Yeah.

Manu Sporny: Go ahead.

Will Abramson: The way you would know is you would define in the
verification method,…

Manu Sporny: Yeah.

Will Abramson: this is an N ofN signature and these are the N keys that
were aggregated to make that and…

Manu Sporny: Got it. Okay. But the math doesn't change,…

Will Abramson: then you would be able to know.

Manu Sporny: but I guess it does change. yeah.

Will Abramson: If you wanted to verify that you'd have to recreate that
public key from all the N keys.

Manu Sporny: I'm wondering…

Manu Sporny: if there's a way to hide that. Will on I think the way that
we're suggesting the keys displayed to the public is you say Mend and you
list all the keys. I'm wondering if we can mix the keys together or provide
a list of

Will Abramson: I think maybe a list of verification methods might work.

Manu Sporny: Yeah. Yeah.

Will Abramson: Yeah, it's not great.

Manu Sporny: I mean that has an n squared complexity or something. No, it's
worse than that, …

Will Abramson: you've Yeah.

Manu Sporny: yeah, I'm wondering how we can hide some of that or maybe it's
the allided multi key, stuff that you're talking about where you don't get
to discover the number of parties until you Mhm.

Will Abramson: Yeah, but the problem is like if you can't recreate that
address that key, right, this multi-party key, then you don't know whether
it's a single public key or a multi key.

Manu Sporny: Mhm.

Will Abramson: I don't know. Maybe there's some proofs that you could do
that allow you to do, but as far as I know, you have to recreate it to
check that actually is what's going to say they're indistinguishable,…

Manu Sporny: Yeah. Yeah.

Will Abramson: one key is just a different

Manu Sporny: Yeah. Yeah. Yeah.

Manu Sporny: I'm trying to figure out how you do multi-IG among a large
group

Manu Sporny: where you don't necessarily want to expose the number of
members in the group or potentially even who the multisig came from. …

Dave Longley: Isn't that just an expression of the combined key as a single
verification method?

Manu Sporny: that's okay.

Will Abramson: Yeah, I think that's just this.

Will Abramson: Yeah, you just express the key, right? And then

Manu Sporny: Okay. Yeah,…

Dave Longley: I also wanted to say in chat I dropped it's special
publication 800-86…

Manu Sporny: I know.

Dave Longley:

Dave Longley: where the curves actually are on. I put the quoting

Will Abramson: Yeah, great.

Will Abramson: I saw it. Thank Yeah, that's all I have. So, thanks. Cool.

Manu Sporny: Okay, thank you for that. yeah, here we go. Allowed for
blockchain related applications. And if you're using decentralized
identifiers that use one of these keys that's rooted on a blockchain, I
would imagine that is a blockchain related application. Meaning I think
this clears the way for kids that use SECP26 256K1 and multi-IG. Awesome.
All right. Thank you, Will. looks good. Thank you for all that wonderful
work. I think any other items that we wanted to cover today? Any other work
people are curious about or anything of that nature?

Manu Sporny: Otherwise, we can end. All thank you everyone for the call
today. really appreciate all the hard work.
00:45:00

Will Abramson: Thanks. See you.

Manu Sporny: Thank you Will. we'll meet again next week to cover whatever
is on everyone's mind. maybe we'll get a readout from the ITF meeting. and
that's it. Thanks everyone. Have a wonderful weekend. Take care. Bye.
Meeting ended after 00:45:23 👋

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