 Yeah. Good morning. Good afternoon. Good evening to you all from here in the UK. And we've got my colleagues coming in from the US as well shortly. Welcome to another webinar. My name is Andy Tobin. I look after our business here in Europe. As you probably know, there's a lot of regular faces on here but these webinars are focused on self sovereign identity and digital credentials and we run these webinars regularly to help you learn faster and build more efficiently. On our last webinar we had a stellar panel with us who talked about health credentials, which is a topic that's all over the news at the moment. And just prior to that as well we had Alan Murray Hayden from iR to talking about the iR to travel pass initiative, which I think goes down as the most well attended webinar we've done so far, which is obvious why really isn't it. And it's fair to say that digital credentials are attracting mainstream interest around the world at the moment, catalyzed by the Covid crisis. And rightly the issue of privacy and confidentiality comes to the fore. So if you just joined you can see the trailer there on April the 14th. We have our next webinar, which is one not to be missed. It's with a special guest doctor and Kavuki and who's the creator of the whole concept of privacy by design. And she's coming to speak to you April 14. So make sure you book that one bookmark that one in your diary. And so in this webinar we're diving deep into the details. Many of the previous webinars we've had if you've been on them, you'll know we have many, many more questions than we can ever handle. And being lots of questions about the underlying technology we've not had really the time to do injustice. And we've had lots of requests to go deeper. So, so you asked for it and you're going to get it. Here it is. Today we're talking about bbs plus. What is it and what does it mean for their final credentials. I'm joined today by cryptographic royalty if you can drop to the next slide. Thanks Alex. My own experience in cryptography stopped at triple days. Brent is in a different league altogether. Brent wrote blog posts recently on everything.com slash blogs, slash blog, describing why the verifiable credential community should converge on bbs plus. It's a well worth a read and it really the interest in that catalyze the need to put this webinar on. So Brent, could you just do a quick intro, please for our audience. Yeah, hi folks, my name is Brent Zundell. I've been working at Everton for nearly four years now and been knee deep in crypto and verifiable credentials and anonymous things and privacy and standards and all sorts of stuff that time so it's been. I'm going to have a lot of fun today. Thanks Brent and you'll run your co chair and the W3C the worldwide web consortium working group as well. Yeah, so chair, one of the chairs of the did working group, one of the chairs of the VC working group. And yeah, worked on some stuff that decentralized at any foundation doing a lot of standard stuff. Thanks Brent and Brent as you'll have detected is very understated and modest. I'm also delighted to be joined by German again as well the architect of decentralized identifies himself. German, do you want to do a quick intro for us as well please. Thank you to Andy. It's ironic in that I, I am not a cryptographer I'm not a cryptographic engineer, I call myself a connoisseur of cryptography and cryptographers, and that's why I'm going to be the one launching all the hard pieces of Brent today to pull out the key points of his blog post and his knowledge which is, you have to do that with Brent because otherwise he's just heads down, you know, producing it producing the code producing the papers producing the standards. And this is an opportunity for us to sort of pull out his knowledge and share it with folks and I'm really excited about that. Thank you very much. So, on the agenda today, really pretty simple agenda actually, we're just going to give you a quick primer into three really simple concepts that are really important to understand we attend a lot of webinars other people give them. We read things that you know blog posts and opinion pieces and all that kind of thing, and it's often the case where where people don't get some of this stuff right so what we want to do is just make sure we all are up to speed on three basic concepts because we're going to be referring back to them a lot in this session so we'll be doing that, and then Brent and is going to be quizzed intently by drum and, and then we're going to open up to audience q amp a. So that's the agenda simple as that really. If you've got any questions, please put them in the zoom q amp a. Okay, there's a zoom chat, but the questions we normally like statement in the zoom q amp a if you can do that please. I'm Alex in the background our webinar wizard. I will pull those together and we'll go through as many of them as we can do after the session with with drum and brain so you if you can ask you question in the zoom q amp a that'd be great. The webinar has been recorded as well, we do publish the recording afterwards, it will be available on our website evanim.com slash webinars. So look out for that and you find all the previous ones there as well. So, without further ado, let's let's crack on a quick primer few on verifiable credentials and privacy on three specific areas. Privacy disclosure compound proofs and zero knowledge proof signatures. So let's crack into those this is a really significant capability that these three components I just described that underpin a lot of the principles around privacy that are built into the way that we've implemented verifiable credentials. So the first one we want to talk about is what's called selective disclosure. What do you mean by that. Well, it's a, it's a superpower that you get with digital credentials that you don't get with paper ones. Selective disclosure simply means you can take selected elements from a credential so selective attributes and only reveal those without revealing the other data in the credential. So in this example with a driving license, you might have already be gone there maybe 15 attributes, but in order to do a particular transaction you only need to reveal two of them. So that's what we call selective disclosure. And in order to do this, you need to have a lot of the stuff that Drummond and Brent are going to be talking about in a minute. You can't really do this with paper credentials or a passport you show it to somebody and they can see everything if it's a driving license they seeing your address when all you want to do is you know it's the only example of getting into a bar. Selective disclosure is all about the ability to pull out individual attributes from a larger credentials so you're only revealing what is important for the particular transaction you want to do. The second concept is compound proofs. So a compound proof is where you're taking attributes from multiple credentials and bringing them together into a single proof. Okay. So in this example here you've got some information from the driving license and you've got some information from the concert ticket to different credentials. You're taking elements of information from each using selective disclosure, but you're compounding you're bringing these attributes from different credentials from completely different credential issues together to create what we call a compound proof. You can do this without ever having to go back to the issue right you can do it on the fly. When the when you're asked to prove something, your app will compute all of this for you automatically and provide a compound proof without revealing all of the other data on those credentials. So really, really powerful that's what a compound proof is so selective disclosure compound proofs vitally important and also demonstrates the flexibility of verifiable credentials done right. You're only sharing the minimal information you need to share, but you can combine different sources of information which is often what happens like if you're onboarding to a bank you've got two proofs of address from different utility companies and the proof of citizenship and so on. That's naturally what we all do so compound proofs allows you to do that. And the third piece is getting deeper into the tech correlating signatures. Okay. When you prove something to a verifier. If you share the issuers signature. Then you're providing them all with a perfect correlator that allows everything you do to be correlated across those different verifiers you're sharing information with. If they assigns a credential, if they sign it with their signature that signature they signed it with is unique to that that credential pertaining to you. So if you have to share that signature in order for the verifiers to check that credential is authentic, you're sharing like a unique global super cookie, and all of those third parties that you're sharing with they could collude behind your back. It's like a super version of a Google ad identifier. Right, so correlating signatures you don't want to have the way you want to do it is instead of sharing the issuers signature and go to the next slide please Alex. So instead of sharing the issuers signature, what you do is you share a zero knowledge proof that you have the issuers signature without sharing the signature itself. So every verifier that you're sharing information with when you're providing a proof, you're not sharing the issuers signature. Now to do that is as we'll find out in a minute drum will ask, ask brain how this works. It's very important. The last thing we want to do with this whole new world of verifiable credentials is create some new global tracking economy. So the ability to share information that can be verified as authentic without sharing the issuers signature stops you being correlated and it also means the verifiers don't have to contact the issuer to verify anything and therefore the issuer is blinded to to what you're actually doing and who you're sharing your information with which is how it should be. So those three concepts of selective disclosure compound proofs and non correlating zero knowledge proof signatures are vital to getting digital credentials done right. And with that, I'm going to hand over to Drummond and Brent because I think you want to dig into this with Brent a bit more on this particular bit about signatures right. Absolutely Andy that's that I first of all you do a great, great job of describing why, why it's important. And Brent in his blog post goes into sort of the origin the story so I'd like to start with my questions to Brent about that. And Brent would you back up and give us a little history what was zero knowledge proof crypto always part of the picture for W3C verifiable credentials or how did it come into the picture. So those those who've read the blog post know that my, my beginnings with the verifiable credential community were rather abrupt so I was, you know thrust into the group. Not sure what standards were or how, how the process worked or any of that I just knew that in order for us to be able to use the resulting standard that that the group was building we needed to have a zero knowledge story. I found ready support from the chairs of the group, they had wanted a good privacy story for verifiable credentials and had heard of zero knowledge proofs. So I got a lot of encouragement from them. Shout out to Manu Sporni the edit one of the primary editors of the verifiable credentials back. I would write a PR and money would come back and go. Now if you want this PR to actually get into the spec I suggest you word it this way. Without that help, zero knowledge proof capabilities wouldn't be represented in the verifiable credential spec today. To briefly answer your question. Not really. There was some hopes for something like what they could provide. Right. So, so this is why, or one reason that the addition that you spearheaded and then others supported of adding zero knowledge proof credentials but is this why there are several what people call flavors of verifiable credentials in the W3C spec. Yeah, there. This is one of the flavors, the, the chairs of the group were really hoping to get some, some diversity of possible implementations. And so I recommend everybody to read a report from Calia about the different flavors of credentials if you haven't read that yet it's a really really good primer on on what we're talking about right now. There was this in the group there was this, this kind of dichotomy between this higher highly interoperable LD signatures on one side using Jason LD, which is really powerful provides good semantic meaning for for what the credential attributes actually what they mean. And on the other side, we had our commendation listening skill, zero knowledge proof capable signatures. You know, very capable and reducing this unwanted correlation that Andy was talking about, not only signature correlation but correlation of the holder, you know, the ZKP credentials don't require that the given an identifier that's shared. We just want to put the ability to basically the ability to correlate myself as a holder should be in my hands rather than as a side effect of the protocol and the credential form that we use. There was no real way for these two sides to come together at the time so we needed, you know, at least a couple different flavors and the JWT credentials, you know, we're in the mix as well. And briefly the JWT credentials can you describe that third flavor briefly. There was there was a the Jason LD camp, and they had done most of the foundational work to verify the credentials. We came in, along with a couple of other parties to do the zero knowledge proof stuff. There was a Jason only crowd that really wanted to take advantage of some existing formats. And so the JWT credential format was a way to try to bridge that, you know, between verifiable credentials and the existing JWT methodology and format. Okay, so so basically as clearly as report describes there have been these three major flavors, JWT and Jason LD and then the ZKP format. So let's let's now zero in on that ZKP format. I think you've hit most of what are the reasons that ever name originally proposed that and that that's been what we have focused our implementation on and the hyper ledger. Indian Aries stack explicitly supports what are the main reasons for for for what I think it's been called anonymous credentials. The original goal of anonymous credentials and of, and of all of the tech that ever known has has built and tried to promote. We want power to be in the hands of the people who own the data. You know it's if the data is about me I should be able to control who sees it how much they see and when. And so we, we looked for credential signatures that had the capabilities, you know that Andy mentioned selective disclosure is is vitally important if I have a credential. And that the verifier really only needs to attributes on that credential, then I shouldn't have to share all 25 and the verifier most verifiers that we work with. They don't want to see those extra 23 anyway that's, they're recognizing more and more that this additional data doesn't really benefit them. Additionally, signature blinding is really important. You pointed out it's a, you know, revealing the signature is a perfectly correlating identifier any verifier that sees that can say oh yep this is the signature hey did you get the same yeah I got what information did you get well let's share let's let's build up a better profile let's collaborate. It also prevents one of my favorite aspects of anonymous credentials, it was, they were originally designed to allow people to anonymously log into systems. The issuer and the verifier in the original concept was the same entity, and they wanted to prevent the issuer from even being able to know exactly which individual was using the potential. The only knowledge that was passed back was, is this individual authorized to be here yes or no. Okay yes they're authorized to be here good and we don't have to know, you know, precisely who they are and all of that we can, we can let them in. And we've been able to expand on that. They also provide link secrets for holder binding, this is a really important concept because it many of the LD signatures and even the JWT credentials they rely on a decentralized identifier for the holder. Now decentralized identifiers are fantastic, but as a holder I don't want the same decentralized identifier to be presented to a bunch of different verifiers I don't want to provide another correlating factor. I want the power to correlate myself as much as I need to and no more. The other thing that CL signatures had that we really, really like is the ability to do predicate proofs. So rather than if I have a credential from my bank of my, you know, my current bank account status. I can share a proof that says, oh yeah my account balance is higher than this amount. I'm not going to tell you what the amount is, but, but I can prove that it's that it has that relationship. And predicate proofs felt really central to the capabilities that we wanted. So with, as you said, the commendation was sent to you a signature format with anonymous credentials we got all four of those things that you mentioned, and that's fantastic now. I'll point out, Ruben Heck from the decentralized identity foundation has pointed out. Privacy preserving credentials are not needed all the time right there certainly times where you're showing credential to you know an organization or or a thing of some kind and you don't need these privacy preserving credentials. They're the same properties that apply to people and totally acknowledge that. So, so we are talking about the set of use cases that affect when a person is issued a credential, especially something that might have sensitive personal data like health data that we're talking about with digital health passes. So, a Brent of the, the four things you mentioned we'll talk more about predicates later but link secrets there. It's, it's always been at the heart of how anonymous credentials work. And yet, there are a lot of misconceptions about link secrets so Brent what exactly is a link secret and what is the problem that it solves. So, a link secret is just, it's a secret. So, let's bring it back to DIDs. If I'm the holder of a DID, how do I prove that it's mine, how do I prove that I control it. Well, I have a private key and I can sign something with that private key and it can be verified. So, the security that DIDs are based on is based on the holder knowing some secret, and I can demonstrate that I know that secret, based on the architecture of the decentralized identity. Link secrets is exactly the same thing, but I don't have to share an identity. I don't have to share anything that correlates me I can still prove I know the secret, but I can do it in a way that doesn't allow that. If I prove to two different verifiers, I can do it in two different ways so that those verifiers can't get together and, and know that they've talked to the same person. So what you're saying is what Andy was talking about was not to the ability to avoid correlation on the issuer signature, which the course, the verifier has to be able to verify that the issuer actually issued the credential. But what you're saying is that link secrets allow you to avoid correlation on the holder signature to prove they have the credentials that right. Right. Right, just as on the issuer side, you know, yeah, the verifier needs to know who the issuer is, but an issuer signing credentials every single credential signature, especially with LD signature it's going to be a unique value. And the verifier just takes that value does a little bit of math and goes yes okay this this this works with ours, we can reveal a different signature every time. The verifier still does a little bit of math and goes yep it works out it checks out they can still verify that the, you know credential hasn't been tampered with and they can still verify that the, it definitely came from that issuer. It's similar with the link secrets that it's a way to do it that doesn't provide the correlation. Right. So, so it seems that since what we need to avoid is to avoid this correlation we need to avoid issuer signature correlation and holder signature signature correlation. Is this is the ultimate conclusion here that to avoid both of those things and void either one being a tracking beacon in your credential, the only option for privacy preserving credentials is to use a ZKP and link secrets. Yeah, I think a lot of people are concerned about zero knowledge proofs. What zero knowledge proof really means, it doesn't mean I'm not showing anything. It means no information is shared beyond what I want to share the verifier gets zero knowledge about anything other than what I'm proving. So they don't get the signature value they don't get an identifier for me as a holder they zero knowledge proofs they feel like this really complicated concept but really what it boils down to is. I share what I want to and nothing else gets leaked. That's the goal of zero. Right. Now that's, that's a very important point because one of the other myths I hear quite a bit about the use of zero knowledge proof credentials is, oh you get to choose, you know what the verifier sees. And the second corresponding thing is, is, you can't actually show the verifier, the data when they need the data, and I'd like you to briefly talk about both of those zero knowledge proofs lets you control or selectively disclose information, but if a verifier needs to know the data with the zero knowledge proof format can they still get the data. Oh yeah they get the data and they get the same assurances about the data that it hasn't been tampered with and that it was signed by the issuer. They get the same assurances that they get with with, you know, straight digital signature schemes, but without some of the baggage. So basically they support a super set of what you can do with with non-ZKP credentials in terms of what a verifier can get, correct? Right. Gotcha. Alright, so, so, so I think we've established why, you know, Evernim and other supporters of DKB credentials made sure they were there and why we've implemented that way and why we chose anonymous credentials, which is, Brent, that's based on crypto that originally started where IBM Zurich Research Labs, how far back does that go? Oh, it's been around for a long time. It came out of IBM Research. Komenish and Lysiansky created this signature scheme, it's been used in direct anonymous attestation and EPID, it's been used a lot of different places. It's got a lot of good things and it's got some drawbacks though. So it's, it's pretty mature technology, which leads me to my next question and the subject of this webinar. If so, if we've already, you know, if it's, if it's specified, if it's been implemented and Evernim customers have these ZKB CL based credentials in production, why now this interest in a new ZKP format? Well, if you want to make a cryptographer wince, start talking about RSA. RSA is is a really widespread, famous algorithm for for signing and for encryption. And over the years, it has been attacked a lot. And in order to maintain security levels within RSA, the keys have gotten bigger and bigger and bigger over time. So, CL signatures are based on RSA, which has served us well. It's, you know, there's got some mathematical properties that we're able to take advantage of to do predicate proofs. But the keys are really big and the credential proofs are really big. And RSA in general is, is widely recognized as something that if you can avoid using you should probably avoid using it. Okay, so tell us a story again that the blog post says the details but at summary form. So how did BBS plus arrive on the scene. Well, from the beginning, we wanted something that was better than CL signatures. But we wanted it to have the same capabilities. So we've, we implemented a pairings based signature from the start we use one with our revocation scheme in Indy. It's a that's a pairings based signature scheme. We, we were working on rich schemas or schema 2.0 we were working on anonymous credentials 2.0, trying to figure out a way to bring our technology into better conformance with the W3 spec W3C spec and better interoperability with with LD signature stuff. So we, we went searching for a good pairing space signature. At the time BBS plus it was the clear choice. It was better than the one we had already implemented. We had pretty close interactions with Jan Komenich at the time and other cryptographers, and they said yeah yeah we don't use that one either we're using BBS plus. So we, we decided to implement it, we being every name and the sovereign foundation and members of the community. You know every man was primarily in a support role for that one, but BBS plus the signature scheme was implemented in hyper ledger Ursa. And we planned to adopt it we just said okay BBS plus is there. Now we need to figure out how do we do predicates with it. We do better revocation with it. And okay there's this whole rich schema side that touches on interoperability how are we going to do all of these things. As folks who've read the blog. No, this didn't quite go the way I'd hoped, you know anytime you spend a year of your life on a project you want it to go somewhere. The schema was just too complicated. It was, it was hard for people to get their brains around and it was hard to convince people that all the pieces were necessary, even though they really felt necessary. And even a non creds to Dotto was trying to, it was trying to do too much. So what, what was the breakthrough then the breakthrough came from somebody else loving the open source community that we have at IW matter global. And if we take BBS plus signatures and do things in this way we can use BBS plus LD proofs, which is an LD signature. And so they, they tweaked BBS plus to make it more compatible with LD signatures, which was the original goals of rich schemas and non creds to Dotto anyway. So like I said they're compatible to LD signatures, they support selective disclosure, they do signature blinding, they include an option to do link secrets. There's also this ability to do, you know, linking of any two attribute values from different credentials which is, which is pretty fantastic, which means even beyond the link secret if I have a passport and a health credential. I don't approve that the same first and last name are included in both credentials, but I don't have to share my first and last name with you. It's pretty powerful capability. One thing they didn't give us was predicates. And so we had to, we forced us to do some, you know, introspection and kind of let go of predicates for now. And your blog post talks about the soul searching that that resulted in so so with BBS plus the BBS plus flavor now a verifiable crunch is what are we getting and what are we giving up. Can we sum it up here. Well, we're, we're getting. We're giving up predicates. We're getting compatibility with LD signatures, we're getting smaller, faster signatures. We're getting all of the goodness of the original anonymous credentials minus predicate proofs for now. I think that it's going to be possible to introduce predicate proofs as a capability that's compatible with BBS plus, but we're not going to have that out of the gate. So that's why we have the asterisk on this chart on predicate proofs. So we basically are giving them up at the outset, but you believe that you and the other, you know, cryptographers in the in the Ursa community are going to be able to add that support. I'm confident that we will. We'll probably focus on revocation first. So revocation as it's implemented in hyper ledger indie is is pretty tied up with the way that CL signatures are implemented and porting that same revocation scheme over to BBS plus doesn't really make sense. When there are more efficient and better ways to do revocation that would be a little bit more compatible with BBS plus. I think we're going to try to figure out probably is revocation but yeah predicates is on the roadmap. It's something that I'm not willing to give up on you. Yeah, I know that sounds important. It sounds like the advantages of BBS plus with revocation actually would be another entry on this table that it's going to help us have a faster, more efficient revocation mechanism as well. Is that right. Right. Okay, alright so so I think it's, you know, hopefully this makes it clear again you want to go deeper in the details Brent's blog post does that. So let's let's turn to sort of the practical implications and and folks are already asking questions here in the chat. What, what, what remains to be done Brent to put BBS plus credentials into full production. So BBS plus LD proofs spec is is very much in draft mode right now. It's a pretty complete draft, but it's, it's being worked on at the credential community group. It's not going to be a W3C recommendation at this stage. It needs to be finished. I think it's close, but the work there still needs to be done. It's done enough that folks have implemented against it and shown that they can be interoperable with it, which means it's, it's really close, but it's not quite there yet. Another aspect because, because BBS plus LD proofs enable BBS plus privacy preserving safe credentials to be used alongside other LD signature credentials. We need to look at the ramifications of that. You know it doesn't make sense to use this privacy preserving safe credential alongside a credential that's perfectly revealing. At least we need to make people aware that that's happening at the very least. So those are, those are two of the things that I think we really need to hammer out before we can use them and, like I said we also want to figure out revocation and predicate proofs those are, those are big musts from, from my perspective. And again I know your blog post goes into more detail about about sort of the roadmap from here to to full production. So, what I see we, I have it on my question list it's already being asked by our audience. What differences will end users see in the move from a ZK PCL to BBS plus. Holders, I'm hoping they shouldn't notice much of anything. They're, they're getting a credential. They've gotten credentials before we intend them to be able to use all of their credentials moving forward. Holders shouldn't notice much of anything verifiers, hopefully will notice that things are a bit smaller that they can do things more quickly that they have access to this greater semantic meaning. You know right now when you share a CL signature anonymous credential, the verifier essentially kind of has to know what the issuer was thinking. So it requires some, some assumptions to know what the meaning of the different attributes is. The LD signatures aspect of BBS plus LD proofs allows verifiers and issuers to, to share that semantic meaning via the credential and via the schemas that are used for the credential issuers are going to have a little bit less setup before they are able to issue credentials. But for the most part, we're, we're hoping that by adding support for BBS plus as an additional format supported by you know ever names verity platform. There, it'll allow issuers and verifiers to transition pretty seamlessly without giving up on the existing signatures I don't I don't anticipate. You know, every CL signature based credential is going to have to be reissued I don't I don't think that'll. We're not anticipating that we're not planning for that we're we're planning for them to be able to be used with the new format with the new scheme. So we'll be adding support for BBS plus credentials but not taking away support for and then so that means issuers can pretty much seamlessly just just transition across and their holders. You shouldn't notice anything and provided verifiers have the software to verify that format. They too should have a pretty seamless transition. Is that right. That's the plan. Okay, so last question before we jump into the audience questions. So what if others in the audience are agreeing yeah it sounds like BBS plus pretty good idea. How do they get on the bandwagon what do they do to get started. Well, check out check out the blog post if you haven't already. You'll find the the BBS plus LD proof spec. It's in GitHub. I'm sure we can, we can share the link to that. Give it a read, give some feedback raise some issues help that get to completion. If you have funding for some cryptography work send somebody to Ursa to hammer at the BBS plus implementation there. But it's a pretty darn good implementation it's very faithful to the specification but the more eyes that you can have on a cryptographic key component the better we want to know. We want to know it's flaws we want to know where it's going to break. And look at in your own organizations what it would take to. To move to BBS plus and support it yourselves, you know so that in addition to ever in a matter and a bunch of other folks that you know we can all interoperate not just with a data model but with a signature scheme. Yep, that sounds great. So Andy, I think it's time I know the questions are stacking up hot and heavy as they always do so let's turn it back over to you to start curing the questions. Can I just say guys, I really enjoyed that I thought that was epic. Really good so thank you very much indeed. I just like to come back quickly on that question about what difference will end users see. And I think there is there is quite an important difference lurking in there which is, at the moment if you use some evidence connect me app, for example, there's no control over the order of the attributes that are listed. Right. And you're seeing the attribute names, which could be quite obscure. And, you know, the verify doesn't have a date is meant to be year month day or day month year and that kind of thing. So you are getting kind of service decorators with this new approach, right that allows you to control that kind of presentation layer with that, would that be right. So, so getting a little technical right now the, the list of attributes for an anonymous credential is a JSON array, which means it's just, it's a list of strings that's all it is. So getting bbs plus LD proofs will be able to take full advantage of any JSON LD schema schema.org has has hundreds of them. As long as it can be described in JSON we can use issue a credential based on it. Now, it's, it's pretty fantastic and on top of that, like you said we can layer attribute ordering information and things like that. And I think, you know, we've had feedback from, you know, live projects like with the National Health Service in the UK, for example, you know, they want to see the name. And then maybe then employee ID at the top of the credential not some strange base 64 hex kind of thing so being able to put a nicer user interface on it, I think is a huge leap forward from just a flat, structure where the actual attribute names are revealed so I think at the technical level there may not be much impact for users but that presentation level I think it's going to make things much more user friendly for people. I think it's going to enable a similar transition those of us who are old enough to remember the move from web 1.0 to web 2.0. You know, it's going to be a similar paradigm shift, in my opinion. And ledger questions coming so keep them coming folks will will cover as many of them as we can do, including the really awkward ones that we can hammer the guys with here so I'm okay let's do this one from hack and hey hack and thank you for this. Why is it an important feature that the issuer signature is non correlated. I mean there did a publicly available on a ledger. Right. You have to know who the issuer is that's that's that's a given. Every time an issuer signs a credential, the credential that's issued has a different signature. Every time DID the signature value is going to be different for every single credentials which means not only is the verify are going to know who the issuer is but they're going to know it's this specific credential that was issued. And every time I share that credential if I don't have a way of blinding that signature, it's going to, it's going to correlate across every verifier and even back to the issuer. And now with anonymous credentials and moving forward with bbs plus, even the issuer doesn't know what the final signature looks like. Right. And the, once the issuer has a public did on the ledger. What they're signing the credentials with is a is a different thing completely really isn't it. So that you know what's on their digs you got the credential definition with signatures with verification keys in it as well. And you got the peer did with that individual person as well plus the link secret right. Right so bbs plus LD proofs does that a little bit differently they be bbs plus signatures gives us the capability of dynamically generating in a hierarchically deterministic fashion, the set of keys that are used for verification. So we need to store a big old cred def on a ledger somewhere for people to refer to the issue right today. Here's, here's the seed that you should use to derive the public keys that you can use to verify it. So it's, it's, you know, much smaller kind of infrastructure requirements. Right interesting. Okay, let's, let's crack on with another one here. This is a bit like related to link secrets actually but what kind of options are available to make sure that attributes in a compound proof are talking about the same person. This is just the same holder, for example proof of age from a driving license and proof of education from a college certificate. The link secret is is one, you know, binding mechanism. Another one that we mentioned was, you can prove that any two attributes are the same without revealing them. So if, if the credential, you know, you can issue a credential using bbs plus to a customer identifier or to a passport number or to a social security number. And if that number is duplicated in multiple credentials, I can prove that. I don't have to share it, but I can prove it. And so in that way you can also do linking between credentials. And Brent, can that also extend to proof of matched biometric. I think it couldn't, but I'm not an expert in biometrics and matching and I know that there's some, there's some fuzziness there. And so I'm not sure exactly how the fuzziness would play with with the math. And you could, you could put the holder's photo in both credentials. Right, and then verify I can match both of those if I asked for them. If you have a, if it's, if it's an identical photo, yeah. So two different photos of the same person would require some processing and we haven't sorted out exactly how to do that, obviously, but yeah. Yeah. It's actually worth pointing out the IARTA travel pass program does use selective disclosure and it uses your knowledge proof signatures, and it uses compound proofs as well so this isn't kind of pie in the sky stuff is is live at the moment. Here's a question from Robert Celeste. What is privacy respecting revocation. I love this topic. Um, so, so the simple way to do revocation is for an issuer to go here are the identifiers of all the credentials that I've issued that I have revoked. As a holder, I would have to take that unique number, share it with the verifier and the verifier goes and looks at this revocation list and goes okay good you're not on the list. A privacy respecting revocation scheme means I can prove I'm not on the list but I don't have to show you the number. Right. So, what we what we're trying to protect against you is the verify having to contact the issuer or being able to correlate right. Both. Yeah, we, we want to reduce as much as possible, any need for the verifier to contact the issuer. And we want to, we want to not have a protocol or a scheme that requires correlation. Yeah, yeah. And I actually just see this Andreas in in the chat to avoid track and trace yeah absolutely right. So if the issuer can see everything you're doing, then it's not very private. So, so you need to be able to have the issuer revoke a credential without the verifier having to speak to the issuer, because also the issuer may may disappear as well that's another thing isn't it, maybe drum and on this one if the, if the issuer is destroyed in a war or goes bankrupt or something. You might still have a credential which might be your university degree it doesn't make your credential invalid because the issue is not there. You need to verify that credential, even if the issue doesn't exist so you don't have to contact the issuer, any point drum and D really. Well, yeah, there's, you hit the two key points Andy there's the privacy issue of what's broadly called the phone home problem, right. Yeah, and and I have heard, you know, for for issuers that are that are for formats that require issuing to a public DID the assumption is you're issuing to public DID. And then the it's brought up well that's the, you know, now you're going to have the correlation of that DID everywhere it's used. The answer has been, Oh, well, we can, we can issue a new version of the credential each time you need to use it. You've converted the problem now you're phoning home every time you're issuing the credential so I neither one of those I think is adequate. But you also bring up the second point of when there is a fully verifiable signature that doesn't depend on having to go back to the issuer, you've got a lifetime credential right you're not limiting it to to the the issuer still being around. So that's what you have with your birth certificate right you have a printed birth certificate, as long as you don't lose it right you carry it with you, and you can always verify you would show in, albeit it could be photocopied etc. But you know, we all have these things and we carry them with us and even if the whoever it was issued the birth certificate is destroyed in a war or disappears, you still have the physical things this is a digital equivalent of that. So here's, here's a good one from a non who is retaining their privacy. What are compound, sorry, where, where are compound or aggregate proofs composed within the wallet. Brent, where, where are these compound proofs created. They would be created by the holder in response to a proof request or a presentation request from a bear. So Verifier composes a set of basically a set of acceptable credentials, or, or attributes they want to see from specific credentials and they say okay this issuer this type of credential would be acceptable show me these five attributes, plus from this other issuer these attributes, if you show me all of those things that I have what I need. So that's that, and interacting with their wallet composes a compound proof based on the credentials they actually hold. And that's all done bang in real time, right. Yeah, as with bbs plus it's it's quicker the seal signatures isn't bad for the actual proof generation. It's the keys and the sizes of things that get out of hand there. But yeah, it's quick enough that it can happen in real time. And with connect me that supports compound proofs already and the evidence mobile app that it does create a compound proof, you know, in under a second and send it off. I think the more attributes you get for the more credentials, it takes longer to do all the calculations right so generally asking for fewer, fewer attributes you asked for the quickest, the quicker it's going to be. This is one from swap now, I've got that name right. Is it possible to choose the type of signature one can use to sign a credential or sign the proof. That's a nice one. As yeah as an issuer you need to. There are some preset up things that you need to do with anonymous credentials you need to generate a credential definition which is a whole bunch of randomly selected prime numbers with bbs plus you need to choose the, you know, the initial value for those hierarchically deterministic key generation there so that there is a bit of setup and so the issuer does need to choose in advance what signature they're going to use before they issue a credential. The holder gets kind of gets what they get. They don't have a lot of option there you know once they get a bbs plus LD proof credential they're not going to be able to. You know, get a different one then I mean without the issuers explicitly supporting that. Yeah. Cool, thank you. I have lots of stuff being answered on the fly in the chat as well so thanks for those folks who are doing that. Just trying to keep up here. So, I'm normally we go a bit after the hour by the way so we've got five more minutes till the German Brent you're okay to just do another 10 minutes after that so. Yeah. Yeah, it sounds good. Here's one from Timmo Glastra hi Timo. What's the role of Indie going to be with bbs plus support for evidence bbs plus signatures are broader than the Indie ecosystem so I'm curious what the role of Indie is going to be when we have Jason LD bbs plus credentials. Is Indie just going to be doing revocation and deeds. That's that one. I'll take a stab at it. The, the primary function of Indie as I see it is to support a distributed ledger that has some, you know, some good oversight. It's, it's, but it's all ledger stuff. So bbs plus removes some of this reliance on the ledger our initial round of bbs plus signatures, we're not going to have a revocation story built in we don't have predicates and the signatures don't require a credential definition on the ledger. And so beyond the issue we're being known by a d ID, there isn't much that the ledger needs to be involved with for bbs plus. So what I anticipate is there will probably be an indie height that says this generic bbs plus LD proofs you can sign anything with that. So where will we going to use them safely in a way that's compatible with, you know, the, the priorities and, and things that Indie, the Indie community cares about. So I think there will be a height that defines some of those things and I, in addition, I expect there will be an Aries RFC that says here's how the Aries community wants to use these, even independently of Indie. So I expect all of those things to really just be here are the specific ways that we are going to be as a community compatible not only with each other but with the the broader uses of bbs plus LD proofs. Yeah, so, so the, in fact, drum and I don't know if you can chip in here on the reducing the dependence on or opening up to allow for multiple ledger support as I guess, because we're seeing ledgers popping up for all sorts of things at the moment aren't we, and people shouldn't have to worry about that. Exactly. I think that's the point and is we've, we've, there has been in the evolution of, you know, verifiable criminal space, a pretty close. It called dependency of wallet and agent implementations on specific ledgers and formats and so I believe and I want Brent to, to validate this that moving to a format like bbs plus and knowing, you know, what we've learned so far is this is going to take us in a step of greater ledger independence, the bbs plus credential format. I believe that it will. Right now, anonymous credentials depend pretty strongly on Indie because Indie has the, you know, this, the transaction types that can be stored there are credential definitions and the revocation registries. And then forward bbs plus requires, requires less reliance on a ledger and the things that it does require of a ledger can be done a little bit more generically. So it's something that's that's much easier for multiple ledgers to support in the same way that, you know, the existing nonprofits, we probably couldn't do. And that, would you say that would apply to non Indie ledgers as well, you know, Ethereum or ion or, or, you know, new ledgers that are new did methods that are current we're now, as you know as co chair of the DID working group I think we're going to pass 90 registered did methods we have past 90. Okay. Wow. As that spec has gone to candidate recommendation folks are like hey I want to get in the door before it gets final night you'll still be able to register after that but folks want to be sort of part of the original party. So, so Brent, do you think bbs plus credentials will, they'll be a wider set of did methods that can support them. Yeah, I see no reason why they couldn't be supported by any, any just in good. Hmm. Very interesting. Oh, Kerry to says Paul, Graham, April. I'm just going to jump in there. Is that another webinar. That's another webinar. I want to say I'm going to be Sam, I'm going to channel Sam Smith here and say, of course, any key format you want to use Kerry can also support Kerry is not a. It's not a specific cryptographic algorithm or signature algorithm is a whole architecture for but that's that is another webinar. Actually, maybe Alex can you put on the list. Let's have a Kerry webinar. Kerry by the way the acronym drum and means. It means a key event. What's the R I key event. Key event resource infrastructure I think it's in a case it's a whole, it's a whole architecture for for self self certifying self certifying identifiers and the corresponding key management, which makes it the most decentralized of to my knowledge of all of that. I'll put in a blog that plug that the book on self sovereign identity that I'm a co author of last two years work is going to come out in April and and Sam Smith has written an entire chapter on Kerry in there. So, lots more to come on that. Yeah, and yeah, anti anti cartoon and in Finland to the rescue there. Key events receipt infrastructure. I'm sorry to bring on the spot there drama I don't know when you do that. I remember that but yeah, I was going for rotation but anyway anyone else who wants to invent some more acronyms, please feel free and chuck them away. And we'll just do another couple of questions before we close off. There are two actually on link secrets. Once from Oliver Hi Oliver, another one is anonymous but what happens to link secrets and bbs plus signatures is a link secrets are mysterious enough that they get more mysterious. What's happening right. Well the, the way that bbs plus LD proofs describes holder binding. They don't see serving way. They don't use the words link secret. They talk about BLS public keys and private keys. The, there's a key feature about BLS keys is that once I have my private key I can reveal any number of different public keys for that private key, which is what a link secret is and does so. It's an identical mechanism cryptographically, and mathematically it's, it's got a little bit different terminology around it, which actually helps us when we're trying to explain these things to, you know, to folks who know what bbs plus LD proofs does is it, it describes holder binding that is either privacy respecting or not. And so, you know, one of the aspects, in my opinion that we need to, you know, take make sure of as we move indie into a position to use bbs plus is to, you know, state rather emphatically that we're going to use the privacy preserving mechanism rather than the, the non. So the same function is being achieved though, right, right with them, or possibly in a different way. Okay, let's do, maybe one last one. Okay, so timeline so Timo Glastra is saying what's the expected timeline for bbs plus support in ever in products. Well, first of all, I just want to say that evidence products were all in on bbs plus and adjusting world maps and all that kind of thing as you might expect but I think the, the, there's probably a question before that which is what's the timeline for bbs plus and this kind of standardization stuff you described. I mean, it feels like it could be, you know, quite a, quite a complex thing to get to the point where we've, we've got some standardization interoperability here but is it, is it that or is it actually happening much quicker than that. It's, it's happening pretty quickly. So from evidence perspective, I am not a product guy and every time I invent timelines for things people wince and cringe, because I'm terrible at it. I know that we want this, we want these capabilities as soon as we can get them and as soon as we can figure out how to do it safely. And definitely this year where we're, you know, ramping up engineering resources to begin implementing all that we can. Now, so, so we're, we're starting to work on it now and as soon as we have it done. It'll be, it'll be done. And what about the, you know, the standards body side of things and like I said the the LD proof draft spec is is in a really good state right now there are still some a few answers here and there. The more folks who are able to give it to give a read through and raise questions about it, the, the faster that can go the faster we can end up with something that a lot of people can agree on. And just, just to clarify there, Andy, the part of the benefit of bbs plus is that the format will be compatible with the w3c standard right. The verifiable credential specification so what we're needing to standardize is, okay let's agree on the signatures, how they're applied to LD so that you know so that it's actually interoperable it's not just compliant with the w3c spec is that right Brent. Right. Right, I mean the w3c spec was a labor of love it. It was a lot of hard work there was years and years of consensus building to get it out the door. And, and even with all of that, it really is just the first step toward potential interoperability. You know, multiple organizations and implementations of that same specification are not going to be able to interoperate without what we're doing now, which is trying to establish some some more practical interop. And, you know, agree on some signature sweets that that we can all be comfortable with. Yeah, so there's a few steps to go but I think what we're seeing is a meeting of minds right isn't it because it feels from my kind of layman's perspective that we've got sweet spot here we've got a lot of the beauty of things like selective disclosure zero knowledge proof, you know not revealing issuer signatures compound proofs. Plus we've got the service decorator side of things that makes it easier to use and put context and structure around it so that's that's my kind of reading of the non technical side of things it's a much more usable evolution of digital credentials that will take it to the next level would that be about right then do you think. Yeah, that's why that's why folks are so excited about about bbs plus all the troops I was the you know the immediate reaction at IW was, you know from the, the Jason LD and the LD signature side was. Oh, this is something we can use. And from the, you know, the ever name in the anonymous principle side, this is something we can use it was both sides, seeing the same thing and going yes, let's do this. And I think it's worth pointing out and that's why the title of Brent's blog post is, is, you know, I would say the strongest advocate for the privacy preserving credentials and you know the work on the KP to begin with. We saw the same thing that I think matter and others did when when they when they publish at the last IW when it's every six months so it's moving fast that this now could bring the the ZKP and Jason LD communities together. And that convergence could really help us with this question of overall interoperability without most importantly without giving I mean Jason LD folks didn't want to give up all the semantic richness and other work on Jason LD but we didn't want to give up and and I say with digital health credentials and digital travel passes we are absolutely seeing the requirement, you must have that privacy preservation they're already enough issues around it. We're seeing that we're seeing that again and again. As people get into the detail I go oh yeah we've got to make sure this is, is, you know as privacy built in and and on that topic I think we're right now. I'm just amazed so many people should be amazed because awesome content but so we still got a whole bunch of people on this whole bunch of questions as you we couldn't get to but thank you for asking them anyway your contributions are great. It really helps us to see what people are thinking about when they ask these questions as well. A couple of things just to let you know about so the internet identity workshop number 32 and drama will tell us he's been at all 32 of them is is on April 20 to 22nd. April, IIW as a session there, convergence on BBS plus a variable credentials who would have thought that was happening. So please go and attend that one and you get a lot more detail on it. Also, we've got our next webinar coming up. So is on the 14th of April on privacy by design with Dr. I'm looking which should be a cracker. And so, please come along for that as well. Thanks for everyone who's attended special thanks to brands for being awesome as usual and drum and for being equally as awesome. Perfect stuff. Thanks very much. Have a great weekend for those who have the day off tomorrow for Easter Friday. Thank you very much indeed.