[MINUTES] CCG Weekly 2025-04-29

W3C CCG Meeting Summary - 2025/04/29

*Topics Covered:*

   - *Updates on Work Items:* Will Abramson presented a pull request adding
   quantum-safe algorithms to the data integrity spec, highlighting the need
   to register new key prefixes.
   - *Anonymous Credentials from ECDSA:* Abhi Shelat and Mattel from Google
   presented their solution for zero-knowledge proofs addressing unlinkability
   in digital credentials. This included discussion of its application to
   MDOC, JWT, and Verifiable Credentials (VCs).
   - *Zero-Knowledge Proof System:* The presenters detailed their chosen ZK
   system, emphasizing its efficiency on resource-constrained devices like
   phones, its use of established and well-understood algorithms (Sumcheck IP
   and La Hero), and its adaptability to various requirements (revocation,
   pseudonyms, hiding issuers). A demo showcased its application to a birthday
   verification scenario.
   - *Revocation:* A novel approach to revocation was presented, relying on
   signing consecutive pairs of revoked identifiers to minimize work for
   issuers and holders.
   - *JSON Web Tokens (JWTs):* The extension of the ZK system to JWTs was
   discussed, proposing modifications to improve efficiency and compatibility.
   - *Verifiable Credentials (VCs):* Initial work on integrating the ZK
   system with VCs was discussed, focusing on challenges related to JSON-LD
   canonicalization and the need for simpler, flatter data structures for
   efficient zero-knowledge proofs.
   - *BBS Signatures:* The presenters explained inherent limitations of BBS
   signatures regarding unlinkability due to the revelation of message
   indices, suggesting that a standardized schema would be necessary across
   all issuers to mitigate this.
   - *Open Sourcing of Code:* The presenters announced the impending open
   sourcing of their codebase within 60 days, with early access available upon
   request.
   - *Biometric Binding:* The presenters acknowledged the concept of
   biometric binding to credentials but pointed out usability and security
   challenges.

*Key Points:*

   - The Google team's approach prioritizes efficiency and deployability on
   resource-constrained devices, using established cryptographic primitives to
   minimize the need for new standards and infrastructure.
   - Their zero-knowledge proof system offers a solution to the
   unlinkability problem in digital credentials, addressing the tracking
   vulnerability associated with device-bound keys.
   - Their proposed revocation mechanism is designed for efficiency,
   particularly when the number of revoked credentials is small.
   - Integration with JWT and VC formats is underway, with ongoing
   discussion to optimize data structures and canonicalization for efficient
   zero-knowledge proofs.
   - A key challenge remains in achieving unlinkability with BBS signatures
   due to index revelation; the presenters propose a system-wide standardized
   schema as a solution, but acknowledge its practical difficulties.
   - The team is working to make their code open-source, facilitating
   community feedback and broader adoption. Early access is available.

Text: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-weekly-2025-04-29.md

Video: https://meet.w3c-ccg.org/archives/w3c-ccg-ccg-weekly-2025-04-29.mp4
*CCG Weekly - 2025/04/29 11:54 EDT - Transcript* *Attendees*

Abhi Shelat, Alex Higuera, Anil John, Arturo BA, Chandima Cumaranatunge,
Dan Yamamoto, Dave Lehn, david waite, David Waite, Dmitri Zagidulin, Erica
Connell, Greg Bernstein, Harrison Tang, Hiroyuki Sano, Jennie Meier, Joe
Andrieu, José Luis Pumahuanca, Kayode Ezike, kazue SAKO, Manu Sporny,
Marvin (us-cam-4cc), Matteo Frigo, Nikos Fotiou, Otto Mora, Przemek P, Rob
Padula, Serguei Alleko, Stephen Curran, Ted Thibodeau Jr, Vanessa Xu, Will
Abramson
*Transcript*

Marvin (us-cam-4cc): Hello. Okay.

Harrison Tang: Hey Mattel.

Harrison Tang: Hello. you.

Marvin (us-cam-4cc): Is also here.

Harrison Tang: Thank you for taking the time to join us today. Thanks.

Marvin (us-cam-4cc): Sorry for missing you in Sophia.

Harrison Tang: Mattel, we'll start around 9:02. people usually join about a
minute or two late. Yeah. Cool.

Marvin (us-cam-4cc): Okay.

Marvin (us-cam-4cc): Thank you.

Harrison Tang: And then these calls are automatically recorded and
transcribed. So the recording actually has just started. Yeah.

Harrison Tang: We'll start in about a minute.

Harrison Tang: All right, welcome everyone to this week's W3CCCG meeting.
today we're very excited to have API and Patel from Google to lead a
discussion around the anonymous credentials from ECTSA. before we begin, I
know some people will stroll in, but before we dig in, just want to quickly
start with some administrative stuff. first of all just want to have a
quick reminder on the code of ethics and professional conduct. just want to
make sure we hold respectful and constructive conversations here. quick
note about intellectual property. Anyone can participate in these calls.
However, all substantive contributions to any CCG work items must be member
of the CCG with full IPR agreements signed.

Harrison Tang: So, if you have any questions in regards to the the W3C
community contribution license agreement, please feel free to reach out to
any of the chairs. A quick note about the call, these calls are
automatically recorded and transcribed. we will send out the meeting
minutes and audio recordings automatically within the next few hours. And
we use Google Meet here.

Harrison Tang: so the feel free to just raise hands if you have any
questions and I will moderate A quick note about I just want to take a
quick moment for the introductions and reintroductions. So if you're new to
the community or you haven't been active and want to feel free to just
unmute and introduce yourself little bit. All a quick moment for the
announcements and reminders. any new announcements reminders, right, I
think everyone can't wait to get to our main agenda. All right.
00:05:00

Harrison Tang: by the way, just a quick preview for what's coming. So next
week we will have the chief architect from tools for humanity to talk about
Warcoin and their orb. And then the week after that we'll have Duncan to
talk about their work in Taiwan digital wallet. All right. any updates on
the work items? please

Will Abramson: Yeah, I could just speak to the quantum safe stuff. I put
together this PR. It attempts to start adding some additional quantum safe
algorithms to the data integrity spec. I was planning to do this a while
ago, but I only just got to I mean I think I know what to do, but if you're
interested in quantum safe algorithms, it' be great to get a review. I am
going to refactor this to extract out some common algorithms so they're not
just repeated multiple times. Like manu said, I guess the only thing to
flag is we do need to register some of these keys as multi key prefixes. I
mean maybe I should bring this up in the data integrity call to make it
sweet, but we need to decide what those prefixes are basically. That's it.

