Architecting Next-Gen DID & Verified Credentials with Hyperledger Indy/Aries

[00:00:00]and then turn it over to Mona okay you are live great thank you very much David okay everyone well welcome to the latest uh Denver Meetup uh virtual discussion and we have the pleasure of having Mona rasuli join us today and she's going to be talking about building a Next Generation digital identity and verified credentials system using hyperledger Aries and Indie which is wonderful and uh I'm really looking forward to this great discussion and seems like we had some wonderful discussions here about verified credentials and tokens we had a nice presentation Last Time by Eddie and uh I'm looking forward to firing off into this one and Mona I'll turn in over to you to kick us off with the discussion sounds like a plan thanks John um 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 want to post where you're coming in from that'd be good as well okay um please let me know if you can see my screen yes it show perfect okay um hi everyone nice to meet you my name is Mona ruli I am a full stack blockchain engineer at oneoff and I'm also the founder of htic s uh today's talk is about a Next Generation identity system uh the specific title is building a Next Generation did and vacc 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 going to narrow down to our solution and our specific use case which is in the context of an ecosystem for brand and loyalty um so to start we're going to do an intro on decentralized identity then we'll cover the general design of self- sovereign identity then I want to talk about a topic that I think is personally extremely important which is accessibility then as I said we're going to talk about our solution at one of our model our design we'll briefly then touch on a little little bit of Forward Thinking some exploration and forthcoming ideas and then I'll leave room for Q&A um 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's actually last week at chain link smartcon it was um delivered in Seri nazarov's keynote and that term is the idea of the verifiable web and I think this actually this idea may transcend and be perhaps a bit more accurate when we talk about web 3 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 overtime and so there's been a decade of work by w3c and I also wanted to cover um a really good quote by Philip Jay windley he's former uh Sovereign share um and that is from his book excert uh from the O'Reilly book um 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 has kind of over time become a systemic problem where every website application or UI has this issue and it this comes at a cost for both teams and users so as we think and discuss the verifiable web um I wanted to list out some very specific key elements um there are some more but these five are really crucial to this idea of the verifiable web and so the first part is uh that it's a meta system it works best if it's a layer at top the current Internet as previously quoted it's like an identity layer at top everything um it's its own protocol the same way we have um TLS and SSL and so what this does is this enables um kind of a continuous system rather than isolated Central systems we have a continuous um layer that it's more that when teams Implement their identity Solutions it's just instances of a larger system rather than isolated um so this allows for more robust infrastructure um contributes to better security and privacy um and it's less a worry about moving users between different authentication pools and it's it's really interesting it's more about users moving themselves with their identities um and so this kind of continues into the next element self-sign identity um users have control of their own data um they control who they share their extens credentials with and to what extent this no gone is the notion of thirdparty trackers or business models that operate at the cost of privacy of user privacy um and the idea again is that it's user consent driven um this is guaranteed thanks to cryptographic verifiable truth which is enabled by a mixture of zero knowledge proofs uh their use case specific methods and that is what the cryptography is what allows us to establish integrity and credibility in the system um interoperability of course ties back into the meta system idea we're going to have many there's many blockchains and applications and systems and so this is like a decentralized um means of interacting with all of them um they're complimentary rather than isolated uh this also additionally makes sense when you think of the identity layer as a global system um each jurisdiction has its own laws and regulations and their own credential types so we really want it to be interoperable not just at a technology layer but like between um different countries and then the last one is like very crucial to just any form of blockchain design and that's to have modular design um so specifications evolve technology evolves you really want to be able to update to new standards update um have your system be scalable um and this is also vital when you even get deeper into it when you're thinking about um Quantum resistance um 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 want to Now cover the general design of self Sofer and identity so I have the technology stack for SSI um this is this graphic has taken from the trust over IP um and starting there's 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 um there's different did methods uh decentralized identity methods May usually correspond to The Ledger with which they're interacting with so whatever method you're using defines how DS are read and written to The Ledger for that specific Ledger um and I'll I have a slide for this next so I'll get more into it um the concept of a universal resolver then becomes key to enable this interoperability um 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 um layer above the network layer is the peer-to-peer communication layer there's this concept of Agents um every user has one or more agents with which they can connect to other agents with and have this peer-to-peer interaction um and then these agents also help manage their wallets uh so the protocol for this in the Indie are stack is dicom um 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 um and another powerful thing that enables this is the concept of pairwise dids where everyone has a did but when you're making a connection for that connection pair a specific c um can be issued and this also helps with privacy um another key thing with the connections is that they when you connect it's essentially indefinite um 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 um 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 this time um 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 um just so you know um when we're talking about the business application it's referred to as a controller for the agents over here um okay so going back then next to First the idea here of dids and DS 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 likely 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 the ID ether which actually has a corresponding EIP it's stag but there's the repository is active you have another example of did sov which is for the Sovereign Network that's an IND based Network did method and then so this string can be resolved to what's referred to as a did Doc um and it's like a specific thing that gets resolved um 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 um each person's did has a did dock which is sort of like sort of like metadata for that uh did okay so now I want to 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 um so agents that act as issuers agents that act as holders and agents that act as verifiers um and these are Aries based agents uh 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 um 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 um whenever the verifier would like to request that they can get a proof which is um thanks to zero knowledge proof technology zkp um and there's trust in the system in this flow because we have an underlying um Ledger we have an underlying blockchain that can help the verifier validate that oh this issuer legitimately issued these credentials to the holder um 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 um 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 I'll talk about this a little bit more when we get more into our design okay so again covering the credential process user's going to provide some information organization's going to determine the validity of this information and issue the user credential the user holds the credential in their wallets and then at um Whenever there is a need to prove their identity either this could be a formal request or or this could be triggered by a restricted action on a user interface it could be designed that way um they're going to 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 it' be like a six step back and forth of like uh requesting offering the credential and then over here as well requesting the proof validating the proof and so forth um and part of the validation check also is to check that the credential is not been revoked okay and what allows for the privacy and security of this is zkp specifically ZK snarks which are non-interactive allowing to limit the interaction between if we go back the prover and the verifier the holder and the verifier um this also enables minimal selective disclosure um 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 um and then a key aspect of ZK narks specifically is that they're suct so no matter how big um the amount of credentials are um the proof is always kind of a smaller message um which allows it to a lot more efficient um 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 an overview of quick overview of self- sovereign identity and decentralized identity now I want to cover accessibility um I wouldn't be the founder of optic St if I didn't cover this um and I think that uh this 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 um specifically when you talk about capture it's not accessible to everyone so for example a blind user capture is not exactly accessible there's even recapture or capture V3 which was designed to be more accessible however um has issues for the de blind community and also any type of capture or authentication system that is puzzle based actually goes against wag 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 um Twitter has Twitter blue um but these are platform specific and so which 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 um stepping away from that as well we have malicious actors there's thirdparty tracking there's Bots there's spam um there's also I I put social engineering on there because um very recently chat GPT was able to there was an article about this in May um it was able to trick a a team member of um some platform that it needed help it was a blind user and it needed help to get past capture and so it actually through social engineering the AI was able to trick the um person that it was corresponding with so what what SSI then provides as a benefit for accessibility is of course increased privacy thanks to zero knowledge proof technology increased security um Central providers have data leakages all the time um if you own your credentials and you choose who you share those with that prevents against that it's not in a central location um again user has control of data it helps avoid the third- party tracking it's no longer your data that makes you the problem products and probably the most important point for accessibility is um inclusion and equal participation in a much larger system and you have this like idea of true Universal login okay so now I want to cover uh our solution ask one 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 uh section you were going through was there's a question here from Imron that says does this mean that the entire uh let me get back to it here credential is encrypted using zero knowledge proof when presented to the verifier correct okay and then uh another follow on question that they had was what is the CL signature um so that is an ecdsa based it's an elliptic curve sorry excuse me it's elliptic curve based signature um it you can kind of look into it um I it's based so it's called CL because it's based on two individuals in cryptography that came up with it I called it CL signatures because their names are kind of long it's the common I'm not going to try to pronounce it but that's what's used to sign on the proofs okay perfect and then uh we got one more question then we can move on to the next section here um looks like BR 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 um and so the difference is like you have like right so desktop flow would be like a server environment and then mobile flow would be mobile environment um so like how you handle the credentials is a little bit different perfect okay mono thanks for answering those couple of questions and ready for the next section awesome yeah thank you guys so much for asking questions and thanks John um okay so uh next part I'm going to zoom in now on our solution so up until this point in the talk this is more of like a shaping our thinking for self- Sovereign identity and decentralized identity now it's more specific to what we did at w 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 want to this is a very quick architecture snapshot of hyperledger Indie and hyperledger Aries specifically so I'm going to break it down but this is the quick picture you have the hyperledger 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 top stack we have the controller which is where the business logic sits and interacts with the agents um very much so outside of this not so much an architecture concern is the indd CLI for some setup but it's not connected or interacting with the network it's just its own separate CLI so starting again going to start it's bottom up but on this picture it's top down um let's talk about the Indie identity ledger so Indie Ledger is a public permissioned 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 like ethereum for example which is public and permissionless but I um do want to mention that um 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 um 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 uh restriction and so what do we actually persist to this Leisure well public data so like public dids schemas some revocation info what we are not publishing of course is just like the credentials private Keys like obviously anything sensitive um par wise D IDs for example are nowhere near the Ledger um Ledger components so you have Indie plenum which is like the engine of hyperledger Indie uh it's the consensus protocol it's the core Ledger um components um so the consensus protocol for Indie is plenum Byzantine fault tolerance which is uh assumes a malicious bft fault tolerance so what this means is the equation is 3 F + one um where f is the number of uh nodes you can handle being um malicious uh so another key thing to this is that a Merle Patricia tree is used for State um this is similar to etherium actually they use also a merco Patricia tree uh Indie node um then which is dependent on plenum um handles more of the identity Logic for The Ledger part um and handles identity specific transactions the notes themselves are actually communicating thanks to zmq and I've included the idea of the subledgers because India is truly for subledgers it's a domain config pool and audit Ledger uh domain is where we have our credential definitions our schemas our identity config is where we can set some governance and some other like uh network settings configuration and then pool is where we have no Discovery Network anytime in node joins the network he would be um the transaction would be recorded in the pool and then audit literally the audit um just have better Integrity in the system um some additional technical Ino info um Ursa previously provided a lot of The cryptographic Primitives but it's been since deprecated um it's still used for individuals that are actually using IND the SDK which is like using an identity system without the use of the agents um now we just focus on a non creds and like I mentioned the SE signatures going forward and this is effective from the agent of 0.8x and up um another key thing to know as well this is perent to the agents you are required to use Oscar wallets not indie wallets with the agent um 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 or um for one of that's our uh private identity uh blockchain Network um next let's cover the agents so this is the architecture for an agent um the picture on the left is a simplified photo of the picture on the right which is also a simplified photo um so you have your occupy agent which has core capabilities for interfacing with your Ledger it also contains the um core capabilities of interacting with other agents um and that's again via dicom uh so what happens is your agent ser all of this functionality via rest um through Swagger and then you would write your business Logic on the controller um to interface with this which then interfaces again with the um Indie Ledger and then also in between your controller application which in our case is ajango application um 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 the between the issuer and the holder and the holder and the verifier there's a very quick um back and forth and that's that's what the web hooks there for it helps facilitate those really quick back and forth um requests okay um 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 um it's its own dedicated registry and it also plays on the idea of cryptographic accumulators um 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 um deploying more as your system grows um and again it's meant to run alongside the network and is 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 rebooked um 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 um Aries agents handle the requests to our identity chain and interact with our controller we use hash Corp vaults um because our architecture also consists of multi-tenant um mode for our you know there we need seed Management in the vault which is very secure um and also some backend token management um I've mentioned that our controller is written in Jango um this helps to communicate between the agents um and then our UI reacts um I'm going to cover it very quickly in the Forward Thinking part but we're also looking at react native for mobile agents so whoever asked about mobile agents react native would be pertinent to that um and then in front of our entire identity uh system in front of our entire um platform we have actually keycloak and our primary authorization point it allows users to sign up and access their decentralized identity and all of these um messages and flow is really like orchestrated and facilitated thanks to Kafka um so we can P Produce and consume identity Firefly and fabric messages in our system it it really like makes it a lot faster um quickly covering our specs so we're running agent version 0.9x and up um of course using askar wallets as mentioned 0.8x and up you should be on askcar wallets uh we're using multi-tenant design which allows for really good scalability and better desktop ux for the user um CL signatures we are using Indie credentials and we're working towards a non creds 2.0 at the time we had developed the solution um it wasn't quite there yet but now it's Forward Thinking what what we want to be um we use standard Asian connections to connect the agents um our deployment is thanks to kubernetes charts um so that's for both the agent and the tail server um currently open sourced is um open shift uh charts um so our devops guys Nathan and Corey um shout out to them uh 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 um more op time and then um agents all of our agents are currently aaby paste so it's all like in a serers 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 that's the multi-tenancy okay so what does our registration flow look like for users well um very seamless ux um users simply signs up they can sign up with um like their social provider they can sign up with a traditional account email they are first registered into keycloak um which is important because it helps with accounts and kind of social recovery mechanisms then they are registered and our identity system which again so they get their theid created sub wallet created and then um sensitive details are stored in hasor Vault then um specific to our wider platform they have they're using Fab connects they have wallet creation and wallet enrollment for our private fabric chain and then also we are our team is also using firly so they have a firefly registration once these three pieces are completed sorry four pieces if you key cook um the user is successfully created and um I actually emitted a demo from this talk because as I was like um looking at our system it's actually it's so seamless the ux that it it didn't really add value to have a demo for this just to show like messages going back and forth um and so yeah so beyond the registration flow it would go back to the credential issuance flow um so this is a fantastic design for Brands and loyalty because we can readily support multiple chains um the did in the user account Works across brand platforms so again think of it as like a microecosystem 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 want to be involved with um stronger CRM is enabled by this actually our um CTO Eddie did a talk on this previously and then also if anybody is side note is interested um Dennis and Eddie also did a talk on tesos connectors when we talk about multiple chains um so and then this also considering Brands and loyalty creates better user engagement because they feel more involved with earning rewarding sweep Stakes ticketing gamification interesting use case for sweep Stakes could be that let's say a sweep Stakes has um a requirement that you have to be 18 years or older to enter the sweep Stakes um you have already had your age credentials issued to you um but without having to reveal your age you can use predicate and it'll just verify whether you above 18 or under 18 it's not we don't need to know your exact age um and then yep uh just also I believe I mentioned this the idea of cross oh no I didn't um cross brand loyalty programs this is o something else that's interesting so you could have um shown loyalty to multiple Brands so you could have something as interesting as a flow of where you verify you have tickets to a concert you can have a um a specific Hotel Brands get a benefit Boost from using that specific brand so get hotel accommodations for that concert and then you could also use a specific merch provider um to get like a triple loyalty boost okay um now quick mention of future work and exploration for our team um so maybe let's 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 inter leave 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 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 um that is when you want a service to act on behalf of the agent on behalf of the user's agent we're not using a mediator in our flow um multi-tenancy you can there so there's two flows with multi tendency you can have a mediator you can have a relay um we're using a relay where um requests are relayed to the appropriate sub wallet great and 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 um with the multi-tenant design so right now we're on desktop only um I was going to cover it in the future work but that's something we're looking into to have not so just sync but more of like an export for Mobile Wallet um we could certainly um explore a sync mechanism as well it's kind of it's it's it's more in like um something we'd have to sit and like uh flush out more though yeah no that's perfect uh and then Colin had a follow on question which was which version of didc come protocol are you using um 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 Mon and then Jim's got a good question here he's asking does your solution have interoperability with dids on chappie networks chapi networks um it could be made to to my knowledge but um 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 uh next one is from Wade why did you choose to host your own Indie node Network rather than use one of the existing services like Sovereign or indicio so Sovereign and indicio are and by the way hey wait he's he a fantastic member of um the hyper leure Community he he's always as answering questions for individuals so shout out to Wade um so dco 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 like a platform for Brands and loyalty we would certainly be interested in um working with Sovereign um and in a dco 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 um but so because ours is specific to um like one of our clients for example I can talk about this publicly is Warner um so like Warner is our first client they're in our identity Network it's specific to um their their mechanisms and their needs okay perfect uh 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 form yeah absolutely Carter already answered that in line by the way okay it looks like Carter did answer it in line 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 uh we're going to 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 um we can um currently we're using uh Sovereign did did sov um but yeah so like again if I as I mentioned in the beginning of the talk ideal situation is when you it's irrelevant you just support whichever wants okay perfect uh then the final question is have you looked at Civic pass have not um feel free to uh 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 than so we're getting towards the the last one is very quick and um thanks Eddie and Carter for the assistant answering questions um so uh future work exploration so um exploring mobile design a lot of questions have been asked mobile design so we're looking at um afj and bolds um also going back to accessibility I think it's very important if possible to support both desktop and mobile um and users can decide which their preference is um next then as well a non creds V2 um recently in the community there was a mention of the hyperledger Agora project with additional ckp properties additional signature schemes so that's something to um at least explore and look into and then beyond that um just expanding out our use cases like I kind of mentioned the sweep Stakes use case but um other ones outside of that um and so now we hit the Q&A okay perfect uh so go ahead and feel free to post it in the chat and uh if you need to you know articulate the question just let me know in the chat that you want to talk as well but one of the questions I had for you Mona is you know you had that great uh run through about inclusiveness and you know making sure things like accessibility are in play for the internet and so one of the things I was thinking is you 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 um I think California specifically is quite strict with that um so legislation definitely contributes and I want to say like maybe incentivizing teams to start with better accessibility practices and accessibility is really good because you're involv like web 3 is built on community um 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 um 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 um like you know being out for like many years or perfect and then kind of a follow on to that is you know I know 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 you know maybe even cross protocol kyc acceptance um 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 um so right as we talked about the idea of like Universal login Universal authentication I think that'll definitely help with that um kyc is a very tricky process um I know there's like some um 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 required to do it that also contributes in accessibility okay perfect uh looks like we got a link for civic in there so we can check it out if you want to look at that uh link and then uh let's see what Jim has to say here Jim you want to come off and ask a couple of your questions that you have in here come off one of them is um again back to the idea of interoperability which you certainly hit up 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 uh a lot of problems go away but one one of the benefits is there's something called the gly network so most financial institutions now because they're responsible for kyc AML compliance kind of thing are looking at um gly dids if you will for uh legal entity which is sort of very different than a sovereign did if you will which doesn't have those same issues um and same responsibilities I'll say so as a result like companies will or sorry I can think of many financial institutions that issue these um life dids um and say okay this is now the IBM's did uh 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 though 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 uh leverage that um instead of having to reenroll a company again in another Network which you know 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 not a winning strategy longterm for a lot of things um where you're actually holding your own wallet it's much like your 40K your IRA is not in your wallet um you know 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 EIP 4337 allow the idea 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 yep thank perfect thanks Jim appreciate that uh 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- tendency enablement okay so um fabric by the way um tends to be more like raft consensus based um we are using fabric as our private chain um so like that's how we handle like minting nfts and and all that functionality okay uh then Collins got another question here and he just wants to double check can I get your services and deploy them on my own infrastructure um do you mean like on board onto our Network or um he wants to get started with like hyperledger IND and IR Colin if you want to come off mute and ask Mona the question directly that maybe it would help hey can you hear me yeah okay good what what I what I mean is you have mentioned something like Helm charts and where it's working so this implies kind of to me that I can get the services in deployed on my own infrastructure which I'm running and then connect to your blockchain of course that's what I meant uh okay so we do have um some kubernetes charts they're currently not open source um I can I believe the intention was to open source now no no no not only open source in general if you have such a option this I don't know prepaid plant or some subscription plan that's what I'm more asking I doesn't mean to be only on open source I got you want me to cover that yes please Eddie that's yeah so are actually putting together uh 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 we will have that out in the publicly available Market in the near term future um 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 you know pay a a fee per wallet we are allowing additions onto our Network and the sport for it I got you I mean thanks I mean that's just answered perfectly in my question thank you all right perfect thanks for uh 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 uh preference from like just like a personal preference or like 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 oh he's he's there maybe he's not on uh video right now if he comes off we can revisit that question how's that yeah okay next is going to be from Neil is there any way for a website app to discover an anonymous user may have an available wallet Anonymous so kind of no because actually um when you look at multi-tenant design if you connect to a multi-tenant wallet um 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 um 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 uh AR 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 um 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 um the technology is sound between all of these Solutions um 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 um for example going back to I mean our platform again specific to Indian Aries I just want to mention this um user can sign up for whatever brands or um loyalty client in our ecosystem they can sign up from their site um but then it's as if they've signed up for the ecosystem and then they can choose which brands and loyalty um clients they want to interact with they have that choice um so it's like actually like a multi-entry point system if you think about it that way but um that was a bit of a tangent going back to your uh question um yeah just just treat it as compatible technology really drill down to what is your use case um there's benefits for both having it on a public permissionless chain and benefits for having it on a public permission chain okay perfect uh 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 in banking bfsi sector if we need any clarification we can get uh the person that posted that come off mute and talk about it looks like it's avalash does that sound correct hey hello John can you hear me yes we can hear you perfectly thank you right uh a c question um so SSI self- Sovereign identity I'm aware of an implementation which happened in NHS UK uh apart from that are there any other implementations the answer is probably um banks are probably doing yeah um they some more like Enterprise institutions often like either they're not super public about it it's more like a like a secret project or um some are outright public about it um definitely banking is um working with a lot of these blockchain Technologies not just SSI just other things in general yeah yes yes I'm aware banking is working in blockchain because I believe the predecessor to blockchain the Bitcoin they first attack the uh what can I say International payments bya bank and the banks were the first one who picked up blockchain that's my sense of raing it but I may be right I need not be right as well uh okay so thank you for your answers so hopefully there are more um implementations in SSI let's hope by next gen 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 uh next thing Mona there's been a little sidebar discussion here with Jim and Eddie uh jumping in about the API Gateway access and an SDK so maybe Eddie and Jim you want to talk a little bit about that and Mona maybe want to give your thoughts on it as well my just that a lot of networks I've worked on we wind up saying okay don't worry about having to become a member a node on the network that's not needed or in SDK using the API Gateway is the most common way to access networks and usually en large networks with many different participants and API Gateway is a pretty basic thing that you would say yeah we got to enable that maybe that's already enable in the solution I just didn't know yeah sounds like Eddie responded that uh they're going to publish their SDK sometime next year so I think that's coming forward pretty quick yeah we we have one of our clients that is uh 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 client need in the first probably first quarter but I'm going to say first half to keep us from getting in trouble next sure thank you and then just to add on those two points I yeah SDK based which that's perfect conversation that was going on in the chat that need to be covered in the video so we can preserve it uh and then re'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 want to catch up and then Wade also did a great job of uh posting the hyperledger Discord link and I'm always wanting to do a shout out out to the community because you know engaging with the hyperledger Discord channel is a great way to get involved and really you know 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 issue struggle you can get an answer you can even follow up on threads if like something changed between versions okay and then uh got one more question in here is talking about sounds like they're referring to Brands being your customers and what specific problems are you solving and uh Eddie I know weighed in with loyalty we had a great presentation that Eddie did previously around you know what you're doing with Warner Music Group and and that whole idea but if you have any other ones you want to add feel free to add those you I think that's the only one we can actually publicly talk about at this point that's what I thought okay no no problem Ed and I understand the confidentiality there I'm just wanting to address the question and make sure we're covering everything okay well that looks like all the questions we have in chat uh if anyone has any other questions they want to bring up quickly just come off mute and ask the question otherwise I'm going to thank Mona for 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 you know talking about this great presentation and I'm not seeing anything new so Mona thank you very much wonderful present and we look forward to catching up with you in the community thank you always John thank you so much thank you have a great day thanks everybody