ZK Whiteboard Sessions - S3M7: zkID (Anonymous Credentials), w/ Ying Tong

Transcript

Welcome to this module of the ZK Wireboard  Sessions, Season 3. I'm today's host, Nico, and our guest today is a former  colleague of mine actually, Ying Tong. Hello, nice to be here. Yeah, what's the topic for today's session? Today we're looking at privacy-preserving  constructions for digital ID, and these are going to be deployed everywhere in the US and the EU, and we should  absolutely be paying attention to them. Can you give us a quick outline of  what you have planned for today?

Yeah, so what we're going to do is start  with existing constructions. So these are the constructions that are already deployed  nationwide, or are going to be deployed EU-wide, and these are based on a cryptographic  primitive called Salted Hashes. Next, we're going to examine why these are broken.

It's a bad start. Um, yeah, and we're going to break down our  privacy invariants and our privacy requirements, and show why the existing constructions violate  them. So in particular, we will look at the privacy invariant known as unlinkability,  which prevents issuers and verifiers in the system from tracking the activities of  holders. And then next we're going to fix it.

So we're going to present here the sort  of snark of a signature construction, that has been proposed by, projects like Google,  Microsoft's Crescent Credentials, and many ZKID projects in our space. And we can think of it  as a privacy hardening layer on top of existing constructions that gives us back the feature  of unlinkability. And then next, we're going to discuss some sort of additional requirements,  and properties in a digital ID system.

So, I think this is very much, part of deploying  in a real-world context. So issuers need to be able to revoke credentials. we want to preserve  certain features such as deniable presentation. Uh, we want to consider extra protocol privacy  leaks, like differential privacy and such. and then finally we're going to go over the details  and primitives used in these ZKID constructions and sort of the trade-offs of each one and  as well as how they interact with standards

which are important to consider when we're  thinking about large-scale deployments. Makes sense. Great. Should we get started? Yeah. There's many ZKID projects in this  space, so it's probably a familiar topic to our viewers. I think what's changed recently  and why this is an urgent topic is because digital ID systems are being deployed in  many jurisdictions and very, very soon. So, for example, there's like EUDI,  EU Digital Identity Wallet. They plan to roll it out just next year. There's  also the MDL mobile driver's licence.

This standard is already prevalent in the United  States. And a great motivating use case for many of these jurisdictions is age gating or age  verification, and this is basically meant to bar access for adult content and pornography websites  for persons under the age of 18. So, yeah. Regardless what your opinion is about age  gating or digital ID, it is happening and soon. Yeah. So, we might as well do  it in a privacy-preserving way.

Yeah. I think it is our  responsibility as cryptographers as citizens, to make sure we don't  sleepwalk into a surveillance state. Yeah. Yeah. so, we can start maybe  with the existing designs for these digital ID systems and  also why they're broken. So, this is not theoretical at all because this  design has already been deployed in Louisiana. It's called LA Wallet and it's  being used for age verification. So basically this design makes use of a primitive  called Salted Hashes. And how it works is you

have some kind of credential, like a JSON web  token or like some binary object representation. And it looks very similar to the credentials  that we have for digital services. So, there's a header, there's some body, and then  there's an issuer who signs this token. Now, what's different about this design is that  it's meant to enable selective disclosure. So...

What does that mean? Selective disclosure means that you can reveal  some subset of the credential, but keep the other parts of it hidden. And basically how they've  proposed to achieve this is that instead of signing the plain text directly... So, let's say  your plain text is like some name and some value. So, instead of signing this directly,  they sign a hash of it. Yeah, so, they, you get some digest, um...

So, just to be concrete, this could be like  date of birth and this is my date of birth? Exactly. It's all key values, like in a JSON. Yeah. Um, and furthermore, to prevent  brute forcing attacks, like for, I could just 365 days of the year,  right? They include some kind of salt. Okay. So, this is like a big random value? Yes, exactly. This is the salted  hashes design and basically this is encoded into - you can call this disclosure 1.