Harrison Tang: Thanks, Will. If you are interested in data integrity and
quantum stuff, just join the data integrity call at 7:00 a.m. Pacific time,
1000 a.m. Eastern time every Friday. All any other announcements,
reminders, guidance stuff? All right, let's get to the main agenda. again,
very excited here to have Abby and Mattel to actually present their work on
anonymous credentials from E Andrea actually share this paper in February
and they actually got quite a bit of conversations and threads going.

Harrison Tang: So that we are very fortunate and…

Harrison Tang: very honored to have them here to talk about their proposed
solution. So Abby Mattail the floor is yours.

Marvin (us-cam-4cc): Thank you.

Marvin (us-cam-4cc): Thank you for inviting us. We're very happy to talk
about this work and the extension since we published that paper. and please
interrupt with any questions that you have. so I'd like to cover
essentially our solution for zero knowledge proofs. It's first started
working with just MDOC but we've extended it to Jot and we're in this call
hopefully trying to figure out how to extend it to the various verifiable
credential formats that your organization has presented. So just as a
beginning I think all of you are familiar with this but I will explain the
problem of unlinkability and why the current solutions for unlinkability
don't work.

Marvin (us-cam-4cc): So here I think what the core problem is is that when
you start issuing digital credentials you need to consider the attack of
users that share credentials. If you have a digital credential and it's
very easy to extract it from your phone and copy it to another phone, then
an aspect of scaled abuse to someone is going to copy their credential to
100,000 or a million phones and then essentially those users will be able
to use a copy credential and assert whatever they want and that would
undermine the soundness of the whole idea behind digital identity. And so
that's a very serious attack that designers need to take into account and
most solutions rely on trusted hardware.

Marvin (us-cam-4cc): And this is the stack of a basic phone. It has a
secure element in it. And the idea is to create a devicebound key that
lives in that secure element and incorporate that into all of the
protocols, the issuance protocols and the presentation protocols. That's
essentially the basic recipe for preventing the sharing of credentials
attack. And in fact, that's the only one that I can actually think of that
works at scale. again a problem is that changing these lower levels of the
phone take many many years and so we're basically stuck with trying to find
a solution for digital identity that works with the current stack that we
have and a sample solution for this is I'm going to present it for MDOT but
Jot and VC essentially have similar ideas and here's a sample do credential
that has been parsed and you see it has salted hashes for the attributes
those
00:10:00

Marvin (us-cam-4cc): the green values and it has this devicebound public
key in yellow right there. And essentially when you do a presentation, so
when a relying party asks for a certain attribute request of age over 18,
they actually send a challenge in this case a transcript that's used for
other purposes too, but it's a fresh nons so to And the user's device when
they reply in the status quo, they essentially give you the MDOC, they give
you this object right here. They give you the pre-image for the salted hash
for the attributes that they want to disclose. if this was the age over 18,
they'd give you a pre-image to that that proves that, for example, age over
18 is true. And then importantly, they'd give you a signature using this
device public key which is on the device for this transcript. And that's
kind of how the relying party would jointly verify that both the attribute
that is claimed is true.

Marvin (us-cam-4cc): the issuer has asserted that the attribute is true as
well as this is a credential that actually sort of is owned by the user and
that sort of deduction requires a few more steps but that's ultimately the
thing and right here these are the four or five steps that the classic
verifier of a proof basically has to check and now the main problem with
the current status quo protocols and I know that all of you have heard is
that although the selective disclosure property solves one privacy problem,
it introduces another. The device bound key which this yellow value right
here it essentially creates a tracking problem. It becomes a tracker and
certainly if you use the same credential across the web then relying
parties can collude and essentially track you across the web.

Marvin (us-cam-4cc): Even if you use a different one for every party, the
issuer and the relying party can still use this yellow value to track. And
that is a problem that has been identified and now essentially in the last
year and a half many people have been trying to address it. So everybody
with me on the problem. Now our claim is that the right zero knowledge
system can solve all of these problems. so that's zero knowledge is this
attempt this method for a prover to prove a theorem without revealing
anything except the fact that the theorem is true to the verifier. That's
kind of the colloquial way of describing it. when we look at the different
flavors of zero knowledge there are many different schemes.

Marvin (us-cam-4cc): but when zero knowledge is being applied to identity
there are a few different problem constraints that I want to highlight
before and this kind of motivates why we essentially landed on the solution
that we've landed and we think that it's the best one. So the first thing
is that unlike blockchain zero knowledge and all the stuff that Ethereum is
doing etc zk identity is actually working in a different constraint regime.
the idea here is to minimize the prover resources as opposed to minimizing
the verifier resources. In blockchains, the idea is your proof is going to
be verified by some node that's running sort of the consensus and that's a
limited computation and essentially the proofs are but done offline and you
have a much larger prover in this model. Instead the phone is the small
prover and the website usually has a big server infrastructure and is the
large verifier.

Marvin (us-cam-4cc): And so we don't need the notion of succinctness
necessarily. We really need a proof system that is very small, very
efficient and runs efficiently on the phone. the second major thing is that
we feel that people and standards coordination is very expensive. So
essentially getting a bunch of different parties to agree on formats and
other parameters is very difficult task and that's in and you're the
experts at that the level it takes to get agreement on standards is a lot
and so as a result we think that using trusted parameters in any sort of
zero knowledge proof system so many zero knowledge proof system require
very large strings that are selected in a very special way and We think
that those kind of setups are not amendable to this kind of problem.

Marvin (us-cam-4cc): So in particular each of the 50 states might want to
think about what process would all the 50 DMV states essentially go through
to agree upon a common reference string that all of them accept and if they
don't accept it will we have 50 different strings and if we bring Europe
into the mix will each of the 27 states there have their own trusted
parameter setups if you get into that type of system essentially it'll be
impossible to deploy on a phone each phone would need to store
00:15:00

