 and then turn it over to Mona. Okay, you were live. Great, thank you very much, David. Okay, everyone, well, welcome to the latest Denver Meetup virtual discussion, and we have the pleasure of having Mona Rassouli join us today, and she's gonna be talking about building a next generation digital identity and verified credentials system using hyperledger Aries and Indy, which is wonderful. And I'm really looking forward to this great discussion, and it seems like we had some wonderful discussions here about verified credentials and tokens. We had a nice presentation last time by Eddie, and I'm looking forward to firing off into this one, and Mona, I'll turn it over to you to kick us off with a discussion. Sounds like a plan, thanks, John. So I'm gonna start by sharing my screen. And if anyone has any questions while we're going along here, feel free to post them in the chat. And if you also wanna post where you're coming in from, that'd be good as well. Okay, please let me know if you can see my screen. Yes, it shows up perfect. Perfect. Okay, hi, everyone, nice to meet you. My name is Mona Rassouli. I am a full-stack blockchain engineer at OneUp, and I'm also the founder of HapticSao. Today's talk is about a next-generation identity system. The specific title is Building a Next-Generation DID and VAC System Using Hyperledger Indian Aries. I've structured this talk to begin more at a higher level overview of decentralized identity and SSI. And then gradually, as the talk continues, we're gonna narrow it down to our solution and our specific use case, which is in the context of an ecosystem for a brand and loyalty. So to start, we're gonna do an intro on decentralized identity. Then we'll cover the general design of self-sovereign identity. Then I wanna talk about a topic that I think is personally extremely important, which is accessibility. Then as I said, we're gonna talk about our solution at OneUp, our model, our design. We'll briefly then touch on a little bit of forward-thinking, some exploration of forthcoming ideas, and then I'll leave room for Q&A. Okay, so let's get started on an intro on decentralized identity. And to start, I wanted to bring up a term that came up very recently. It was actually last week at Chainlink SmartCon. It was delivered in Serkin-Azerov's keynote. And that term is the idea of the verifiable web. And I think this idea may transcend and be perhaps a bit more accurate when we talk about Web3. And I think it's a powerful means for reshaping how we think about the internet and the state of how we want this to evolve into over time. And so there's been a decade of work by W3C. And I also wanted to cover a really good quote by Philip J. Windley, he's a former sovereign chair, and that is from his book, excerpt from the O'Reilly book. Because the internet is missing an identity layer, every website service provider and application has solved the problem in a unique way. As a result, people are subject to cognitive overload, friction, increased costs, loss of privacy, and even outright fraud. So this is kind of over time become a systemic problem where every website application or UI has this issue and this comes at a cost for both teams and users. So as we think and discuss the verifiable web, I wanted to list out some very specific key elements. There are some more, but these five are really crucial to this idea of the verifiable web. And so the first part is that it's a meta system. It works best if it's a layer atop the current internet. As previously quoted, it's like an identity layer atop everything. It's its own protocol, the same way we have TLS and SSL. And so what this does is this enables kind of a continuous system rather than isolated central systems. We have a continuous layer that it's more that when teams implement their identity solutions, it's just instances of a larger system rather than isolated. So this allows for more robust infrastructure, contributes to better security and privacy. And it's less a worry about moving users between different authentication pools. And it's really interesting, it's more about users moving themselves with their identities. And so this kind of continues into the next element, self-sovereign identity. Users have control of their own data. They control who they share their credentials with and to what extent. This gone is the notion of third-party trackers or business models that operate at the cost of privacy, of user privacy. And the idea again is that it's user consent driven. This is guaranteed thanks to cryptographic verifiable truth, which is enabled by a mixture of zero knowledge proofs, their use case specific methods. And that is what the cryptography is what allows us to establish integrity and credibility in the system. Interoperability of course, ties back into the meta system idea. We're gonna have many, there's many blockchains and applications and systems. And so this is like a decentralized means of interacting with all of them. They're complimentary rather than isolated. This also additionally makes sense when you think of the identity layer as a global system. Each jurisdiction has its own laws and regulations and their own credential types. So we really want it to be interoperable, not just that a technology layer, but like between different countries. And then the last one is like very crucial to just any form of blockchain design that's to have modular design. So specifications evolve, technology evolves. You really want to be able to update to new standards, update, have your system be scalable. And this is also vital when you even get deeper into it, when you're thinking about quantum resistance. So being able to change out certain things to make them more resistant to quantum attacks. Okay, so that kind of sets the stage for this talk at a very high level. I wanna now cover the general design of self-sovereign identity. So I have the technology stack for SSI. This graphic has taken from the trust over IP. And starting, there's four layers to this, but starting from the bottom, we first have a public utility layer, which I also call the network layer. This layer consists of ledgers, it consists of DIDs and the idea of everything being interoperable. There's different DID methods. Centralized identity methods may usually correspond to the ledger with which they're interacting with. So whatever method you're using defines how DIDs are read and written to the ledger for that specific ledger. And I'll, I have a slide for this next. So I'll get more into it. The concept of a universal resolver then becomes key to enable this interoperability. You need to be able to resolve for whatever blockchain you're using so that it's not that like, oh, I can only verify if I'm on this specific blockchain for this specific platform, it follows throughout the system. Layer above the network layer is the peer-to-peer communication layer. There's this concept of agents. Every user has one or more agents with which they can connect to other agents with and have this peer-to-peer interaction. And then these agents also help manage their wallets. So the protocol for this and the in the area stack is didcom. And in the same way that you can connect from person to person, you can have organization to organization connect and organization to person connect. And another powerful thing that enables this is the concept of pair-wise DIDs where everyone has a DID but when you're making a connection for that connection pair specific DID can be issued. And this also helps with privacy. Another key thing with the connections is that when you connect, it's essentially indefinite but you can opt into a connection or opt out of a connection at any given time. Okay, so those are the lower levels, those first two. A layer above that is the verifiable credential model which is secured thanks to zero knowledge proofs. I have a dedicated slide to this so I'm not going to spend too much time at this time. Layer above then of course is your application ecosystem. This is where your business logic will be written for how you want to deal with credentials just so you know when we're talking about the business application, it's referred to as a controller for the agents for here. Okay, so going back then next to first the idea here of DIDs and TIT docs, there's different DID methods and so the string is like this. It goes, you have DID, you have the method you're using which corresponds to most like the specific type of ledger you're using and then you have the actual like ID parts that is generated from your method of choice. So here's two examples, there exists DID ether which actually has a corresponding EIP. It's stagnant but there's the repositories active. You have another example of DID SOV which is for the software network that's an indie based network DID method. And then so this string can be resolved to what's referred to as a DID doc and it's like a specific thing that it gets resolved. So this on the right is an example of a DID doc and to draw an analogy for understanding in the same way that NFTs have metadata that tells you details about that specific NFT. Each person's DID has a DID doc which is sort of like metadata for that DID. Okay. So now I wanna cover the verifiable credential model which if you recall was layer three and this is where the credential issuance occurs. So there's three major key players in this and that's so agents that act as issuers, agents that act as holders and agents that act as verifiers and these are Aries based agents. So the issuer is an entity organization that will be issuing the credentials. The holder is the user and then the verifier is another entity or organization that would be verifying those credentials. So the basic flow is that an issuer will issue credentials to the holder based on some information that the holder provides. The issuer will determine if it's valid and then issue it to the holder's wallet and then at a given moment, whenever the verifier would like to request that they can get a proof which is thanks to zero knowledge proof technology, ZKP. And there's trust in the system in this flow because we have an underlying ledger, we have an underlying blockchain that can help the verifier validate that, oh, this issuer legitimately issue these credentials to the holder. It's not the case that there was forgery. Okay, so the model specific to our organization, one of has one of as the issuer and as the verifier and this is the design right now at inception. The longer term goal is as we onboard more clients that are in the brand and loyalty space to onboard them to our network as issuers and verifiers. And I'll talk about this a little bit more when we get more into our design. Okay, so again, covering the credential process, users gonna provide some information, organizations gonna determine the validity of this information and issue the user credential. The user holds the credential in their wallets and then whenever there is a need to prove their identity, either this could be a formal request or this could be triggered by a restricted action on a user interface, it could be designed that way. They're gonna have to share their credentials to provide the validity. And then if it's valid, it's done. And it's a simple flow, but realistically under the hood, it's actually, it consists of a very quick back and forth facilitated by a web hook. It's like almost like a six step dance between these two actors. So here would be like a six step back and forth of like requesting, offering the credential. And then over here as well, requesting the proof, validating the proof and so forth. And part of the validation check also is to check that the credential has not been revoked. Okay, and what allows for the privacy and security of this is ZKP, specifically ZKSNARX, which are non-interactive, allowing to limit the interaction between, if we go back, the prover and the verifier, the holder and the verifier. This also enables minimal selective disclosure. You may have a credential with many attributes, but you don't need to necessarily disclose all of them. You can even disclose a fact about them. That would be considered a predicate. And then a key aspect of ZKSNARX specifically is that they're distinct. So no matter how big the amount of credentials are, the proof is always kind of a smaller message, which allows it to be a lot more efficient. And so CL signatures are specifically what's used to generate the proof. And you can also combine these with some blinded identifiers to get more privacy. Okay, so that was a quick overview of self-sovereign identity and decentralized identity. Now I wanna cover accessibility. I wouldn't be the founder of Aptixtow if I didn't cover this. And I think that this idea of an identity layer really contributes to this. So let's discuss that. So traditionally we have a lot of issues with verification. Specifically when you talk about CAPTCHA, it's not accessible to everyone. So for example, a blind user CAPTCHA is not exactly accessible. There's even RECAPTCHA or CAPTCHA V3, which was designed to be more accessible. However, it has issues for the deaf-blind community. And also any type of CAPTCHA or authentication system that is puzzle-based actually goes against WCAG recommendations for cognitive accessibility. And then from a usability perspective as well, every platform again has its own platform-specific verification. So you may have noticed on LinkedIn very recently they had the driver's license validation. Twitter has Twitter blue, but these are platform-specific. And so reach leads to my next point. It adds at a UX level, it adds friction and it's a bit tedious to do on every website or application or any of these platforms that also have KYC processes. They're often inaccessible and user has to ask for additional help each time they want to validate themselves on a platform. Stepping away from that as well, we have malicious actors, there's third-party tracking, there's bots, there's spam. There's also, I put social engineering on there because very recently chat GPT was able to, there was an article about this in May. It was able to trick a team member of some platform that it needed help, it was a blind user and it needed help to get past CAPTCHA. And so it actually, through social engineering, the AI was able to trick the person that it was corresponding with. So what SSI then provides as a benefit for accessibility is of course increased privacy thanks to zero-knowledge proof technology, increased security, central providers have data leakages all the time. If you own your credentials and you choose who you share those with, that prevents against that. It's not an essential location. Again, user has control of data, it helps avoid the third-party tracking. It's no longer your data that makes you the products. And probably the most important point for accessibility is inclusion and equal participation in a much larger system. And you have this idea of true universal login, okay? So now I wanna cover our solution. We'll have a couple of questions here, Mona, before we move on here. Oh, sure thing, sure thing. And then we'll come back to the discussion. So a couple of points in the chat that were posted about that other section you were going through was. There's a question here from Imran that says, does this mean that the entire, let me get back to it here. Credential is encrypted using zero-knowledge proof when presented to the verifier. Correct. Okay. And then another follow-on question that they had was, what is the CL signature? So that is an ECDSA base. It's an elliptic curve, sorry, excuse me. It's elliptic curve-based signature. You can kind of look into it. It's based, so it's called CL because it's based on two individuals in cartography that came up with it. I called it CL signatures because their names are kind of long. It's the common, I'm not gonna try to pronounce it. But that's what's used to sign on the proofs. Okay, perfect. And then we've got one more question then we can move on to the next section here. Looks like Bright has a question about, can the digital wallets function with mobile phones and tablets with SIM cards? Yes, yes they can. So there's actually, there's like two flows to this. There's a desktop flow and a mobile wallet flow. And so the difference is like you have like right, so a desktop flow would be like a server-side environment and then mobile flow would be mobile environment. So like how you handle the credentials is a little bit different. Perfect. Okay, Mona, thanks for answering those couple of questions and I'm ready for the next section. Awesome, yeah, thank you guys so much for asking questions and thanks, John. Okay, so next part I'm gonna zoom in now on our solution. So up until this point in the talk, this is more of like a shaping our thinking or self-sovereign identity and decentralized identity. Now it's more specific to what we did at Wanao and what we are specifically operating within, which is like a microcosm of the larger macrocosm that has been presented up until now. So I wanna, this is a very quick architecture snapshot of Hyperledger Indie and Hyperledger Aries specifically. So I'm gonna break it down, but this is the quick picture. You have the Hyperledger Indie blockchain and I'll go through that. Then you have your agents, which interact with the blockchain. You have a tail server, which is separate for handling the revocation of the credentials. And then remember in the TOTIP stack, we have the controller, which is where the business logic sits and interacts with the agents. Very much so outside of this, not so much an architecture concern is the Indie CLI for some setup, but it's not connected or interacting with the network. It's just it's on separate CLI. So starting again, we're gonna start, it's bottom up, but on this picture, it's top down. Let's talk about the Indie Identity Ledger. So Indie Ledger is a public permissions network. And what this means is that anyone can read from it, but not everyone can write. That's what permission means. This contrasts to Ethereum, for example, which is public and permissionless. But I do want to mention that we shouldn't think of these as isolated. Remember to think of it as more of a meta system that you can interact with these guys. So again, zooming in on Hyperledger Indie. Public permission ledger, it serves as a decentralized source of trust that anyone can read from, but for brands, loyalty or more enterprise use cases, they want a stricter ledger where not everyone can write, especially when you're thinking about issuing credentials, you want a little bit more of that restriction. And so what do we actually persist to this ledger while public data, so like public DIDs, schemas, some application info, what we are not publishing, of course, is just like the credentials, private keys, like obviously anything sensitive. Paralyzed DIDs, for example, are nowhere near the ledger. Ledger components. So you have Indie Plenum, which is like the engine of Hyperledger Indie. It's the consensus protocol. It's the core ledger components. So the consensus protocol for Indie is Plenum Byzantine Vault Tolerance, which assumes a malicious BFT Vault Tolerance. So what this means is the equation is three F plus one, where F is the number of nodes you can handle being malicious. So another key thing to this is that a Markov Patricia tree is used for state. This is similar to Ethereum actually. They use also a Markov Patricia tree. Indie node, then, which is dependent on Plenum, handles more the identity logic for the ledger part and handles identity-specific transactions. The nodes themselves are actually communicating thanks to ZMQ. And I've included the idea of the sub-ledgers because Indie is truly for sub-ledgers. It's a domain, config, pool, and audit ledger. Domain is where we have our credential definitions or schemas or identity. Config is where we can set some governance and some other network settings configuration. And then pool is where we have node discovery, network, any time in node joins the network, you would be, the transaction would be quoted in the pool. And then audit, literally audit, just have better integrity in the system. Some additional technical info. Ursa previously provided a lot of the cryptographic primitives, but it's been since deprecated. It's still used for individuals that are actually using Indie SDK, which is like using an identity system without the use of the agents. Now we just focus on a non-creds and like I mentioned, the CL signatures going forward. And this is effective from the agent version of 0.8.xup. Another key thing to know as well, this is pertinent to the agents. You are required to use Ascar wallets, not Indie wallets with the agent. And then I've also just included the library lip sodium, which is used for cryptographic operations in this. Okay, so that was snapshot of the Indie ledger. For one of that's our private identity blockchain network. Next, let's cover the agents. So this is the architecture for an agent. The picture on the left is a simplified photo of the picture on the right, which is also a simplified photo. So you have your Occupy agent, which has core capabilities for interfacing with your ledger. It also contains the core capabilities of interacting with other agents. And that's again via Ditcom. So what happens is your agent serves all of this functionality via REST through Swagger. And then you would write your business logic on the controller to interface with this, which then interfaces again with the Indie ledger. And then also in between your controller application, which in our case is a Django application, you have a web hook that helps speed up the back and forth interactions. So if you recall, when I was showing the verifiable credentials model, I said there's actually a little bit more to it when between the issuer and the holder and the holder and the verifier, there's a very quick back and forth. And that's what the web hooks there for. It helps facilitate those really quick back and forth requests. Okay, so that was the agents, that was the ledger. I want to very quickly talk about the tail server. The tail server exists for the use case of revoking credentials. So if you issue a credential, you either want it to have an expiration date or you want it to be revoked for whatever reason. It's its own dedicated registry and it also plays on the idea of cryptographic accumulators. They're designed to be also horizontally scalable because tail servers have like a very finite amount of credentials with which they can hold for revocation. So you need to keep deploying more as your system grows. And again, it's meant to run alongside the network. And this serves as a point of reference when you're actually doing the verification step that you want to verify that the user's credential has not been revoked. It is possible as well to issue non revocable credentials, but again, this is like an interplay of what is your use case for those specific credentials. Okay, so again, continuing for one of specific our technical stack up until now we've covered indie blockchain, which is our official public permissioned blockchain. It's optimized for identity. Aries agents handle the requests to our identity chain and interact with our controller. We use hash corp vaults because our architecture also consists of multi tenants mode for the others. We need seed management in the vaults, which is very secure and also some backend token management. I've mentioned that our controller is written in Django. This helps to communicate between the agents and then our UI is reacts. I'm gonna cover it very quickly in the forward thinking part, but we're also looking at React Native for mobile agents. So whoever asks about mobile agents that React Native would be pertinent to that. And then in front of our entire identity system, in front of our entire platform, we have actually key clock. And it's our primary authorization point. It allows users to sign up and access 30 centralized identity. And all of these messages and flow is really orchestrated and facilitated thanks to Kafka so we can produce and consume identity, firefly and fabric messages in our system. It really makes it a lot faster. Quickly covering our specs. So we're running agent version 0.9.x and up. Of course, using ask our wallets. As mentioned, 0.8.x and up, you should be on ask our wallets. We're using multi-tenant design, which allows for really good scalability and better desktop UX for the user. CL signatures, we are using indie credentials and we're working towards a non-credits 2.0. At the time we had developed the solution, it wasn't quite there yet, but now it's forward to thinking what's what we wanna be. We use standard agent connections to connect the agents. Our deployments is thanks to Kubernetes charts. So that's for both the agent and the tail server. Currently open sourced is OpenShift charts. So our DevOps guys, Nathan and Corey, shout out to them, wrote some Kubernetes charts for our specific deployment. And we're also using AWS cloud for our indie network, expanding into other cloud providers just to have more opt-time. And then agents, all of our agents are currently occupy-paste, so it's all like in a server-side environment. On the right, I also have a quick chart for multi-tenant occupy instance. The idea is that there's like a big wallet that relays into each user's specific wallets. They're all tenants, since the multi-tenancy. Okay, so what does our registration flow look like for users? Well, very seamless UX. Users simply signs up. They can sign up with their social provider. They can sign up with a traditional account, email. They are first registered into Key Cloak, which is important because it helps with accounts and kind of social recovery mechanisms. Then they are registered in our identity system, which again, so they get their DID created, sub-wallet created, and then sensitive details are stored in hash-corp vault. Then specific to our wider platform, they're using FabConnect. They have wallet creation and wallet enrollment for our private fabric chain. And then also our team is also using Firefly, so they have a Firefly registration. Once these three pieces are complete, or sorry, four pieces if you include Key Cloak, the user is successfully created. And I actually omitted a demo from this talk because as I was like looking at our system, it's actually, it's so seamless, the UX, that it didn't really add value to have a demo for this, just to show messages going back and forth. And so yeah, so beyond the registration flow, it would go back to the credential issuance flow. So this is a fantastic design for brands and loyalty because we can readily support multiple chains. The DID and the user account works across brand platforms. So again, think of it as like a micro ecosystem of brands and loyalty organizations that the user can kind of travel through. And so that creates a smoother onboarding. You can choose which brands you wanna be involved with. Stronger CRM is enabled by this. Actually our CTO, Eddie did a talk on this previously. And then also if anybody has a side note is interested, Dennis and Eddie also did a talk on Teslas Connector. So when we talk about multiple chains. So and then this also considering brands and loyalty creates better user engagement because they feel more involved with earning, rewarding sweepstakes, ticketing, gamification. Interesting use case for sweepstakes could be that, let's say a sweepstakes has a requirement that you have to be 18 years or older to enter the sweepstakes. You have already had your age credentials issued to you. But without having to reveal your age, you can use predicate and it'll just verify whether you're above 18 or under 18. It's not, you don't need to know your exact age. And then yep, just also I believe I mentioned this, that I do have cross, oh no I didn't, cross brand loyalty programs. This is also something else that's interesting. So you could have shown loyalty to multiple brands. You could have something as interesting as a flow of where you verify you have tickets to a concert. You can have a specific hotel brands get a benefit boost from using that specific brand. So you get hotel accommodations for that concert. And then you could also use a specific merch provider to get like a triple loyalty boost, okay? Now, quick mention of future work and exploration for our team. So- Well Mona, maybe let's just jump back in and take another quick look at some of these questions before we move on to that section. Yeah, sure thing, sure thing. And I'm just trying to interleave some of these within the presentation here. So let's go back here and it's and some of this you may have already covered but let's just go through it quickly. Yeah, sure thing. So where do you have the mediator server for the mobile agents and is this part of the tail server? Okay, so mediation is separate from that. That is when you want a service to act on behalf of the user's agent. We're not using a mediator in our flow. Multi-tendency you can, there's so there's two flows of multi-tendency you can have a mediator or you can have a relay. We're using a relay where requests are relayed to the appropriate sub-wallet. Great, and it looks like Wade also kind of weighed in here as well on that question. Okay, another question we have from Colin is as you mentioned, there is a mobile wallet and desktop wallet. Can you sync verified credentials between the two wallets? Yeah, so that's interesting. So we started with the multi-tenant design. So right now we're on desktop only. I was going to cover it in the future work, but that's something we're looking into to have not so much a sync, but more of like an export for mobile wallet. We could certainly explore a sync mechanism as well. It's kind of, it's more in like something we'd have to sit and like flash out more though. Yeah, that's perfect. And then Colin had a follow-on question, which was, which version of DITCOM protocol are you using? The latest, so you'd have to look up that one. I'd have to get back to you on that one. Okay, yeah, no problem. And then Jim's got a good question here. He's asking, does your solution have interoperability with DITS on CHAPI networks, CHAPI networks? It could be made to, to my knowledge, but we haven't had that come up in any discussion so far. Okay, great. I'm going to go a couple more here and then we'll get back into the section four here. Next one is from Wade. Why did you choose to host your own IndieNode network rather than use one of the existing services like Sovereign or Indicio? So Sovereign and Indicio are, and by the way, hey Wade, he's a fantastic member of the hyper leisure community. I've always asked answering questions for individuals. So shout out to Wade. So Indicio and Sovereign are fantastic networks and they serve their own purpose. We specifically chose to host our own Indie network because we see our use case as more specific to like a platform for brands and loyalty. We would certainly be interested in working with Sovereign and Indicio net-based networks. We've actually had some like conversations a little bit but like want to get back to it later. We wanted to build this out first. But so because ours is specific to like one of our clients, for example, I can talk about this publicly as Warner. So like Warner's our first clients, they're in our identity network. It's specific to their mechanisms and their needs. Okay, perfect. Then got a couple more here and then we'll go back to the presentation. Got one here from Neil. Is there a link where they can try out the registration process? Any type of demo for him? Yeah, absolutely. Carter, I think you answered that in line by the way. Okay, it looks like Carter did answer it in line and thanks Carter. So yeah, this is the Warner music group rewards. And this is one that Eddie went through on his great presentation previously. So thanks. Okay, we're gonna do two more and then we'll go back to it. So Jim's asking another question about do you support DIDs from other networks? We can. Currently we're using sovereign DID, DID SOV. But yeah, so like again, as I mentioned in the beginning of the talk, ideal situation is when you, it's irrelevant, you just support whichever ones. Okay, perfect. And then the final question is, have you looked at Civic Pass? I have not. Feel free to share any links. Perfect. Okay, Mona, looks like that's the current question. So I'll turn it back over to you to go through the presentation. Sure thing. So we're getting towards the last one is very quick and thanks Eddie and Carter for the assistant answering questions. So future work exploration. So exploring mobile design. A lot of questions have been asked about mobile design. So we're looking at AFJ and by-folds. Also going back to accessibility, I think it's very important if possible to support both desktop and mobile and users can decide which their preferences. Next then as well, a non-creds V2. Recently in the community, there was a mention of the hyperledger agora projects with additional CKP properties, additional signature schemes. So that's something to at least explore and look into. And then beyond that, just expanding out our use cases. Like I kind of mentioned a sweepstakes use case, but other ones outside of that. And so now we hit the Q and A. Okay, perfect. So go ahead and feel free to post it in the chat and if you need to articulate the question, just let me know in the chat that you wanna talk as well. But one of the questions I had for you, Mona, is you had that great run-through about inclusiveness and making sure things like accessibility are in play for the internet. And so one of the things I was thinking is, is there any type of legislation that's coming down that's really going to force some of these players to adopt verified credentials for accessibility purposes? Yeah, for sure. I mean, there's definitely updates in legislation. They've been a lot stricter recently. You've seen maybe in the news of some more lawsuits as well for organizations. I think California specifically is quite strict with that. So legislation definitely contributes and I wanna say like maybe incentivizing teams to start with better accessibility practices and accessibility is really good because you're involved, like Web3 is built on community. So when you involve your community and you get feedback, it not only makes your products better, it contributes to everyone having a sense of like loyalty and enjoying the product more. And the sooner you start with that and keep these things in mind, the better off you are versus trying to like redo everything from scratch after like being out for many years or... Perfect, and then kind of a follow-on to that is, I know that KYC is always a big issue, know your customer, whether that's coming to banking or whether that's with exchanges or crypto exchanges. So what are you seeing as far as more adoption in that space of maybe even cross protocol, KYC acceptance? So at the moment, it still seems to be more like isolated cases where you just go on a platform and you have to KYC for that specific platform. So right, as we talked about the idea of like universal login, universal authentication, I think that'll definitely help with that. KYC is a very tricky process. I know there's like some takes on both sides about the necessity of KYC. It's definitely important. It definitely serves its purpose. It just has to be made as accessible as possible. And if we can reduce the amount of times you are required to do it, that also contributes in accessibility. Okay, perfect. Looks like we got a link for Civic in there. So we can check it out if you wanna look at that link. And then let's see what Jim has to say here. Jim, you wanna come off and ask a couple of your questions that you have in here? Come up here. One of them is, again, back to the idea of interoperability, which you certainly hit upfront, which is really critical. And I think eventually when I'll say all of the concepts of a standard did VC and so on, an anonymous credential, once those are all fully interoperable or recognizable across multiple systems, a lot of problems go away. But one of the benefits is there's something called the Glyph Network. So most financial institutions now, because they're responsible for KYC, AML, compliance kind of thing, are looking at Glyph dids, if you will, for legal entities, which is sort of very different than a sovereign did, if you will, which doesn't have those same issues and same responsibilities I'll say. So as a result, like companies will, sorry, I can think of many financial institutions that issue these Glyph dids and say, okay, this is now the IBM's did. We've issued that for our company and we have a credential that has a relationship with them as a vendor or whatever it is. All of that stuff is going on now actively. And so the argument would be, it would be great at some point to be able to leverage that instead of having to re-enroll a company again in another network, which as I guess the solution now you wind up with multiple separate identities in the SSI world, I guess to accommodate it. The only other thought was around wallet services. So different than wallets, which is sort of not a winning strategy long-term for a lot of things, where you're actually holding your own wallet. It's much like your 401k, your IRA is not in your wallet. You have a few hundred dollars in your wallet from a risk perspective, you decide on a custodian who actually holds your real assets. And so wallet services under that EAP 4337 allow the idea of custodial wallet services as well instead of metamask or something. Yeah, for sure. Thank you so much for sharing that, Jim. Yeah, account abstraction definitely contributes to better accessibility in UX. Yeah, thanks. Perfect, thanks, Jim. Appreciate that. We have another question here is about how is fabric for storing and retrieving information at scale? And what layers is it best compatible with for multi-tenancy enablement? Okay, so fabric, by the way, tends to be more like raft consensus-based. We're using fabric as our private chain. So that's how we handle minting NFTs and all that functionality. Okay. Then Colin's got another question here and he just wants to double check. Can I get your services and deploy them on my own infrastructure? Do you mean like on board onto our network or he wants to get started with like hyperlitraindy and iris? Colin, if you want to come off mute and ask a moment of the question directly that maybe would help. Hey, can you hear me? Yeah. Okay, what I mean is you have mentioned something like the Helm charts and where it's working. So this implies kind of to me that I can get the services and deploy it on my own infrastructure, which I'm running and then connect to your blockchain, of course. That's what I meant. Okay, so we do have some Kubernetes charts. They're currently not open source. I can, I believe the intention was to open source them. No, no, no, not only open source in general. If you have such an option, I don't know, prepaid plant or some subscription plant, that's what I'm more asking. That doesn't mean to be only an open source. Oh, I got you. Do you want me to cover that? Yes, please, Eddie. That's what this is for. Yeah, so we are actually putting together an offering for doing the essentially digital wallet as a service at the dead level and then also the wallets underneath on the multi-chain configuration. So we will have that out in the publicly available market in the near-term future. And part of that is if you want to be on the network is running a node. So yes, if you wanted to run a node on the network and you wanted to pay a fee per wallet, we are allowing additions onto our network and the support for it. I got you in. Thanks, I mean, let's just answer perfectly my question. Thank you. All right, perfect. Thanks for checking in on that. Okay, next one we have is from Brett. And Brett wants to know if there's any preference with DAPS such as MetaMask or Trust Keys? Preference from like just like a personal preference or like a system. Brett, if you want to come off mute and just ask Mona the question directly, that'd be great. I don't know if Brett's still with us. I don't see him in the, he's there. Maybe he's not on video right now. If he comes off, we can revisit that question. How's that? Yeah. Okay, next one is going to be from Neil. If there's any way for a website app to discover an anonymous user may have an available wallet. Anonymous. So kind of no, because actually when you look at multi-tenant design if you connect to a multi-tenant wallet you actually it's, you won't know if it's multi-tenant or not. Like that's how it was designed. So I think if I understood the question correctly, yeah. Yeah. And I think it's probably something like, you know it comes in through an anonymous browser and some way you can detect that there's a wallet available to use through the browser. Okay, let's look at the next question then. Areeb has a question about what's the benefit of hyperledger in terms of dids compared to polygon or optimism? So I like a very neutral stance on that. They're all fantastic pieces of technology and it's all part of a larger broader, I guess more like a better technical vision for how we handle these things. So I rather than, so like treat it as more of like what's specific to your use case and what you want to use. The technology is sound between all of these solutions. What's important is what's your use case and just making it as interoperable as possible so that it's like seamless for users. For example, going back to, I mean our platform against specific to Indian areas I just want to mention this. User can sign up for whatever brand or loyalty client in our ecosystem. They can sign up from their site but then it's as if they've signed up for the ecosystem and then they can choose which brands and loyalty clients they want to interact with, they have that choice. So it's like actually like a multi entry point system if you think about it that way. But that was a bit of a tangent going back to your question. Yeah, just treat it as compatible technology really drill down to what is your use case. There's benefits for both having it on a public permissionless chain and benefits for having it on a public permission chain. Okay, perfect. Next question we're going to look at is going to be, are there implementations for SSI and what are the use cases that are implemented for SSI and banking BFSI sector? If you need clarification, we can get the person in post of that come off mute and talk about it. Looks like it's Abilash, does that sound correct? Hey, hello John, can you hear me? Yes, we can hear you perfectly. Thank you. Right, a quick question. So SSI, self sovereign identity. I'm aware of an implementation which happened in NHS UK. Apart from that, are there any other implementations? The answer is probably banks are probably doing. Yeah, some more like enterprise institutions often like either they're not super public about it. It's more like a secret projects or some are outright public about it. Definitely banking is working with a lot of these blockchain technologies, not just SSI, just other things in general. Yeah, yes, I'm aware banking is working in a blockchain because I believe the predecessor to blockchain, the Bitcoin, they first attacked the, what can I say, international payments via bank and the banks were the first one who picked up blockchain. That's my sense of reading it, but I may be right, I need not be right as well. Okay, so thank you for your answers. So hopefully there are more implementations in SSI. Let's hope by next January or by next year, next mid-year, therefore they are public on it. So just look curious to know about it. Thank you. Yeah, thanks for asking. Okay, next thing Mona, there's been a little sidebar discussion here with Jim and Eddie jumping in about the API gateway access and an SDK, so maybe Eddie and Jim, you wanna talk a little bit about that and Mona, maybe you wanna give your thoughts on it as well? My question is just that a lot of networks I've worked on, we wind up saying, okay, don't worry about having to become a member of, note on the network that's not needed or an SDK. Using the API gateway is the most common way to access networks and usually in large networks with many different participants, and API gateway is a pretty basic thing that you would say, yeah, we gotta enable that. Maybe that's already enabled in the solution, I just didn't know. Yeah, sounds like Eddie responded that they're gonna publish their SDK sometime next year. So I think that's coming forward pretty quick. Yeah, we have one of our clients that is going to be onboarding to the platform early next year and they are insistent on it being a publicly available SDK, so that is being driven by a client need in the first, probably first quarter, but I'm gonna say first half to keep us from getting in trouble. Sure, thank you. And then just to add on those two points, yeah, SDK-based, which- Yeah, that's perfect. It may be better than API gateway. Conversation that was going on in the chat that needed to be covered in the video so we can preserve it. And then Areeb's got another comment here. He's working on DIDS on optimism and he would love to connect around, let's see what he's looking at here. Folks working on DIDS and using other chains and their use cases. So he's basically saying, reach out to him on LinkedIn if you wanna catch up. And then Wade also did a great job of posting the Hyperledger Discord link and I'm always wanting to do a shout out to the community because engaging with the Hyperledger Discord channel is a great way to get involved and really learn about these great new projects. For sure, it's a wonderful community, very responsive and it's like a treasure trove of information. You can actually go in and before you even ask a question, search. Probably someone has had similar issues, struggle. You can get an answer. You can even follow up on threads if like something changed between versions. Okay, and then got one more question in here. It's talking about, sounds like they're referring to brands being your customers and what specific problems are you solving? And Eddie, I know Wade in with loyalty and we had a great presentation that Eddie did previously around what you're doing with Warner or music group and that whole idea. But if you have any other ones you wanna add, feel free to add those. I know what you mean, mom. I think that's the only one we can actually publicly talk about at this point. That's what I thought. Okay, no problem Eddie. And I understand the confidentiality there. I'm just going to address the question and make sure we're covering everything. Okay, well, that looks like all the questions we have in chat, if anyone has any other questions they wanna bring up quickly, just come off mute and ask the question. Otherwise, I'm gonna thank Mona for her time this morning and such a great presentation. We really appreciate it. And also to the other community members that have joined us today like Eddie and Jim for jumping in and talking about this great presentation. And I'm not seeing anything new. So Mona, thank you very much. Wonderful presentation. And we look forward to catching up with you in the community. Thank you as always John. Thank you so much. Thank you. Have a great day. Thanks everybody.