 Okay, so welcome to this session of Emerging Ovis Forum. Today, me, Kizubisako and Dan Yamamoto will be doing this presentation. This presentation is for 40 minutes. We plan to have 15 minutes, 15 minutes, and then leave time for 10 minutes for Q&A. But feel free to interrupt me while we are talking. So, well, this, the title, is Open Source Implementation for Linked Data-Based Verifiable Credentials with Selective Disclosure and Zero Knowledge Proofs. Wow, there's a lot of technology terms in here. So I would like to see a show of hands. How many of you know what is linked data? Okay, what about verifiable credentials? Okay, what about selective disclosure? Okay, none, probably. And the last zero knowledge proof. Okay, so that was the one with the most majority. So let's start the presentation. So I'll start with what verifiable credentials is. It is a mechanism to express digital credentials in a way that is cryptographically secure, privacy respecting, and that can be read by machines. So this has been standardized at W3C, and currently it is data model is 1.1, but they are currently working on a second version. And you will see these three people when you see the explanation of verifiable credentials. So there is going to be an issuer who is going to issue credentials to a holder. For example, this example, the verifiable credentials is saying that this holder, not name is John Smith, is living in Tokyo. And in order to make sure this is a correct statement, there is going to be an issuer's signature, digital signatures, like this bit pattern. And then the verifier, what he wants to do is he is talking to this holder and he wants to confirm, are you really living in Tokyo? And if he is, he might be getting a 10% discount or something like that. So the holder is going to use this verifiable credentials to show to this verifier, yes, I am indeed living in Tokyo. And the presenting of this credential is called verifiable presentation. So the verifier receiving this verifiable presentation can confirm that this person's name is John Smith and his address is in Tokyo and there is issuer's signature. So this claim must be true if verifier believes the issuer. And so as I said, this can be used for identity documents like passport or academic certificates, like I graduated from University or something like that. And we'll see in the next slides, there is going to be an example of using it for a vaccine credentials that someone was vaccinated. And there are variations of this verifiable credentials and like JSON Web token based. And there is a special JSON Web token called selective disclosure, SJWT based. But today we are going to talk about linked data based verifiable credentials. And I think I want to add here that we'll be talking about privacy respecting verifiable credentials. What do I mean by privacy respecting? If this holder, let's see if I can, yeah, yeah. So if this holder only wants to show to the verifier that he lives in Tokyo, does he have to reveal his name that is written on this credential? For privacy reasons, he just might want to say, yes, I live in Tokyo and this issuer is saying I am living in Tokyo. So the selective disclosure means you can selectively disclose what is written on the credentials. And yet the verifier can verify that indeed the claim that holder made that he is living in Tokyo is correct. So that is there is an issuer's signature on that statement. Okay, so I will move on. If you have any questions again, feel free to interrupt me. So I said linked data based and we made it LD for short. LD based verifiable credentials because we want to have machine readable, we are going to explain what is written, what are the meanings, what are the semantics written in the credentials. For example, in this example, so this person's name is John Smith and he is a vaccinated in this June 4th and its number is 9999 and which vaccine he vaccinated is the code 123. That's the name of the vaccine. And there is this issuer, perhaps Japanese government, saying yes, this person had vaccinated on the state using the vaccine and there is a signature. So there is this link data showing all these statements in a way that machine can understand. Okay, so now in this case, the verifier wants to know that you got vaccinated using authorized vaccine after this year's April. Okay. So in this credentials, what we have is that he was vaccinated using this vaccine code 123 on a certain date, but it doesn't say if this vaccine is authorized or not. So because this is a linked data, we can link these data that is written on the credentials and we are going to have a second verifiable credentials. That is, indeed showing that this vaccine named code 123 is called awesome vaccine and this status is authorized and that has been certified by a different issuer with its signature. So from the first verifiable credentials, you cannot verify whether or not this vaccine is authorized, but if you link these two together, then you can verify that this John Smith has been vaccinated using authorized vaccine after April 2023. So that's the merit of linked data. You can link various verifiable credentials and prove a lot more predicates. So coming to the privacy preserving aspect, do we have to show again the name? Maybe I just want to prove I'm in a restaurant and I just want to show that I was vaccinated without showing my name. So with all this statement about this John Smith, he can prove without disclosing his name or without disclosing the credential serial number or without disclosing the name of the vaccine and still prove that this vaccine has been authorized. And how we do that? We don't want to link two credentials together with a different vaccine. So we are going to prove in zero knowledge that the name of this vaccine here are equal. So indeed, the vaccine he received is authorized. And there are more things we can do. We want to hide the signature of this, written in these credentials and same here because if we disclose signature, these big patterns can be used to trace the user. So even though he's hiding his name, maybe if he used these credentials in a different place that can be linked and that's not good for privacy. So that's what we have. And also what's fascinating is that we don't have to show the exact date when vaccinated. We are going to have a predicate proof that the date written here is earlier... Sorry, after. So it's going to be after April 23. So that kind of things can be also done in zero knowledge proof for more privacy preserving way in a way that the holder can disclose only the disclosure, only the information he wants to disclose and yet satisfy what verifier wants to verify. I'm losing my... Wow, I have a lot of functionality in here. So if this credential is not bound to this holder, meaning if this was like this string ticket we received and this is not bound to us, then I can give this ticket to him and he can use it because he doesn't have his name on it. So in this idea of verifiable credentials, if because he's disclosing... Well, he is not disclosing his name, it's hidden here. Maybe he can give this whole set of verifiable credentials to someone else and that someone who wasn't vaccinated can fool the verifier that he has been verified because all these things are hidden. But that's not the case we want. What we are going to do is that we have this public key tied to the holder, again, and this is not disclosed, but it is going to be the person who has a secret key corresponding to this public key that is subliminally written on the verifiable credentials that can prove that indeed this is my verifiable credentials. So that's going to be sent to the verifier as a verifiable presentation and he successfully meets the goal with all these anonymity features and proved to the verifier that I got vaccinated using authorized vaccine after April 2023 and that is me. Good. So maybe I think I want to say something a little bit technical about this. So I've explained to you how fancy things we can do respecting privacy and respecting the correctness of the claims. But what is different here and what was the hard thing we did was that if we use this common digital signature to sign verifiable credentials and we can also do that we can't simply do selectivity disclosure because if you're hiding some of the text that an issuer assigned that means you can't verify the signature unless you see the whole text. That is what the ordinary digital signatures are. So what we are going to do is instead of using this common digital signatures that we know it for 30 years, 40 years but instead we are going to use this zero-knowledge friendly digital signatures like BBS plus signatures and Communiuchalistianska signatures and Pointwell-Starn signatures so that we can still hide the parts of the message and still prove that the issuer signed this message. Okay. Maybe this is a good timing to switch to Dan who will be talking about our implementation using BBS plus signatures. Okay, thank you Kazee. So I'd like to introduce our implementation using BBS plus signatures with zero-knowledge proof. And so first I try to explain what is BBS plus signature scheme briefly. So this is a variant of Bonet-Boyen and Chacham group signature scheme. So it's called as BBS stands for Bonet-Boyen and Chacham and it's different from the usual common digital signature. It's a kind of multi-message signatures. That means this signature scheme can sign multiple messages at once and generating some small signatures. And it's based on elliptic curve cryptography and it's not so brand new things. It's originally proposed in 2004 and currently it's being standardized by the IETF. So I believe we will use standardized BBS plus signature scheme in a few years, I believe. And what's the great thing about BBS plus signature scheme already Kazee mentions, it enables us to achieve selective disclosure and proof of message equality, signature hiding, whole dividing by signatures and pairwise signature identifiers. All these kind of privacy respecting and security features can easily be obtained using this BBS plus signature scheme. And BBS plus signature scheme can be used in a way just like the standard digital signature scheme. So we can get multiple messages with issuers secret key to generate some short signature value using BBS plus signing algorithm. And typically issuer, the issuer role can are doing these kind of things. And then these three things including issuers public key and multiple messages and signature value are packed as a single credential which is handed over to the holder and then holder can use the second special algorithm named derived proof algorithm. Then holder can choose which part of messages should be disclosed to the third party. So in this case just say the holder choose one and three as disclosed indexes of this credential. And now using this derived algorithm the holder can get special type of zero-knowledge proof which is non-interactive proof so we can use this kind of zero-knowledge proof value as our standard digital signature value. And now holder packs issuers public key and only disclosed messages. In this example holder just pick up the M1 and M3 as disclosed messages and zero-knowledge proof all these things are packed into the presentation and holder send this presentation to the verifier. And finally verifier uses VBS plus verification algorithm to check this presentation. Also this M1 and M3 are actually signed by the issuer who has this IPK as its public key using this zero-knowledge proof value and verifier can decide they should accept or reject this presentation. So VBS plus signature scheme has this kind of algorithm already they prepared this kind of scheme. So what we did for creating our prototype implementation are the gap between this VBS plus signature scheme and linked database verifiable credential is the type of message. So this VBS plus signature scheme is a kind of basic cryptographic building book. So it takes our sequence of integers as its intended messages. But we want to sign to not only this kind of sequence of integers but also we want to sign to the linked data as Kazue mentioned. So we need to encode the linked data, graph data into this kind of integer array to utilize this great VBS plus signature for our linked database verifiable credentials. So we developed some kind of encoding from linked data to the integer array which is given to the VBS plus signature. So this part is the one what we developed from linked data, graph data into this kind of integer array which can be used as VBS plus functions. So at first this figure, this kind of diagram cannot be used by the computer as it is. So it should be represented as some type of format and we can use multiple formats to represent this kind of linked data but we just used the most famous or popular format to represent this kind of linked data which is JSON-LD, JSON for linked data. So this diagram can be represented as JSON-LD as follows. For example, the credential subject has ID XYZ that corresponds to this part, XYZ and whose name is John Smith and who is patient of some vaccination where the vaccination is occurred on 23 June 4 and vaccine code 1 to 3 was used in this vaccination. So this diagram can be represented as a JSON data using JSON-LD specification like this. And then we want to... we have to convert this kind of JSON data into some type of RDF data which is actually named NQUADS document. So I don't have enough time to explain what is NQUADS document here but it just says this JSON-LD can be represented as this kind of sequence of RDF triples like this. So essentially both have completely same meaning and same information each other but the problem is representing as RDF NQUADS document has a kind of ambiguity or flexibility. So all these three NQUADS document is isomorphic with the original JSON-LD document or the original diagram. This is completely not a great thing for using signature scheme because if the signer or issuer use the first NQUADS as the value to be signed and if the verifier uses the third representation then the signature cannot be verified because the message looks like completely different. So we need to remove this kind of flexibility or ambiguity caused by using this kind of RDF NQUADS statement. So that can be done by using the RDF canonicalization algorithm which is also currently being standardized by the W3C and actually Kazue and I are a member of this W3C working group which is standardizing this canonicalization algorithm. So if we use this special type of algorithm then we can reduce or remove the flexibility or ambiguity of these NQUADS document to get the single deterministic canonicalized NQUADS. Then now we can just split all these terms in this document like this and then use some special type of hash function to get integer. So then now we finally get the integer array which can be given to the bbsplus function so we can now successfully sign a linked data using bbsplus algorithms. So we implemented this kind of encoding to get lots of other necessary components into these demo applications and three open source libraries. So we developed... At first we are using third party open source library which is provided by DOC network which is a great cryptographic library which already developed bbsplus signature scheme and related zero-nullage proof cryptographic things. So what we developed are these middle-layers libraries which all implemented the encoding scheme as I mentioned earlier and these kind of Rust APIs and TypeScript or JavaScript APIs to use all these functionalities as developer-friendly way, I hope. But currently the documentation improvement are completely required and code optimization are not sufficiently done yet so we need to keep doing all these things but you can still check to our implementation... current implementation on the GitHub. And about this demo application we developed some kind of playground web applications and you can use this playground to access this URL or QR code and you can try the kind of zero-nullage-friendly features of very valuable linked database, very valuable credentials on this playground and if I have enough time then I try to show a few functionalities now using this playground site. So this is the playground site. And the left side you can see issuer part and in the middle of issuer and verifier you can see holder part. So at first I can use this playground as an issuer to issue some kind of linked database verifiable credentials. So this is the first example of credential which is about, again, John Sumis who's bus date is blah blah blah and he's living in the city A. So this kind of verifiable credential draft are now set in this issuer part and you can see there are no signature value yet because it's a draft and we have to generate some signature for making this verifiable credential draft as verifiable one. So you can click issue then now this holder can now get the verifiable credential because this credential now has this proof value part which is the base 64 encoded value of BBS plus signature value. So this is now verifiable so you can check okay this credential is completely authentic one. So if you try to forge for example it's not John, it's Jane then you cannot convince the verifier to be accepted in this credential so it should be John as an authentic one and you can show this credential as it is but now we can use selective disclosure feature so if you want to hide this serial number of this credential and if you don't show this John's identifier and John's given name and family name and birth date and if you just want to show okay I live in city A without showing your name or your identifiers then you just edit as like this and click the present then this presentation is what it's the verifier can see and this has its own proof value with the credential subject part that only includes John Sumis' home location city A without any his name or his birth date but still it can be verified using BBS plus signature with their knowledge proof so this is a kind of privacy respecting presentation of the verifiable credential and it also has a linked data specific feature but I think I don't have enough time to explain it so I skip it and back to the slide and I want to say the conclusion of this presentation so we have developed verifiable credentials using linked data featuring selective disclosure and various privacy preserving features based on zero knowledge proofs and implemented and released open source port types along with a web-based demonstration and our future work includes extending other features like credential revocation and delegation capabilities and also we have to enhance code quality for better performance and maintainability so I'd like to give many other people's skills or experiences to make our code quality for better maintenance, better maintainability and we also aim for interoperability with other projects like Hyperledger, Anoncred and Hyperledger Agua level project because Anoncred and Agua are completely cryptographic and credential things so it's a very similar goal and feels are completely same as ours so I think we can cooperate with each other to make a better society and conduct thorough security and privacy analysis to facilitate future standardization and finally we will develop a kind of post quantum security thing so that's it, so thank you for audiences thank you for your listening so if you have any questions or comments then feel free to ask us thank you time for Q&A, yes thank you so much for your talk and my name is Hirotaka from Goldman Sachs and I have one question, actually two questions but the first question is that during the demo you showed that we can detect the specific name from the JSON LD but at the same time you mentioned about the BEBS and we need to have certain order for verifying those messages and how can we determine that for example the original message has name but the presented one only has home location how do we can detect that home location is kind of like message number 3 or 4 something like that so how do we determine that from this JSON? great question I just skipped the complicated part of deriving proof using BEBS Plus with this kind of linked data but if I say briefly we use some kind of the holder can simulate the verifier's view or how can I say the holder can hold and knows everything so holder knows if the verifier uses double 3C RF canonicalization to this presentation then the verifier must see this sequence of integer messages so the holder can create some kind of permutation or mapping from the original order to the derived order which will be shown to the verifier so holder just calculates such kind of permutations or mappings and try to embed into this presentation actually this proof value part in this proof value part such kind of permutation or mapping is already embedded so the verifier can use such specific information to reorder the derived message into the original structure or the order of the messages that is a complicated part thanks so much hello so like you said you are collaborating with Hyperledge also and even blockchain there's a lot of research going on in ZKB so how can we use directly this in blockchain can you talk more about that okay so we need to be careful how are we going to use blockchain because this verifiable credentials has a lot about personal data so NGDPR does not allow us to use blockchain for putting our personal data so what we think blockchain is important is that we want to staple issuers public key and for that reason I think blockchain is a great place to use it so that the verifier is not looking at the wrong issuers public key hope that answers your question thank you let me ask a very basic question can you share about the targeting use case as a viewpoint from the social implementation okay thank you very much so maybe I have a question to all of you is anyone from Europe today? originally okay so in your EU is considering a digital identity wallet for all the people in EU and they are thinking about these verifiable credentials however they are not using BBS plus signatures so there is an issue about privacy which we are very much concerned but still that's a way forward so maybe we can start with the very basic ones and then enhance it to use these all of these nice features that we can enjoy privacy and that I think is a big use case that we need to consider thank you very much we have two more sorry again second question so in this I think it's a working progress but this demo we can't so holder can pass that credential to someone else and I think it's still like someone else can utilize it is it correct understanding and also if so how do we prevent we need to show I'm holding this credential and Sako-san and I pass it to Sako-san but Sako-san should not be able to use that one so how do we implement this mechanism yes so we assuming here that a person is not giving away his or her secret key to someone else because it's dangerous and in order to do that maybe we can embed this secret key in a smart phone and you don't really want to send it to the smart phone to someone else or we can have like other biometric feature inside so the very fabo credentials show your face or something like that so there are maybe it depends on the use case you want to implement but yes we have to think very carefully about what kind of misuses you want to have and in this playground you can use this holder options part to indicate the holder's secret so if you it's not completely not secret value but if you use secret as a secret value then and then using these kind of complicated things to get the bound type of verifiable credential then the person who knows secret can only show credential as presentation this might be a silly question but is it possible to rotate the secret of the holder rotate secret is one of the challenging things so we are now trying to solve such things but it's not implemented yet thank you