Marvin (us-cam-4cc): I guess 70 to 100 different trust parameter setups and
these parameter setups are quite large that's why we've ignored systems
that use this type of mechanism even though they have really remarkable
efficiency properties and of course the final thing is that we can't ignore
all of the completed work on different data formats and so we've taken one
of them which is this ISO MD doc one we've also worked with we have an
implementation that we'll show you today that works with JSON web token and
we're also looking at how to do this with the various W3BC formats and we'd
love your input on which ones to try there. Finally, the other main
constraint we want to point out is that in our opinion issuers are limited.
So it's very hard for them to deploy new crypto infrastructure the DMB has
a signature scheme like a ECBSA trusted HSM but for them to deploy a new
HSM for a different signature scheme would be very difficult.

Marvin (us-cam-4cc): we also believe that it's not a good idea to have
issuers essentially do internet scale processing. So we don't believe that
they should be highly available because again they may not be currently
used to being a highly available website and we certainly don't want them
to be involved in internet scale activity in their daily processing and so
they should not be involved in any online flow and they also should not be
required to do work that's proportional to the number of login on the
internet and so those are the constraints those are things that we believe
that should drive the selection of a solution in this space I'd love to

Marvin (us-cam-4cc): get your feedback on any of these points.

Marvin (us-cam-4cc): Go ahead, manu Yes.

Manu Sporny: This is all wonderful and…

Manu Sporny: I think the foundational assumptions you're making are very
much aligned with at least the W3C verifiable credential work. so the other
thing you might mention here is that the phone home aspect of it is
typically frowned upon. so that's another reason not for the issuer not to
be involved at all. But I don't think anything you're working on requires
any sort of real time verifier time phone home. good. this is looking good.

Marvin (us-cam-4cc): Yeah, Otto's question, are you saying that maintaining
HSM for DMVs is cumbersome?

Marvin (us-cam-4cc): Yes,…

Marvin (us-cam-4cc): we do believe that and we also believe that they have
deployed a certain set of HSM which currently only support for example
ECDSA and RSA signatures. Go ahead Joe.

Joe Andrieu: Yeah, as politely as possible.

Joe Andrieu: I think you shouldn't imagine that issuers are limited. I
think the democratization of the ability to make a verifiable statement is
part of what verifiable credentials are about. So I anticipate everyone on
the planet is going to be an issuer as we create a new fabric of identity.

Marvin (us-cam-4cc): It's interesting. so you're more of a decentralized ID
type of person. for our problem statements though we're bootstrapping
identity with essentially stateisssued identity. The use cases we work on
at Google essentially work through that mechanism age assertion is
something that u like legally you have to rely on a certain set of
assertters to check that.

Marvin (us-cam-4cc): but I do agree with you that we do agree in a world in
which there are many more issuers than just DMBs but certainly whatever
scheme we propose has to be one that works with the major and state
issuers. Go ahead Demetri

Dmitri Zagidulin: I think Joe one way to reconcile what you said is issuers
are limited vertically not horizontally right so an issuer doesn't need to
have Google scale compute requests per second ability but there could be
lots of issues right so it's the vertical limitation that's the key on that
slide

Marvin (us-cam-4cc): Okay I am going to push back a little. If you pick a
protocol so Manu's already address this but if you pick a protocol which
requires a DMV to issue maybe batch issue like everybody 10,000 credentials
because that's the number of login they do in a month. that's going to be a
problem for them even if they do it batched and offline because at peak
you'll have to have a lot of resources. So we can take that conversation
offline. but I do see your point that there's nuance to the statements
we're making here. let me move on here. in the next phase of this I want to
explain our ZK proof system, explain some of its features and then I want
to make sure we have enough time to talk about for example BBS and W3BC and
our approach. we are actively trying to integrate a scheme that handles all
of these type of things.
00:20:00

Marvin (us-cam-4cc): So I want to make sure we spend time we have time for
that. So we agree that the right ZK system can solve both the first problem
which is unlinkability for presentation and we can also solve the three
problems of constraints that we just basically had and our recipe is
essentially the second oldest recipe for producing a zero knowledge proof
system. It goes back to this 1988 paper that says anything provable is
provable in zero knowledge. And the recipe they give is they say pick an
interactive proof system. And run that interactive proof system that IP to
generate a transcript for the computation that you would like to prove. you
commit to that transcript using a special commitment scheme. And then you
run a zero knowledge proof system not for an arbitrary circuit but for a
basic circuit that says the commitment contains a transcript and the
interactive proof verifier on that transcript would accept.

Marvin (us-cam-4cc): So if you have these three yellow components, then you
can build a efficient ZK proof system for any statement. And this recipe is
basically as I mentioned, the second oldest one. it hasn't changed since
1988. And it predates all of sigma protocols and all of the other sort of
mechanisms. It's just that we didn't know efficient implementations of the
commitment and the CK system until essentially the last two decades. So the
IP that we have picked is the sum check IP and that's again another paper
that was presented in 1990 that's been sort of very thoroughly reviewed and
it has a formal proof of verification for its soundness for some check and
more importantly the prover in the last decade essentially the efficiency
of sumcheck has improved.

Marvin (us-cam-4cc): So the algorithm has been well known but the
efficiency the prover runtime the better algorithm for computing the sum
check basically arose in the last 15 years and we can now compute
essentially sum check transcripts in order C time that means linear in the
size of the computation and that's a really big advantage because as you'll
see all of the other proof systems are bottlenecked by a step that requires
an C log C or essentially quasi linear a log C overhead for essentially
processing a computation. So our first step is sum for those reasons. It's
old, it's well established and it's very efficient. And our second choice
is essentially for the commitment and the zero knowledge system is La Hero
and previously we've experimented with various things. we used one that
required an elliptic curve assumption but La Hero essentially only uses
shot 256.

Marvin (us-cam-4cc): So upon essentially the encouragement from people
inside Google and Apple, we wanted to make a proof system that was
postquantum secure did not require or use in the zero knowledge step any
sort of elliptic curve assumption. And so Learo essentially fits that bill
perfectly. We've written a paper about this. We've put a spec about our ZK
proof system and how it can be applied sort of at this location. And our
results is that when you apply the recipe to these choices and when you
carefully implement it we essentially have the fastest known approach for
these ZK proofs for legacy when all of the costs are considered when you
consider the cost of making the first proof as well as making each
subsequent proof etc. When all of the costs are considered we stand by that
statement. We have dog food deployed this in Google wallet.

