 Got it. Okay, great. And as usual, I will start with working group updates for the first half of the call and then we'll turn it over to you Arshad for your presentation. Absolutely. No. Welcome everyone to the identity implementers working group call for November 17, 2022. Thanks for joining us today. My name is sharp howland and I'm a co-moderator of this group with Tim spring. Let's see, as usual, since this is a Linux foundation call we're following the antitrust policy. And as a hyper ledger call we are following the hyper ledger code of conduct. And both our links here, if you'd like more information. This call is being recorded and will be posted on this meeting page later today. I will send the link to this page. And if anybody wants to put their name under attendees. That would be great. Would anybody like to introduce themselves if you're new to the working group. Arshad feel free to introduce yourself now or before the presentation, whichever you prefer. I'll do it later. No problem. Sounds good. All right. Well, thanks everybody for joining. Just a couple of announcements. There is an in DCO meetup. On Tuesday, November 29, the topic is on how to use occupy to issue and verify Jason LD credentials. The present, the presenters are Daniel bloom and Peter Struble. And the registration link is here. Let's see, and then we won't have this call on December 29 for the, for the holidays. Is there any other announcements that anybody would like to say before we start in with the working group updates. All right. So moving on to working group updates. Main identity working group. We've reported on them in the past. The hyper ledger in the contributors working group. There's more detailed updates on this group because I'm going to start co-chairing this group. So the main two initiatives we're focusing on are getting the open to 20.04 upgraded completed. This has been a bit of a heroin process, but hoping to accelerate that to the finish line. The other is eliminating the indie SDK. So those are the two main overarching goals in the group as well. We're also working on creating a roadmap for the project. So we'll have some discussions about that. And if you, if you would like to give input on that, you are very welcome to join the calls. Let's see the sovereign node build item is about the pipeline for sovereign. No, this is the test automation to make that process easier. Getting indy node past the RC status. There's been development on two different branches of indy node and plan them. So getting that all sorted out. So that's mainly what we've been working on in that group. Let's see areas working group. Anybody attend. Yeah, go for it Lynn. Sorry, I just wanted to come in and make sure there's been a misinterpretation of a, of an issue that I presented a little while ago and so I wanted to make it public. The results of my findings. I have a comment in one of our Confluence reports from not this last one with the one before that there might be a security issue. And I had raised that issue that I was going to look into it. And some people had unfortunately taken that issue and thought that it was a real issue. And I did a bunch of testing and stuff this is related to the BDR issue with Genesis file node mismatch issue. It's mentioned on the thing here, but I give a few more details. There's some problems discovered where if too many nodes from a Genesis file. Go out of are not available anymore based on their information that's in the Genesis file that there's some troubles with indy BDR and so as I researched that I thought there might be a security hole. I did a bunch of tests and tried to prove that there was a security hole and there is not the current indy node implementation through indy BDR and through indy SDK. Do not have the security issue that I thought might be there. I thought you might be able to take over a network. For example, by just having one node from a Genesis file. And that is not the case. And I just wanted to report that here. Thank you. Yeah, thank you for reporting that Lynn. That sounds like very good news. So I appreciate you jumping in with that. All right. Aries working group. Did anybody attend this one who'd like to report. So they've been talking about push notifications. They merged in a PR with updates to the push notifications. And then there are a few documentation related PRs for push notifications that need to be merged in. Also merged in some air reporting PRs. And then they've also been talking about the replacing indy SDK, like we just talked about in the indy contributors call. And then also planning out IAW topics, which a lot of the groups have been doing. Another thing. One thing relevant to areas we had a hyper ledger areas workshop this past Thursday hosted by the Indy CEO team. And there were attendees from over 20 countries and lots of great questions. So that was a success and a great thing for the project. I see anybody attend the areas by fold user group. Looks like they've been working on OCA and some bugs and particular mediation mediator connection bug, and then state management. Let's see. Another question for the recording. I'm really interested in how the bifold user group is dealing with or relating to the open wallet project that the Linux foundation announced. So for anyone who hears this recording and is involved in bifold, it would be really good to hear an update about that. Yeah, absolutely. Thanks for asking that question. All right, in the ACA pug call. This past week we, there's an interesting discussion on cues and caches, Redis and Kafka mediators and agents. So that was the majority of the meeting. And then version one zero zero RC one has been released in all the normal places. So also good news. Anybody attend areas framework go. Not too much info on their page. It looks like they've mainly been going over work updates. Let's see. Anybody attend the AFG meeting. To the first point on credential delay with what they're working on there it sounds like a first credential exchange has a significant delay from accepting the offer to receiving the credential where it doesn't return the did when it has founded on the ledger but it just continues to try to resolve it from all ledgers. And so then the more ledgers are added the larger the delay. And they discovered that qualified kids can provide a solution to this, because they don't need to fetch them from all the ledgers. And then they've also been talking about did calm the to support and the zero three zero release and then again the, the indie SDK migration that we have already discussed. And then hyper ledger or saw anybody want to report on this one. So, I posted the link to the their q3 report. It looks like the, the project also described it as shaky, but they have reasons to be hopeful. There have been no new maintainers or contributors added lately. On a more positive note, the code review and assessment of Ursa was completed this past quarter by ID lab and only minor issues were discovered, and then they also predict that with the new hyper ledger non creds project. This will increase focus and hopefully activity in Ursa. All right, any other hyper ledger related updates. All right, moving on to the trust of IP foundation. Let's see, it looks like we talked about the all members meeting last time. In the, the last steering committee meeting. They had a. They had a vast proposed that the steering committee would make it an explicit strategic objective of the foundation to establish an interoperability certification framework. And then in two years of publishing the V1 to IP technology architecture specification. So, that was mainly what they talked about. Anybody involved in the communications committee. It's like they've been going over blog updates and approvals website update defining digital trust ecosystems. How about the governance stack meeting. Looks like they got an update on the governance architecture task force and discuss the proposed to IP interoperability certification framework. Let's see looks like we reported on the technology stack working group last time. Let's see utility foundry. Lynn, were there any updates there. There are no updates there the utility foundry working group members have all kind of en masse, moved over to helping with the governance architecture task forced some of the things we were doing kind of matched with that and so we've all of our current efforts are working on that task force. And so our committee meetings and work group meetings are currently on hold until that task force is complete and then we'll move on with more stuff later so we're kind of on hiatus I guess might be the right word for it. Okay. Great. Thanks for that update. Alright, and then for the ecosystem foundry group. Looks like they've been also talking about the governance architecture. The methodology and to IP ecosystem components. Concepts and terminology. Let's see. They've been planning IW sessions and talking about a holder binding paper. Any other to IP updates. Alright, moving on to the diff for the did come working group. So just to reiterate the new plan for these meetings the first Monday of the month is the did come working group the next three Mondays are the user group and then there's a break if there's a fifth Monday in a month. That is the new plan for the future it was intentionally out of order the past few weeks so we reported on the last working group meeting that was on October 31 out of order and then the next Monday was an out of order working group meeting and this past Monday was canceled for IW. So, we have already reported on them. The did come users group anybody attend this one. I was only able to attend just a little bit of it and I wasn't able to track down the meeting notes. Looks like the interoperability group was canceled for IW and let's see. And these last few is anybody aware of any sovereign related updates or W3C related updates. All right. Well, unless anybody has any more working group related updates, I think we can turn the call over to Ashok for your presentation. Fantastic. That's a very exhaustive update that you have. Great. Yeah. So, hi, everyone. Good to meet you all. My name is Ashok Granathive. I'm director of professional services for Casper Labs. And I'll talk about Casper Labs a little bit. But about me, I've been with Casper Labs for about three and a half years now. I joined pretty early when the company was founded. I think I was when I joined the company was still in single digits. We are close to 83 now. Prior to Casper Labs, I was with Google. I spent 12 years with Google across different parts of Google and different regions as well. I started in India in Hyderabad for about four and half years. Then moved to Singapore for three years and then Mountain Dew before I left Google to join Casper Labs. And prior to Google in my previous life, I was with Indian Navy. I did a full commission with Navy retired as a commander. By education, I have undergrad in mechanical engineering, graduation, master's degree in nuclear engineering from IIT Kanpur, MBA from XLRI and executive MBA from Stanford. That's my short introduction. Casper Labs is a layer one blockchain, a proof-of-stake blockchain that is designed and implemented with enterprise use cases in mind. So from the very inception, the founders were now, I haven't focused on making it suitable and try to solve problems that enterprise adoption has been facing in particularly public blockchain networks. And the presentation that I have today is a step towards making that, you know, getting more enterprises onto a public network and solving some of the problems that enterprises have been facing. So let me quickly switch over my screen. Are you able to see my screen? Yes. Okay. Okay. So, what I'm demonstrating today is interoperability between Hyperledger Fabric and Casper Blockchains. The setup here is essentially that you have a private network on which assets are assets, there are assets which are stored on the permission private network run on Hyperledger Fabric. And Casper network, which is a public network, has the currency that can be used to, used to acquire or transfer these assets. Both parties here, Alice and Bob have accounts on both the networks, that's important to understand this. And this is essentially the flow where Alice creates an agreement and locks it with a certain secret phrase. And then Bob looks at this available asset, which is owned by Alice and wants to buy it from her and he sends out a proposal. There is a transaction of tokens happening on the Casper network, which is then reflected in Alice's account and Alice then enables the transfer of the asset to Bob. The assets are locked for a certain time in a contract. In any of the state where anything fails, the asset, the whole situation will go back to the original state, right? If Bob is not able to acquire the asset, the tokens will be restored to Bob and will not come into Alice's account. And if Alice is not able to transfer, again the same situation will be established. So this is the bond network. This shows the CBDC or network on Casper, the bond network is using a hyperlegal fabric. And this is essentially the steps that we are going to follow here. So there are basically three actors here. One is the treasurer. Treasurer is the person who creates a bond on the bond network. You can say administrator and Alice and Bob are the two parties transferring or exchanging the asset. They have accounts as I mentioned earlier on both the networks, right? So let's go through the steps one by one. I log in here as a treasurer. I can see available bonds here. I can also see issued bonds that have been issued with the current owners. Let's create a new bond. One, say face value of 1000. You can assume some interest rate, gold. You can create a new bond. Now you can see the available bonds has increased. This is the bond that we have just created, right? We can note down this bond ID for our record. And I can use the same at the end of this for keeping this record of things that we are doing here. All right. So this bond is created. I now log out. I log in as Alice. And I see here the number of bonds that are actually acquired by me as an Alice, the total bonds that are available and owned by different persons. And here is the bonds that are available for my purchase. And this is the bond that we are looking at right now. This was created today in the earlier step. And I as an Alice initiate a purchase and I purchase this and this is the primary market, right? So the purchase has been successful. Now I see this bond under my bond. So this is now held by me. Please stop me if you want me to repeat or explain any other steps. Now I log in the bond network as a Bob. And I again here, I see the bonds that are owned by me, the bonds that are listed and the bonds that are acquired by different people. Now I see this particular bond. This is the same bond that Treasurer created and Alice acquired from the primary market. And I'm interested in purchasing this bond. So I initiate purchase and I request this. Let me exit from Bob. Alice on her will get a notification here that you can see on the top right corner. CC is the notification that there is a request from Bob to acquire this particular bond. And she can either reject or approve it. If she has to approve it, she'll kind of create a secret code. Let's go with this code at this point in time. And she can approve. What's the purpose of typing in the secret there? I don't understand that part. So, I mean, in this particular case, we are demonstrating the secret code is so that nobody else other than Bob actually, you know, acquires the asset. So, so there has to be a code with which the cost the smart contract locks in the bar. Alice is going to share that with Bob at some point. So, no, she actually doesn't share the code that there is a weaver engine operating behind the scene, which actually shares the hash with the smart contract. So this bond is now locked with a hash. Okay, so this is hash time lock contract. So let's note down this hash here. Records. Right. And come back to the next step. Which is also this is where we are right now the secret code is created and the bond is locked in now with that particular code. So let's go over to the CBD C network and log in as Bob here. I'm sorry this is too slow today for some reason. So Bob currently has around 12,000 tokens, but he needs to transfer these tokens to Alice's account, so that he can then claim the bond right and you see the request has been received by the by the CBD C network Bob account, and you see this hash is same as the hash that we saw here. This one. So now Bob knows that his request has been approved by Alice. She has initiated the transfer of the calm transfer of tokens. So 1000 tokens will be taken out from Bob's account and eventually will be transferred to Alice. So he approves this and now you have a deploy hash because this is a public network. A deploy will be made to the public network. Let's record this as well. So this is a deploy hash where tokens are being transferred from Bob to Alice, but they don't go directly they are locked into a smart contract. And Alice has to later go and claim it. We can observe. Let's log out of this. And let's observe the chain. This is a block explorer for Casper last chain. We'll have to wait for the deploy to go through. Okay, so this deploy has gone through you can see the success criteria here. This is the deploy hash that we have seen here. 4, 4, 3, 2, 3, 1, 9, C, 4. And if you want, you can, you know, see the details of the of the transfer here in the in the raw data that is available with that transfer. So essentially this these tokens are now locked in. You can see this is a deploy, which is successful screen. We can now go to the CBDC network, log in as Alice. Sorry before that way to come here. Log in as Alice. So Alice is now come to her account and she wants to claim that opens. She puts the same secret key that she had put in the bond network when she locked the bond transfer to to Bob. So she claims the amount. This is again a deploy that goes on to the network. Let's note it down. Then we go to the explorer and see and observe the transfer takes about a minute for it to go through. This is still in pending state. The concept here is of the hash time locked contracts. That's what has been implemented. We have a smart contract running not cast a blockchain and and Weber is managing the transfer of the keys behind the scene here. So now we see that this is successful. And in this particular deploy, the secret key is also revealed. So this is the secret key that you see here, which Alice had typed in. But even though you can observe this a third party cannot make use of this anymore, because even if they know the secret key now, the, the actual transfer is locked in to only Bob. So only Bob and Bob can claim it and nobody else on the bond network. If somebody else tries to log in and claim the bond. They won't be able to. So let's log in here again as Bob. Now that we know that the transfer of token has happened. We can now claim the bond. And I now know as Bob the secret key because I've observed it on on the chain and then I claim the bond. So bond has been successfully claimed. We can see the same bond here. This is created today. Same bond that we have been in the treasure initially created and Alice later on. So this actually demonstrates how using hash time lock contracts, we can transfer safely between the assets on permission network. By transferring the tokens on a public network. So that completes the demonstration part. I am open to questions. Thanks for the demo. It's a really clean interface. Do you think you could go back to the diagram that shows the steps between Alice and Bob. Just now that we've seen it in action. I think you could talk just briefly through those steps. Yes, certainly. So we have we have not talked about the treasure creating the bond because that's kind of given. So Alice, Alice agrees to Bob's proposal and essentially locks the asset with with the hash. And this is locked for a period of 2 t, for example. Then Bob creates corresponding agreement and. So, so this. The transfer of tokens on the. On the public network is is happening here. Bob transfers tokens to Alice's account. That information is captured by the smart contract. And then the transfer is enabled. Essentially that's what we are doing here. So Bob transfers the tokens Alice takes the tokens and then automatically the bond is released from Alice to Bob. In the intermediate space, the smart contract locks both the bonds and the tokens. So if anywhere this had to fail, it will go back to the original state tokens will be restored to Bob's account and the bond will be restored to Alice's account. Okay, that's really helpful. Thanks for for going back over that. Thank you so much about hyper ledger fabric. Can you talk about why you chose that ledger to develop this interoperability with the Casper blockchain. So, essentially that the, you know, hyper ledger fabric has been extensively used by many organizations for, for, for maintaining a ledger of their assets. Now there are several reasons one is definitely. Early on, right. The public permission less networks were not considered very reliable. Secondly, many organizations don't want their data to be on the public chain. So they wanted to keep it in a permission network. So as a result of that as a result of, you know, just a legacy a lot of organizations already have assets on the hyper ledger fabric network. And it's also considered as enterprise great permission network right. So that's the reason we created this we also work with IBM very closely on this. In fact, this was presented by a first time in a world economic forum Davos and in in May 2022 by me and Varga was the principal, you know, scientists at IBM, and then hyper ledger family conference in Dublin in September. Me and Shyam present Shyam from IBM presented it second time with some improvements to the UI. Cool. Thank you for explaining that. Yeah, I mean, basically it's, it's a concept that is more important here, which is that you can work across a permission and a permission less network in a seamless manner. So, you know, whether you have assets on permission network, you can still make sure, you know, ensure that the cash ledger or the public ledger can work with it in a very secure manner. Actually, I have a question. Sure. So the, so it's obviously some sort of, I guess, the term I would use is linkage between these two networks. So is it, is it one network or the other that provides the linkage and then the other one is is just stand alone and can be used or is there neither of them and they're both standalone and there's software that does the linkage for them. How does the community. Yeah. Yeah, so the linkage is implemented through Weaver. Weaver is an open source. So software available through the RIVX Foundation, I guess. So Weaver is the one that we have used to implement. So there are some changes happening on the Weaver side. I think it is getting combined with Kektai. So that's, that's the one which is the relays and the smart contract is sitting on the Kessler network. The other networks don't really know about the other network at this point. There's a, I didn't hear what you said. I don't know how you spell it. Weaver or something it sounded like. Weaver. Can you spell that please. I'll put it in the chart here. That'd be great. Yep. So it's just that tool that does the, you know, manages the. Yeah, it manages the linkage and the smart contract and on Kessler has the ability to lock in the tokens. Oh, okay. So there's some feature on the Kessler network that allows for this tool to be able to perform the linkage. Awesome. Yeah, the smart contract on Kessler is also written in a way that it implements the. The hash time lock contract. Excellent. Thank you. Yeah. And we were is used for the relay between the two chains. Any, any other questions? Yes, so primarily this opens up a tremendous number of use cases because currently a lot of a lot of organizations enterprises have high pleasure fabric as their core blockchain and assets are residing on those. Yeah, this must be really useful. I can see how there's so many use cases. Yeah. And if use cases that that will come up as a result of this. What were some of the biggest challenges in developing the interoperability between Casper and fabric. I think that just the concept of the hash time lock contract and in implementation of that was a bit noble so that that was one and. And the piece of we were which kind of relays the hash of secret between the two chains. That's an important piece as well. So, and of course, right? Yeah. Imagine the. The expertise in. You need three, three different experts here. One is someone who knows fabric really well someone who knows Casper smart contracts well and someone who also understands we were. I think that was. That was important. Right. Right. Well, thank you so much for this demo. Were there any other questions? All right, we'll really appreciate you joining the call Ashok and really interesting project and I appreciate you walking us through it. I know it was low attendance today because of IW but I'm sure those who watch the recording will really benefit from this so thank you all for joining and jumping in with working group updates. And we'll see you all in two weeks. Yeah, and if there are any other questions, you can certainly email me and I can follow up. Great, thank you. Thanks a lot. Yeah, thank you. Thanks a shot.