[MINUTES] Data Integrity 2025-08-01 (was: Re: Advances in Longfellow ZK (was: Re: Event Updated: CCG — Data Integrity))

On Fri, Aug 8, 2025 at 6:38 AM Denken i <denkenie@gmail.com> wrote:
> Hi folks, sorry I missed it. Will the minutes (with text and video, as usual) be published for that event?

Hey Denken, unfortunately we had our first failure of Google Meet to
transcribe and record a CCG call. I've searched the archives, but it
looks like Google Meet failed to do the recording and transcription of
that particular meeting.

This has never happened before, and it's really unfortunate that it
happened for this very important call. I will attempt to summarize the
meeting below:

Abhi, Matteo, and Sergei presented a number of changes that would need
to be made to make SD-JWT more efficient wrt. LongfellowZK. The group
agreed that the change is necessary, highlighted that they do not
believe SD-JWT is well-suited for efficient ZKPs, and noted that
alternate mechanisms would work better.

Abhi then presented a new Pedersen commitment based approach to
LongfellowZK that is quite similar to BBS, which the group does have a
lot of expertise in. After some light evaluation of Abhi's proposal by
the group, we all agreed that it was a very promising direction for
the following reasons:

1. Pedersen commitments are well known (having been published in 1992)
and having been analyzed as a part of the BBS work at the IETF CFRG.

2. Serialization into a list of messages is also well known for the
BBS work and the W3C Data Integrity work.

3. One of the biggest benefits is that we can now evaluate a message
with thousands of commitments very quickly (several hundreds of
milliseconds).

4. LongfellowZK has been introduced at IETF CFRG as a general
cryptographic primitive and is under active review.

5. We identified that pseudonyms were missing in Abhi's proposal, but
Abhi noted that he believes adding them in would be fairly
straightforward.

6. The mechanism described by Abhi would be easy to integrate into a
W3C Data Integrity cryptosuite, since most of it is already
implemented via the BBS Data Integrity cryptosuite.

7. What would be needed would be a lightweight IETF CFRG draft that
explains how to put together some of the BBS approaches that have
already gone through review, but using Longfellow ZK in a some key
places.

In other words, what Abhi, Matteo, and Sergei presented seemed to fit
into existing work on BBS, which has made it quite far within IETF
CFRG, which means that we wouldn't have to start over from scratch for
a new ZKP mechanism that uses LongfellowZK. It would be standardizable
within 1-2 years vs. it being a 3-5 year endeavor. We think we had the
right people in the room to create the solution, perform review, and
get the specs done at IETF and W3C.

We ended the call by committing to help Abhi and his team in whatever
way we can to create a Data Integrity cryptosuite that uses
LongfellowZK. The concrete work items that were identified were:

1. [Abhi/Greg] Creation of a lightweight spec bridging LongfellowZK to
BBS/Pedersen primitives.

2. [Greg/Dave] Creation of a W3C Data Integrity cryptosuite that uses
the Pedersen version of LongfellowZK.

3. [Data Integrity group] Review of specifications and approaches to
ensure optimal mechanism is created that doesn't have to pay the price
of having to conform to existing digital credential serializations
that are not well suited for ZKPs.

We'll keep moving this work forward in the Data Integrity group and
Abhi and team have an open invitation to use future calls to move the
LongfellowZK stuff forward within our community.

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
https://www.digitalbazaar.com/

Received on Friday, 8 August 2025 13:40:56 UTC