Marvin (us-cam-4cc): it works with the MDOT format first but also with the
jot format and I'll give you more details about that and as I've mentioned
here we'd like to handle BCS as well and most interestingly it's robust to
new requirements so for example after we did the MDOC people asked how will
we do revocation how will we do pseudonyms how will we hide the issuer and
all of these things are very easy things to add on to our circuits to
essentially add those features and this is true because we easily handle
the ECDSA function and glue logic like comparisons. And so that's one of
the main reasons why I think this is all of these pieces fit well together
because it not some ZK proof systems are very fragile. if the statement
changes a little bit or the document format changes a little bit, you
essentially have to start from scratch or build some, ad hoc mechanism. And
we feel like we've built a framework that handles all of these things.

Marvin (us-cam-4cc): to give you a sense essentially these components I'm
going to show you putting them all together I'm going to show you some
demos but just these three components ECDSA and glue logic so ECDSA we can
essentially do a proof of one signature in about 60 milliseconds and these
are substantially faster than for example other approaches that are known
in the literature even recent papers from this year essentially are either
15 or six times slower than our latest work here and for
00:25:00

Marvin (us-cam-4cc): we can essentially prove a image of an NB block SHA
message for n equal 1 that's about 11 milliseconds and for n equal 32 it's
about 300 286 milliseconds and our proof size essentially it's large but
fits within essentially the pattern and you can glue these components
together now to solve our first application which is how can we give a zero
knowledge proof for the legacy

Marvin (us-cam-4cc): protocol. Right? So I told you that these five steps
verifying the signature of the MDC by Massachusetts, verifying the
signature of the transcript, verifying the pre-image, and then verifying
the credential expiry conditions. Those are the five steps that a
traditional verifier has to do. And we've essentially taken those five
statements, turned them into a formal statement like this, and turned this
formal statement into a circuit and essentially produced a zero knowledge
proof. And our proof runs in about 2 seconds for a very large M do for a 2
kilob 2 and a half kilobyte MD doc. If you use a smaller one that for
example if you only have two or three attributes that you want to do we can
essentially get subsecond performance in this regime. I'll show you let's
see a demo so this is a test verifier website and here let me go ahead and
pause this for a second.

Marvin (us-cam-4cc): what's happening here is there's a website that's
going to ask for your birthday and it's going to require a zero knowledge
proof of your birthday. and then essentially this is also going to show a
cross device flow. So the credential lives on your phone and this shows
essentially how and right over here to the right is essentially a
screencast of the Pixel 6 Pro that we're testing all of this on. And
essentially you'll see how the zero knowledge proof is essentially conveyed
from phone to website to the browser to the relying party website. So you
get this QR code just like you do with pass keys. So we're relying on that
and now essentially the credential selector shows up. You select one of
your driver's licenses tells you what you're about to disclose. You have to
use a biometric to unlock your secure element.

Marvin (us-cam-4cc): And essentially now at this point you're essentially
producing the proof and sending the proof back to the website and now it's
already sent it to the website and if you scroll down you'll see that the
protocol response was sent there and essentially the verification indicated
that was the birthday. So that shows you that essentially this process the
second of proof latency isn't that disruptive because you already need to
do human action. any M do show requires you to use your fingerprint or
biometric like a face in order to unlock the secure element and so this
latency is kind of hidden in that entire process and it doesn't seem that
cumbersome at least that's our opinion in our testing since the last time
that I spoke to we've improved quite a number of features of our system we
have a revocation system pseudonyms hiding issuers all of these other
things so let me quickly go over some of these extra features are there

Marvin (us-cam-4cc): Are there any questions at this point?

Harrison Tang: I

Marvin (us-cam-4cc): So one of the main problems is how do you revoke these
anonymous credentials? and of course one of the easy thing is to say that
the issuer reissues them every 30 days. But sometimes that's not enough.
you actually may need to revoke it for example in one day or 1 hour and
there are basically two ways to do that. You can essentially force
everybody on every pre presentation to prove that their certificate is on a
long list of valid credentials or alternatively you can prove
non-membership on a smaller list of revoked credentials.

Marvin (us-cam-4cc): And our approach for our system is to essentially pick
this bottom one, the blue one because it gracefully reduces the amount of
work that the issuer and the holder and the relying party have to do in the
case that the revocation list is very very small. The yellow list on
contrast essentially would require every party to do a lot of work every
time a credential is and so we've actually fit within a very small change
to the currently specified identifier list mechanism. we've made a small
tweak to that and that allows us to essentially very efficiently handle
these type of revocations. So here's our proposed change to this identifier
list scheme.

Marvin (us-cam-4cc): so the issuer is going to periodically publish a list
of revoked credentials just like they do today, except they're going to
have to do it in a slightly different way. So they're going to have to sort
the list of revoked identifiers. Let's call that R1 to Rn. And they're
going to have to sign consecutive pairs. R1 and one, Ri +1. It's going to
sign those pairs and issue essentially a sequence of signed pairs. Okay?
It's going to publish this collection of signatures.
00:30:00

Marvin (us-cam-4cc): the device only downloads a pair that corresponds to
their identifier in particular. so if we take a look at this data
structure, what we've done is the revocation authority has essentially
signed this first green thing which includes of course some version
numbering and the R1 and R2 are essentially the lexographically first and
second identifiers for the revoked credentials and R2 and R3 are the next
pair etc etc. this list is going to be a hundred times smaller than an
allow list because if the revocation list is only typically one less than
1% of the users, this pair of signatures is also going to be essentially 1%
of the total issued work. And now the trick here is that we are going to
give a zero knowledge proof of non-revocation.

Marvin (us-cam-4cc): In particular, we're going to show that we're going to
have knowledge of a signature of a left and right pair such that our ID is
strictly greater than the left one and strictly less than the right one.
And that proof essentially with respect to the version number, it gives you
a very efficient proof. Remember, it takes about 60 milliseconds to prove
that I know an ECDSA signature of this particular message format. and we're
able to basically give a very short proof that The credential that I hold
on this phone has not been revoked. And go ahead, Manu. No,…

Manu Sporny: Is the sort based on the version or the signature?

Marvin (us-cam-4cc): it is based on your revocation ID.

Manu Sporny: Doesn't matter.

Marvin (us-cam-4cc): So in our current implementation, we're using the
device keys X coordinate as the revocation key.

