Credentials Community Group

<harrison_tang> @Greg you might want to check your microphone. i don't think we can hear you when you unmuted earlier

Harrison_Tang: All right um welcome to this week's w3c ccg meeting uh today we are excited to have Greg uh Bernstein back again to present on the anonymous holder binding and student sum so about 2 weeks ago Greg uh.

Harrison_Tang: Present an update on the PBS signatures and uh today we'll follow up with uh related but different discussion regards to uh the holder binding Anonymous holder binding and uh pseudonym so before we get to uh the main agenda I just want to quickly go over uh the administrative stuff um so first of all a quick reminder on the code of ethics and professional conduct uh just want to make sure that uh we hold uh constructive and respectful conversations and discussions.

Harrison_Tang: A quick note on the intellectual property uh anyone can participate in these calls however all substantive contributions to any ccg work items must be the member of the ccg with full IPR agreement signed so if you have any questions in regard to getting a w3c account or signing the community contributor license agreement uh please just let any of the cultures know.

Harrison_Tang: A quick note on uh the minute meetings uh these uh minutes are automatically recorded and we will publish the meeting minutes as well as the audio and video recordings in the next uh 1 or 2 days.

GregB: Sorry guys I couldn't hear a thing I don't know what was happening okay sorry.

Harrison_Tang: Because uh does this sound work now can you hear us now.

GregB: Yeah all all I was hearing is the recording is on and I knew that you guys were talking because I started seeing the transcript sorry.

Harrison_Tang: Oh no problem I'm glad it works um.

Harrison_Tang: All right so uh uh just getting back uh to the administrative stuff and then we'll have Greg on uh to present and be the discussion on the anonymous holder binding.

Harrison_Tang: All right so again these meetings are being automatically recorded and will publish the meeting minutes audio recording and video recording in the next 1 or 2 days we use GT chat to cue the speaker so you can type in Q Plus to add yourself to the queue or cue minus to remove.

Harrison_Tang: I think it's a time for introductions and reintroduction so if you're new to the community or you haven't been active and want to re-engage feel free to unmute and just uh introduce yourself.

Harrison_Tang: All right 1 of those days I'm gonna start calling on people but today's mostly uh familiar faces so I'll let it go all right um announcements and reminders uh if you have anything new or new events or new projects uh feel free to just uh unmute or uh.

Harrison_Tang: Typing Q Plus to add yourself to the queue.

Harrison_Tang: Money you want to go first.

<benjamin_young> Here's how to add your implementation: https://github.com/w3c/vc-test-suite-implementations?tab=readme-ov-file#usage

Harrison_Tang: Thank you man.

Harrison_Tang: By the way Erica uh do you have new announcements uh.

Harrison_Tang: Great we can hear you great.

Harrison_Tang: Thanks a lot and Erica like if you can send a link to me or directly to the public list that would be great too.

Harrison_Tang: Benjamin do you have anything else to add.

Harrison_Tang: thank you.

Harrison_Tang: Thanks a lot.

Harrison_Tang: All right any other announcements or reminders.

Harrison_Tang: All right updates on the work items.

Harrison_Tang: Thank you man.

Harrison_Tang: And uh we'll have a West actually uh talking about the verifiable credential barcodes on August 6th and uh in addition to that uh uh will has been uh contacting different work item um leaders uh and owners uh in regards to uh providing updates uh as well as uh scheduling them uh to uh you know hold a special sessions on those work items so we're working on that actively so uh stay tuned.

Harrison_Tang: All right uh any last uh.

Harrison_Tang: Work item uh discussions.

Harrison_Tang: Last calls for introductions announcements reminders and work items.

<manu_sporny> Nice!

Harrison_Tang: Great thanks Clea.

Harrison_Tang: Didn't know that about the Swiss government so learn new things uh every day so great.

Harrison_Tang: All right any last calls for introductions announcements work items.

Harrison_Tang: All right let's get to the main agenda I think uh you know 2 3 weeks ago we had a we had a Greg here to talk about BBS amazing discussion learn new things and uh today we have him back to talk about Anonymous holder binding and Sudan so Greg uh the floor is yours.

GregB: All right now I am.

GregB: Share this screen.

GregB: Okay but I'm doing it from a different browser okay.

GregB: You see anything.

GregB: Great can you still to see things.

Harrison_Tang: Yep looks good.

GregB: Going cross browser all right.

GregB: So we're going to talk about some Advanced features that we've added to BBS so we're gonna kind of do an overview remind folks again.