Okay. Okay. Now, because the issuer has  signed a bunch of these digests... So, for different key value pairs? Exactly. Yeah, you could, when you, the holder,  present this credential to some verifier, you could choose to open only the relevant subset  of values. So, yeah and this signed credential is sort of packaged together with the plain texts and  disclosures, including the salts, up to N values.

And this whole thing is given to the holder. Yeah. So, the verifier is only  going to see the signature, the digests, and then additionally, whichever  plain text the holder chooses to disclose. Okay. Yeah. So, you said this isn't, like,  the best way to do it. Why not?

Um, this is a really bad way to do this.  and the reason is that these digests, along with the signature, are static. Right. So, they are random, but they are static. And so... So, they're always the same, no matter  how many times they present my credential. Exactly. Exactly. So while it is true that I  don't need to open this when presenting it, I do need to provide its digest to the verifier.

And so, a verifier seeing the same  digest twice can identify that it is the same person who presented it. So,  this design, or something very close to it, has been deployed in LA Wallet in Louisiana. And people have to use it to verify their  age when accessing Pornhub or OnlyFans, or maybe in the future, social media. Okay.

So, it achieves selective disclosure, but it fails at every other, sort of,  privacy property we'd like to see. I think it fails very specifically, in  this property called unlinkability. And, yeah, this would be a very good property to  discuss, because it's our main motivation for, moving to a ZKID design. So, for  me, it's always useful to formally state the privacy invariant, the  privacy property that we want.

Um, and how we can do this is through threat  modelling. So, we need to first reason about, who are the actors in the system. And  there's, at the centre of it, the holder. Um... So, the holder of the credential? Exactly. This is the person who's, sort of,  requesting, a credential from the issuer. And the issuer, you can think of as, like,  maybe some kind of government, let's say.

Um, so, the issuer is sending this  document with their signature. So, like, a passport, a driving licence? A passport, driving licence, and it could be  in the SD, it could be in it salted hashes data for now. And then the issuer…  this is called a credential. Yeah.

And then, the holder can present this to a verifier. So, a verifier could  be, like, let's say a bank. So, yeah. And I think one important thing to  note is that at time of presentation, the holder can choose to selectively  disclose some subset of this credential. And does not need to present the whole credential.

Yeah. Yeah. And then, so, what we were saying just  now about unlinkability and why it's a problem is in multiple ways. So, first of all, we want  there to be an observability on the issuer site. And what this means is that given a list  of the credentials they have issued, they should not be able to detect when  these credentials are being presented.

Okay. So, even the government doesn't know  just by looking at this who is presenting. Exactly. Exactly. so, yeah. If the issuer is, colluding, even if the  issuer is colluding with the verifier, we don't want the issuer to be able to link any of the  presentations to any of the credentials. Right. and this becomes very important when  we're considering the interactions that do happen between the issuer and verifier.

So, one main interaction is basically revocation.  So the issuer has to be able to revoke credentials if they get stolen, if they expired, and, yeah,  the verifier needs some way to stay updated as the revocation list is changing. So, yeah, the  issuer and verifier do interact in the real world, and it is crucial that their interactions  do not allow the issuer to link credentials.

Another kind of unlinkability is if they  consider a single verifier. So, given a log of presentations, they should not be able  to link any two presentations to the same person. Okay. No matter how many presentations are made? Exactly. Okay. Yeah. And then this is also true of multiple verifiers. So, multiple banks getting together.

Exactly. So, even if they were to put  together their logs it shouldn't give them any extra information or allow them  to correlate any presentations. Yeah. And so, you can see clearly that  having some kind of static hash or static signature allows linkability  and observability on all these fronts. Right. Yes. So, how do we achieve these  properties of observability and unlinkability? The key thing we have to do is conceal the  static signatures and static hashes and operating in the real world we are subject  to certain design constraints. So we found