Marvin (us-cam-4cc): But of course if the credential has its own issued
number for example some range of numbers 64-bit numbers then essentially
this revocation ID can just be that ID and you just prove that your number
is essentially between those two. the version number this epoch thing is
that of course if my credential was valid yesterday then I would hold a
signature that proves that my credential is right between two revoked
credentials.

Manu Sporny: Mhm. Yeah.

Marvin (us-cam-4cc): Suppose it's revoked today. Then of course now I still
hold yesterday's signature that it was correct. Right? So to make sure that
these lists and to make sure that all of the approvers are using the
correct latest up-to-date list, we have this epoch or version number that
basically changes. So if you revoke every day, then this version number
will just be the day. If you revoke every week, then it'll just be every
week etc. It's up to the revocation authority to kind of do this.

Marvin (us-cam-4cc): Now we have implemented this and I don't quote the
quote the time but it's on the order of less than 100 milliseconds to add
this type of revocation span to the proof.

Manu Sporny: But I guess the prover needs to fetch that new value every
day. So if your revocation is going to happen every day, it needs to get it
every day to generate new group.

Marvin (us-cam-4cc): So that is true that's essentially has to be true with
every cation So any revocation system you have to get the latest
information from the revoker. However, in our case, the only thing you have
to download is the particular signature for your witness. And we have
various schemes to make sure that you can quickly identify that and
essentially the one that you download doesn't immediately identify you.

Marvin (us-cam-4cc): But if you think about other revocation systems for
example accumulators require each phone to download a specific witness for
each person and some of those accumulators require that witness to be
private to that particular user. So we've looked at many schemes and in
terms of the balance of what you have to download you don't have to
download the whole list only one signature and you only have to download it
when essentially the issuer decides to update their revocation list and
moreover the amount of work that's done is proportional to the number of
revoked identifiers.

Marvin (us-cam-4cc): So in other schemes for example the issuer has to do
work that's proportional to the total number of valid credentials at any
given time. And so we think that this is kind of a good balance for
deployability.

Manu Sporny: Okay, thank you.

Marvin (us-cam-4cc): We can come back to this if there are questions about
the certification proposal. I also want to talk about jots. so this is a
standard jot that many of you I'm sure are familiar. there's the red part
which explains the kind of signature, the green part which gives you a base
64 encoding of essentially a JSON format and essentially the last part
which is an ECDSA signature.
00:35:00

Marvin (us-cam-4cc): what we have done very simply with our tools is to
give a proof of knowledge of a payload and such that this signature is a
signature on the B 64 encoding of the header appended with the B 64 of the
payload and the payload contains the age over 18 colon true attribute. So
this is essentially our ZK jot proposal. It's different than SD jot because
again jotss have existed before SD jotss and SD jotss have essentially that
property of salting hashes but you don't need salted hashes when you
essentially have a zero knowledge proof system. So we've implemented this
on a proof like this and our prover runs in again less than a second
slightly more efficient than the MDO system.

Marvin (us-cam-4cc): And now to add the device binding, we've actually kind
of looked at the sort of the JSON KB keybinding spec. And we imagine having
an object something like this. where again the first of it this violet part
is essentially the body of the c The body of the credential obviously
includes the device public key. this information right here. And then the
second app the credential again with this tilda right here. This again
doesn't have any SD disclosures. It just gives you the keybinding signature
which again is just in the same JSON signature format with the header with
the body and with the signature. one sort of modification is what gets
signed here. typically it's this hash of this entire particular body.

Marvin (us-cam-4cc): And our proposal is to essentially make this signed
value more similar to what's done in Seabor. Make it the public transcript
that's actually sent as part of the flow. With that type of scheme, our
system immediately applies to it and essentially gives you essentially the
same sort of performance. We haven't fully benchmarked this one yet as our
Seabore solution because it's essentially using the same components. so any
sort of thoughts or this again is slightly different than what's been
proposed just because we're changing what gets signed just to make it
slightly more efficient. But we've talked to a few people about this and
people seem to be open to these type of changes. Go ahead. Yes.

Manu Sporny: The counter signature is done in zero knowledge as well,
right? That's what that SD hash is.

Marvin (us-cam-4cc): Essentially yes I didn't write exactly the zero
knowledge statement but the zero knowledge statement for this s zk jot
proposal that I'm making here is that this is true and header the payload
contains a device public key and I know a signature under this device
public key for the challenge the public challenge and…

Manu Sporny:

Manu Sporny: Got it. Thank you.

Marvin (us-cam-4cc): here I would like the public challenge not to be a
hash of the document because that's not something that the verifier can
check, I'd like it to be something that's easily publicly verifiable. For
example, in a public transcript message that's part of the challenge
response in particular,…

Manu Sporny:

Manu Sporny: Got it. Thank you.

Marvin (us-cam-4cc): it could just be this nons. It doesn't need the SD
hash component.

Marvin (us-cam-4cc): and then this proof has not added the validity
constraints about how long the expiry etc. but those are pretty standard
and this is something that we're actively working on. And if you have any
feedback on changes we could make things that we could do to make this a
little bit more easierly deployed for people who are using jots today or
SDJ please let us know. we've done some experiments with the verifiable
credential. we've just started on this and we'd love to get a little bit of
feedback and help with this.

Marvin (us-cam-4cc): I know Manu I think we spoke a long time ago last fall
about this I'm just getting around to it but we don't fully understand all
of the constraints and system. So for example in JSONLD this credential
looks very similar to our SD Jot credential and in particular we're
wondering essentially how similar and whether we can build a solution that
works for both Jot and VCs at the same time. So I played around with their
system and this is in the verifiable credential playground essentially this
is the object that's produced it's the credential subject and then right
below here this proof part is essentially just an encoding of the
signature. So from our perspective there are only very simple syntactic
changes between what's happening here and what's happening with zk jot.
00:40:00

Marvin (us-cam-4cc): one change is essentially instead of base 64 encoding
this you're applying some sort of RDF canonicalization and then signing
that and we don't exactly understand how to reason about the RDF
canonicalization and how to prove that we have an RDF canonicalization that
corresponds to a credential that has this particular attribute but if we
could get some assistance I think that's something that we would be willing
to experiment with so that our library supports all three major credential
formats

Dmitri Zagidulin: So, another option, instead of RDF canonicalization is,
simple JSON canonicalization. Would that be a little bit easier, for you to
reason with?

Marvin (us-cam-4cc): you mean it would produce something like this.