GregB: BBS we're going to go in a little reverse order because when I was walking through figuring out how to tell this story it seemed like pseudonyms were the things to start with and I was a little shocked to discover that they are now specified for the EU diw European Union digital identity wallet.

GregB: so I.

GregB: This stuff about cryptographers reviewing the ud ARF which.

GregB: That came up and I was saying good okay so we're going to talk about pseudonyms and then at the end we'll get to Anonymous Soldier binding because that comes.

GregB: Comes with everything okay.

GregB: Have talked before yeah.

GregB: Been helping to co-edit these specs I do a lot of the cryptographic test fixture generation for these specs um working out I've got open-source software for almost all this stuff somebody did recently asked me uh can I use some of this code and I had forgotten to put a open source license thing in it if you run across any of my code and it's missing an open source license statement just tell me I've got a update those things.

GregB: And I'm working with the ietf on the BBS specs which we're going to be talking about a little bit here.

GregB: We're concerned with tracking so there is a famous song back in the 80s by a band called The Police Every Breath You Take every move you make every Bond you break I'll be watching you.

GregB: And it was a very sweet song and it was mistaken for a love song but it was really about a stalker so people were using this as their wedding songs and things like that.

<harrison_tang> ;(

GregB: It was a very popular song so people went crazy with the lyrics to not only Every Breath You Take but every move you make every leaf you rake.

GregB: And so it really is about and if I was currently teaching cyber security like I used to I would make my students go through and say How could somebody get this information on you oh you went to the Home Depot website and looked up a leaf blower oh your ring doorbell uh camera caught uh you doing something at blah blah blah so we're concerned with tracking.

GregB: And so when we've talked about tracking.

GregB: we talk.

GregB: Talk about the main players in verifiable credentials the issuer the holder and the verifiers.

GregB: All right this thing is I'm seeing this thing right in the middle of it okay.

GregB: So what if a verifier shares information about an encounter with a holder.

GregB: They learn things.

GregB: They understand the holder's been visiting various sites.

GregB: Seems like they should especially if the holder fully identifies themselves.

GregB: What about if the verifier.

GregB: Shares information about encounters withholding presentation of credentials.

GregB: Okay from the holder to a verifier shares that information back with the issuer it seems like obviously the issuer know all the places the holders visiting.

GregB: Okay and we can go 1 step further say what if the verifiers share that information about their encounter with a holder to a third party that third party could get to know all that information.

GregB: How do we stop that.

GregB: Or minimize that well.

GregB: First of all don't reveal your name okay and you can do that with the selective disclosure mechanism okay minimize what you reveal to the verifiers about yourself.

GregB: to make.

GregB: But there's a bit of a problem with verifiable credentials and it's that.

GregB: General signatures the digital signatures we use are very unique.

GregB: Okay and they can take the place of your name to become an identifier used to track you so we need something called unlined to make sure the security features that secure the credentials don't become an identifier to track US okay.

GregB: BBS signature scheme applied to VCS can provide both these things okay selective disclosures and these things known as unlink proofs.

GregB: There was just a cryptographic review of these wallets the European wallet standard and they actually say now that.

GregB: To obtain okay not allow providers of electronic attach stations meeting some kind of credentials okay to obtain data allows transactions or user Behavior to be tracked linked or correlated okay unless explicitly authorized okay.

GregB: And they say this technical framework of the wallet shell enable privacy preserving techniques which ensure unlike ability.

GregB: I did not make that error that was an errors that's unlink but I copied it straight from the document so they have a spelling error okay.

GregB: So we know we want this not always.

GregB: And even if we want anonymity.

GregB: How much anonymity do we want.

GregB: there is.

GregB: Another song from the 80s.

GregB: Is all well after my time don't you forget about me right.

GregB: Got these very Anonymous credential from BBs.

GregB: Your selectively disclosed a minimal amount of information.

GregB: And you want to.

GregB: But you'd like the verifier.

GregB: To be able to.

GregB: Recognize you from a previous encounter.

GregB: But not be able to link your data with other verifiers.

GregB: So you'd like them to recognize you.

GregB: But not link you with other verifiers.

GregB: That sounds a little tricky okay.

GregB: Another variation of this would be led a verifier associate you with a previous encounter.

GregB: Not link your data with other verifiers.

GregB: Issuer to know it's you okay oh why would you want that.

GregB: Um let's say we go back and do a pandemic.

GregB: We want to prevent people from hoarding you have to prevent some kind of present some credit credential to say hey I'm allowed to buy toilet paper and we're going to not let individual stores tracker toilet paper use but we're going to see that there's no hoarding going on by letting some issue or check that.

GregB: So subtle right.

GregB: Remind you BBS signatures.

GregB: what do they.

GregB: It look like somebody comes up with a bunch of information that BBS calls messages.

GregB: So this looks like a driver's license for a tree.

GregB: First name Sequoia Sentra and lives in the Redwoods uh State Park in California where you can create a signature.

GregB: Okay this signature information.

GregB: Okay can act as an ID okay.

GregB: With BBs though.

GregB: We don't the holder doesn't present that signature it only goes from the issuer to the holder they don't pass it along.

GregB: So he wants to go into a bar to get a very large drink of water and the requirement is.

GregB: Got to live in California because we had sometimes have droughts and he's got to prove his age.

GregB: So he's only going to select those 2 pieces of information to reveal.

GregB: Generate proof at all.

GregB: It's always great when you do a demo.

GregB: Sorry I was not using the online demo.

GregB: Oh demos are always great.

GregB: I do have a demo of the thing we're doing but let me see let me go back and get to the code.

<harrison_tang> demo is better than no demo

GregB: Too many links create signature.

GregB: Is above signature.

GregB: Select date of birth generate the proof.

GregB: Now as many times as I hit create signature.

GregB: That signature number which is the cryptographic signature won't change.

GregB: This proof that's generated by the holder to present to the verifier.

GregB: Every time I hit generate proof I get a unique proof.

GregB: For all purposes like a signature but it's not correlated.

GregB: So that's what we mean we get that anonymity unlink.

GregB: This is a property of BBS you don't get this with the other signature algorithms.

GregB: You don't get this with eddsa or ecdsa.

GregB: Okay so that's we can do this.

GregB: Or at least we can get that anonymity.

GregB: Appropriate conditions okay but how can we make it so they can remember us.

GregB: Okay well there's an idea known as a pseudonym right it's a fictitious name that you use for a particular purpose right.

GregB: Writers like Samuel Clemens wrote as Mark Twain the mathematician Charles Dodge and Dodge and or however you pronounce it wrote novels under the name of Lis Carol Wright.

GregB: And when you visit websites you can do the same thing you can use a different username for each website and you make sure you use the different password for each website.

GregB: And if you had to.

GregB: Verify with an email address you could use a unique email address that can be a little bit bothersome but there's some places that make it very easy to come up with unique email addresses that forward things to you so if I'm if I think a website that I'm registering with is a bit dodgy and I don't want them spamming me I'll go use uh email forwarder that comes up with unique addresses for each website like Duck private addresses.

GregB: So that's great that's pseudonyms that's 1 approach is good for the web but how would you do that with a verifiable credential.

GregB: Oh and look.

GregB: In this European digital wallet which I just learned about.

GregB: I'd like you to be able to generate pseudonyms too.

GregB: We're making up a unique name for yourself for every place sounds a little problematic okay.

GregB: How are we going to do this for VCS.

GregB: I guess we could ask the issuer.

GregB: The issue of EC to the holder under each pseudonym the holder wants.

GregB: Problems the issuer would have to issue lots of near duplicate credentials to the holder for each verifier that the holder encounters.

GregB: Sure would know the holder pseudonyms and can track all their encounters with verifiers.

GregB: We sit in 1 of our 2 use cases that like the uh the hoarding prevention use case this might be allowable but.

GregB: In general no we don't want to be dragged okay or that's not okay but let's start with this first 1 how could we prevent this headache.

GregB: Okay of having to make an issuer issue lots of VCS under each pseudonym we want and such okay.

GregB: Well we could do this with a cryptographic technique okay.

GregB: We could have the holder know a secret.

GregB: Find that with par verifier public data to produce.

GregB: Pseudonym okay it's not going to be nice and readable and things like that but it would be very easy to use in the digital wallet okay so how do we do this in general.

GregB: Have a hold or have a secret number we can call our approver ID that's what we do in uh the BBS specs okay and you want it essentially unique.

GregB: So a random number that's super secret.

GregB: The verifier we're going to let us have a public essentially unique number call to verify our ID a vid a bid and a vid okay.

GregB: The holder generates a certain Name by raising the vid to the power of the pit.

GregB: and shares.

GregB: Okay so how does this help.

GregB: An issuer needs to only sign the VC with info about the proofer ID.

GregB: Generate the pseudonym for any verifier that they that publishes a verifier ID.

GregB: Let's keep track of this with appropriate parameters the difficulty of the discrete logarithm problem this is 1 of those mathematical things that drives.

GregB: Most of the cry uh most of the digital signature schemes where you're using today ecdsa and eddsa are based on this thing called the discrete logarithm problem in addition to um.

GregB: Uh key sharing algorithms like Diffie helmet okay and it prevents any other verifiers discovering the pit from the pseudonym and linking with other verifiers.

GregB: Don't freak out it's a little bit of math okay but.

GregB: It's not that hard to do.

GregB: Value would be a number and then BBS we call such numbers as scalar.

GregB: The vid value the verifier ID would be an element of the group G1 and BBs.

GregB: BBS has functions already to take an arbitrary number and turn it into 1 of these scalars or to take an arbitrary number or bite string and turn it into such an element okay a suited in the value oh let's see how this works.

GregB: Okay so here's this is not yet this is actually running on my machine I did.

GregB: Not get this demo out yet so I'm the holder.

GregB: I'm going to generate a random secret number that I'll call my approver ID okay.

GregB: So here's my PID this number I'm showing in text just for Simplicity it's are we use hex for large numbers when we do these tests vectors because.

GregB: it's easy.

GregB: Whatever language people are writing their code in okay oh but look the verifier ID I'm using looks just like a URL doesn't have to be.

GregB: Should be unique something to verify or has that they're going to make public okay from these 2 pieces of information I can generate a pseudonym.

GregB: This is what it looks like it's a big long hexa decimal value okay from this value.

GregB: Nobody can go with in current computing.

GregB: Uh terms can go from this value back and discover what my original secret Brewer ideas.

GregB: And I can hence use this value as a pseudonym.

GregB: With that particular verifier so we can sometimes call this a pseudonym or a pervert ID.

GregB: But it's got these nice properties okay.

GregB: Do we have enough to do something.

GregB: Make a protocol that gives us a pseudonym that's good for being recognized and that can't be tracked across verifiers.

GregB: yeah we.

GregB: Let's see how this would work.

GregB: Issuer known pit flow so the issuer in this case we're going to have them.

GregB: Come up with approver ID our secret value they're going to share it with the holder okay in addition what they're actually going to do is they we'll see in a sec they're going to sign it as a message that they provide using BBS to the holder okay the holder gets to verify our ID from the verifier somehow they know it already it's published somewhere they compute the pseudonym.

GregB: Then they create their selective disclosure vidi vici and send it with the pseudonym to the verifier the verifier sees the pseudonym they can recognize oh it's the same entity.

GregB: coming back.

GregB: Back with this credential I've seen them before I can say hello how are you.

GregB: Got whatever it is that you want it.

GregB: Or whatever we continue that relations okay.

GregB: Once again this does not prevent tracking by the issuer so this would be good for the case of issuer assigns this number and if needed could with verifier help track purchases or whatever the holder is doing okay we're going to get to the harder case in a second okay so the issuer duties they generate the bid they create a BBS signature the VC adding the PID value.

GregB: At the end.

GregB: Right create the signature.

GregB: Use above signature.

GregB: What we don't do is we'd never revealed the pit oh.

GregB: Oh but this but they have to know the bid and they're told the bid and when they get their signature.

GregB: Never revealed the pit so the other the verifier never learns it but they have to prove it.

GregB: Okay send VC with bass proof bid to holder what is the holder do holder verifies.

GregB: Obtain the verifiers pit value uh vide value the verifier ID computes the pseudonym based on those 2.

GregB: Permanent is the minimal amount of information to disclose to the verifier and especially not their approver ID.

GregB: The VC with the derived proof okay that's our term in the BBS VC BBS spec we have the base proof which is the original signature which is unique derived proofs have that BBS proof where I said every time you hit the button to regenerate it its unique and can't be correlated.

GregB: Send that derived proof and hands and the pseudonym to the verifier.

GregB: Now what we do.

GregB: and this is.

GregB: In the BBS pseudonym draft is we actually extend the proof to make sure.

GregB: That pseudonym value calculated and everything like that is legit and based on the proof of it okay.

GregB: We'll see a little bit about how those kind of things work coming up.

Harrison_Tang: Hey Craig do you mind taking a clarification questions.

Harrison_Tang: Yes so so far what you described the solution does not solve the issuer tracking uh when they collude with verifiers and tracking the uh tracking cases what it solves is when verifiers collude with other verifies verifiers and and and.

Harrison_Tang: it solves.

Harrison_Tang: Right like I just want to clarify okay.

GregB: Yes exactly okay because we're going to need something more for that next case okay.

Harrison_Tang: So so in the earlier presentation you represented 3 types of tracking 1 is the verifier colluding with other verifiers 1 is the issuer's colluding with uh verifiers and the third the third 1 is the third party so the solutions so far solves the verifier collusion problem does it solve the third party problem or not not.

GregB: Yeah unless yeah unless they are working with the issuer they don't know the pit the that proved her ID value so yeah you know.

GregB: Good there okay and that's why when we write some of these specs and I've gotten on some of the the cryptography people's specs cases like you got to be really clear about what information is known to who otherwise they can't figure out what the attack scenario is and what you're protecting and you got to tell me what is protected and what's not so under the assumption that the issuer does not reveal the pit to anybody we're protected from that third-party tracking.

Harrison_Tang: Got it thank you.

GregB: So we didn't solve the problem of.

GregB: Issuer being able to track us we need something more from that okay so how can we prevent the okay so this is the question how can we prevent the issuer from knowing the pit in the first place and be able to track all their encounters okay and even even more so what if we wanted to come back to uh a verifier.

GregB: With credentials from somebody else and say hey this is me.

GregB: Use that same PID.

GregB: With a different issuer without revealing it.

GregB: So what we want to do is we want to have the holder.

GregB: Generate the PID this prover ID value and keep it secret but how could this work if it's kept secrets.

GregB: Let Me Go full screen.

GregB: The prover ID to be kept secret by the holder.

GregB: What good is the secret and the amazing part of BBS and zero knowledge proofs start to kick in okay.

GregB: BBS is based on zero knowledge proofs that's how we get that on linkability and it already uses this stuff inside but let's understand it.

GregB: Apply to prove her ID uh this whole pseudonym thing the first thing we need to know is something called a commitment scheme.

GregB: So a way that you can commit to a number.

GregB: Keep it hidden from others.

GregB: With the ability to reveal it later but not change it.

GregB: It's that classic beginning of a magic trick where it's like think of a number write it down on a piece of paper fold it up but don't show it to me.

GregB: After they get it they do their magic trick they're going to say ah look I know your number.

GregB: or what.

GregB: There was a card or whatever somehow they figured out what your number was okay.

GregB: But it okay so it's like writing something down to be revealed later so commitment scheme has the following properties.

GregB: A commitment is generated.

GregB: You can only open it to that original message okay you can't change the message or your secret number your secret message whatever it was okay after the commitment has been made.

GregB: Other thing we want out of a commitment scheme particularly.

GregB: Uh for what we're working with here is we also want something called hiding.

GregB: Okay the commitment string should not reveal information about the committed message.

GregB: For example what if it's a very simple message like I flipped a coin heads or tails you call it right and you're going to do this interact you know it's like.

GregB: Wait there's only 2 messages you know maybe I can just reverse engineer things okay well let's take a look at a typical commitment scheme.

GregB: We've got a message m.

GregB: We choose a number number another number separate from the message that we're High we're committing to randomly we commute compute a commitment this is just 1 example of by taking the hash.

GregB: Of our number or message.

GregB: Concatenated combined just glued together with that random value.

GregB: The person we're committing to you know this is like riding that na number and on a piece of paper putting it in an envelope sealing it up sending it off to them we send them both the value computed and that random number.

GregB: On revealing it.

GregB: Okay we revealed the message we can prove then that we haven't changed things by having them recomp compute this.

GregB: Okay so that's 1 example of a commitment scheme.

GregB: Another more another famous commitment scheme is something called a Patterson commitment.

GregB: Oh we've got this group Theory stuff so we have these 2 numbers 2 separate numbers X is the number that we want to our message okay and this is more like how BBs Works inside.

GregB: Message ours are random number known as the blinding factor and we compute the commitments.

GregB: Oh it's got that these are those discrete log things to solve this is not easy it looks easy to write down.

GregB: and we.

GregB: Can compute exponentials easily but to try and reverse this is hard.

GregB: Uh how does this help.

GregB: If we reveal the pit.

GregB: We can be tracked still.

GregB: So we don't ever want to go that full step of doing the reveal.

GregB: So what we're going to do.

GregB: Is provide a proof that we know this value.

GregB: And require the proof doesn't reveal any information about.

GregB: This is what we mean by a zero knowledge proof.

GregB: And these get quite quite complicated okay you've heard maybe a thing is called ZK snarks or such like that you've heard of things that huge computations.

GregB: that's not.

GregB: Not the case.

GregB: With BBs or what we're doing here it's a zero knowledge proof but it's 1 of the first cases of zero knowledge proofs BBS is remember go back 20 years.

GregB: And uses some techniques so what kind of concepts are we going to have here so we're never going to reveal the pit we're going to prove we know the pit.

GregB: Without revealing it so what do we need here first of all we're going to have this proof thing this protocol we got to make sure by the time we're done with this protocol.

GregB: That it actually works you know.

GregB: Okay so if we accept things.

GregB: You know it's true.

GregB: We want to make sure.

GregB: There's a thing called special sound is that basically says.

GregB: They must know that number to be able to complete this proof of this protocol.

GregB: Okay so first if we go through all the steps.

GregB: It better be right okay we're we're told hey you really know that number okay we get a an accepting conversation.

GregB: Again you have to know that secret number okay the prover needs to really know the number to finish that proof call.

GregB: Okay then the final piece is.

GregB: Okay meaning in an honest verifier I mean they're not using active attacks and things like that it doesn't learn anything about that unknown information from the proof protocol.

GregB: Some of these things are very easy to prove okay.

GregB: Others take more effort so how do they I said I'm going to make this commitment thing.

GregB: Okay this Patterson commitment okay this is going to be my pit value this is my blinding Factor okay I want to prove that I know the 2 values.

GregB: Okay so I'm Computing this information.

GregB: The prover and to verify are both going to know g&h the only the prover knows Alpha and beta.

GregB: Okay Alpha is going to be our pit beta is going to be our hiding Factor okay prover gives you to the verifier.

GregB: And they want to prove they know those things that they know the other 2 values.

GregB: So stolen straight from Bonet.

GregB: The B and bbs's book uh free graduate course book on applied cryptography how these proofs work.

GregB: Is we got P for the approver V for the verifier we pick a couple random numbers.

GregB: Okay we compute something kind of a test value okay we send that over.

<wendy_seltzer> (Boneh, for the transcript)

GregB: The verifier computes a random challenge value sends it back to us.

GregB: Craig what's the point of all this.

GregB: Then at the end they test things.

GregB: well let's.

GregB: Look a little bit Alpha and beta the things that the prover keeping hidden.

GregB: The challenge value comes from the verifier and mixes in with those 2 values.

GregB: That's dangerous oh but these Alpha T and beta T kind of help blind those values so they can't learn it okay kind of makes sense and then we're going to check at the end.

GregB: The verifier is going to look at these 2 values raised to powers and see does that correspond to.

GregB: That test value times the other stuff raised to that power of the challenge okay lots of math don't freak Do Not freak okay written out long form okay.

GregB: The simplest part of this thing is proving correctness meaning that if you go through this procedure and the condition is satisfied that this thing on the left equals this thing on the right then you should accept it it's an accepting conversation and that just.

GregB: Follows from doing some stuff with exponentials okay.

GregB: the other.

GregB: 2 things are proven in the textbook okay Greg what does this mean.

GregB: And how are we going to use it.

GregB: Did 1 more piece.

GregB: so we're.

GregB: Going to be able to generate a proof that we actually know those values.

GregB: Know our now we need somebody to sign it for us.

GregB: There's something known as a blind signature in cryptography is a form of digital signature in which the content of the message is disguised how are you going to disguise it yeah with that person commitment thing before it's signed the resulting blind signature can be publicly verified against the original unblinded messages.

GregB: Blind signatures are typically employed in privacy related protocols where the sir and message authors are different parties.

GregB: Examples include cryptographic election systems and digital cash schemes.

GregB: Yes maybe if they ever come but we're leading the charge here.

GregB: We have this used need and use and credentials okay.

GregB: BBS already uses all those proof techniques I was telling you about okay and a lot more complicated elaborate ones.

GregB: The proof that BBS generates from the holder that gets sent to the verifier.

GregB: The BBS signature scheme can be easily extended to support blind signature functionality okay and a blind signature setting the the prover will request signature on a list of messages without revealing those messages.

GregB: to the.

GregB: However they will be proving to the Ser that they know what's in those messages they know their secret value okay.

GregB: So we have an API for blind BBS signatures that looks just like BBS signatures okay except here's the secret key the public key header all this stuff the messages.

GregB: Okay but it allows us.

GregB: To furnish a commitment.

GregB: That Patterson commitment thing I told you about.

GregB: But we have to furnish it along with the proof.

GregB: They will check okay so let's see how this works a little bit.

GregB: So let's go to the holder.

GregB: Okay we got the issuer we got the holder.

GregB: The holder has a secret number.

GregB: To do that computation like I said and generate a commitment with proof.

GregB: In all this stuff.

GregB: 2 of those random numbers uh the scalar plus the computation of the commitment blah blah blah stuff okay.

GregB: We can validate that commitment with proof.

GregB: They don't learn the holder secret approver blind okay they don't learn the pit value but they are going to check that the prover is actually proven they know this.

GregB: So we can validate the commitment once again you change 1 number.

GregB: And things won't validate this is all cryptographically rigorous material okay.

GregB: And it's about 20 years old okay this was what shook up things it was this is as a practical version of zero knowledge proofs okay early on.

GregB: So what are we going to do.

GregB: The holder's got to generate the pit.

GregB: So the holder generated the bid.

GregB: We got the commitment used previous commitment double check it's valid.

GregB: It goes over to the issuer ah but now.

GregB: In addition to all the messages that were they're going to sign they're going to sign.

GregB: Over this thing that that came from the holder okay.

GregB: A commitment to the bid.

GregB: it's not.

GregB: Not the pit itself it's not the prover secret number and it's got a proof.

GregB: The issuer can check to make sure that the holder is not lying about knowing that number okay.

GregB: We can create this blind signature.

GregB: We get the signature bundle all this useful information okay.

GregB: So hold your generates their secret value.

GregB: They don't share the secret value with anyone.

GregB: Commitment to that secret value along with the proof that they actually know it.

GregB: Not enough to send just the commitment because they never want to reveal that stuff they send it with the proof.

GregB: Issuer is going to do a blind signature.

GregB: On that commitment thing.

GregB: All the good.

GregB: Information there verifying right my trees driver's license here.

GregB: We got to send that back I forgot to check we're almost out of time ah sorry.

GregB: We send that back.

GregB: Do the holder what's the holder do well they've got a pseudonym.

GregB: To go do proof generation.

GregB: I live in the state park uh my date of birth.

GregB: Generate the proof.

GregB: Here's my proof bundle it's got all sorts of useful stuff in it okay.

GregB: Out over to the verifier.

GregB: Gets the pseudonym here was the verifiers ID they need that they can do the calculation and verify the proof.

GregB: So using zero knowledge proofs in a very practical way.

GregB: A way that's already used and we can achieve pseudonyms.

GregB: Are on trackable by either by collusion between verifiers and verifiers issuers.

GregB: Since we learned how to do.

GregB: When somebody issues you a credential.

GregB: Got a signature in it anybody who receives that credential could potentially go and use that credential then.

GregB: It's not strongly bound to.

GregB: Okay anybody who knows the signature in BBs.

GregB: Generate these BBS proofs however.

GregB: If we want to lock down a virtual of VC okay.

GregB: Using blind signatures approver cam commit to a secret message before issuance okay so this is like smaller than the Sudan case the holder generates a secret commits to the secret blind BBS signs on the commitment plus the other messages.

GregB: Ah we generate a BBS proof with the secret we never reveal the secret but nobody besides the holder who knows that secret okay.

GregB: Generate the proof this is what we mean by Anonymous holder binding it's bound the VC is bound to the holder but it's only the holder secret that nobody else knows and it can't be correlated against them.

GregB: Okay I know that's a lot and we've run out of time summary and final words.

GregB: Completely unlined once again.

GregB: If you sit there and tell them in your selectively disclosed information your name address and your telephone number it's not on linkable anymore okay.

GregB: Able pseudonyms okay that can be tracked by the issuer if required.

GregB: Cryptographically strong but um linkable binding of VCS to anonymous.

GregB: The holder okay.

GregB: Is cryptographic techniques are well established and contained in the BBS literature okay.

GregB: All these techniques are currently used in BBS so what are we doing.

GregB: we have.

GregB: To finalize the apis because partially what was driving needed to drive the apis was what what did we want from the app requirements.

GregB: the init.

GregB: Verifier ID suited in draft didn't have the hidden case.

GregB: Oh but we can do that okay so that's where we are here.

GregB: Go to cryptography but nailing down the apis and producing test vectors and things like that.

GregB: Questions sorry to run so late.

Harrison_Tang: No great presentation amazing um.

Harrison_Tang: I know.

Harrison_Tang: Some people might want to drop off but we can take like 1 or 2 last questions.

Harrison_Tang: Anyone have questions.

<brandi_delancey> great presentation! thanks greg!!

<harrison_tang> yeah, amazing presentation!

GregB: Oh no they they they they're well aware of the anonymous Soldier binding and they thought that was.

GregB: Important and pseudonyms they did not specifically mention the 2 flavors of pseudonyms they said BBS should be used for pseudonyms but not even the the European Union digital wallet got into quite understood the subtlety of the 2 different cases where you know sometimes we do want the issuer to be able to track things for good reason you know Controlled Substances use tracking um.

GregB: So yes those cryptographers are were aware of the blind signatures and their use and this nice feature of this Anonymous holder binding which helps lock a credential down to somebody better.

Harrison_Tang: 1 more question from the audience.

<dave_longley> "holder binding" means "binding to a secret only the holder knows (and is expected to keep secret)"

<dave_longley> (for clarity -- as this terminology has been confusing sometimes)

GregB: Short answer is that EBS are signatures in its capabilities its kind of looked at as a a more modern version than CL signatures that's why the a non-red or look folks are looking at 2.0 to use BBS and that was mentioned in the uh that cryptographic review so.

GregB: Both good uh there's also something called PS signatures that don't for um um.

GregB: Select a disclosure but they offer uh unlink so there's some good stuff out there now um.

GregB: Case of pseudonyms.

GregB: There was the issuer known prover ID case that in that case the issuer should not.

GregB: Publish that proved her ID value they should keep that secret otherwise all the verifiers can correlate and know what the holder is doing that should only be shared between the issuer and the holder.

GregB: In public uh know the thing that needs to be publicly done is a verifier needs some unique public information to form the verifier ID.

GregB: That's the thing that needs to be published and that and that's why I cited used the URL like you need to my little domain that I own as that information okay and BBS has nice things to Hash a value like that into a curved point so we can make all the math work.

GregB: Can start with something.

GregB: like that.

GregB: Um and turned it into a number that we can use so yes the so we're getting a perverse pseudonym or perverse ID and it's composed of 2 pieces a hidden piece from the that the holder knows and a public piece that's unique to the verifier.

<dave_longley> technically, a Web origin, a DID, any identifier/string could be turned into a Verifier ID (vid)

GregB: And as you and as you can see it'd be nice to have some protocols to go around this and procedures but that's out of scope right now so we're baking things into the VCS to be able to do all this.

GregB: For for some of that deeper stuff I recommend the cryptographic that recent cryptographers review because it is discrete log based its elliptic curve it's got the same issues as eddsa and ecdsa right.

GregB: There are there is work on post-quantum Style.

GregB: Signatures that are privacy preserving just in the same uh vein uh 1 of the authors of a privacy preserving um.

GregB: Sanders PS signatures actually has been working with a group of folks on a post-quantum lattice based uh privacy preserving signature in the same vein so people know that they want these features um now as far as Hardware support.

GregB: A lot of the stuff came from um some initial attestation Anonymous attestation work for TPMS um and so.

GregB: That was mentioned in that cryptographic review uh of the digital wallet and so.

GregB: I am not actually sure on that I do know that.

GregB: You just saw.

GregB: Best running in a web browser uh I have run it on a cheap in a web browser on a cheap.

GregB: Uh cell phone that I use for wind serving that's waterproof but low $160 cell phone and that's running in JavaScript not even C or rust so these things are definitely implementable and can run um.

GregB: Exact nature of the hardware support and TPM I don't know.

Harrison_Tang: Alright well thanks Greg we're 10 minutes over time but no no actually I do want to probably work with you to schedule a follow-up session in september or October I personally have a lot of follow up a lot of questions about this as well this is very very presentation very very.

GregB: The more the more questions the more I can hone it you know because sometimes I start these things with uh it's a tutorial to myself to remind me how this stuff works.

Harrison_Tang: Oh no I I I love it like I I think demos uh is way better than slides in regards to teaching us how how these things work so this is this is amazing thanks Greg thanks a lot.

GregB: Okay thanks a bunch guys.

Harrison_Tang: All right so I think this concludes uh this week's uh ccg meeting I'll work with Greg uh to figure out uh how do we schedule a follow-up session so if people have any more questions in regards to these interesting topics we can continue the conversation.

Harrison_Tang: Thanks a lot.

The W3C Credentials Community Group

Meeting Transcriptions and Audio Recordings (2014-today)

Go Back

W3C CCG Weekly Teleconference

Transcript for 2024-06-25