that in particular, it's hard to change  issuer behaviour. So issuers are used to certain data formats and signature  algorithms that have been standardised. So, yeah, our design challenge here is how can we add a privacy layer without  modifying the issuer behaviour. Right. So, here we're saying the credential  will always be, like, a passport. They're not going to change how they do passports, but  we still have to do something on this side.

Yes exactly. Cool. Exactly. And maybe down here as well. Yes yes. Okay. So, this set of design constraints motivated  the ZKID construction, and this is very much the construction that Google recently presented in  their anonymous credentials from ECDSA paper. So, as we discussed just now, we don't want  to change the issuer behaviour. And so, the issuer, as before, is still going to work  with SD-JWT, and this contains their signature, the issuer public key, and a list of digests that  are the salted hashes of the actual attributes.

Um, and then we don't want to change this. Okay. But we want to conceal the static  hashes and the static signature. Right. So, here at the level of the prover or holder, we can introduce modifications. And this is  where we're going to introduce a ZK-SNARK. Here we go.

Yeah. So, as we said we want this  SD-JWT to be a private input. Mm-hmm. Um, and as we also mentioned before, we don't want to modify the data format  or the signature algorithm. Right. So, unfortunately, this means that we have to eat  the cost of some SNARK-unfriendly primitives. For example, ECDSA-verify, that takes  in the signature, the issuer public key, and the message signed, which is, let's say,

the digest. Digest. And then another thing  we have to do is parse the data format. So, we have to, let's say, parse a JSON  and output, say, an array of key values. How do we jump from digests to key values?

Oh, that's true. So, oh, the issuer, if you recall also provides to the holder  the plain text disclosures. Okay. And these disclosures contain  the key values, as you said, as well as the salts used to produce the  digest. And so, yeah, inside this circuit, we do have to open these salted digests  and then parse them into their plain text. Okay. So, JSON parser will also do, like, some checks that these values  hash correctly to the digest.

Exactly, yeah. JSON parse  needs to open and hashes. Okay. Yeah. So, no, we're not quite done yet.  I put these into one relation because if you notice, these do not  change with the presentation. These only have to do with the credential itself. Yep. Um, so, regardless of which subset  of these you choose to disclose, you would need to parse all of them anyway.  If you have the foresight to separate out this relations, you can absolutely  pre-process them and store them.

So, I do this once and for all my presentations,  I have this work already done for me. Exactly. Cool. Yeah. How do we do the presentation? The presentation, you cannot pre-process and you do actually have to tailor it to the  verifier's disclosure request. So, yeah, here, the verifier is going to send you  a request for a subset of these fields. Yeah. And, in addition, is actually going to send you  a nonce, a session nonce, to enforce liveness.

To make sure I'm not reusing a proof from  a previous session or for someone else. Exactly. It’s to make sure that the  presentation is being done live, by the same person to whom this  credential was issued. Right. Um, so, in this presentation relation, we have  to disclose based on the verifier's request, some subset of these attributes that we've parsed. And  then we have to approve liveness somehow. So, how this is realised in practice is that the holder's  secure element is used to sign the session nonce.

Yeah. So, this is trusted hardware in  whatever the holder is using to prove? Yeah. So, exactly. Let me, this is one thing I  alluded to previously, but it's an absolutely crucial element of that the holder public  key is also signed here by the issuer. Okay.

And so, at the time of presentation,  the holder needs to prove possession of this public key and furthermore,  use it to sign the session nonce. Right. And that ensures that the holder is using  the same device that is known to the issuer? Exactly. Okay. And that the holder is  in control of the device right now. I see. Yeah. So then these two relations  have to be linked in the sense that they need to use the same set of digests  that were signed by the issuer. And yeah,

furthermore, the holder's public  key has to also be consistent. So, there is some linking proof as well  between the prepare and show relations. Okay. And so all of this generates a presentation  proof, which is in our case a ZK proof, that the verifier checks.