Dmitri Zagidulin: No, no, it would be the same data integrity signature as
on the other slide. It's just that instead of RDF canonicalizing the graph,
you would be doing lexical sorting on the JSON property fields,…

Dmitri Zagidulin: So, it's just JCS.

Marvin (us-cam-4cc): Okay. Yeah.

Marvin (us-cam-4cc): So I mean that's something we'll look into. I couldn't
figure out how to get the playground to essentially produce documents in
that way but if I appreciate the suggestion Go ahead and take a note. How
important is the canicalization? presumably you would accept zero knowledge
proof that we have a document whether or not it is canonical that contains
a given attribute.

Marvin (us-cam-4cc): Is the canonicalization important part of the
soundness that you have in mind?

Manu Sporny: So I can jump in here. So happy to help work through this.
we'll probably take more than this call, but I think the important takeaway
here Abby and Mateo is that the canonicalization mechanism that you use,
you can optimize for ZK mechanism. So you don't have to use the same
canonicalization mechanism that we're using right now. And in fact this is
an active area of discussion in the data integrity work. So the data
integrity work is the thing that does the canonicalizations and signatures.
And currently we are exploring all kinds of alternative ways that are more
efficient for building cryptographic circuits on this stuff.

Manu Sporny: So unlike the MDOC and a jot mechanism, you can actually do a
canonicalization on this input document to get it into a state that is more
efficient to prove in zero knowledge.

Manu Sporny: So that's just high level what you should probably take away
today. We're very happy to chat with you on what that could look like in an
actual implementation and…

Marvin (us-cam-4cc): Okay, that's great to hear,…

Manu Sporny: we are actively pursuing that in the Friday data integrity
calls. but that Yes. Yes.

Marvin (us-cam-4cc): Manu, because that's exactly what my next slide was,
which was, can we kind of nudge you to pick something that is not nested
and as small as possible. Those are the two main features we've learned
that essentially if you have very flat structures like this. even this
nesting thing is kind of annoying to parse. flat and small meaning that you
don't use very large names if you can use smaller names and compress them
and get the structure as small as it's possible that is for this legacy
format.

Marvin (us-cam-4cc): For ECDSA, the bottleneck is computing the SHA of the
message that is signed. And one other thing is for example, we spend a
bunch of effort doing B 64 decoding for the jot format.

Manu Sporny: Mhm. Yes,…

Marvin (us-cam-4cc): So if you don't have to use B 64, if you can just kind
of sign the original document, that would also help. So we'd love to
participate in those discussions with you.

Marvin (us-cam-4cc): Go ahead,…

Manu Sporny: that's great.

Marvin (us-cam-4cc): Greg. Okay.

Manu Sporny: So sorry, I'll recue.

Greg Bernstein: Yes.

Greg Bernstein: to bring up what Manu said, the approach with verifiable
credentials for selective disclosure and for anonymous credentials is we
have a base signature thing that comes from the issuer to what we call the
holder or the prover. And then we have a derived proof that goes part of
the credential that goes from the holder to the verifier. We have the
option of determining how we'd like to set up that derived proof.

Greg Bernstein: Yes, we can do regular the whole credential after
canonicalization and put it into ECDSA or we can do other things how we
flatten things and such like that because for example for BBS we needed an
ordered set of messages because that's what BBS takes. And so how we set up
to go from a credential into that ordered set of messages that can work
with any format of credential or any way that people set up the context the
schema that determines the credential. So that's our flexibility.
00:45:00

Greg Bernstein: That's how you can use your root of trust with the Z with
the ECDSA but how you want to set up that first credential that gets signed
with ECDSA we have flexibility there okay and then we can take the second
step and use the ZK but we can optimize that first step for whatever
mechanism people want to use.

Marvin (us-cam-4cc): Go ahead,…

Greg Bernstein: And of course,…

Marvin (us-cam-4cc): Demitri. Go ahead,…

Greg Bernstein: we have example code available. All our test vectors

Marvin (us-cam-4cc): Dimmitri. You're might be muted. I see.

Dmitri Zagidulin: Whoops. thanks. my question was going to be about the ask
for flat versus nested. why is that? is it just smaller key lengths,…

Dmitri Zagidulin: right? Because with nested you can always resort to dot
notation or JSON path notation to flatten it.

Marvin (us-cam-4cc): It's parsing.

Dmitri Zagidulin: So why they ask parsing?

Marvin (us-cam-4cc): The problem is parsing.

Dmitri Zagidulin:

Dmitri Zagidulin: Help me Say more about that if you can.

Marvin (us-cam-4cc): So if you want to parse a nested data structure have
essentially for every bite of the string you kind of need to know what
level of so parsing so without getting into too many details on how the
parsing circuit works ultimately if you needed to support a document with
six levels of nesting each bite

Marvin (us-cam-4cc): each bit of the witness essentially needs to have six
extra witnesses that sort of tell you what level and…

Marvin (us-cam-4cc): sort of what level of the parsing infrastructure
should be used to process it. Let me try to give a better yeah so…

Dmitri Zagidulin: Is that the case?

Dmitri Zagidulin: Is that the case even if you flatten the keys? if you use
a dot notation, right? So, if you had,…

Marvin (us-cam-4cc): if it's just key value so if you just have a key value
store that's one level that's a very very easy data structure to parse all
you need to do is handle the escaping of essentially the quote right in
JSON with two levels now you need to now handle essentially the internal
curling

Dmitri Zagidulin: right, All right.

Marvin (us-cam-4cc): curly brace, but you need to make sure that the curly
brace itself is not inside a quote and also not inside another closing
level. It may be helpful to explain a little bit the constraints of a
circuit. So the circuits that we build then that we necessarily have to
build on in this kind of zero knowledge system are purely combinational
circuits. So they have no memory, they have no stack, they have no program
counter, no nothing. Right? You need to build a circuit of all and…

Dmitri Zagidulin: I see.

Marvin (us-cam-4cc): that gates at least abstractly that pares the thing.

Dmitri Zagidulin: I see.

Marvin (us-cam-4cc): And We have done it. There is some description in the
paper but it is very expensive. It's very hard to design. So we don't want
to do anything like that.

Marvin (us-cam-4cc): So any formula that looks like cobalt from 1960 is
best for us…

Dmitri Zagidulin: I Got it.

Marvin (us-cam-4cc): because anything that has fixed length fields and you
maybe one level of interaction but not many more than that would be ideal
whereas anything…

