 And we are recording. All right. Thank you everyone for joining us today, February 8th, 2024 for Decentralized Identity and Interoperability. Connecting Credo with Hyperledger Bezu, Cardano, checked Hyperledger Anon creds, and OpenID Connect for Verifiable Credentials. I'd really like to thank everyone for joining us today. And most importantly, I'd love to thank our three presenters, Alexander Renata and Artem. They are amazing members of our community. They've been contributors for a very long time to Hyperledger, but especially the Identity Projects at Hyperledger. I got to work with Alex five or six years ago, and that's been a, that was a great experience. I am going to really quickly take you through a couple of slides as an intro, and then we're gonna jump into the presentation. Yeah, okay. I don't know why you're doing that. All right. Sure, it's great. All right. Really quickly before we start, we have the Linux Foundation Antitrust Policy. And this applies to all meetings at the Linux Foundation, working groups, special interest groups, workshops, such as this. If you have any questions about these matters, please contact your company council. Or if you remember the Linux Foundation, feel free to contact Andrew up to grub of the firm Gessmer up to grub LLP, which provides legal counsel to the Linux Foundation. And also it was with all Hyperledger meetings. This is under the Hyperledger Code of Conduct. The best way to sum this up is be excellent to each other, but we do have the Code of Conduct documented and that's going to be in the links that I'm gonna share once we get started. But really quickly about Hyperledger, we're the open source global ecosystem for enterprise grade blockchain technologies hosted by the Linux Foundation. We have a number of graduated incubating and labs projects. These are just a sample, but a non-creds Aries, Beizu are really the, some of the internal, some of the Hyperledger projects are gonna be highlighted today, but we also have some non-Hyperledger projects. That's what makes this presentation so exciting. But identity is an ecosystem. There are a lot of different organizations involved and we're gonna, this team is gonna talk about them during the presentation. We mentioned Hyperledger a second ago, there's the decentralized identity foundation, which hosts the Didcom working group, the interoperability working group, side tree, identifiers and discovery working group, there's trust over IP, which is really focused on that governance layer, but the good health pass, the trust over IP layer model and then multiple working groups underneath that. There's the open wallet foundation, which is just about to turn one years old, which hosts Credo, which is one of the technologies going to be used today, which we're pretty excited about. Multiple SDJOT projects, the safe wallet special interest group, the architecture sig, the credential format comparison sig, which is doing some great work, as well as the open ID connect for VC's due diligence sig. Then you've got the W3C, which is where a lot of this work started years ago with the W3C credentials community that did core specification and the credential format. And we're really excited that that's gonna get a mention shortly. And then open ID, open ID connect for verifiable credentials is a really nice part of this presentation, one of the bridges that we're really excited to see being built through all this interoperability work in the identity space. But open source only works with you using the products, learning about the products, contributing to the projects, which would be fantastic and helping to maintain them as you go along your contributor journey, but also advocating for the projects. We cannot exist without the help of our community. That's why we say we host these projects, but also the communities that build them. One of the reasons to engage, well, you wanna keep up with the community project, you wanna provide use cases that help the projects better serve your needs. If you've got a really interesting healthcare and decentralized identity use case and you're the only one who knows about it, well, maybe the community is not gonna be building the things that you need to bring that to life. That's why you wanna engage. Easier help with issues. One of my favorite things about this community is we have an incredibly active discord and it is fantastic. And the signal to noise ratio is generally great. And we have really great contributors who, they have day jobs, middle of their day, they'll stop and answer a question from someone who's stuck on a really thorny problem or is trying to get through getting started guide. And that's something that we're super proud of. Our community is very open and welcoming. But it's not just to contribute to the projects. You wanna include feedback as well. And it's not just developers. You can engage in UX, you can engage in documentation. We need project managers on these projects. Anything you can bring to the table, the Linux Foundation and more importantly, Hyperledger and the projects themselves really count on that. How we communicate as just Hyperledger and the different projects. We say every project's different, but we have a bunch of tools that are in common. Discord, email lists, SIGs and special interest groups and project calls, as well as Github itself. Github is sort of the center point for each of our projects. And there's a lot of communication that happens there as well. And then what to expect from the community. We've mentioned the antitrust policy a moment ago. We've mentioned the code of conduct. We record all of our meetings and we take notes and put them into our wiki. I mentioned Github a second ago. We should probably add the wiki to here as well. And then the last slide for me before I turn it over to our fantastic presenters. What to expect from today? We're gonna have a workshop with great knowledgeable presenters who've been working in the space for a very long time. An informative presentation that I think you're gonna get a lot out of, particularly in the context of how important interoperability is, not just to identity, but just to the DLT space itself. A fantastic demo, which I'm looking forward to seeing. And then we're gonna get hands on using the service Gitpod. We're gonna put some links in the chat shortly. You need to connect your Gitpod account to your, yeah, so A.M. thank you for putting that note in the chat, I'll answer that in a second. You need to connect your Github account to Gitpod to be able to get hands on. But once you do, you're basically getting a development environment with everything pre-installed. You're not gonna, we're not gonna stop the workshop at an hour and a half to give folks an hour to install applications. So we're pretty excited about that. This is not being live streamed. So this slide is slightly a lie. It is being however recorded to YouTube. It will be on the Hyperledge YouTube. I'm also going to embed the video in the Wiki page. The Wiki page is going to include the recording, the notes and the links that I'm gonna share momentarily. There's gonna be a thank you note, which will go out probably next Monday to everyone who registered. If you didn't register, that's fine. All the links are gonna be in the YouTube video description as well as on the Wiki page and Gitpod. If on Sunday you wanna go back and refer to the video, you can go back into the Gitpod link and play with the environment. So we're pretty excited to experiment with that. With that, I am going to turn it over to Alexander, Renata and Artem. I'm gonna stop sharing and let them share their screen and let them introduce themselves and kick us off. Thank you, Alexander. Thank you. Thank you, Sean for the great introduction. Share my screen. Can you see it? You look good and you sound good. Okay, perfect, perfect. Thank you, thank you everyone for joining today. We're looking forward and hoping that this presentation will be interesting, useful for those who are new in the centralized identity space, for those who are not new, there still can be some good things in order to summarize the knowledge, in order to specifically talk about the topic of interoperability. So just a couple of words about what we want, what we want to achieve with this presentation, why we are doing it. Actually, there is a number of myths about self-serene identity, maybe some misconceptions. And one of the goals is to domesticize and provide actually more context about what is self-serene identity, what is the state of interoperability in self-serene identity. And the first thing that I wanted to start with that self-serene identity or the centralized identity is it is not a framework, it's not a tool or a library. The society is a concept, it's a model for digital identity. And there are multiple specifications, protocols in self-serene identity. There are multiple frameworks, tools, libraries, APIs implementing these principles and protocols. So it can look like a bit mass, but one of the goals of this presentation is actually to show that it's not as complicated as it seems. And there are very good trends in the community kind of to stabilize these protocols, to converge them. And interoperability, probably for someone it can be surprised that it has now a much better interoperability than it maybe used to be before. So the first goal is to summarize the main approaches, specifications, profiles in SSI. So before we start talking about interoperability, we need to kind of define what is SSI and what are the points in SSI where interoperability may happen occurs. And the second goal is actually to show this interoperability between some of the approaches, tools and frameworks. So as Stone already mentioned, our presentation today will consist of three main parts. The first part is a presentation, the theoretical part. The second one is a demo. And the last one is a hands-on session where everyone will have a chance to maybe write some code to do something in your environment, or synthesizing Git part environment to simplify the prerequisites and installation and can just feel how it all works. The first part, the theoretical part will consist of three sections. The first one, just a brief overview definition of what is also an identity. For those who are new just to understand what we are talking about and for those who already know about it just to remind and maybe also summarize some of the core principles. The second part, before we actually move to the demo in interoperability, it's important to define the dynamic points, the variable points or interoperability variables. Sometimes it's called profiles. And in particular, to discuss different formats of refiable credentials, different exchange protocols, different DID methods, refiable data registers. And the third part of the theoretical section of the theoretical part, we are going actually to discuss the exact values of interoperability variables that we are going to show in the demo and the hands-on parts. In particular, we are going to provide a short overview of the credo or exteriors framework, JavaScript framework. We're going to talk a bit about the hyperledger unencredced and the refiable credential formats. We're going to provide an overview of hyperledger areas and open AD for the refiable credentials and in terms of the refiable data registries, which is quite often blockchain or distributed ledger technology. Now, we're going to talk and then show on the demo such frameworks as Cardano, checked hyperledger as part of the ledger int best initiative. So, about us, about the speakers. So, my name is Alexander and I'm head of decentralized systems department at the DSR Corporation. And I've been working with open source, with the cell-storing identity, decentralized identity technologies as well as distributed ledger technologies and blockchains consensus protocols for many, many years. And in particular, I have a lot of experience in contributing, maintaining such projects as hyperledger indie areas, ERSA, unencredced and so on. And I will present the first part, the theoretical part of the presentation and the demo and hands-on parts will be driven by Renata Tar. She's a lead software engineer at DSR Corporation. She also has many, many years of experience working with the open source, cell-storing identity, blockchains, distributed ledgers and such projects as hyperledger indie areas, the check and so on. And also we have our term with us on the call and also can be ready to help the questions in chat or anything that may arise during the hands-on. Just a couple of words. So, we both represent DSR Corporation, just some background, why we are providing this presentation because actually in DSR, we have a lot of experience of working with blockchain and cell-storing identity technologies and contributed to many, many open source projects which includes in particular many identity frameworks, projects like indie areas, ERSA, sorry, unencredced, checked. And also we are the members of hyperledger foundation open wallet, deep trust over IP. So kind of one of the main organizations which adopt and advance decentralized identity. So, let's move to the presentation part and the first thing that we need to understand is what is actually cell-storing identity? And let's start with three models of digital identity. So the first model, it's probably a traditional model, a centralized model where an identity and the attributes associated with the identity are usually controlled by third party organizations which actually means that there is a different representation of the user or in every organization. From UX point of view, it means that usually people have to create a new account with a new passwords for every service. And it's not perfect of course from the security point of view, from the privacy point of view because people don't have any control of the information about that. Also it's not so convenient and secure from the UX point of view. It may lead to lots of passwords that needs to be managed, many of them may leak and so on. The second model is a federated identity. That's a model when the information about identity, the attributes are encapsulated in identity providers and the third party organizations can leverage the identity providers to be authorized to access this data. Just some examples that can be associated with this model are OAuth, open edge connect protocols. From the UX point of view, it may look like when people go to their website, there can be buttons to log in with Facebook or Google or Apple or GitHub, whatever. And UX is much better. Of course, UX is much better. But in terms of privacy, there is still no control by the identity owners of the data how it's used, how it's processed and so on. And finally, we have a third model, self-studying identity or decentralized identity. And unlike other models, this is a model which is focused on privacy and it actually enables the holders, holders or the identity to maintain full control of the identity or the attributes associated by that entity. So it doesn't require intermediaries to provide the necessary data. So identity is fully managed by the holders and presented disclosed to the corresponding services when needed. So it's more privacy preserving, it's more peer-to-peer communication. And also it sometimes leverages the blockchain or distributed ledger technologies, but as we will see later, it's actually more abstract than these and it's not mandatory. So another representation of a non-SSI versus SSI approaches in non-SSI approaches on the left side, you can see that information about us, it's really distributed the internet. So lots of representations, lots of pieces of identity in many, many services to run the net and no control by the user. So it's more close to the web to approach when actually organizations leverage the information about the users. And on the right side, the holder, the actual controller owner of the identity is at the top. It's in the center and it's more close to the VAP3 approach where the control is returned back to the users. There is no need in mediators between the users and the final service. So before we consider an actual example of what it means actually how it's achieved because right now it's just some words, right? But before we move to these, let's consider two very important concepts associated with the self-serving identity. The first one is verifiable credentials and the second one is the decentralized identifiers or DADs. Both of these concepts are not just concepts, it's actually standards as part of W3C, it's recommended standard. And let's start with the concept of a verifiable credentials. Now, first of all, a credential is a set of one or more claims made by an initiative. So let's consider, for example, a digital ID, digital passport, right? And there can be some claims like a name, surname, address, rate of birth, and so on. Just some mapping, some claims, some key, some values, right? What is verifiable credential? Actually, verifiable credential is a temper evident credential, which means there's a claim and some signature, for example, digital signature, which can be verified so that when the user presents this digital passport, it's possible to actually check that it's authorized, that it's issued by the government or corresponding authorities. So yeah, that's what about verifiable credentials. And the second concept is a DID, the centralized identifiers. So basically the centralized identifier can refer to any subject, like a person, organization, thing, abstract entity. And unlike traditional identifiers, it can be decoupled from any centralized registries, identity providers, certificate authorities. What is important here? What is important here? So we have an identifier, but also we have a DID document, which contains some kind of metadata, some data associated with this subject and identifier. For example, in DID document, we may have some service endpoints, we may have some keys, some keys like public keys, which can be used for authentication, which can be used for the proof of ownership, proof of possession of this identifier, which can be used to do any assertions, key agreement and so on. It's very important that it's identifier plus the keys and other metadata in form of DID document, about the DID subject. And also previously mentioned that DID is decoupled from any centralized registries. And actually, if you look at the syntax of DID, it consists of did, then did methods and did method specific stream. And the did method, it's actually what defines how exactly the idea is processed in terms of current operations, where it can be resolved. And here we have the concept of a Refiable Data Registry. Refiable Data Registry. So this is like an abstraction. It's an abstraction, can be a database, can be a blockchain, a distributed ledger, where, for example, the did documents can be published and can be resolved. Like in a simple way, we can have a ledger and where for every DID, we have a did document published as a ledger and anyone can read it, right? And we can actually get information about, for example, the public keys associated with this DID. The number of methods, it's quite significant. It's more than 100 different methods for various approaches, various blockchains, ledgers, some of them don't use ledger at all. We will see it in a sec. So on this slide, we have an example of a DID document. A DID document, you can see it may have some services, for example, like service endpoints, URLs, which can be used to access the did subject. And also we have verification methods, which is basically an array of public keys in different types, different formats can be used. And these keys, as I mentioned, that can be used for authentication, for to prove the ownership of this DID for assertion, key agreement and so on, various purposes, okay? So we just considered the concept of verifiable credential, like some claim with authorship, with signature and the DID, some identifier with the corresponding keys. Now let's put two of these concepts together and consider them in action to actually understand how SSI works while as the main SSI workflow. In SSI, in SSI, we usually consider a three actor model. So we have an issuer, a holder and a verifier. So issuer is an entity, it can be an organization, it can be a user who actually issues a verifiable credential. Verifiable credential is issued by the issuer and it's sent to the holder. And it is a holder who actually manages the credential who stores this credential, usually in some wallet, it can be a mobile wallet, it can be some cloud-based hybrid wallet. So that, that's one of the first differences between traditional non-SSI approaches and SSI approaches. The SSI, the data, the added data in form of verifiable credentials is stored on the holder side, not in some identity providers, not in the blockchain, never, but on the holder side. Then on the right side, whenever the holder needs to access some service, the service as a verifier can request some proof. And the holder can present this information derived from the verifiable credential. And the verifier, since the verifiable credential is not just the claims, they also contain signature from the issuer. The verifier can check, can verify the signature and make an attestation that requested perimeters, requirements are satisfied. So here we have a verifiable data registry. So let's need it. So we just discussed and considered the verifiable credentials, the issuer issues verifiable credentials, it sends to the holder, then holder presents its credential to a verifier. The DADs, it's also important here because in order to sign a credential, some keys are needed, right? And we remember the DAD is not just identified, it's identified plus some keys, plus some metadata in the DAD dog. So the issuer usually has a DAD, it's called DAD1 here, and the verifiable credential is actually signed by the keys associated with this DAD1, okay? And this DAD1 and the corresponding keys which were used for signing, they can be published to verifiable data registry. So what it means that the verifier when presentation comes to the verifier, verifier can see, this is a presentation for a credential issued by an issuer with DIT1, and they can go to the corresponding verifiable data registry, how it can be done, it's defined by the DIT method. And they can actually resolve the DAD with, they can get a DAD document, they can get the public keys and verifies the signature from the issuer. Okay, that's why DADs are convenient here because they can actually decouple these keys, as identifiers from any centralized things and make all these things very decentralized. Also, by the way, what is important here? That verifier doesn't need to communicate with the issuer directly. You can see that this resolving is done via a verifiable data registry in a decentralized way. So it's good in terms of correlation, privacy, the issuer doesn't know when the credential was used by the holder, when it was presented by the holder. And also the issuer can be just, the service may go down, there's no dependencies on the issuer service in the process of verification. Okay, and the last part here, you can see D2 associated with the holder. So depending on different SSI frameworks, specifications, this part can be different, but essentially, essentially, usually, revival credentials are usually issued for some holders, DAD for some subjects, DAD, D2 in this case. And of course, the issuer signs not just the claims, but also the fact that it's issued for D2. And why it's also, how it can be used during the presentation, during the presentation, the holder can actually prove that he owns these DAD2 by presenting the corresponding proof of ownership, the signature associated with the DAD2, right? So usually on the verifiable side, you may have two signatures, one by the issuer, initial with the DAD2, initial signing of the verifiable credential, and the second one from the holder made by D2 and it kind of establishes an ownership of this presentation of the corresponding keys by the holder, which means that it's actually the entity for whom the credential was issued, this entity is going to present it. So we have D1 for the issuer, D2 for the holder, we have the refurbished credentials signed by D1, associated with D2 and on the verifiable side, the presentation comes usually with two signatures, one by D1 from the issuer, the second by D2 from the holder. Usually D2 doesn't need to be put on the blockchain, in many cases, some off ledger approaches for DAD are used, something like DIT key, DIT peer, some forms of DDION or DIT carry and so on. So it doesn't always mean that a DAD must be published on the ledger, no. There are some approaches, some methods, DAD methods, which doesn't require it and it can be quite good for the common people for holders because they don't need to put some data to blockchain, which can be good from, for example, GDPR compliant purposes. Okay, so the next... Looking at the structure. Sorry, any questions? No, Alex, go ahead, that was an artifact. You're good. Okay. So the next slide, it's about trust or IP stack. We can see that trust or IP, it's one of the organizations that advanced in social and advanced technologies and one of the main outputs of the working groups is the creation of trust or IP stack, which has a very nice, very nice layered representation of the concept identities. And let's try to actually map what we just discussed to this stack. So let's start with the left part. It's like a technology stack. And on layer four, on layer four, we have actually the application ecosystems. Where we apply social and advanced identity, what use cases that can be like supply chain or healthcare or, you know, education, banking, whatever. On the layer three, we have some protocols, actually some trust as protocols. And the credential exchange protocols that we just discussed, where the issuer issues refurbished credentials and the holder presents approved to the verifier. It's one of the examples of these protocols. Of course, there are more protocols than just that. There can be some protocols to establish a connection, some protocols for discovery, a number of them. And the next question is, okay, right now we just discussed that the credential is somehow was sent from the issuer to the holder and then holder somehow presented it to verifier. But how exactly, what are the channels? What is that transport? What is the communication? And actually we go to layer two. It's like a peer-to-peer communication layer, right? So on this layer, two entities, for example, issuer and holder, holder or verifier or just some abstract agents, they establish a connection, a peer-to-peer connection, peer-to-peer channel between them. And the information, for example, the state machine of the protocol, the refiable credentials, the proofs, they can be exchanged via this channel, okay? And usually one of the approaches for this channel is a DITCOM, DITCOM communication approach where this channel is created, there is all information is encrypted, leveraging the keys associated with DID, DIDs. It's also very convenient and powerful way, which is also transportation, right? And on layer one, we have public utilities. That's where we have the refiable data registries, where we have the DIT methods. It can be some databases, blockchains or other ways to resolve the DIDs, to get the keys and so on. So you can see like the protocols on layer three, some state machine is executed and the messages are communicated via some peer-to-peer communication channel on layer two, and on layer one, we have like the blockchain, the ledgers, refiable data register, abstraction, and so on. Okay, it's about the technology stack and also important part of trust over IP stack is a governance stack. On every layer, there can be a separate governance which defines the actors, the roles, the framework, the corresponding certifications, just an example why it's needed. So we understood that the refiable credential is issued by an issuer and then the holder presents it to the verifier. But the question, why verifier should actually trust that it's a valid credential issued by the issuer? Yes, we can verify the signature, we can verify the shift apart, but it can be that the holder just signed this credential on his own. That's why we need some trust framework. That's why we need to actually understand that this particular DAD, for example, this particular key which was used to sign a credential, it can be trusted, it can be associated with the government authority entities, right? So the verifier can check that, yeah, it's a credential associated with the corresponding credential definitions, the decentralized identifiers which are actually owned control by the government. That's just one of the examples why we need some additional governance and it's not only about this, it's of course also about like the frameworks, the wallets which can be used, can be certified and so on. Okay, and the last slide in this part, it's just to emphasize the relationship between SELSA identity and the blockchain because one of them is that the SSI can not be done without the blockchain or that the blockchain is a very essential part of SSI. The answer is no, blockchain part is optional in SSI cases. Blockchain may appear only on layer one, layer three, layer two, haven't seen any blockchains there, any ledgers. On layer one, we may see as an example of the refiable data registry. It's actually quite popular situation when blockchain is used, distributed ledger is used as a refiable data registry because it's actually a very good option in many cases, especially to publish the issuers publicly. Previously we discussed that it's good in terms of trust, in terms of decentralization, in terms of there is no need to verify to access the issuer infrastructure. So it's a very reasonable option in many cases to use refiable data registry, but again, it's not mandatory. Also, it's important to understand, important to understand how exactly the ledgers, the blockchains are used. What is usually stored on the blockchain? Issuers, the ID did document publicly. Again, it's just pure public information, right? No private data. Revocation registries, revocation, it's quite important part of SSI because in many situations we may need to revoke a credential. For example, consider a driver license. By obvious reasons, it can be revoked sometimes. And credential schemas, it's also quite popular case when credential schemas defining what exactly we can expect in a credential. This information, public information can be part of the ledger. For example, like what the fields in the digital passport like name, address and so on can be there, what are the formats, the attributes and so on. Then what maybe optionally stored on the blockchain? It's holders, DIDs and public keys. Previously we discussed that the refiable credentials are usually associated with some DID from the holder, subject to DID, right? And in some situations it can be okay to publish these DIDs of holders, public keys. There's a blockchain, although in most of the cases it's not needed and more of it's even maybe not desirable because blockchains are immutable. And in terms of GDPR, in terms of some regulation laws of common citizens, it may be better to use some DAG methods alternatives which don't require publishing data on the blockchain. And it works just fine. Again, SSI doesn't require to leverage to use blockchain in all these cases. And also what is important? What is never ever stored on the blockchain? The verifiable credentials, the verifiable credentials are never put on the blockchain. The keys which were used to sign credentials could be put but the verifiable credentials itself it's always stored on the holder side with some wallets. And of course, private keys, private keys as well they're never put on the blockchain. Okay, so we are done with the ORU part and let's consider the next part before we actually jump into interoperability. Let's consider so-called interoperability variables or profiles. It's actually the points which we need to define before talking about interoperability. It's the points and nodes in SSI kind of approaches where these variables may appear. Let's look actually, let's use the trust or IP model as an example. We have three layers, credential exchange, communication and public utilities like VDRs. And if you start thinking about verifiable credentials and these three active model, we may realize that usually we need to answer at least three questions. What is the verifiable credential format? Like so what exactly we are exchanging here when we say that issuer, issuers and sends a verifiable credential to the holder but what is the format? What is verifiable credential, right? Right now just some abstraction and that can be multiple kind of ways to represent, for example, a digital passport, right? In terms of encoding, in terms of signatures, in terms of semantics and so on. The next question. Okay, let's assume we define the format of verifiable credential, but how exactly is transferred from the issuer to the holder, from the holder to verifier, what is the exchange protocols? And also multiple options can be there. And the third one is where? It's about the AD methods and the VDRs. We already discussed it can be multiple, the AD methods. So do we need to use a blockchain, a ledger or we need to use some existing trust within domain names or you should make it off ledger, some centralized databases. So where exactly is public keys, is the AD and did methods a store? So we can see just some examples here that in terms of formats, it can be hyper-ledger, on the crates, it can be WST, verifiable credentials then either JSONLD, JOT or SDJOT formats. It can be a mobile driver lights in this and so on. Of course, it's not a full list, it's just some examples, some popular options. Exchange protocols, it can be hyper-ledger areas, it can come based, it can be if also it come based formats, it can be open identity for verifiable, open ID for verifiable credentials, it can be W3C, a verifiable credentials AP or CHAPI, it can be formats defined mobile driver license, ISO standards. And where, so we're going to consider a number of options. There can be like some self-resolving options which doesn't require any other storages, did keys an example. There can be some DNS based resolving via the web and there can be some ledger specific things like Indie, did Indie did soft check, for example, check the Cardano, Prism, Bezu, Indie, Bezu and so on. And the combination of these variables, not actually only these variables, there can be more variables defined, it's just, I would say the core ones, the combination of these and other variables is sometimes called a profile, sometimes called a profile. And as an example of more variables, we can define the approaches for revocation, for trust and so on. So let's start thinking about these variables and the very first, the very first combination of variables that was part of hyper ledger and one of the very first production ready frameworks approaches for SSI, it wasn't still associated with the hyper ledger Indie and later with hyper ledger areas and unencredced, which means that hyper ledger unencredced is used as a refurbished format, hyper ledger areas, did comb based approaches are used as exchange protocol and hyper ledger Indie ledger, permission to ledger is used as the video. And it's, well, one of the profiles, the reason about has its constant process any other profile, but what is important here that there are much more options, there are much more options and profiles than just this and especially for people who may start their journey in the centralized identity world, if they start the journey with some particular organization of framework, let's say at Indie or mobile driver, let's insist or open ID, they may think that like this framework is the only way to implement SSI, which is not, which is not, you can see that there can be multiple different options. And even in hyper ledger areas, even in hyper ledger areas and like greater framework, which was also part of hyper ledger areas sometime ago, we can see that much more variables and formats are supported. Not just Adam Kratz and there is an Indie like the standard Indie based one, even as part of hyper ledger areas, we can see a support for both Adam Kratz and SSI, we can see support for areas for open ID, for refurbishable credential protocols, we can see support for many, many different types, the ID methods, ledgers, blockchains, that actually what we are going to see today during the demo and presentation part. And just a couple of more details to be about different variables. Let's start with what, with a refurbished credentials format to see the difference. Before we start discussing this difference, it's important to understand what is selective disclosure and predicates, right? So let's assume we have a credential, like we have a password, digital ID, with some claims about the subject holder, selective disclosure means that during the presentation of this credential to the verifier, only top set of the claims can be disclosed. For example, just a nickname and some information about the age is presented, is disclosed, and for example, address is still hidden. It's not provided to verifier. But just of course, this feature is very good in terms of privacy, in terms of being unlinkable. So it's a very, very nice feature. And the second feature is a predicates, predicates. One of the options is actually to disclose the attributes as is, but another option is to use predicates and disclose, for example, not the exact age, but a predicate that age is over 18 or 21 or whatever. It's also very strong, it's a very powerful privacy preserving feature. And what is important, that depending on the refurbished credential format, some formats has support of selective disclosure and predicates, some formats don't have it. What is also important when we're discussing these different formats, we don't say that like one format is better or worse than another. Refurbished credential format or exchange protocols, they all have their own cons and pros and depending on the context, depending on the interoperability requirements, one or the other format can be a right selection, right? So let's just briefly consider probably the most popular ones and the difference between them. The first four formats, they are part of WST, refurbished credential, that's actually the most popular, the most common standardization of a refurbished credential format form of a JSON or JSON-LD. So as serialization, the first two we use JSON-LD and the second is just JOT, just obviously JSON. What LD means, it provides some linked data capabilities to just a pure JSON, which means that there is some semantics, some schema, some meaning in the JSON fields, which can be a very, very nice feature in some cases. The difference between these formats is not only in serialization, but also in the proof format and signing algorithms used. The first one is just the standard JSON-LD. Usually some common standard signatures are used in form of data integrative proofs. It can be like a CDCA, a little curve signatures can be RSA, can be a DDCA, lower gen ed to 559 signatures. It JSON-LD is encoded. It doesn't support selective disclosure, it doesn't support predicates, as like any common standard signatures, they don't support it. The second type is JSON-LD with BBS plus type of data integrative proofs. BBS plus, it's a more advanced type of signature, which supports selective disclosure, which supports selective disclosure. The third one is a dot. It's like in the first one, it usually uses some common signatures like a CDCA, RSA, DDCA. JSON is a serialization type and it's actually a valid, a common dot, leveraging AWS, GVA and HOSA family of standards, which can be a nice option if the dot is already part of any system and you're leveraging a dot to represent the refiable credentials can be a reasonable option. And like any common dots, it doesn't support selective disclosure neither selective disclosure nor the predicates. And the fourth format that we are going to discuss as part of the AWS VC family, it's SD-JOT, it's selective disclosure-JOT. It's actually an extension, an extension of JWT-JOT standard to support selective disclosure, to support selective disclosure, which means that it's issued leveraging some assets and not all the values can be disclosed to the verifier. It's a very nice, very nice extension, which is more privacy preserving than common JOT. And still it's a valid token, which can be used in the same cases where JWT is used. Okay, so that's about like some popular combinations for refabrication format as part of the AWS VC, but the AWS VC refabrication show is not the only standard, it's not the only format. Hyperledger, Anuncrats, most commonly used in India and areas, it's another very popular standard has been adopted, been in production for many, many years. Right now, it has its own specification definition. It's part of Hyperledger Anuncrats project. You can see that it's the most privacy preserving standard because it supports both selective disclosure and predicates. It also has other very nice features because it's based on zero-knowledge proof cryptography. Of course, much more advanced complex cryptography based on CL, Kaminesh Lysanskaya signatures. Jason was used as a serialization. I'd like to note that as part of the recent Bistegaf opportunity, right now it's possible to represent the Hyperledger Anuncrats, the refiable credentials in AWS VC, as AWS VC refiable credentials for refiable presentations. So I hope that it's actually a very big step forward, the convergence and interoperability and it should be possible actually to leverage existing Hyperledger Anuncrats credentials where, for example, AWS VC refiable format is expected. So it's not as separate now as it may look like. And the last popular option as part of a refiable credential, it's mobile driver license, which maybe it's not always considered as a refiable credentials, but it is by essence. It's driven by ISO format and it's actually already part of many frameworks to write mobile applications for Android, for iOS. And it's based on a binary serialization format, SD-BOR and COSAC responding types of signatures, the CDC-8, the recommended way to sign, recommend the signature there. Although the signature, it's like a common one, it's somehow similar to SD-GVT because it also supports selective disclosure. It's also supports selective disclosure, not providing all, not disclosing all the information in the mobile driver license, but it's possible to disclose only part of this data. Okay, so that's what about refiable credentials formats. Now let's look at the how part, that's about refiable credential exchange protocols. And the first one here, it's an open ID for refiable credentials, which actually consists of three main standards, open ID for refiable credentials, issuance, presentation, and also a self-issued open ID provider with two. We are going to discuss it in more details a bit later. What is important now, that it can work with any refiable credential format, right? So also it's one of misconception that it can work only, for example, with W3C-JSNLD credentials. No, it's possible to leverage these standard exchange protocols for mobile driver licenses, or for Anomkrat, or for Jots. It's really format-agnostic. Transport, it's not only HTTP, but there are some work-in-progress specifications to use it our Bluetooth, and some offline scenarios. So yeah, it's a very promising, it's a very promising set of standard specifications being adopted on some government levels. And yeah, can be a good option, especially if open ID or OAuths are already used within the product. The second type of credential exchange protocols, it's DIT-COMB-based and hyper-ledger areas, or DIFF-VACCHI are two well-known examples here, especially hyper-ledger areas. In terms of refiable credential format, it also can work with any format, so it's not like it's linked or restricted only to hyper-ledger Anomkrats. Although of course traditionally, in most of the implementations, in most of the frameworks, it's used with the hyper-ledger Anomkrats, it's part of indie areas. Also, no restrictions in transport, right? DIT-COMB is designed in a way that it's transport-agnostic, that it can work over HTTP, Bluetooth, NST, whatever. So essentially it supports both offline and online scenarios. The next type is the mobile driver license protocols. Well, these protocols, of course, they were designed specifically for mobile driver licenses, it's part of ISO. And as for transport, it's quite versatile. It can work over NST, Bluetooth, Wi-Fi, GPS, watching both offline and online scenarios. The next I think it's a W3C credential handler API or CHAPI, it's like browser specific thing. And also W3C has a verifiable credential API which is basically a REST API to process verifiable credential, to issue, verify, present, store them. So it can also be a nice option to achieve interoperability, interoperability in SSI and verifiable credential-based workflows. Okay, it was the second thing about how? And finally about where? Where, what kind of deep methods and corresponding verifiable data registries we can use? As I mentioned before, there are more than 100 different deep methods. You can find them in this link. I'll just mention some of them with different properties. Deepkey, it's self-resolving and ledger independent. What it actually means, that as part of deep identifier itself, we have a public key encoded. So once a receiver has a DAG, DAG stream to identify itself, they can just encode, get the corresponding public key like deep doc right from this DAG stream. So it's obviously doesn't require any ledgers, any databases, because well, it's just self-resolving. Deep peer, it's a bit similar to deepkey. It's also ledger independent. It's partially self-resolving. It's a bit more advanced because it supports some rotations, some more dynamic in a DAG document. Deep web, it's an example of a DAG which also doesn't require a ledger, doesn't require a blockchain, and it leverages existing domains reputation, resolved through DNS. Can be an option for some scenarios where, yeah, make sense to leverage existing web trust. Deep web as, it's a new extension of deep web, which uses carry, carry instead of DNS for trust. It tries to actually keep the nice properties and formats of deep web, but at the same time, best to solve some centralization data issues related to trust. Deep carry, it's carried by itself. It's quite interesting approach to SSI, also one of the, another set of corresponding specifications, standards, and implementations. And deep carry, it's a ledger agnostic VDR. It's famous that it's ledger agnostic. Did I own, did I own this DAG methods, the IDs are resolved through blockchain agnostic side-tree protocol on top of Bitcoin. There are some variations of side-tree protocols on top of other layer one blockchains like Ethereum. Also, did I own has a self-resolving option similar to did key. So for example, if it's a holder where we don't probably want to publish the DAG on the ledger, we can use a self-resolving option for did I own. If it's an issuer, maybe it makes sense to use a full version of the I own, which is resolved against like Bitcoin, Ethereum or some layer one blockchain. Did India did sovereign, it's a well-known deep methods as part of hyper ledger family, which are associated with India ledger and it's sovereign in particular with a sovereign deployment, which is the most famous, the most one of the oldest deployments of India. Did Ethereum, it's a self-managed approach for self-managed the IDs resolved on Ethereum as a VDR. It also has very nice properties in terms of gas savings, since it's a permissionless blockchain and also it has a nice properties to be self-verified. Did checked, thought checked, it's a very nice option for permissionless ledger for SSI cases, supporting multiple formats. It's based on Cosmos SDK and as a result it's part of the Cosmos internet of blockchains family. So it's, you can see that all of these methods are very different. Some of them use blockchains, some of them don't use blockchains, some of them use permissioned ledgers, some of them use permissionless ledgers. So there is a big variety of approaches there. Okay, and as mentioned before, sometimes the combinations of these variables and other variables is called a profile. Also, I'd like to know that the notion of a profile is not like just fully established definition across various organizations and working groups and not all the profiles have formal specifications, some of them have, but many are just kind of essentially a combination which are just used in practice. There is a nice link as part of Open Wallet Foundation, there's a working group which has a very nice spreadsheet compilation of various profiles and properties and variables. I would like just to mention a couple of profiles, high assurance interoperability profile. It is an example of a profile with a formal specification which has a formal specification. It's based on OpenID for refurbished credentials on selected disclosure jobs as a refurbished credentials. And well, it doesn't require usage of the AD, so it's usually just based on some row keys or well-known extension. The second profile which is also standardized which also has a formal specification is decentralized identity interoperable profile. It's also based on OpenID for refurbished credentials. It's based on Jot, refurbished credentials and it assumes this one, compared to the first one, it assumes usage of the ADs like did web, did a double key. I saw mobile driver licenses, MDL. We have seen previously that they have their own set of standards or the format of the mobile driver license for the exchange protocols. And of course, Hyperledger, Indie, Anuncrats, which usually it's a very popular combination in many areas, frameworks, many production deployments and services. They use Hyperledger, Anuncrats as a refiable potential format. They use Hyperledger areas as exchange protocol and they can use Hyperledger, Indie, yet Indie already solved as a ledger. As a ledger. Okay, so we just discussed kind of the interoperable point and before we move to the actually the demo part, let's consider what are exact values of these interoperable variables. We are going to show today during the demo and hands-on parts. So for the demo parts, we are going to have four or demos. The first one is the Anuncrats and Cardano, which shows the usage of Hyperledger, Anuncrats, Hyperledger, Anuncrats with Cardano as a VDR. It's Cardano as a VDR and Hyperledger areas as exchange protocol. The second one is Anuncrats plus check. There we also have Hyperledger, Anuncrats, VDR as a VDR type and checked as Anuncrats VDR and the DAD VDR using the checked method. The third one is also with checked, but in this case, we are going to see that it can be compatible with W3C revival credential. So W3C revival credential, JSONLD with ED255.9 signature and checked as a VDR. The rest again is an exchange protocol. And the fourth one, it's W3C with C and OpenID for revival credential. There, unlike the previous examples, we are going to see that OpenID for revival credential. Specification is used as revival credential exchange protocol. W3C revival credential is a format and for simplicity uses DIT key as a most simple DIT method. So you can see some level of interoperability and even if you're talking about Hyperledger frameworks, it's not just, you know, Indy or Anuncrats. Different combinations that Anuncrats can work with Cardano, Anuncrats can work with checked. Also, they can work with Anuncrats, they can work with W3C revival credentials, OpenID also for revival credentials is also very interesting case. So it's about the demo part. So unfortunately it's won't be interactive. So you will just see the demo provided by Renata. And the third part will be the hands-on part. It's where you'll have a chance to actually write some code and run some demo on your own. And this part will be devoted to a new initiative in the Bazoo initiative. And it's a nice initiative, not only to show that this initiative just exists, but also to show the interoperability between Hyperledger areas, Anuncrats, W3C and Hyperledger Bazoo, another very well-known framework distributed ledger from Hyperledger family. So it would also be quite interesting. Okay, in terms of the frameworks that we are going to use for the demo and for the hands-on parts. Our demo that has- Yeah, I interrupt you for one second. Before we dive into the demo scenarios, do we wanna see if there are any questions left in chat? I have one, and it seems like the person deleted their questions. So let me just check here. If you do have a question, please let me check. Can you speak a little bit about anonymity and privacy and the challenges with the various credential format types? Ah, yeah, yeah, sure. Well, actually I can answer it now. Maybe I can answer it a bit later because actually we are going to- We are not jumping to the demo right now, right away. We are going actually also to describe some of these things in a bit more detail. So maybe let me answer the question in like 10, 15 minutes. Go for it. Yeah, so in terms of the frameworks, in terms of the frameworks that we are going to use, we're going to use Credo. Some of you may remember it by the name of Ares, a framework JavaScript. As in the last year, it was moved from Ares, from Cryptology Ares to OpenWallet Foundation. And it was renamed, first of all, it was renamed to Agent Framework, Framework JavaScript, but now the latest brand, the latest name is Credo. And the Credo, it implements both bottom crates and refurbished credentials. W3C refurbished credentials, this PC formats. It also implements, of course, Hyperledger Ares. This is one of the essential parts of Hyperledger Ares family, which it was. And also Credo has support for OpenID for refurbished credentials. And in terms of FIDAR for Cardano, we are going to use AFJ, I still call it AFJ because it was AFJ extension at that time, from RootsIT, which uses Cardano as testnet and uses Cardano as a registry for non-crates. Also, we are going to use AFJ module. It's just part of the Credo AFJ main repository. It's possible to leverage checked and we are going to use testnet, of course, of checked for the demo. And we are going to use the Indie Bezu. It will be a local setup in Docker. An instance of Hyperledger Bezu is corresponding smart contracts for the hands-on part. And there is actually also an AFJ extension, which provides this functionality integrates the Indie Bezu into Credo or AFJ. Okay, and before we jump to the questions, maybe the next couple of slides also can answer some of the questions. Some more details about the formats and frameworks that we are going to touch on the demo. Credo, Credo, RS Framework JavaScript, as I mentioned, it was moved to OpenVolet Foundation. It's a framework based on JavaScript TypeScript and it can be used either as a backend web server, such as, or it can be used in mobile applications, example, React Native. And another Hyperledger RS Framework, RS Byfold, RS Agent React Native, it's based on Credo, based on RS Framework JavaScript. So Credo provides an SDK API to be integrated into web or mobile applications. And also there are some extensions. The framework is pluggable and there is a number of extensions. There are some extensions providing RS API on top of. So Credo used to be one of Hyperledger RS projects since 2019, and it was moved to OpenVolet Foundation at the end of last year and renamed to Credo. In terms of kind of the main components, functional parts, it has a wallet. There are options for the wallet, Indie SDK wallet and Hyperledger RS SCAR. Right now the Indie-based wallet is being deprecated. So Barcelona, the next release is going to, RS Oscar would be the main, the only option. Refabric credential format, Hyperledger AnonKratz is supported, double it to receive refabric credentials like this NLD, Jot are supported, Selected Disclosure GVT is supported, and also there are extensions for VBS Plus. Exchange protocols, areas, V1, V2, and OpenID for refabric credentials. The last one, it's kind of work in progress, but there are already some functionality available and we're going to show it today. And deep methods, traditionally, of course, Indie, Ledger, the Indie itself are supported, but also did peer and did check integration with the checked Ledger, it's part of the core framework, it's part of the core framework. And also there is a number of extensions, different deep methods for resolving, for registering, options for AnonKratz, and in particular, Cardano, we're going to leverage one of these extension to show the support of Cardano blockchain as an option of PDR in Credo. Okay, so then about the next frameworks that we are going to look at, the refabric credential format, Hyperledger AnonKratz, Hyperledger AnonKratz. Right now it's a separate Hyperledger project and there is a specification, there is a specification and there is also a reference implementation in Rust, AnonKratz-Rust. As a format, a certifiable credential format, AnonKratz now needs to be the most privacy-preserving format because it supports predicates, sexy disclosure, zero-knowledge proof properties, anonymous free vocation and so on. And the main adoption historically, it's Hyperledger Indy, Hyperledger Aries. It does, it's important to know because many people wondering why it's so different from W3C refabric credential, right? Doesn't use this format from the very beginning. And as for this question, because it was implemented, it adopted before W3C refabric credential standard was actually finalized. Right now, there is a way, thanks to BCGAF-CodeRes us opportunity, there is a way to represent Hyperledger AnonKratz credentials in W3C verifiable credentials. So this gap, it's almost closed, but still. Hyperledger AnonKratz, they have a custom format based in Jstone. They have zero-knowledge proof based signatures CL, combination of SEMSCA, AnonKratz signatures. So as I mentioned, recent W3C representation support, so it gets quite important milestone. And it will be maybe important for the demo part, if we need to work with the Hyperledger AnonKratz, usually we will need to publish a number of entities, a number of entities to a VDR, such as a ledger, such as Indy ledger or other ledger. The three main entities, the first one is credential schema. The first one is credential schema. Schema defines what are the fields in the credential in the claim. For example, if it's a passport, you can be like the name, surname, address, and so on. The second is credential definition, which is basically a public key, the issuer's public key. The signature, since it's based on zero-knowledge proof, it's a bit non-standard. Yeah, that's why it's like a specific format for this public key and credential definition representation. So credential definition or possibility you can consider it just as an issuer public key. And the third part, I think we won't look at it as a demo, but usually if you need a revocation, the revocation registry, also set of keys, set of corresponding data for accumulators, it's also usually published to a VDR to a ledger. Just a slide about the history of iron crates. I think it's just quite interesting. So initially, initially, hyper ledger iron crates was just part of a hyper ledger Indie and it's in production since the sovereign mainnet is launched in 2017, so it's like almost seven years. And it was part of the Indie crypto. It was a separate project to maintain iron crates and other things are required for Indie. And it was adopted as part of Indie SDK and Indie ledger. Then in 2018, dedicated hyper ledger earth subproject was established. So it was considered to be as a common place for a crypto as part of hyper ledger. It's replaced Indie crypto and STL iron crates implementations, limitation of these zero knowledge proofs were moved there. Right now hyper ledger is deprecated, but yeah, there's a number of other dedicated repositories in hyper ledger which are still implement this, provide this functionality. And in 2019, the hyper ledger areas appeared. It initially mostly used Indie, many of these frameworks used Indie SDK and Indie ledger and as a result of these hyper ledger iron crates. And in 2022, the hyper ledger iron crates separate project appeared. So the goal of this project was to actually create a specification of iron crates, very detailed the standard specification and also have a ledger agnostic implementation of iron crates independent of Indie, independent of areas. And the good results of this characterization that we are going to see on the demo or because of this we can use iron crates not only with Indie, but also this Cardano is checked and any other ledger which implements the corresponding interfaces. That's kind of a history of evolution of hyper ledger iron crates. Okay, the second format that we are going to see during the demo presentation part, it's like the most well-known, the common W3C refurbished credential. There is a current model version one which is the recommendations since 2022 and there is the working draft for model version two. As a sterilization, it uses JSON and JSON-LD with link data, context and semantic. For proof formats, it can be either data integrative proofs which can be considered more or less like common standard signatures or JOTS JWT format, JWS standard is leveraged. And as I mentioned before, SD selected disclosure JOT which actually extends the JOT to provide some nice privacy features in terms of selecting disclosure. Crypto signatures, it can support BBS plus as more advanced, direct disclosure support it, cryptography or it can use some standard traditional schemas for signatures like ECDCA, D2 curve, RSA, EDDCA and so on. Just an example of how a refurbished credential can be presented as a W3C JSON-LD format with data integrative proof and ED25599 signature. On the left side, it's a refurbished credential and on the right side, it's a refurbished presentation. The refurbished credential, it's what is issued and signed by the issuer and stored on the holder side. And the refurbished presentation, it's what is derived from the credential and shared with the verifier, with the verifier what is presented for verification. So what is important here, since it's JSON-LD, it has a context which introduces some semantics, some meaning for the fields. It contains an ID of the credential issuer. It example, this one, 49, it's a DAD of the issuer and we can resolve this DAD and find the corresponding public keys which were used to sign this refurbished credentials. And that's actually what the verifier does. We have the claims about the subject of the holder, like ID and some name, for example. Name, contract number, it can be address, whatever. And you can see this ID, it's the ID2 if you remember it in the very first example that they gave at the beginning of presentation. It's actually the ID of the holder, the ID of the holder. And of course, the proof, it's just a signature made by the issuer. It's made by the issuer. You can see the verification method. It's a method from the issuer's DAD. It's a signature by the issuer. Now let's look at the verifiable presentation, what it has, it has a verifiable credential. Kind of, we can assume almost as is, as on the left side. So the verifier can see the issuer to issue the credential and it's the DAD also of the holder of the subject of the credential. Since it has a verifiable credential, it obviously has a proof signature from the issuer, signature from the issuer here. And also in addition to this, it has a signature by the holder, it's kind of proof of key possession, proof of ownership. We kind of making sure that the credential issued for this particular DAD for this holder, it, the presenter actually has access to the corresponding private key, has access to the corresponding private key and can create a signature. Usually during issuer, the issuer may also ask the holder to prove the ownership of this DAD so that the issuer can make sure that the credential is issued to arrive to the correct owner of this identifier for this DAD. So that's a standard representation, some examples. Okay, the next part is exchange protocol that one of the protocols that we are going to use and see during the demo is hyper larger areas. And what is important, also one of the myths that hyper larger areas is some particular framework like ACAPI or AFJ or wherever go. And well, of course it's true, all these grad projects are part of hyper larger areas. But what is important areas is also a set of RFCs, a set of protocols, specifications which kind of define these protocols and multiple frameworks, they can implement these protocols. The very same protocols can be implemented by areas VCX, ACAPI, AFJ, and so on. Of course, there are also tools for interoperability. And if you look at these protocols, these RFCs, they are DITCOM based, but it means that DITCOM is a secure private communication methodology built at the decentralized design of the agents. So usually it's kind of a peer to peer communication, transport agnostic can be run against any on top of any transport. And it establishes a secure channel, a connection between two agents, for example, two wallets. Each of these wallets may have a DAD like did one, did two, the corresponding keys. And these keys are used for encryption to encrypt the data, to encrypt the data. Sometimes it can also sign the data if some non-repudiation properties are needed. And the protocols, they can be run on top of the secure channel, on top of this DITCOM. DITCOM, there are two versions, V1 and V2. V1 was developing as part of hyperledger areas, hyperledger areas RFCs. DITCOM V2 is being developed as part of decentralized identity foundation, decentralized identity foundation, but it's also being implemented and leveraged by many hyperledger areas frameworks as well. And so, yeah, DITCOM is kind of a channel, communication methodology, and on top of DITCOM, we can run any protocols or state machines. DITCOM.org website, you can look at it and it contains a list of various protocols. And one of the main, the most important and well-known protocols which are run on top of DITCOM are revival credential exchange protocols. So like exchanging issuing credentials and presentation of credentials, it can be formalized as a protocol. But actually any other custom protocols can be implemented like any state machine and on this website, you can see other examples, not only related to revival credentials. There can be even a composition of protocols. For example, an exchange protocol can be just part of some interaction where credential needs to be issued or presented, but there can be a higher level logic which may be implemented as a state machine. For example, a game or I don't know, almost many things in the real world can be represented as a protocol. So it was about like the hyperledger areas, part, DITCOM exchange protocols. And yeah, one more thing about hyperledger areas, it's areas interop profile. As I mentioned before, it's very important in areas. It's not just some random framework unrelated. We, areas actually cares about interpretability quite a lot between the implementations of the protocols, there are some tools, some test frameworks to make sure that it is there and there are profiles kind of a combinations of areas, protocols, areas RFCs which needs to be implemented to satisfy this interop profile. Currently there is a V1 and V2 profiles. As part of V1, the goal was to be able to establish connections like connection protocol, as part of DITCOM, exchange credentials and presentations via connections like issuance and presentation protocols and also be able to complete a connection less proof request, proof transactions. As part of V2, V2 is more advanced. It has improved UX. It allows to reuse existing connections out of band protocol. It improves how connections are established, improves how the issuance and presentation are done and other things like multiple ledger types, multiple refurbished credentials format and so on. Okay, so it was about hyperledger areas. Then about the next change protocol that we are going to look at the demo, it is OpenID for refurbished credentials. It is an OpenID for refurbished credentials. So first of all, let's just consider high level difference between the common OpenID connect and OAuth and the OpenID for refurbished credentials. So in the common usual OpenID connect protocols, we have like the issuer or some identity providers which provide the information about the user's identity to the verifier. You can see this arrow. So it's actually the protocol that's for authorization OAuth for authentication, OpenID on top of it, where the folder authorizes the verifier to access information on her behalf. We have some identity providers, but OpenID for verifiable credentials, they support self-storing identity credentials change where there is no more this error, this communication between the issuer and verifier and the holder, the holder can actually provide the credentials on their own. So it's actually cloded to the concept of self-issued identity providers because if we have a verifiable credential on the holder side, then the holder can also be considered as an identity provider. There is no need for any mediators anymore, but still other kind of many other properties so the protocol can still be there and OAuth or OpenID connect can still be a basis for this exchange information. So just let's look at these three main standards as part of OpenID for verifiable credentials. The first one is what is needed for authentication is self-issued identity provider. And it defines how the holders can authenticate in a self-storing way without any actor. So they can issue a special type of token, no need to communication with any external parties, no need to communication with the issuer. So in this case, the self-issued provider is the holder itself. And usually these protocols can work together with a presentation protocol. It defines some mechanisms on top of self-issued provider to allow the presentations of claims in terms of verifiable credentials. So the first approach we just defined that it's possible to leverage the holder itself to present some information. And the second thing it's actually leveraging the verifiable credentials to present them. There are multiple options for this protocol. It can be like same device or it can be cross device. The workflow can be, the UX of course can be a bit different, but yeah, essentially it's the same protocol which works on top of OAuth for OpenID Connect. And the third protocol here, the second group for issuance, it's OpenID for a verifiable credential issuance. And it defines a way, an API, and based on OAuth and corresponding endpoints which can be used to issue every verifiable credentials. There are also multiple options in this protocol with a pre-authorized code or without it, depending that if it's the wallet initiates the issuance or it's the issuer, for example, website initiates the issuer. It can lead to different UI UX, for example, just a QR code to scan or the issuance is done from the wallet is started from the wallet. And of course, some steps in the protocol can be different, but essentially yeah, it's still OAuth-based protocol where Nexus token is received and can be used to actually receive the credentials. And also again, I would like to emphasize that it doesn't, but it's not restricted to any particular type format of refurbished credentials. So any refurbished credential format can be issued or presented with these protocols. Okay. And finally, let's consider the last set of variables. It's verifiable data registry where variable. And we are going to see in the demo three main options for VDR, not main, but the two options that we are going to show today. It's Cardano, it's checked and it's HyperledgerBezer as part of IndieBezer Initiative. Let's start with the Cardano. Cardano, it's a public permissionless blockchain. It's quite popular blockchain. It was one of the first ledgers which implemented and adopted a proof-of-stake consensus protocol of course much earlier than for example, Ethereum moved to proof-of-stake. Some of the properties of this blockchain that it's pure, reviewed and has the verifiable security can be used in different applications for smart contracts, the decentralized application, DeFi, DAO, NFTs, and SSI. And they have a main net since 2017. So it's quite well-established and popular option for a permissionless blockchain. As for Cardano and SSI, we're going to base our demo on IFJ extension to use Cardano as an Anarchrath registry to publish schema and credential definition. So we're going to show the interoperability between Cardano, Pridog, XFJ, and Hyperledger Anarchrath. And it was based on the work by HOOTSID, this extension, this plugin. Also, I'd like to mention that there is also a project which is part of now Hyperledger Labs. Used to be called Attella Prizm, now it's open source test Hyperledger Labs as open enterprise agent, which is also one of the frameworks implementing SSI principles and having integration with Cardano. In terms of the standards, W3C revival credentials, which is also what is present in open enterprise agent and Hyperledger Anarchrath is part of Credo and has been supported in open enterprise agent. The second VDR, the second ledger blockchain that we are going to look at today, it's checked, it's checked. It's a public permissionless blockchain. It's based on Cosmos SDK and Tendermint, now it's CommandBFT, BFT. It's a pub application-specific blockchain, there's any blockchain written using Cosmos SDK, which means it was created specifically for decentralized identity SSI use cases. It also has a proof-of-stake consensus protocol and the main net since 2021. It has some very nice SSI features, of course it has its own DID method, did check, you find how to resolve the DIDs on the checked public permissionless blockchain. So also checked can be used not only for DID resolution, but Anarchraths registry supports Hyperledger Anarchraths, revival credential format. So both W3C revival credential and Hyperledger Anarchraths are supported. A very nice feature is a dint-linked resources. It's possible to use checked ledger to link any resources. For example, Anarchraths entities can be also considered as such resources with any DID, with any DID. And universal resolver support. And we are going to just use the package, checked package as part of credo, as part of credo. So it's just essential part of credo or AFJ, which is available right in the repository. It's just another good example of interoperability between Hyperledger, non-Hyperledger, open wallet, and so on. And the last video that I'm going to look at today, it's Hyperledger Bezu, it's Hyperledger Bezu. And they're going to look at the Indie Bezu initiative, but before we move to Indie Bezu, let me tell you a couple of words about Hyperledger Bezu. So Hyperledger Bezu is a graduated, active Hyperledger project since 2020. It is Ethereum client written in Java and it can be used for two use cases, for public networks, such as the public Ethereum networks and for private permissioned networks, such as enterprise network or supply chain ledgers. Depending on the approach, if it's public or private, there are different internals like different features, different consensus protocols. For example, Bezu supports private transactions, which is very important for private cases. Also, it includes several consensus algorithms, several consensus algorithms. For public networks, it makes sense to use proof of stake or proof of work previously, which used to be leveraged by Ethereum. For private permissioned cases, some type of proof of authority consensus algorithm is usually used, for example, IBFT, QBFT, click, where IBFT is a recommended one right now. And proof of authority, it's the consensus algorithm, which actually defines as part of permissioned network what nodes can perform a validator role and we can participate in creation of new blocks, unlike permissioned less networks where anyone, almost anyone can run a new node and you validate it. So what else? The business logic, the business logic in Hyperledger Bezu is written as smart contracts, as Telerity, Ethereum smart contracts. Also Bezu has a very pluggable architecture and just an example of private permissioned use cases where it can be used as CBDC. It's a popular example and Bezu is being adopted by a number of banks, for example, in Brazil and Norway to implement CBDC solutions. The supply chain as any permissioned network, Bezu or Hyperledger Fabric, the supply chain, it's a very natural use case. And the sell certain identity, yes, we all see, it can be a nice option for sell certain identity because, well, permissioned ledger, it's actually a valuable, reasonable option for sell certain identity use cases. In some cases, it may be okay to use permission less ledger if dealing with the tokens and proof of stake is not a problem, but in many cases, and that's actually, that's why we have Indieledger, public permissioned ledger is a better option because it can provide, it doesn't require dealing with the tokens, it can provide more even trusted requirements, especially in government specific cases. So Indie Bezu, Indie Bezu, it's a new initiative, which is currently in progress. So it's part of Indie and there is a dedicated repository Indie Bezu repository. It's a public permissioned ledger for SSI. So it's essentially the same as the current Indie node. But unlike Indie node, it uses Hyperledger Bezu for the blockchain part. Just a bit of history, Indieledger, as you've seen, it was created like almost seven, eight years ago, and at that time, there were no good options, production-ready options for a public permissioned ledger, consensus protocol and so on. That's why Indieledger contains not only the business logic required for SSI, like DAD, Simon Krets and so on. It also contains the whole framework for distributed ledger. It contains a custom implementation of a consensus protocol, RBSD consensus protocol and so on, which of course makes maintenance of Indieledger the code base quite huge and the maintenance non-trivial. So the goal of Indie Bezu is actually to reduce this complexity significantly. And instead of maintaining and supporting a custom consensus protocol, RBSD-based consensus protocol is part of IndiePlanum, we can leverage another framework, which is specifically built and maintained for these purposes. And Hyperledger Bezu is a nice, nice option here. So in Indie Bezu, the whole bunch of Indie, like IndiePlanum, is replaced or the core blockchain part is replaced by Hyperledger Bezu and SSI business logic instead to be like application-specific and written in Python. Now it's written in Solidity Ethereum smart contracts, which is quite compact way. It has a good level of adoption, I mean, Solidity and so on. I'd like to note, of course, it's not an official replacement of IndieNow. It's just an experimental initiative. It's just an experimental initiative. It's been discussed, evaluated by the Indie community because everyone is welcome to join. But yeah, we already have some PUC, they have an MVP that can be shown. So what IndieBezu also has, it has a client library, a VDR library, it has integration with Credo, it is framework JavaScript that we're going to see in a moment. In terms of SSI features, it has support for unencouraged costs, unencouraged registry, and also it has support for W3C refurbished credentials. It's also a nice extension. The old Indie Ledger didn't work, doesn't work with the up-to-date standard of W3C refurbished credentials so IndieBezu can do it. And in terms of DID methods, right now IndieBezu has a support of DT Ethereum. It's like a standard method for Ethereum-based networks with nice properties. And also there is work in progress of a separate methods, which initially we called it Indie2. Maybe we will rename it to IndieBezu. It's maybe a method which will be a bit better in terms of migration of existing data identifiers in terms of permission networks and so on. And about like the history of this project, this initiative was proposed by DSR in December, in September last year. And in November, we had the first PVC for experiments for discussion. So this initiative is being discussed by Indie community and the code is now moved to separate Hyperledger in the repository IndieBezu and there is ongoing MVP work discussions and implementations are continued. Okay, so I think that's enough or even more than enough information before we jump to the demo part. And I think it's the right time for questions before we move to the demo. Awesome, thanks, Alex. I will maybe work backwards on some of the questions that did not get answered. So Leonardo posted, is it possible to interoperate with authentic chain data containers, ACDCs and verifiable credentials data model V2 mentions the compatibility, but you have VC exchange samples that use AC, do you have VC exchange samples that use ACDCs? Well, no, as part of our today presentation, we don't cover ACDC and carry based things. So it's a bit out of scope right now. Yeah, they use a bit different standards in some ways, but for example, did carry it's one of the DIDM methods which is compatible to DIDM method specifications. So even that, there is of course, some level of interoperability. As for ACDCs, I think it's a bit more challenging. But, well, you see that even in case of FUN and CRATs and W335 or credential, we already have examples and just examples of code, the working code, which can be used to represent ACDCs in W335 or credential. And for other methods, it's also not that complex to implement it if needed in some cases. Okay, thank you. Raganash asks, can you explain a little bit ZKP and ACDCs? What are the entities involved? How are ZKPs, zero knowledge proofs generated and verified? Yeah, I will try to just briefly explain because it's quite a complex topic, but still. So, what is important there? That on the holder, on the holder side, there is a concept of linked secret. It's not a usual standard private key, but let's consider just some secret which actually links multiple credentials together and links these credentials to the holder. During issuance, during the issuance, this linked secret is presented to the issuer in some blinded form, not SES. And the issuer issues a credential like the claims itself and this blinded linked secret in a specific form. The secret is quite complex. Currently, it's a restate-based signature for the main claim and select curve-based for revocation. For revocation, it's a separate signature. And then, what is the most interesting and important here? That when the holder presents, creates a very favorable presentation for the verifier based on hyperledger and on crates, the holder doesn't disclose, it doesn't present the credential as is. Unlike, for example, many cases in W3CVC where credential just sent to the verifier SES plus some data. There, the presentation or proof to the verifier, it's a new entity. It's a new entity derived from the credential and created by the holder. And it's created depending on what fields needs to be disclosed and what predicates needs to be proven. Based on this information requested by the verifier, the new entity proof, a new blob is created and sent to the verifier. So, verifier can check the corresponding signatures and the verifier doesn't know too much, the verifier just knows what they requested, the disclosed attributes and the predicate. But since the signature is unique every time, the proof is unique every time, there is a nice property which reduces to remove correlation, right? Because in a traditional signature, the signature is always the same, right? So it's one of the ways correlation. But there, the signature is unique. It's always the zero-knowledge proof, kind of non-interactive zero-knowledge proof. That's why it reduces that correlation, it's more privacy-preservant. So it's, first of all, it supports related disclosure, we can disclose only part of the attributes, the second predicates, we support predicates, the third, the signature is unique every time. That's why it's very hard to link this in terms of the signature, it's impossible. And the fourth thing, revocation, it's really advanced technology for revocation is used based on accumulators. It's also anonymous so that the verifier doesn't know and even if you look at the ledger, we don't know what exact credentials are. So anonymous revocation, it's the last thing. So if you're interested in learning more, there's an anchorage pack and there's corresponding mathematical paper as part of URSA and the libraries which get the first all the necessary formulas and details, how it works. Cool, thank you, Alex. AAA has a question, what are the best points of research on key management? It might be out of scope, but authentication threshold signatures and end user distributed storage backup, I expect, is part of the landscape somehow? Yes, it's also important, it's also quite important things that can be part of any profiles which may define some standard ways. So first of all, what is important that the keys, especially we're talking about the holder side stored in the user wallet, which can be mobile wallet or it can be some cloud wallet. And here there is also no just one standard approach. It may be different and some approaches they may require usage of some hardware, hardware secure modules, some wallets, the properties of operational system are used, especially on mobiles, securing clays can be used. Regardless of the approach, of course the wallet needs to be secured, the data needs to be encrypted, the keys should not, some best practices should be applied, should not leave any memory and so on. As for backup, as for backup, it's also very important thing in SSI because well, it's a natural question what happens if the holder loses the wallet, the wallet is lost, what should be done. And of course, one of the approaches there is just to reissue all the credentials. A second approach there is to do some kind of a backup. There are some techniques which try to kind of link the backup recovery with biometric, with user biometric and the general access to this wallets can be linked to biometric. But yeah, there is no just silver bullet, it's kind of multiple usual best practices for key management and wallets. Plus it can be specific for particular use cases, operational system, environments, profiles and so on. Awesome. I think we'll take one more question then we'll jump to maybe take a three minute break and then get into the demo, Alex. VC presentation has the signature of the holder. This VC presentation can be used by verifiers to misuse this holder to other verifiers. How to basically prevent this type of impersonation as the holder? Yeah. Well, the thing that this usually a new signature created for every new verifier. So it's science against some nonce. That's why it's a fresh new unique signature, right? It's one thing. The second thing that of course any credential can be used in a malicious way if it's not linked to biometric. For example, if a father provides access to his phone to a son, then son can use all the credentials of a father, right? That's it. But the usual way to prevent this situation, it's get a flavorage in some biometric in addition to just claims, right? So it's actually applies the same in the case of verifier. If for example, a photo or some biometric providers are involved in terms of verifying fingerprints, then it's not easy to reuse the same data malicious. So two things. The signature is always the same every time. Plus usually in many cases, some additional checks are required such as biometric to link the actual credential to a particular owner or the holder. Okay. Let's take a three minute break in case anyone needs to use the bathroom. And then we're going to get into the demo. IS, I do see your question there. We're going to try to get it answered when we start up again in about three or four minutes. So it right now is one of three my time. We'll see everybody at one of seven. So three minutes, Alex, and we'll get going again. Okay. In case you got to use the bathroom, we're going to cup of water or something. So hope everyone. And we are back to recording. I'm going to stop sharing. And Renata, you now, let's take it away. Great. I understand that the first part was long and productive. So I hope you have had time to be a bit free. So let me share my screen and show you some magic from credo, not just areas framework, so script. So what starts, let me share my screen. I'm not sure you see everything. So what are we going to? So Renata, we're looking right now at the demo deck. We're looking at your PowerPoint. PowerPoint? Yes. I'm seeing PowerPoint with demo scenarios. It is really strange. Well, it's okay. And the usual puzzle. So I try to share the whole screen. Is it successful Troy? So again, we're seeing- Yeah, yeah, because it's a whole screen, but the current window is a PowerPoint. Is it? Oh, yes, yes. Great, great. I just wanted to mention what we are going to see. You got it. Thank you. So firstly, we want to issue credentials, unincorrect credentials, throw cardana and checked daddy documents. And also we are going to issue double through C credentials, throw checked daddy. And also the most interesting point, it is issued a credential, throw open ID connection protocol. From my point of view, it is a reason why now we don't need to pronounce the whole areas for work JavaScript and just have credit. Because it is not only areas protocols now, but also open ID connect. So, let's start and let's start Faber University, like an issue, and Alice who wants to get a credential from Faber. Okay, as a first step, we need to create a peer-to-peer connection between Faber and Alice between issue and credential and holder. So, let's create a link to have an out of band connection. So, connection is established, it's been established. Now, on the whole, on the issue side, let's set up an issue. For example, we can create a DID and schema and credential definition. One creates for DID-Indy. I think it is a common case and most of you already saw this. So, we create a DID, schema and credential definition, for example here in a British Columbia testnet. So, we can check this and it will be already on the ledger. So, but we are interested in setting up, checked DID-Indy. So, and also schema and credential definition. Well, the damage is always something wrong. Sorry, something wrong, the connection, sorry, let me try again. Oh, I can tell you about this error while we are waiting. Account sequence mismatch. It is an error of using Cosmos SDK CLI but fortunately, they have this issue, still have this issue. It is an issue of comparing the current data on the different nodes. So, we spend a lot of time trying to fix this but I'll start to recommend it as just stop this. So, establish the connection. Let's set up an issue. Hope now it should be okay. Sorry. I'll be there the third time, it will be okay. So, sorry for this technical issue. I just went in so many times with your diploma. So, let's create a connection. Let's start with an issue and let's start with INDI like an original DID-Indy. And during this process, we can create an issue ID. And let's start checked. Looks like finally we won't. Yeah. So, we can check this identifier through Universal Resolve. So, we can check that it is already on the led room. So, and to check a specific data like schema, we can use the API or the referencing. Unfortunately, right now the referencing doesn't work for Universal Resolve but with other tools, I believe it will be available soon. So, we see a schema that we created on the led room. So, it is the name of schema and it is a version of schema because schema is an immutable entity and if you want to create, to change something, on your credential schema, you need to create a new version. It's required because if we, in theory, have a possibility to change attributes in the existing schema, all old issued credentials will be an issue, sorry, because of these changes. So, and it is the same for credential definition. Credential definition contains an issue of public key to sign a credential given issuing. So, a lot of words, let's start to issue credentials finally. Let's offer a credential, anonymous credential and indeed credential, throw checked DID. So, Alice got a credential, got an offer firstly and secondly accepted it and got a credential. So, it is a name, degree and date of issuing of these documents. So, also we have an issue ID here and we can see that it is checked DID of this credential. So, now let's issue the same type of credential with Cardano DID, let's set up an issue this DID Cardano. But in fact, it is did key as we know. So, and we also can check it's on the ledger where universal it is over, long pink. While we are waiting, I can show you, for example, Cardano Explorer, so there are our transactions and let me update it with our DID documents and so, for example, and checked Explorer with our last transactions, it is not our last one but there are some ledger create resources from us. So, let me show. So, and finally, speaking about Cardano, yes, it is resolved. It means that we created DID key, we created DID documents by average from our X areas from our JavaScript and we put this DID documents to Cardano ledger with this identifier. So, now let's offer credential, unincorrect credential with this created DID. So, let's accept it from any side, from the holder side and we can see almost the same credential because it is the same unincorrect credential type but with another issue ID. Now we have another method and it is the DID that we created and checked right now, previously. During this issue setting up this issue, we created also schema and credential definition on Cardano ledger. So, now when we finished with unincorrects, let's create less issue credential, double through C credential. Let's start with the DID checked and let's offer this type of credential to Alice. So, Alice can see a credential preview that she can accept and get this type of credential with, for example, degree and some description of this document. So, credential received means that everything is okay. Also, we can offer credential, sorry, we can already created this credential, sorry. So, we also can set up issue for double through C credentials through DID key, like we did it for Cardano. And now we offer credential, this double through C credential. So, we also have the same preview because it is also double through C credential but here we can see another issue ID with DID key method. Let's accept it and throw the errors protocol, we should receive this credential from the issue. So, just an overview, we created four types of credentials. In general, first type, it was unincorrects with the issue based and stored in checked ledger and in Cardano ledger. Also, we created two credentials, refurbished credentials of double through C type with DID documents, issue of DID from checked ledger and with issue of DID from Cardano ledger. So, and the last item of our demo here, it is another new demo, we, no, let's be clear. So, it is another type of demo, it is another type of protocol, this open ID connection with refurbished credential protocol. It is just in progress and implementation right now, we used just a feature branch for this demo. So, but it is, it works and just some preparations are needed. Okay, I believe you remember about Faber and Alice but now we just have boring issue, issue and holder. The logic of issuing a credential here will be the same, just another protocol. We don't need to make an additional step here for creating a connection, we just create a credential offer from the start. But let's say university credential and as for out of bands in Alice from war, Alice protocol, we just create this one offer and use it for holder. And now we can see this credential preview that's issue offered to holder. So, here we have formats, GVT, verifiable JSON, there's a type of this credential, so types of credential general. And holder can accept this credential offer, divide which one and look at the whole credential on the holder side with all signatures and so on. I want to emphasize here IDID on the credential subject and of course a date through right now. So, this credential was created right now by this issue. You can see that there are different identifiers because in theory for this demo, it may be an identifier or new identifier of holder. Like an example. So, that's it with demo, I do have any questions. So I believe my colleagues help with questions in the chat and I wanted to say thank you for this hot discussion in the chat, it is the first time I remember this a lot of questions and a lot of answers. Okay, is there are no active questions about demo? I will be happy to continue with the third part of our event, so and I suggest you to code a bit. So I am ready to start from the scratch with you. So here I have a wrapper, let me post, thank you. Let me pause the link. Here you can find set up script for setting up the whole environments and steps for reproducing demo with Indy Bezo if I speak not to clear and transparent. So let's start from the first step. Our goal for this workshop, hands on part is creation demo for issue a credential, anonymous credential, anonymous credential and double-thrucy credential throw credo errors for JavaScript. So let's start from creating a workspace. Whoa, whoa, whoa, not so fast. I suggest to use visual codes and now while we are waiting for creation, usually it is fast enough. Let me copy this link to chat, so it is already created. The first thing that we need to do is set up an environment. So here we have a set up script and nothing more to be sure. We need, we have to use Suda and send it unpleasant a bit, but we use Gitport environment and also we have to install some libraries. There's a reason of using Suda here. So I want to describe what we are going to do with this script. So firstly, we need to set up in Debezo ledger. So we clone it and execute run script. So here we can see that a lot of different pages were created. For example, this one, it is Prometheus as far as I remember. Where you can see metrics for in Debezo ledger. Also there are not this one. One of them anyway is Grafana. So in Grafana you can look on the progress of your ledger, local setup. So I want to open it here. Let's say instead of BigDipro. So let's open the first dashboard we have for Bezo overview. So here we can see some information about validators. So after some time here we will have more data about a progress and block time and ledger specific data and metrics. So and also we have an explorer. Right now it is in progress. So some data not configured. So let me check. I believe it should be somewhere here if it works. No, sorry. Let's check once it started. I even know why sorry. It is because we run it without B key. So if you want to have explore on your local setup, add here this key. So hope you had enough time to create a workspace and to set up an environment. Also in the script we created the clone areas from work report. And now let's try to do something without demo. So before our workshop, I have broken this demo absolutely. To make it possible to code with you the most interesting part of this demo. So these removed parts you can find here in this file. Demo, source, favor, TS. Because it is a file of issuing different types of credential. And also other place where we store data on the ledger. So let's start with DID. I hope it was removed here. Because of a lot of red, I believe yes. So let me continue with our presentation. Here we are going to use an uncred credential and W3C credential and implement this part where we need to issue a credential. So the first time that we are going to implement is storing DID documents on the ledger, on the base ledger. What is important? Right now we use the Ethereum, DID Ethereum method. So also we had the Indie2 method but decided to change a logic of implementation here. And right now we are designing IndieBasil method. But let's start with the Ethereum because there's well-known method. And so it is easier to understand what is going on. So let's start with DID creation. I believe here in the code you should have a place where we create a DID document. So the first place it is here where we create a key firstly. And after this, we have to create a verification method. So let me check one moment for our demonstration. It is about grid history to be sure that we are on the same branch. So I need to check address from John's script. Good luck. Okay, it is a current branch but it looks like we can use more actual branch here. So let me check the script. The best demo, yes, I believe we can use another link here. So to make it more actual, let's change the tab script to another one, WorkSpaces. So let me find another one. So this branch, and let me change this link. Make it fast on the GitHub. Okay, now you can pull a new script or just change the branch here to another one. So let me share a new branch. There it is, like this for address from Work job script. So and now let's change branch here for our demonstration. I'll remove a address from Work wrapper to maybe clean up some data to be sure that I have a cleaner environment. Okay, and set up the script again. Now let's back to our birth script. I don't know why it is red, but no. So, and back to our creation of data documents as we start. So it is here. Frankly speaking, it was a change of branch to remove already existing code. So hope everything's okay and you had a chance to change this branch successfully. So let's continue with the code. Now we want to create a DID documents by creating a key, throw an agent, putting this key to an agent wallet in address from Work job script. And after this, we are going to create a Bezel DID document using specific Bezel, Indie Bezel plugin inside areas from Work job script using Ethem method and using verification key that we created right now. Here is the key that we created here. So I can just put it, but I understand that it will be too demanding not to share this code with you. So let me share this in the chat. Also it will be available in presentation. So if it is to, so here we created a DID documents and so on the next steps, we create schema and credential definition. But it's, in general, it is the same. So let me show this place of creating a schema. We get to a schema method, create a schema, it is unincreased entity on the little. And here where you use a specific module, you can register a schema on the little and also in areas from Work site. So the same for credential definition. Dental definition, we register it inside areas from Work and also on the little sites. It is possible not to use a verifiable data registry for storing these entities, but as we discussed in the chat, it is a question of trust. So it is better to store them somewhere to make it possible for checking these entities and this public key on the ledger like a blockchain distributed storage. Instead of checking it from the one agency on the sum, areas from Work JavaScript based agency or something else. So now when we created a DID documents, being me, if you have any questions right now or troubles on these steps, or part of things okay. So we want to create a credential definition. We want to issue this. So for issue the credential definition, let's visit the next empty place. Here in the method of issue unincreased credential, we are going to add some code. So firstly, we have to create a credential. So still Alice want to get a diploma with some degree and with some data of finalizing her work at Faber University. So let's create a credential. Firstly, this is pretty simple. So the most interesting and important place here maybe a credential definition identifier. So based on data theorem DID that we created. So and after creating a credential, we need to offer it to a holder. So let's create an offer and let me put this code to chance. This for creating credential and it is for offer a credential to a holder. And also at the same method, we have to wait Alice answer for this credential. The connection record, I'm not sure why. Visual code doesn't look good. Right now, but I believe everything will be okay after the installation. So and anyway, we can set up your installation a bit earlier. So let me step in environment a bit. So I hope this time was enough to put code examples to un-create creation. And let's continue with just know the credential. So it is a double three C protocol. We will use double three C protocol for each one credentials here. So there are samples, the same in general, because we have to create a credential, but with another fields with type because it is just know the credential and we need to follow a strict structure. But thinking about offer credential, it is almost the same just with another connection record ID because it is a new connection and there may be the same protocol version, the type of this credential and signature that we are going to use. And also we have to wait and for answer as usual. So let's create a credential here at the start after getting a connection. So let's create a credential offer to Alice. So during this construction, execution of this construction, offer credential will be sent to Alice. And now we need to wait and for answer. So let me post it to chat. The same three parts. Finally, that's it. We created the ID documents. We implemented credential issuing for ungrads and we also implemented issuing for double three C credential here. So let's try and look, was it successful? So if you have any questions, please ask. So I will be happy to help you if you have any issues with this coding. So we need, firstly, what steps were here? We installed a correct version of node and after this we executed here in install to get all libraries that we needed. And now we can start Alice and Faber as we saw in previous demo. So in general, okay, it's okay. Just some troubles with, let's check. We build a signature, it's okay because it is not included in our demo for now. So let's stop Faber and also let's start with Alice. So here we can choose what type of credential we are going to issue. And let's start with unincorrect credentials. So firstly, we have to create DID, this code that we implemented to store DID document on the ledger. So let's create DID documents. Let's start with Indy. I feel that it is always a good idea. And let's create DID Ether. So here we created DID documents and put it to DID Ethereum, put it like DID Ethereum DID method, DID documents to Indy Bazaledrum. So we store it on the ledger. As far as you remember, on previous steps, we set up Indy Bazaledrum here, the orange tab script. And now I have a connection and can put this document to the ledger. Now let's create a schema code with this soul. So some troubles, let's check maybe some code issue at last. Okay, ledger is available, but something is wrong. Let's start maybe restart it. So and let me check. Dedication maybe we lost an account after this. It is a good moment when you can share your emotions and your progress. Do you have the same issue with ledger connection or no? Yeah, I think the error is that sender account not authorized to send transactions are probably something they're all signed to the sender. Yes, it might be the wrong issue, but we changed permission on the ledger for this demo to allow everyone to write. So maybe let's check this moment in the tab script. It looks like it was something wrong with my last commit. Sorry, let's change this branch which should help, I believe. This here should be, the branch should be okay, but let's try another branch. Thank you, Alexander. So let's try to change the tab script. So I believe we have to use firstly, let's stop the current ledger. Because remember I deployed it with explore last time. Let's firstly start with the ledger part. For this, we need to visit. This error, I believe I saw it is really wrong branch. And the node, and the basal. Because we last time, we changed network scripts. We changed a wrapper for in the basal because firstly we deployed it to in the node. And right now we have a separate wrapper on GitHub in hyperledger in the project. But within you code. So let's stop it and remove this for anyway. Let's remove it, let's try from another place. Because we started it from the root directory. So suggest to use that caches. So and now let's remove this data. Okay, so I suggest to change a branch to a new one. Let me open it in a new window. So a new wrapper we placed in hyperledger is here. And the correct branch should also here. It is a new branch that you can check out for the ledger part. And let's use it for our codes. Oh, sorry, we didn't remove a wrapper. And let's stop on your version of our code. So give me a second. So while we're waiting, let's check explore for now. It is still in progress, I believe. We need some time to set up and explore here. Oh, the export, okay. Anyway, let's back to our demo. Oh, it is explore where you can see. For example, transactions. The list is empty right now because we didn't create any DAD documents and resources. Let's do it right now. Let's restart Alice and let's start Barbara. So by different steps, it is the same demo that we saw. And here on slides, if you want to try it after this call, there are steps that you need to execute to issue a credential. Let's try again with a new ledger and that's to get your schema. Okay, now it was successful. And it was a good point where we could see that without a good connection with the ledger, we can create a schema. Now it is created. And now we have to create a credential definition. Also on the ledger. So by some time, a transaction will be loaded. So and you'll see new transactions here. So we created a credential definition on the ledger and now we have to issue a credential. For this, let's make it comfortable and let's create a connection between Barbara and Alice. We created a connection invitation like in the previous demo. So connection established. And now we have to offer a credential and press credential for Alice. Alice received credential offer and can see what is inside this offer. Inside this credential and accept credential. So Alice got a credential. And now we can request a proof for this credential. Whoa, we lost Alice, sorry. I did it too fast. So anyway, while we're waiting for Alice, it is already here, we can create a new connection. Important moment when why it was broken last time if you push enter too fast, you can broke a menu by putting exit here. Just choosing this too fast. So we have connection, let's issue credential and check it offer credential, accept credential, credential is created. The whole list of signatures. And now let's request a proof. So there is only one credential, or it means that we request this proof. And now Alice can provide and create a proof for this credential. So this one is a proof and create a proof. Proof is requested, proof presented. So we can see that everything is okay and we have a relevant data of Alice credential. Okay, let's try to restart it and try another type of credential. Let me remember that previously we created, we implemented the part of creating W3C credential. So let's also create a connection. Let's create a DAD. So here we can create different types of DAD like for the previous demo and let's create data theorem. So here we also create data on the ledger side and create a DAD documents on in the bezel that are launched right now. So we created a DAD and can offer credential. Alice received this credential. You see that it is a bit bigger because of format that we describe here like JSON-LD credential. Here JSON credential, but here you can see specification links and others that are specific for LD credentials. Also it may be used. So and date of signature and overview of this credential. Here and Alice can accept this credential and order will receive information that credential accepted from Alice site. So that's it. Let me show what we implemented right now. We created a DAD documents on the ledger. We implemented a part of creating a credential of uncredited type. And also we implemented part of creating a credential and offer this and issue by a double through C type. This type of credential using in the bezel ledger. It is on the face of POC and we are implementing MVP right now. But anyway, it is already available and we will be happy for any interest questions and of course help with the IndieBasso project. So that's it, thank you. So if it was too long, I will be happy to answer your questions. So Shibu asked, thanks Goddard. So when we tried the demo, do we check out IndieBasso demo using dead ether branch? Was I muted? No, it wasn't. Renata, did you hear that question? So I see the- That's the question in chat. Yeah, the question- That's the question in chat. Yeah, so when we try the demo, do we check out IndieBasso demo using dead ether branch? Yes, it is a correct branch. Sorry for small mistake in the setup script. As my colleagues mentioned, it was the previous link was to the oldest version where we blocked all unknown transactions. Here on this branch, we have open roll map where everyone can push that transaction. So let me push and use the script to fix this confusion. So are there any questions? Ooh, any other questions in chat? Alex and Artem, we're diving in on questions as they came in so we may not have any, but we'll give folks another couple of seconds. If they do have a question they'd like to ask Renata based on the demo, please feel free. Farouz asked in chat, can we use NoSQL SQL databases as an on creds VDR? If it's possible, then what steps would be followed to implement that custom VDR? That's a good question. So in general, it is already here because if we speak about creda, it is from JavaScript X. It is already have no, as far as I remember, no SQL database. The way you can store a DID wallet firstly and DID public key of issue credential definition, schema and so on for different types of credentials on creds too. So it's possible to use this storage and also it's possible to change not by plugins but change the storage inside errors from JavaScript. So yes, of course it's possible to already in errors from JavaScript. Yeah, I'd also like to add that basically is ledger, hyperledger on creds is ledger agnostic. So it means there is kind of an interface to implement for this registry for the VDR. And you know that this implementation or the interface can be anything. It can be India Bazoo, it can be Cardano, it can be checked any other blockchain or it can be something in memory or a database. So it's right now one of the advantages of hyperledger on creds, specification and implementation that is really ledger agnostic and you can have any implementation that are suitable for particular cases in terms of trust for VDR. Awesome, thank you Renata and Alex for that answer. Any other questions, please put it in chat. We don't wanna leave your questions out although Artem and Alexander are doing a fantastic job knocking them down in chat but we wanna give everybody a chance. They do have a question before we jump over to the next part of our workshop. All right, back to Alexander and Renata. Oh, here we go. No, we just answered that question. Thanks for those. Well, so if there are no other questions then, thank you, thank you everyone for joining us today. Thank you for the vision. It was a pretty long workshop and lots of different terms and theories as well as lots of demo and code. I hope it was interesting and you found something new. That's something new. If you have any questions, first feel free to reach us in Discord as part of our community calls and LinkedIn and yeah. Thank you everyone, join in. And thank you everybody. Couple of things to note. The deck slides that Alexander presented earlier are on the Wiki page. I just posted in chat. The video when it finishes encoding will be embedded on that page. It's also on the Hyperledger YouTube channel. The Gitpod URL is on the Wiki page in case you wanna go through the hands-on part of the workshop again on your own time with the video running in the background. Not a problem. We're gonna keep that up for a couple of days at least and I'm going to send out a thank you note early next week to everyone who registered for the workshop. It's gonna include all the links. It's going to include information like when the different community calls are happening for Bezu, for Anoncreds, for Aries, for Credo. It's also gonna include a quick note if you wanna share back with us your experience of working with Gitpod and let us know how you felt about it from a hands-on perspective of being in a workshop. We would love to hear feedback on that. This was an experiment for Hyperledger to see if we could have more interactive workshops and I'm hoping that if this doesn't work out we can try another product but I'm hoping to, we wanna have more interactive workshops where folks aren't just watching demos but they're able to get their hands dirty in the code. So once again, I would like to thank Artem, Renata, and Alexander for putting on such a fantastic and DSR for putting on such a fantastic workshop. We really appreciate it and by all means, join us on Discord. Join us on a mailing list. You can check out what we're doing on the Hyperledger YouTube. We have a channel for workshops. We have, I'm sorry, we have a playlist for workshops. We have a playlist for decentralized identity. All of our community calls are put up there and we would love to see you and if you have any questions we'd love to help and if you'd like to start using these tools and products we'd love to see you do that. With that, I'm going to thank you all for attending and I'm going to end this workshop. Thanks everybody. I really appreciate all the questions and interaction from the attendees. Thank you very much. Let's give everybody a second in case of emergency. Thank you. Thank you Lord.