Okay. So this is just one proof  for this, this and the link. Yes, exactly. So it's interesting this design  because for instance, the Google construction lumps all of these pretty much into one  relation that's done live at presentation time. So no prepare for them. They redo it every time. Yes exactly. Okay.

Um, whereas there exists other designs such as  Microsoft's crescent credentials that make use of easily re-randomizable commitments. So in  particular, they use Groth16 for prepare and can very cheaply re-randomise and link these  pre-computed proofs at presentation time. Yeah. So this looks like a super powerful pattern, right? Like verifying a signature  and then parsing whatever was signed. Um, can we apply this anywhere? Like, is  this how ZK Passport works for example?

Yeah, this architecture is generic  over the underlying credential. Okay. So that is the power, the flexibility of  generic ZK proofs. So if we wanted to, we could replace this underlying data format with  passports. As you said, we could replace it with national IDs and we could even replace it with  credentials that are not signed. So for example, some kind of TLS session. For example,  some kind of social graph attestation.

Um, so as long as, we can input this credential  into a circuit, we can use this architecture as a privacy hardening layer to realise anonymous  credentials from arbitrary format. Right. I was, I wanted to ask before you  moved on to TLS, anything signed, does that include like, is  this also how ZK email works? Uh, ZK email? Yes. ZK email has a DKIM signature. Um, so the emails are signed by someone, and then we do the same thing of proving  the signature and parsing the email format.

Exactly. Is it exactly the same with TLS or  are there things that change a bit? So with TLS, the data, the session  and its transcript is not signed. Instead it's encrypted with a symmetric  key. And so it is, we need an extra step between the session and  inputting it into the proof. Um, so for instance, we might need to know  that the prover doesn't know the whole key. Okay.