Dmitri Zagidulin: It's got it. Thank

Marvin (us-cam-4cc): where we have to parse strings and escape characters
is you have to do in a circuit is complicated. So we only have 13 minutes
left Manu I'm going to ask that we take our discussion offline. I want to
get to the BBS portion of this to get your feedback on that. It's one of
the main design points why we haven't been focusing on that. And Otto, the
answer to one of your early questions, yes, it's a non-interactive s
knowledge. It's not necessarily succinct. We don't care about that. and we
can follow up later. I'm going to skip the pseudonym part. I'm going to
skip the idea of hiding the issuers.
00:50:00

Marvin (us-cam-4cc): So again another very simple extension is if we want
to prove that you have a driver's license from a United States state one of
50 we can easily handle that and this is one of the constraints that it's
hard to handle in something like BBS it's hard to hide the key of the
issuer in something like BBS go ahead Manuk Okay.

Manu Sporny: real quick. Pseudonyms is one of the key things I was hoping
to discuss with you today. but we don't have to do it. please continue just
noting it as pseudonyms are a vital property of these unlinkable systems
that's kind of like a must mustave. but we can talk about it at the end.

Marvin (us-cam-4cc): Sure.

Marvin (us-cam-4cc): to give you a short thing. it's a nothing burger for
us because all we need to do is have the credential include some sort of
hash secret as the attribute and then all we do is give another proof of
essentially SHA 256 of this secret and then the context that's used and so
it's essentially two SHA hashes right here and one extra attribute revealed.

Marvin (us-cam-4cc): So it's very little lift on our part. it adds very
small overhead.

Manu Sporny: Is it I think the answer to this is yes,…

Manu Sporny: but is it post-quantum resistant in does it provide
everlasting unlinkability?

Marvin (us-cam-4cc): So everlasting is kind of a funny word that people are
throwing around. the cryptographers usually refer to statistical security
like statistical zero knowledge is I believe the same notion as everlasting.

Marvin (us-cam-4cc): the idea that a computationally unbounded prover can't
link this and so again our zero knowledge proof system is statistically zk
and we only use the hash function right here and so as long as the
parameters are chosen so that the seed is large enough it can't be brute
forced sorry as long as the randomness parameters in our proof system are
chosen large enough which they are then we support statistical zero
knowledge and

Marvin (us-cam-4cc): essentially both of these things will be everlasting
as you say which is not true for example with the DOTski PR VRF if that was
the other approach you were thinking about okay so I' that this is a big
rush but I do want to get some feedback on these points so here are some
notes on Crescent I don't really want to talk about it but the is that this
is the Microsoft scheme the main point that we think is problematic is that
it requires sharing a very large trusted parameter setup up which we simply
don't think can be deployed at scale.

Marvin (us-cam-4cc): the BBS family. I know y'all have done a lot of work
on this and there's of course the natural problem that it's requires a
pairing friendly curve and that makes it hard to deploy on this phone for
example and on HSM. there's a variant that doesn't require that that has
its own issues. however the main problem that I want to point out and I
wrote you Greg an email about this but I haven't found a good solution to
this so far. so again we all know that BBS signs a vector of messages right
m1 through mn okay and for example be age over 18 m2 can be another
attribute and whatnot and later on you can give a proof that for example i
component of that vector is vi okay but the proof does not hide the index
of the revealed message okay and that's critical I know it's like you guys
have well documented the fact that the index essentially

Marvin (us-cam-4cc): is part of the revealed statement. And This is
concretely the problem. If you have credential one and the issuer is
assigned age over 18 to the first base and sort of name as the second base,
And credential two they sign in a different way. Here name goes to base one
and age goes to base two, right? a distinguisher is going to be able to
distinguish because if I give a proof that my age is over 18 and I reveal
index one, the issuer is going to know that this corresponded to credential
one and if for example I reveal index two, they're going to be able to
track that this corresponds to credential two.

Marvin (us-cam-4cc): And so this is the problem and we've looked at many of
the state of the documents that y'all have written and I like and so
there's one mechanism that randomizes the schema all the time and that
doesn't solve the problem because again the issuer and RP can collude and
they'll know exactly which one corresponded to which slot and so ultimately
the only solution we know to this is that every issuer in the whole system
across the

Marvin (us-cam-4cc): needs to be using the same schema for mapping
attributes to message indices. And we think that's going to be hard to
achieve in practice. And that's one of the reasons we've kind of not been
pursuing this signature scheme for our proof systems. I want to know what
you think about that. Okay.
00:55:00

Manu Sporny: Definitely can't cover all that right now but yes agreed that
publishing one schema for everything is not going to work but we have
mitigations for the attack that you're talking about. I don't think they're
in the specs right now. It's something we've been looking at. and we're
trying to get to good case set anonymity as well. So I think we've got a
good response to that but it'll need a longer discussion. the other concern
around BBS I think we're less concerned about there being multiple parallel
branches for doing unlinkability. So I don't think we're looking for I
think we're looking for multiple approaches that give us good unlinkable
credentials in the short term.

Manu Sporny: And you're proposing something that I think has a tremendous
amount of positive aspects. but at the same time, we don't want to harm
other approaches that have different characteristics. that's all. So I
think given the assumption that issuers have fixed infrastructure that must
use ECDSA then yes it leads to kind of a solution that you're proposing but
we don't necessarily think that that is a fundamental underpinning for some
of the other issuers in the ecosystem.

Manu Sporny: not necessarily nation states, but there are other issuers
that are private industry that would be happy to deploy S. but again, I
don't think we should even get into that discussion. it's one of the
reasons we continue to look at BBS,…

Manu Sporny: look at postquantum unlinkable schemes, look at ZK, circuit
based mechanisms. I think they're all kind of in the running for different
reasons. right now.

Marvin (us-cam-4cc): Yep. …

Marvin (us-cam-4cc): as Otto points out, there's also this device binding
thing. we wanted to share with you that we have this approach of combining
sigma protocols with our essentially narc not even s sigma bus does it with
snark so it applies to our scheme as well and we can use ecdsa for
essentially a second clause so we make a proof of a statement I hold a BBS
signature on a bunch of attributes the device public key is one of those
attributes and then I hold an ECDSA signature by the secure element on a
transcript under that particular key

