 So the recording has started, I have a couple of short announcements to make before we have Kalea present on the flavors, VC flavors. One, we are bound by the Linux Foundation and Active Policy, so that's one of the requirements that all of the attendees have to agree to that. The second one is the Code of Conduct from the Linux Foundation, which says that essentially that you have to be, you know, when you, even when you disagree with people, you cannot be disagreeable, that is the first thing. Second is, permit everyone to talk, no rudeness, which is pretty straightforward. Anyway, so I think we have about 10 people right now and Kalea is going to present on a verifiable credential flavors, which is the various ways in which it can be presented and held and issued and so on. Everyone knows Kalea, that is what I've learned, and she's quickly becoming a legend. And without any further hesitation, I'm handing it out over to Kalea to begin the presentation. And mute. Thanks, Vipin. Good morning, everyone, or evening, depending on where you are in the world. So this is, I'll, I'm going to share a slide presentation version of the paper that was published last week by the COVID Credentials Initiative on our Linux Foundation Public Health, but before I, I just wanted to set some context, which is that I'm the Ecosystems Director and I work on COVID Credentials Initiative part time along with Lucy and John. We were founded last April and there are over 400 participants from around the world who are looking at standardizing productizing VCs and really focusing on addressing COVID use cases. And we joined Linux Foundation Public Health in December 2020. This is a really good match for us because Linux Foundation Public Health has been working on open source software with public health authorities and specifically the proximity detection applications. They host code bases for several applications that have millions of users around the world. At CCI, we have three different work, three different groups doing work right now. Use cases, implementation work stream, rules and governance and the vaccine credentials focus group and we're very keen on both open standards and open source development. This is more details about the specifics of our work stream and work products that we've already developed. And then in terms of open standard, that's one of the places that I've been really active in for, you know, decades, but really focused here on seeing how we can align the standards around fair product credentials and the exchange protocols. And we are also exploring the opportunities to take in different code bases and sort of provide core open source tools to enable the vision that we're articulating. And if you want to get involved in our community, these are all the places you can do so and these slides will be shared after we'll put a link to them in the show notes basically and I'll post them on slide share. So this is getting to the main agenda item, which is this paper. I was, I've been paying attention to these differences in verifiable credentials for quite a while and was noticing that some were dismissing the real technical differences as instead of understanding them as substantive and meaningful, we're dismissing them as tribal and petty. So the purpose of this paper was to really get clear these different technical choices underlying different flavors of verifiable credentials. So at its heart of verifiable, the verifiable credential standard is a data model. It's a universal data format that lets any entity express anything about another entity and provides a common mechanism for, for understanding that they're cryptographically secure tamper evidence and if you do it right, they can also be privacy respecting and they're all machine readable. So this is the core architecture that we're talking about. And within this, this is what we'll be going into detail on. There's a Jason LD family of data presentation along with LD signatures or with a new emerging signature format with BBS signatures that enable zero knowledge proof. There's Jason, which is can be signed with Jason Web tokens. And then there's the ZKP, Kemenish, Laskaya signatures or ZKP CL. This just since this is a hyper ledger focused group, this last ZKP CL is the type of signatures and data that is, is sort of the predominant form in areas, although there's new work bringing in the Jason LD, BBS plus work. So this is a verifiable credential. And there are two data formats and the signing mechanisms for claims that are articulated in the specification. So this is Jason. It's JavaScript object notation and it's open standard for object and document format that's usable for interchange and it's human readable and it consists of. Attribute value pairs and you can see a real world example of Jason on the right. And examples of the different types of values that are acceptable within this format. So there's numbers, there's strings. So the first name John is string. There is Boolean values of true or false. There's also you can leave, leave fields empty and they are null. And you can have an array, which is an ordered list of zero or more values, which may be of any type. So in this example, you see an array of different types of phone numbers, a home phone number and an office phone number. JWT claim is sort of leveraging this suite of signing capabilities and the current way that you find out what the meaning of the different terms are in Jason is looking them up in the IANA registry for different the meaning of things like name and phone number. And so there is this one registry and if the terms you want to use are not in the registry, you can use them, but it's really ambiguous what the meaning is. And when I've talked to large technology companies who implement this form and say, hey, how do you find out the meaning? They're like, well, I guess they guess. OK, so next we and then this is what it looks like when you sort of a very high level zoomed out graphic version of a verifiable credential in Jason. There's a persistent decentralized identifier for it. It has a set of name value pairs and those are signed using JWT using the private key of the issuer associated with the public key and the did document. For that issuer. Next, we have decent LD, which is JavaScript object notation linked data. So decent LD supports an additional layer of context to map the name part of the name value pair into an RDF ontology. So what is an RDF ontology? It's basically a way that to find out the meaning of particular terms, a large repository of RDF ontologies is found at schema.org. And this happens to be following the schema.org contact type of type for movie. So if you go and you look it up and schema.org, you can see what name, director, genre and trailer actually mean so you can do disambiguation when you're looking at two different credentials from two different sources and trying to understand whether they mean the same thing or not. And if they're both pointing at the same RDF ontology, they do mean the same thing. And if they're pointing at different ones, they may or may not, but you can do the machine parsing to figure it out. Additional features that Jason LD introduces on top of Jason is a universal identifier mechanism for Jason objects via the use of IRIs, way to disambiguate keys shared among different Jason documents by mapping IRIs in context. You're able to, this is really, really valuable. Animate strings within other languages. So for example, a real world example is the DIVAC code base that India's developed to roll out its vaccine is using Jason LD because they have 22 official languages, actually the total number of languages in India's over 700, but there's 22 official languages so they can have the schema for the credential and translate it into all those languages and be able to present it to folks. There's a way to associate data types with values such as dates and times and a facility to express one or more directed graphs such as a social network and a single document. So Jason LD also canonicalizes the attribute value pairs in a predictable way based on the information model being processed so based on the RDF. So this is what it looks like on a high level simplified graphic version. You have a persistent decentralized identifier that the credentials anchored to the context points outside of itself to a URL where the RDF can be looked up and it's signed using link data signatures with the private key of the issuer associated with the public key in the did document of the issuer. So neither of these formats easily supports selective disclosure and ZKPs, but both claim they can. If an issuer puts an attribute into its own separate VC, this is possible. So I could get a verifiable credential from, say, if this ever happened, the state of California that was associated with my driver's license. But instead of putting my birthday on it, they just say over 21 in the in a separate VC that I could use just to to sort of hack selective disclosure by having credentials that already are sort of pre-prepared to address various needs. It's not possible for a holder to separate different verifiable credential claims when they're all bundled together in one VC and both Jason JWT credentials and Jason LD, LD signature credentials require that the holder show the whole credential with verifiers. There's no partial share or show. And this makes it much harder to support selective disclosure. So this is a quote from one of the community members, Ori Steele. JWT is part of the Jose family framework and provides no means to support semantic disambiguation, but has the benefit of being simpler for assertion format implementation. So they is the rice and beans of Christyre who standards. It's got everything you need to survive and it's easy to make, but it's extensibility model guarantees you will be eating rice, base 64 URLs and beans, Jason forever. That might make you fat because base 64 URL inflates Jason. On the other hand, link data proofs as seen in verifiable credentials and verifiable presentations are like the pharmaceutical drug. Really hard to build, but capable of solving all kinds of problems that formerly described by an information theoretic model where that molecular formula approximates RDF, link data proofs are capable of working with other bases, other structured data formats and extensibility model is anything that you can model in RDF. Context determines the relevance of either model. Most people don't go to pharmaceutical lab to make lunch, but most people who make drugs in their kitchen eventually end up sick. So now we get to the presentation side of things. So this is again, this high level graphical attempt I have at sort of encapsulating what's true for both Jason and Jason L.D. is that you're sending the assigned version of the whole verifiable credential to the verifier. And it contains a nonce that's from the verifier so that the presentation of that credential can't be replayed. So this is a strong security feature, but you can't selectively disclose. So now let's move on to the understanding ZKPCL. So schemas are defined in a document that's written to an indie ledger so that they can't be stained and to update the schema a new version must be created and written to the ledger for future use. And so this is, I kind of want to let me go. So this you can see the schema definition is here being posted to to the ledger. The other thing that's different about these credentials is that they're anchored to a link secret known only to the holder and stored in the holder software. And this has been described to me as somewhat of a like a watermark. So it's really specific to the holder and it is like a number hidden within a number that you can prove that the whole that all of the credentials and a particular holders while it were issued to the same person and using that same wallet. And this is a positive thing in terms of, you know, a difference is that the ZKP methods don't use persistent dids to anchor the credentials to and creates a privacy problem when you share your credentials if they're all linked to the same identifier. So this is and each of the each of the messages in the credential has its own separate signature and it's through this mechanism that when you get to the verifiable presentation that the holder can choose to share some of those statements and not all of them. And the verifier can still do the calculations they need to get the proof that the statements haven't been altered and that they indeed came from the issuer. So. Hey, clear. Thanks. So I get with this C.L. signature that you could determine the authenticity of it. But how do you tell if they're manipulated? There's usually a hash or some sort of checksum or something. So how do you determine, as you just said, that they weren't manipulated? How do you determine? In other words, if your name is signed, you can look at the signature to see that it's authentic, that, you know, the right. I think you're going to have to ask him more areas per specific. OK. Person this question. I am doing my best to provide technically accurate yet simplified information. No, you're doing I just I. Yeah, it can you answer that question? Is there any. No, oh, there. OK, this is this is a public key signatures. It's so so there's public and private keys. And when you make a credential, you actually when you make a credential definition, you write to the ledger public keys corresponding to each one of those fields and you keep private keys in your wallet. Then when you issue a credential, you are issuing a credential using your private keys for that particular item within your credential. And and so it is unique to the item and to your public key that you published on the ledger so you can verify the the origin because you go out to ledger and you get that public key for that particular item and you authenticate the data that it's unadulterated at the same time. But it's yeah. Anyways, it's it's signed by the issuer's keys. Right. It's kind of a a subkey system. So when you write, that's the whole purpose of the credential definition. Do you write to the ledger is that you are writing in that credential definition? You're writing subkeys for each one of those fields that are public, private key pairs. That does I explain it OK? I don't know if that's true, but I'll go with it. I didn't understand that every single field in a in a in a in a ZKPCL has a separate set of keys to sign it. Yeah, it's it's a it's a subkey, but yes, it does. You can look on the ledger, you can see them. Wow. OK, so this is why people say this is really heavy. OK, and then. There is a new emerging. It's now, I guess, it's getting to be almost a year old that this was put forward into the community, which is sort of combining the best of Jason LD with the opportunity to provide selective disclosure. And so they leverage Jason LD. So the meaning of the fields can be looked up in the same way that you do with Jason LD. And then each of the statements is signed separately with the issue or private key associated with the public keys in their did document. And you can either use the same mechanism that has been innovated for the ZKPCL to do a link secret or an alternative way, which is BLS SIG, which is less cryptographically heavy and is based on more widely spread cryptographic. Tooling. And then this is the sort of my high level articulation of the verifiable presentation where the the holder can decide which ones of the statements they want to share with the verifier and the verifier does their checks to check the veracity in this, you know, in the same way. So I feel like I missed a slide. I'm going to go back. Ah, we didn't miss a slide. So this Jason LD ZKP with BBS Plus is based on the usage of Jason these signatures and a sub. Which is a sub Jason BBS Plus Jason LD signature is a subclass of LD signatures. And it's used in common with combination with the Jason LD credential schema. It is a multi-messenger signature scheme. So that's where each of the statements is signed separately. And you can because of this, you can break up the claims into their fundamental attributes. And the benefit of this approach is that it provides interoperability with existing schema technologies and credentials using Jason LD and by extension. And it's fully compliant with the verifiable verifiable credential specification as it exists today. And by leveraging the technology of Jason LD with the specific set of cryptographic keys types and algorithms, the mechanism is able to produce a VC that can generate a proof of presentations and ZKP is the selectively disclosed attributes of a credential. So with that, that is all of the slides I have. And we can open it up for questions and discussion. Can you give examples? I'm of course familiar with the Hyperledger Indy. Can you give examples of where the other flavors are being used, what blockchains? So the blockchains, the least important part about verifiable credentials. Right, okay. They become very important in Indy because you have to go get the schemas, right? So let's just say like what other folks are using. So the Jason LD work is being used a lot in supply chain stuff because steel and pallets of microwaves don't need privacy. And so that's, and so the Silicon Valley Innovation Program has been really focused on Jason LD. So companies engaged there are using that. The Jason JWT is being sort of Microsoft's go-to and Workday has also adopted it. So, yeah. Thanks. Oh, and consensus. I have a question. Thank you for the presentation. Yeah. We know that verifiable credentials schemas quite generally need and it allows many different options, at least theoretically the models quite open. And for instance, it allows for the subject to be distinct from the holder, which is the most typical case indeed. In the normal case, we are thinking of the holder of a verifiable credential being the subject as well of the credential. Yeah. So that he's able to prove that he has proved a possession of the credential. Nevertheless, the specification as far as I understand are more open than that and they allow for different models where the holder is not the subject. The point is, I'm not aware in fact of any implementation in the present state of the art, dealing with subject different from the holder. Do you know of some of this implementation? Can you point to some examples? That might be relevant for some use cases we're considering. Yeah. Well, the subject of a credential about steel imports is the steel. Yeah. Okay. So all of those use cases that are around. Things. Are that. And the implementation supporting this concept. Yeah. Okay. The one which I know for more closely, namely hyper ledger areas. I have the impression that do not support this model. Oh, they must. I mean, there's a whole guardianship working group out of sovereign. And they've been working on this type of use case since the very beginning. Okay. So that, that should be possible. Yeah. Thank you. Thank you. So delegation and guardianship. Have been. Worked on. Like. Colleases. From. And stuff. And I, you know, as far as implementations go, we have to defer to the. People who know more about that. If Calias says there are. We assume there are. The, you know, we, we probably could question the identity working group implementers were, you know, identity implementers working group, which is kind of a sister group of this group. But I'm not sure whether such implementation fixed, because you are obviously interested in. Actual implementations because you're working on some kind of a delegation or. Guardianship. Use case. Yes, that's exactly the point. Thank you. Thank you. Thank you. Thank you. Ruben anything more to add on this because you. Mentioned that you. Use. Or anybody else for that matter. No, I just, I think maybe. We, when we started, we. I thought the. The tooling wasn't quite there yet. So we use JOT in the beginning, but we are now also going to add support for Jason. Because we believe that Jason, that he was BPS plus seems to be really good compromise to chief. A lot of the interoperability plus the security. So I think. That's our direction. And BBS plus work. Was done. Which is also a. Project. It started off as a lab. But now it's. Project. I think Mike Loder. Worked on it. He has a pretty. I'm safe explanation of. BBS plus. On the matter website. If anybody's interested. Not too much. Not too much. Not too much. Mathematic. Anyway. Yeah. And I think just to add on the previous point. There isn't an interesting. White paper developed by. IOTA. And how are they seeing. IIT devices using self-sovereign identity. Let me post that white paper link in the chat box. In case if that sounds interesting for someone. Yeah. Thanks. So I'll put the link to the paper in the. Chat. This is really. This was a very, I went by faster than I. This is my first presentation about it. So one by faster than I thought. But you definitely need to read the paper. If you want to actually understand all the things I said. Yeah. So the paper link is also being provided in the wiki page. And probably we'll have this. The slides also on the wiki page of. Our wiki page. In addition to the. The recording of the video. Which should give more. Exposure. To different people. I'm more interested in this. Because of the. Operability implications. Especially. In other space. Like, for example. Let's say you're doing financial transactions. And how can you. Create interoperability in that situation. Using. Identity as a pivot. And. So I, you know. Maybe I'll be looking more into that. And I think the CCI. Work is very interesting. We started off. Our year last year in April with. Basically. Explanation of the. Apple and Google schemes. To do. Exposure. Tracking. And now we have come to this. To the other side of things where we are. We have a vaccine. And I think. Callia, you, you had a. Pretty extensive. Sort of. On it. Today's words, I think. At the WHO, right? Isn't that correct? Okay. You just went from like gain API. To WHO. I'm very confused. What are you asking? I'm not asking. I'm basically asking. I'm not asking. I'm basically trying to. Say that you had several. On this CCI initiative. And this paper is developed as part of that. That's, that's all I was saying. Anyway, I think we have come to the end of this. Presentation. And so. Unless somebody else has. Questions, we can close. I'm not asking. I'm basically trying to. Say that you had several. Questions. We can close. Or as fast. Sorry. It's okay. You know. We, we learned something. Unless anyone else or Calia herself has. Some things to say about this. The topic. So see you next time. Next time it's going to be drumming talking about his new book. That he's written. So that's. Two weeks from now. At noon. Thank you for attending. Thanks. Bye.