Or we might need to know that the person  making the proof knows the direction of the communication. And so there are  various, ZK TLS, NPC TLS designs that basically allow us to make an attestation  over a TLS session and then to make a proof about it. `but usually, yeah, this involves  introducing a layer of trust assumptions, like a notary or your proxy, because the  attestation has to come from somewhere.

Right. So summarising the problem is  the data is not signed. We have this sort of symmetric encryption  or symmetric MAC, I think. Um, so the prover could have issued  a credential to himself, right? Exactly. Okay. And so we need to  break that relation somehow. Exactly. Okay. That sounds a bit trickier. Yes. But yeah, the very nice feature of  this architecture is it doesn't change issue or behaviour. And that's why  this anonymous credentials from ECDSA is being considered as one of  the contenders for EUDI wallet.

Um, yeah, there's other proposals such as  BBS signatures, which are lightweight and don't have the full expressivity of a  generic ZK SNARK, but as a trade-off, they require the issuer to change their parsing.  And as well as their signature algorithm. Right. Okay. So we, we had like a super  friendly data format and signature. We can actually get all  this stuff for much cheaper. Exactly.

Okay. So I think a big challenge of working in  digital ID is the need to interface with legacy standards that are widely  adopted already that people have converged around. So the big advantage of  generic ZK SNARKs is this compatibility. One thing I wanted to ask is, all  right, we have this architecture. Can you give us a bit of introduction as to why we  get all the properties we wanted from the system?

Yeah. So, as you can see the verifier no  longer has access to the static hashes or the static signature. So the verifier  only sees a zero knowledge proof and every proof looks random,  indistinguishable from any other proof. Um, I think the, for instance, being able  to conceal as well, the holders public key is a huge benefit of this architecture  and yeah, we can see as well the issuer, just looking at these proofs, also  has no idea how to link them back

to the original credentials that they  issued from the zero knowledge property. Super strong. Okay. Exactly. You also mentioned revocation  as sort of part of our threat model and something that the issuer  could do. How would we do this here? Yeah. Revocation is a requirement in digital  ID systems and it's often very subtle to realise it without violating our unlinkability  requirements. So there are a spectrum of solutions that have been proposed for revocation  and each comes with its trade-offs.

Um, so, and they, they're on a  spectrum of linkability basically. So, the most privacy preserving revocation solution  is to have the holder prove client site, that they're either in a white  list or not in a black list.

Um, so I should ask before we start  here by revocation, do we mean when my passport expires or do we mean sort of  deactivating my passport before it expires? Uh, it could mean both. Yeah. But so  yeah, revocation is stronger than expiry. So your passport could be revoked if you're  considered a criminal by the jurisdiction, for example. Sometimes people are also interested in proving non-inclusion on a sanctions  list, the OFAC sanctions list. Yeah.

But expiring is also one of the methods of  realising revocation. So if each credential, comes with some kind of, expiry token that  is only valid for a certain time window, your proof needs to include a check  that this time window has not passed. Right. Yeah. And so we can set this window for the token  to be shorter than the window of my passport. Exactly. So what this also means is that the  issuer needs to regularly renew this credential.

and the holder needs to periodically  re-register for a credential. And, yeah, this introduces more interaction. And  it is good to note that in the digital ID system I described, an interaction at issuance time  is a requirement because the issuer has to sign the holder's public key, if you  recall. So at the time of registration, the holder actually has to prove  possession of this public key.

Actually, that's something else I wanted to  ask. Is that because of a legal requirement or do we need this device binding thing  for credentials in the first place? This device binding requirement comes from, it  appears in the EUDI’s high level requirements. Okay. Um, but if you talk with projects like ZK Passport  or projects that use physical credentials, there is not this concept of device binding and there's  no need to interact with the issuer, for device binding. But for them, they are often interested  in some proof of liveness at presentation time.

So ZK Passport and Rarimo both are working on some  kind of facial recognition, client-side solution. Yeah. So this expiry tokens are one approach  to revocation and basically require more interaction between the holder and issuer.  So the most privacy preserving solution is for the client to download a revocation list and  then locally prove non-inclusion in a blacklist.

Um, okay. So in this model, the issuer would  regularly update some kind of official blacklist. Exactly. And this puts an online requirement  on the client at presentation time. Right. So, or at least within a certain window. I guess the verifier also needs  to be aware of the blacklist. Yes, that is true. Yeah, but as long as we're  using some kind of public registry for revocation, we need to assume online communication between  the issuer and the verifier as well as the…

and in this case between  the issuer and the prover. Yeah. That's the arrow you drew way back. Yeah. That's the initial diagram. Exactly. So the last sort of common solution  is the worst in terms of privacy. And this is basically having the verifier just ping the  issuer and ask is this credential revoked? Um, so this violates - Unlinkability right?

Yes, exactly. It violates unobservability  because the issuer can tell that this holder is trying to present their token  and yeah, it violates unlinkability between the issuer and the verifier. So it's  important to note here that this would only work if the holder reveals some personally  identifying information to the verifier. Um, right. So otherwise the verifier has nothing to show to the issuer to get  any kind of information. Yeah.

So another interesting consideration when it  comes to revocation is issuer privacy. So, right now sanctions lists are public as we know,  but passport revocation lists are not public. So they're available to law enforcement  officials and the borders, for example. Um, and a concern with public revocation  lists might be that the issuer doesn't want to reveal sensitive information.  So for example, if you're a business,

and you're firing employees and  revoking their employee passes, right. And this might reveal some  information about the state of your business. Um, so I wanted to bring this up as interesting  privacy invariant that doesn't get considered, as much as holder privacy. Right. Yeah. Are there other sort of additional features or additional privacy properties  that we should be considering? Yeah. Another one that comes to  mind is deniable presentation.

This also known as plausible  deniability or repudiation. So this is a feature that the holder  after presenting a credential can plausibly deny having presented it. And this is... Oh no, I did not go to that  tattled website. It wasn’t me Exactly. Exactly. I think of them in the  context of physical interactions especially. Um, and in fact, in the UK and in the US, many of these digital ID systems are partnering  with physical venues like clubs, pubs, liquor stores. And the idea is they would replace  the presenting your physical licence. So yeah,

the worry there is that this digital  interaction will somehow produce a trace. Um, even though we have unlinkability? Uh, if we have full unlinkability and it's  a fully offline presentation, I think that's good. But yeah, when we're considering  let's say the wallet provider or metadata, other ways to fingerprint an interaction,  that might create a trace. But, um... So like my network address or the timings  at which I present credentials maybe or...

Yeah. Yeah. All the things that  could be used to fingerprint you in a digital interaction that you  couldn't in a physical interaction. Um, but for our purposes,  we are worried about sort of linkability when it comes to pseudonyms. Okay. So  it is a feature in many digital ID systems that we want to have a long lived pseudonym  between the holder and verifier.

So even if the holder conceals her actual identity  maybe they want to access repeated services, accumulate points with a service provider.  And in those cases, a long lived pseudonym is a useful feature. Now this enables  linkability in the single case. Okay.

Right. And basically as long as a single  verifier is able to link your presentations, they will be able to then show it to a third  party. And even though each presentation is selective disclosure, we have to consider the  combination of credentials of presentations and whether or not in combination  they might be personally identifying. I see.

So for example, there was this study that  found that just the zip code, birthday and sex of an American was sufficient to  uniquely identify 87.1% of them. So if for a single verifier, across multiple  presentations with the consistent pseudonym, the holder reveals some kind of personally  identifying subset of attributes. This could allow the verifier to identify them and prove  statements about them to a third party.

Yeah. And in this case, deniable authentication  becomes interesting, or deniable presentation. So even if the holder has revealed personally  identifying subset of attributes, we want them to be able to deny having had these interactions.  So the one very simple construction of this is… Sorry, before we get to the construction to  make sure I understand, I want, we want to be able to say, so the verifier won't claim, I  have seen someone show up with this zip code,

this birthday and this gender. And  myself, if I'm the targeted person, I want to be able to say, no, the verifier is  lying. I've never been authenticating with them. Exactly. You want to be able to accuse  the verifier of forging these proofs. I see. Okay. Yeah. And one way you could do this  is we had our relation just now. Our pair and show.

Yeah. Relation like - we had prepare, show.  so yeah, taken on its own, this relation, like approve of this relation is very hard  to deny because you're proving possession in particular of a certain public  key that was signed by the issuer. Um, so how we can bootstrap deniability is  we can add another pathway for verification, which checks whether or not the person  making the proof is the verifier.

Right. So if the verifier wanted to forge  a valid proof without knowing any of your attributes without possessing  your phone's public key, it could simply input its own private key and fulfil  like this branch of the relation. I see. So myself as an honest user, I'll use  this parts and this will always be false and the verified, well, someone observing the proof coming  out of this doesn't know which path was taken.

Exactly. So it could be either an honest  user or just the verifier. Exactly. Wow. Okay. Um, so I rarely see this property being  discussed in digital ID constructions. and I think there's a lot to  explore here. For example, making it very easy for verifier software to  forge proofs that would strengthen the claim. Um, and also perhaps allowing anyone to  forge a proof after a certain time window.

So that again, the set of people who  could have forged it as like large, large, and your claim is more believable. Yeah. One additional question. How can we avoid these kinds of situations? Because this  seems very inconspicuous, right? Like I'll give you a zero-odd  proof of my zip code, birthday, and sex. Like what's the worst that could happen? That's a really good question. And there are  many ways to de-anonymise a holder outside of the protocol. And one of my worries for ZKID  or privacy-preserving IDs is that it sort of lulls us into a false sense  of security and encourages

us to reveal paradoxically more  than we would have otherwise. Um, so I think there's been a lot of studies  when it comes to differential privacy as well of how the relationships between attributes can  actually be personally identifying. So yeah, in some and it's orthogonal to the cryptographic  design protocol design. But yeah, I think it's important to keep in mind and it's important  not to fall into the trap of thinking that just because something is ZK or selective  disclosure that we can let our guard down.

Um, and yeah, in fact, placing restrictions  on what verifiers are allowed to ask for, I think is a good starting point. I guess, for example, with let's say I'm  doing a job interview and the verifier is asking me my sex. I would love to  be able to say that like, please no. Right. It's not information you need to know, right? Yeah, there's definitely, when it comes to  selective disclosure, a spectrum of use cases, there's some use cases where the verifier  does need to know everything about you.

So, I guess something medical, for example. Exactly. Exactly. And in that case, you  don't need selective disclosure at all. So really this only matters when the  verifier is only entitled to some subset of the attributes. yeah. So yeah, these privacy  invariants, like unlinkability, unobservability, a deniable presentation, they interact  with these extra particle attack vectors. Yeah. And I think the idea here is  that if we have a system that is very limited in what it can do and what  it can learn, then we guard ourselves from these attacks or make  them easier to reason about.

So, so far we've been sort of looking  at the construction from a high level and we've been saying like ZKP is this  black box. I was wondering, you know, we have a whole zoo of like zero knowledge  proofs. I was wondering if there's any proofs that we prefer using over others,  any properties that are super important? Um yeah. Yeah. We've seen a range of designs already. I  think maybe a good illustration, a comparative illustration is Google's  design versus Microsoft's.

Um, so, and the Microsoft design  is called Crescent Credentials. So, as we recall from previously, we  have two relations: prepare and show. And the link, right? But I guess. And the linking proof enforcing consistency  of the inputs shared between them. So in Microsoft Crescent Credentials, these  are two different phases and they use groth16 for the prepare phase. So now, the benefits  in this it's very efficiently re-randomizable.

And this is a property of Groth16  proofs that they're easy to. Exactly. They're easy to re-randomise. And, so that means I can make a new proof  without having to like recompute everything. Exactly. Exactly. And yeah, it's a good  point here that you cannot literally just reuse the same proof, cause then  that's a static proof and it's linkable. Right. But as we know, Groth16  needs a trusted setup. And this is true for KZG, any system that uses  KZG commitments as well. And in fact,

Groth16 also needs a per-circuit  trusted setup on top of that. So yeah, in many ways, this is an anti-feature, because you are coordinating across a huge  ecosystem of issuers, verifiers who don't trust each other necessarily. And would want to, would  want stronger guarantees than a trusted setup. So how do we make sure like that they're  somehow all contributing to the trusted setup?

Um, that's a coordination problem. What if the circuit needs  to change for some reason? Yes. Yes, exactly. But one way to think about the  trusted setup is it could actually make use, we could make use of our existing trust assumptions  about the issuer to instantiate a trusted setup. So this could actually be a  feature. So what I mean is, right now, the issuer can already  forge whatever credentials it wants to.

Right. Yeah. The government  can make new passports. Yes. I mean, we hope there's some kind of watchdog, but  yeah, for the sake of argument, issuers can forge. Exactly. So if the credential is signed by  the issuer, this means the issuer holds the private key and can sign whatever they  want. So, if we give the toxic waste from the trusted setup to the issuer, have we  really changed anything about the trust model?

So the issuer… With the toxic waste can  produce any proof they want. Yes. It can forge proofs of invalid, for not unsatisfying witnesses.  But basically nothing has changed. Um. They could already forge  presentations by forging a credential. Exactly. Even presentation just by forging a proof. Exactly. I see. Yeah. So yeah, I think, yeah, designing  in real world contexts, very often the constraints and the trust models, actually expand  their design space. And yeah, carefully examining

like who we already trust can help us make  decisions about like downstream tech stack. Yeah. But basically we can instantiate  a designated verifier, Groth16, allowing the issuer to forge proofs. Yeah. So, whereas in the Google case, they're  using some combination of GKR and Ligero, that is ZK. Mm-hmm. And so this  is not efficient to re-randomise.

So, so it uses the BCS transform  which commits to the witness using Merkle commitments. Mm-hmm. And so unlike the  Groth16 commitments, these are not homomorphic. And if, we subsequently want to re-randomise  them, we basically need to redo the whole proof. Right. Yeah. But because they don't use,  they don't need a cryptographic group, they don't use discrete log, they don't use  pairings, they can use very small fields.

And actually they can use arbitrary fields. And,  so I think you'll hear in the ZK podcast episode with them that they exploited this property to  the fullest and chose native fields and binary fields and basically just the most efficient  fields for the underlying operations. Right. Yeah.

So they make up for the fact  that they have to redo, prepare, but just make sure that everything is super  fast and you can do all this quickly. Right. Exactly. So even though they have to each time  recompute the whole relation, they've made it just I think it's about on the order of one  second or two seconds on a phone. yeah. So I will say that a setting that  might be interesting to consider is a multi-credential presentations.

What does that mean? So instead of only presenting a single credential, you're taking multiple credentials  and linking them somehow. Right. So my passport, my driver's  licence, maybe some email I had. Some email, your bank statement.  Yeah. And then when it comes to multi-credential presentation, it can get unwieldy quickly if we don't have an efficient  way to pre-compute them and to link them. Right.

Um, so yeah, basically in the  case of like say n credentials, the Google relation possibly  would just blow up to n times. I see. Whereas for Microsoft's crescent credentials, we  don't pay at all for the pre-processed proofs. And then, so the factor of n is like  only at the show, which is way smaller. Right. Makes sense. So it seems that even  though it's like one general architecture, there's so many approach to do things.

Um, question I have is if we want this  to be like actual legally binding ID, do we need some kind of  standard way of doing this? Yeah. a lot of these solutions are  targeting national level ID systems. So like the EU digital ID wallet, as well  as the mobile driver's licence in the US. And so it becomes crucial to be able  to specify and standardise your scheme and provide assurances about a security. So  another good thing about Google's design is they only use standardised cryptography. So  yeah, they only meet hash functions basically.

Right. Um, and yeah. Whereas the stuff here is  less standards, more recent. This, yes, they in particular need pairings.  And that has not been standardised, by any major standards body. So a big part of a  digital ID project that interfaces with national level stakeholders is to be able to work with  standards bodies like the IETF and W3C and ISO.

Yeah. so yeah, for example, Google  has their libZK, informational draft on IETF. And I have been working on a  standard for polynomial commitments here. And yeah, in many ways, piracy preserving  digital ID is theZK community's first contact with standards bodies. And the W3C  is a kind of a higher level standards body that they take primitives from the IETF and  use them in applications and the web level.

Um, so IETF likes you to standardise  the specifics you get proof for use, whereas W3C, the whole like, here is  how I construct a presentation. Exactly. Exactly. The W3C wants to be able to  consider the ZK proof as a black box and then use it in higher level applications  like verifiable credentials and data integrity proofs. So yeah, besides these standards  bodies, yeah, there are many, many others.

Um, and yeah, I think the benefit of standardising  something is it provides a security guarantee. So if your implementation conforms to the  standard then it's going to be that, let's say 128 bit level security is guaranteed.  So yeah, I encourage people working on ZK ID or privacy preserving digital ID to get familiar  with existing standards and start to think about how we can work with these standards bodies  or even start to standardise our own schemes.

Makes sense. Thanks. I think  that's a good place to wrap up. Um, let's see if I can summarise sort of  what we saw. We had first the strawman protocol of how to do selective  disclosure. And we saw that doesn't work because our credentials were static  and our presentation was static as well. Um, then we looked at the threat model.  We realised our presentation needs to be randomised somehow private. We have this  SNARK of a signature system that you showed. Um, then we discussed extra  properties like deniable presentation, the worries about de-anonymisation  and then specifics of what proofs can we use and how do we standardise  them. Amazing. Thank you very much.

Thank you.