Marvin (us-cam-4cc): You can make this type of and proof using this
mechanism. The one problem we've discovered is that it's not complete in
the sense that the BLS curve can basically hold the group in size of G1 is
this big and the size of P256 is this big and so you can see that about 60%
of the keys don't fit into that range. and so essentially that's a problem
with BLS 381. One would need a different curve. However, in principle there
is a solution to the binding. I did want to share that. Greg mentioned that
he was interested in that when we talked to him last week. but aside this
is the main issue that we're looking at.

Marvin (us-cam-4cc): So, Manu, I'll follow up with you offline to ask about
what you're doing to prevent this type of linkability attack on and again,
we would love to work with you on figuring out in your ecosystem. We'd love
for our library to be a solution. we think it's pretty mature.

Greg Bernstein: Is there any open-source code that we can use to try this
out? R

Marvin (us-cam-4cc): And we understand the performance and the security of
it very well. And it's now a matter of building the circuits that sort of
handle your different credential formats. Go ahead, Greg. Yeah. thank you
for bringing that today is the day that Google list did a press release and
that we are green lit to open source our code.

Marvin (us-cam-4cc): So if you personally send me your GitHub ID, I will if
anybody on this call if you're interested in it, the way this is going to
work, we're green lit to open source our code and right now it'll be in a
GitHub private repo and we're basically soliciting community feedback and
then within essentially 60 days we aim to make it completely open. But if
you send me your GitHub ID, I can give you reader access to this library.
again, my email is shellot@google.com and anybody who sends that over just
in the next week. this process will hopefully get through and you can look
at our library, run our benchmarks, give us feedback, we would appreciate
that. Yeah, it will take us a few days to set it up and…

Greg Bernstein: Sounds great.
01:00:00

Marvin (us-cam-4cc): yeah, we couldn't set up the repository before getting
the official approval. So we couldn't pipeline the process, but give us a
couple of days to set it up.

Marvin (us-cam-4cc): Go ahead.

Otto Mora: Yeah, I know that some folks are interested in this idea of
biometric bound credentials.

Otto Mora: I know that the device itself is being unlocked with the user's
biometrics, but have you explored perhaps the idea of the credential being
bound to the user's biometric hash in some way? I think that might in
increase the assurance that the holder is the same person. that's kind of
the topic that I've heard out there.

Marvin (us-cam-4cc): Yeah, we're aware of that topic and…

Marvin (us-cam-4cc): we're looking at different solutions for that.

Marvin (us-cam-4cc): depends on what layer of the operating system you do
that biometric check. so yes, we're aware of that problem. Currently, our
system does not do anything like that.

Otto Mora: X.

Marvin (us-cam-4cc): There are a lot of usability issues with that type of
thing that we don't fully understand. So for example, if you lose a
fingerprint, can you no longer use your credential? You can get back into
your phone in various ways, but if you basically cryptographically bind the
credential to your biometric and your biometric changes like your face
changes or something we don't know we don't know how to deal with that. So
we're not sure that that's a good idea. although we're familiar with all
the arguments on both sides of that.

Marvin (us-cam-4cc): go ahead. Manu

Manu Sporny: Yeah this is a standardization question noting the time and we
might have to go to the mailing list to answer this but our hope is that in
the CFRG this is standardized as kind of a cryptographic set of primitives
that could be reused across various different specifications. I'm pretty
sure you're already headed down that path. do you know what the timeline
is? Because one of the big problems with nation states or large enterprises
accepting this stuff is that they need to do their own nation state,
cryptography review, what have you. and our experience is that it takes
more than 5 years.

Manu Sporny: It's typically a seven-year process. What is being done in
this case to fasttrack it? I know the UDI stuff is really kind of putting
pressure on this …

Marvin (us-cam-4cc): Mhm. I don't have any insight into that.

Manu Sporny: because it's a big shortcoming not being able to do this. Do
you have any insight on to what's going to make this process faster than it
typically is?

Marvin (us-cam-4cc): What we're doing is doing our best to essentially make
our scheme transparent. We're doing internal and external security reviews
on our codebase. and we're writing very detailed specs on what it does. As
to who accepts this and when they accept it, I dont know. I know all of my
cryptographer friends have looked at it and they seem to be positive about
it.

Marvin (us-cam-4cc): So, the experts I care about have vetted it, but, the
governments that, ultimately decide, I don't know. Go ahead, David. Yeah.

david waite: I just want to point out that one of the big benefits of this
system using ECDSA is that from a government issuer perspective they're not
really changing the technology. So this can be adopted in mixed
environments where the issuer has a lower level of requirement than the
issuer in terms of using approved algorithms. It doesn't solve the problem
but it does lead to a usable system quicker.

Marvin (us-cam-4cc): And I would also say for example we just use ECDSA
signatures and SHA 256. We don't use any new curves or anything new.

Marvin (us-cam-4cc): It's just like the Nobody requires governments to
essentially validate the salted hashing but that uses a hash function or
Merkel trees that uses a hash function. Those aren't essentially specified
or standardized. but they're used widely. And similarly we are doing the
same operations that Merkel trees do. in fact that's about the only
cryptographic operation we do. Merkel trees and read Solomon encoding. so
in that sense all of our steps are pretty basic. So I appreciate that
perspective. I know we're over time now. So I think Harrison,…

Marvin (us-cam-4cc): you want to go ahead and…

Harrison Tang: Yeah. No.

Harrison Tang: This is a great presentation and conversation. If you don't
mind, can you kind of share with a public list this presentation? this will
be great. Yeah. Cool.

Marvin (us-cam-4cc): I'll make a PDF of these slides and I'll send them to
you.

Harrison Tang: Sounds good. And then I think we can continue this
conversation over the email threads if people have any questions. And then
I think if you guys don't mind I probably want to schedule a follow-up
session in the second half of this year to see…
01:05:00

Harrison Tang: because it sounds like there's so many unfinished
conversations here.

Marvin (us-cam-4cc): Yeah, please send us your feedback.

Marvin (us-cam-4cc): Okay.

Harrison Tang: Sounds good. Thank you. Thanks a lot.

Marvin (us-cam-4cc): Yeah, I'll write that Ted right now. Thank you.

Harrison Tang: All So this concludes today's W3CCG meeting. thanks for
joining us. Thanks a lot.

Marvin (us-cam-4cc): Okay. What do you
Meeting ended after 01:05:39 👋

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