 Yep, you are live awesome. Thank you so much And then I will share my screen once Hello everyone and welcome to the November 2nd meeting of the identity special identity special interest group identity sake here at Sorry, I guess I'm stuck in my throat Yes, welcome to the November 2nd special identity interest group for identity Today we'll be doing a quick working group status update and then we have a couple presenters here From polygon ID. Thank you auto and alexander for joining us here today Just a reminder we are under the linux foundation antitrust policy. So please You know be nice to each other and don't say anything that you don't want out in the public Jumping into our working group updates Looks like the hyper ledger any contributors working group met last week. Was anyone able to attend this session that might have a recap for us? All right, looks like they were discussing some IW takeaways and any 2.0 initiatives Moving on it looks like the areas working group met yesterday. Was anyone able to attend this session They were discussing Sorry, I did attend but um, yeah, there's a lot of topics Um, probably a recap is covered as well All right, sounds good. Thank you. Um, and then yeah, if anyone has any questions they can these all linked to the latest meetings. So Uh, moving on it looks like the uh, areas by fold users group met on the 24th Was anyone able to attend this session? All right looks like they're also discovering discussing some IW takeaways and uh, the next updates Uh areas cloud agent python met just a couple days ago as well. Uh, was anyone able to attend this session? Um, yeah, I was there. Um, there's another um, first, um, really release of acupy Probably is I don't remember the version number of top of the head, but you might just want to add the note. It's like um But unfortunately, I can't really What the number is off? All right, no worries. Thank you, Tim. We'll get up. Sorry about that Yeah, no worries at all Uh Moving on it looks like they haven't met in a little while That was your ursa and non-creds. Uh, it looks like T. I. O. P. Had an all members meeting in october Uh, was anyone able to attend this t. O. I. P. Session? All right, it looks like they're looking at a few new task forces Uh, and then the technology stack working group met just a few days ago as well Uh, was anyone able to attend this session? All right, well, they have quite a few different task force Next steps. So if you'd like to learn more, you can find out some links there Uh, moving on to the diff didcom spec working group. Uh I was unable to find Too much on this in terms of updates. Sam, would you have anything for us? Uh, we did we did meet. Um, the the discussion is about whether we advanced the didcom to spec to the itf Which was the original plan. There was a little bit of a pause while While the work matured a little bit In the you know, the creation of the users group, etc And also some question about how that related to the trust of rp trust spanning protocol The the rough consensus is coming down on the side of advancing it to the itf Under the possibility that it wouldn't provide That it wouldn't provide the tsp may not provide what we really need In terms of of what's going on So anyway, the the the short answer there is that advancing the spec to the itf is likely All right. Good to know. Thank you, Sam And then for the didcom users group Uh, were they able to meet recently or this It's less relevant They didn't meet this last week because it was a fifth monday and they don't meet fifth mondays Or but still going on with some good discussion about stuff that's going on and and all that All right, sounds good. Thank you Um Looks like the diff interoperability group has not met super recently And that looks like a cold meetings go All right, unless anyone else has any other updates they'd like to share I think we'll move on to the presentation Giving it a few minutes. All right. Uh one second as I stopped sharing my screen And then uh today we have auto and alexander with a presentation for us. So take it away. Uh, you too Thank you so much. I appreciate the opportunity to present here a shout out to alfonso who I met in peru Um, you know great great to meet the folks from hyper leisure in person Also shout out to sam also from the didcom group great to great to see it and Keith as well Uh, so yeah, my name is otomora. I'm based in san josecos to rica and uh, i'm the america's uh tech sales lead for polygon ID And i'm joined here by my colleague alexander or As we like to call him sasha. So sasha, maybe you want to introduce yourself Yeah, hi everyone. My name is alexander brieshnev. Yeah, I'm a technical leader at polygon ID And responsible for the development of the protocol part of it Excellent. Uh, yeah, so, uh, hopefully you can see my screen Um, and we can get started with this presentation so, uh, yes also in the spirit of uh open sourcedness and Freedom we are releasing this presentation under a creative commons license so that it can be leveraged for future use in any other setting Okay, and so yeah, so just a little bit of the agenda looking into polygon ID very valuable presentations using setk proofs Uh, some overview of our did method how the ck proof are generated Uh, the credential issuance methods that are available The uh discussion around identity management and other features of the did method uh, also some, uh Details around how our miracle trees operate and how we perform claims revocation Uh, then just a final look at what's available today. Uh, maybe some contrast also with other Uh privacy methods including bbs plus and others And then also some discussion of how the polygon, uh, p os chain compares to hyperlegio indy for the usage of uh blockchains and identity Okay, uh, so have you or a friend ever done this? Um, so not not a quite a common thing, but I believe that you may have seen it and What we think of this is Before one selected disclosure in the physical world, right? They want to hide certain aspects of their Identity identity documents. They want to keep certain aspects private But with the internet being You know so widely available and almost it seems like you can't keep a secret nowadays They maybe don't know that you can do this in the virtual world as well Thanks to you know ck technology This capability is now possible and it is possible in a privacy preserving way as we'll explain so, um our DIT method, um Allows the ability to use set k proofs, right? So you would have a very viable credential the very viable credential would have information about you Uh, your data birth your place of residence. Uh, maybe your credit score a number of other things Through the interaction with the third party verifier The third party verifier can ask questions about it And they would ask questions using a set k query language that we've defined And the questions can be in the form of oh, are you over 18? Uh, show me that you are a resident of colorado or show me that maybe you are not a resident of list This list of sanctioned countries or it could be even be a range question like Show me that your credit score is between 500 and 600 So these types of questions, um Are asked by the verifier The holder of the credential can then generate a set k proof from his device And his device could be either the phone or the browser extension identity wallet that he's using to be able to respond to this right this, uh Answer then comes in the form of a set k snark proof that is generated And uh, then the third party can verify that that proof is correct, right? And so in answering that question, you've only revealed The correctness of the proof and they just no answer to The question that was being asked by the third party, right? And you didn't actually reveal the full credential, right? So quite similar to what you would do with other, uh, technologies that enable this as well But we have our own way of doing it using set k snarks So a common question that I get is our polygon ID set k proof stored on chain Because we do have other chain, uh Scalability technologies that store the proofs on chain and the answer is no, right? We don't we don't do that We keep the users data private but Can the polygon ID set k proofs be verified on chain and the answer to that is definitely yes And as you will see you have the option of either choosing that the proofs be validated off chain Or that they be validated on chain, right? So you have the ability to choose either one How does uh our did method look like at a high level, right? So, um our did method as you can see uses uh json ld's for the credential schemas We have those credential schemas being generated. There is a Also a notion of the identity state of the issuer being recorded on chain Before you can issue credentials and there's a couple ways to do that as well. We'll get into the details of that But essentially once the holder has those json ld files in their device They are then able to generate a verifiable presentation, uh, which we've Enveloped in a modified json web token jwt or jot That is actually called that jw set for json website or knowledge that we've come up with So this presentation packs these set k proofs that are the response to the queries being made by the third party, right? And then afterwards the verifier can check the identity state check the correctness of the proof Check that the proof has not been the credential has not been revoked and a number of other things, right? So the first method to issue credentials is what we call the sig method, right? This method relies on the issuance of credentials with a bjj signature Um at this point the credential is then not added to the issuance mercury But we just do a baby job job signature, which is then verified upon presentation um This is probably the method that uses the least amount of gas and is the most economical in terms of spending gas on chain Uh, so after the initial issuer state has been published, which is just a few cents to get to do that Then it's just free to issue as many claims as you want And this is very similar to the ether method which enables this capability as well, right? So you would see the user providing their information the credential is then uh, not added but instead we just have a bjj EDDSA signature added to the credential and then you can uh, just verify it, right? So as long as as you're not, uh, revoking the credential or rotating keys as an issuer You're essentially not needing to spend any gas for this you can issue thousands of credentials without any need to spend gas So this is the first credential method that we have The central credential the method that we have is what is called the mtp method or merkle three proof method In this case, uh, the validation of the proof is done against the hash that is published on chain, right? Uh, no personal information is ever shared or stored on chain Uh, so we preserve the privacy, but interestingly this method allows you Uh to do some interesting things such as having smart contracts being able to issue credentials, right? Uh, and this is a method that would uh do Uh require the spending of gas in this case We've estimated uh, approximately two million gas on average, which is point three six medic Which is you know, still pretty pretty minimal Um on on the gas cost to do this, right? And also if you wanted to do, um, you know Massive credentialing issuance you could do batching so that you could optimize the cost of the gas issuance process, right? So that that would be something that you can do as well so So this is a second method Now moving on to other features here, um They did polygon ID, uh method also enables you to do identity management, right? So we do support the ability to you to Rotate keys and have multiple keys, right? So an identifier controls a set of keys for which for web three by the way It's like trying to get away from that because People think tend to think in web three in the blockchain world as an identifier More of a public key, but we actually think of an identifier controlling a set of keys, right? So that's that's how we like to think about it Um, we do also provide a civil resistance proof of uniqueness, uh through the usage of nullifiers And then also a history of the profiles used which I'll get to in a little bit Is used in a their identity wallet? Um, I would also like uh, Sasha here to comment on our genesis identity Uh, Sasha, maybe you want to comment on the various ways in which the genesis identity can be, uh control Yeah, sure. So, um We have two ways of creating identity. Basically, uh, we have The ones that we initially started it. It's a baby job job key controlled identity where we added into the claims tree and then it's a Becomes an identity state and part of this Identity state hash is Then becomes an identifier of the person but also we Later created another way of creating identities that is based on just Ethereum address So it's Ethereum account controlled identity where it could be Externally owned account. Uh, that is that is essentially a key keeper of of Ethereum Or it could be a smart contract or Um, abstracted account Yeah But uh from from a functional perspective as they are almost identical. There are Um, a few minor things That differentiates them but yeah Nothing too big Perfect. Yeah, so exactly. It just depends on the user's preference of which Way they want to see their identity Excellent So another interesting thing and I believe this is the best way to explain it With this movie I find there's probably the best metaphor Is the ability to manage profiles, right? So the default behavior that we have is that we generate an anonymous random identified For each interaction that the credential holder will have with third parties, right? This is very much similar to what you would do with The incognito mode in google chrome or in brave where you're being protected against tracking and then you're generating random identifiers And you know skipping cookies and things of the like, right? If the user does want to be remembered by the third party They can then decide to select a permanent identifier for interactions with that third party So for instance headweek could be your gaming profile Where you are going online and using nfts collecting You know assets and collect digital collectibles, etc But then, you know, maybe patricia could be your more serious defy profile, right? And you can go on compound and ave and spend, you know, some stable coins and get some return But interestingly because of the usage of setk proofs Any credential that is issued to headweek can be used by patricia interchangeably, right? so You can kind of You know use any credential And then show a specific identifier or expose a different identifier as you as you prefer Right. So this is a nice ability. I believe for wallets and for people They just want to segment their digital life, right? They want to split out their identities Sometimes you have a work profile. You have a kind of non-profit that you volunteer at and then you have your You know your your gaming profile and you want to keep those things separate, right? Also another feature here is the ability to bridge your identity to other Chains in the ethereum ecosystem, right? So the identity state contract, which we will introduce in a little bit Can be bridged to other ethereum one To the ethereum l one chain as well as to other L2 chains in the ethereum ecosystem and this effectively enables polygon ID Very fabled credentials to work in other chains in the ecosystem, right? So this is currently done through our alliance with rademo Which they allow disability to do identity state bridging, right? And this is a nice ability which makes You know kind of your identity state portable across the ethereum ecosystem Another nice feature is the setk query language that I was mentioning So maybe Sacha, do you want to mention some features here? predicate proofs and and so on? yeah, so it's query language that is inspired by by MongoDB query language. So you you can just write that I want proof that You have a credential, let's say of A KVCH credential schema type with Birthday that is more than some value. So in this way, you would prove that you are over 18 Or you can Do a selective disclosure you can ask I want to to see your passport number or name from from this credential. So we have this query language, which is Supports different operations like less than greater than equal non equal in the least not in the least and And also selective disclosure Yeah Perfect. Yeah, so also on the proof verification as I was mentioning the proofs can be verified either on chain You can feed the proof into a smart contract and take some ability Do an airdrop or do another action Or you can just verify the proof of chain and on your own just validate that the proof is correct and then take some action as a verifier Another interesting thing, which I believe Can be of interest to the group is sort of the usage of this format that we came up with called the JSON website or knowledge But I'll let Sacha maybe comment on this further Yeah, essentially it's JWT token where instead of a signature in in regular format that is digital signature or hash of data with with a secret key instead of that we are doing Signature using zero knowledge proof We Why we are using it is that because we have this identifiers and profile identifiers and with zero knowledge, we are proving that user is Controlling this identity. So it's kind of signing This message that is inside with with this proof that controller of this identity that is saying something about myself Perfect. Thank you for that Yeah, and also moving on to some additional features. I know something this is something that sample like of course, which we also love did come We do have another patient of did con called identity come And as sam would know this communication is transport agnostic and would not require the usage of ATTPS like open id or all those So you could do, you know transfers over bluetooth or nfc You know think of situations like a traffic stop or a place where you may not have that ability to connect over the internet And you just want to have a quick communication from device to device So that's a nice feature Some additional features as we said also smart contracts can verify credentials that were issued off chain and on chain And then smart contracts can act as issuers of credentials using the mtp or miracle tree proof method as well So getting into the miracle trees, right? So we do have a set of miracle trees and we're going to go Explain each of them a little bit more detail The initial one is the claims tree and this claims tree is issued by the identity holder And they will be able to add Either keys or credentials issued to this miracle tree. It is a sparse miracle tree And each credential that is added to this miracle tree or key has what is called a unique revocation nonce This revocation nonce can be used to revoke claims and we will provide more detail To that later, but as you can see the credentials Issued can be either keys or actual credentials and this allows you to add, you know more keys and so on I think there's a question. Well, we'll take we'll take that question at the end But yeah, great question. Actually tim Okay, uh the identity state, uh as well So this notion of the identity state, right? So initially identities are in what is called the genesis state As sasha was mentioning there where their identity state can be proven directly with the identifier Uh, but then the identity states are published in what is called the gist or a global identity state tree Which is a sparse miracle tree on chain And then proofs can be provided to demonstrate that one of the identities is being used without revealing which one, right? So this is this this feature here that we have Then the smart contract that we have on chain is kept up to date with the information of the identity state We'll also provide more details on that later But the smart contract has a check of what is called a state transition function Which is required to update the identity state and verify the correctness of the transition. So You can create your identity, right? But in order to register that identity correctly, uh and issue credentials that can be verified On chain, you do need to have this initial state transition function done, right? So This does require to spend a little bit of gas as I mentioned in the SIG method But once you do that, you can issue, you know, many credentials and then as long as you're not revoking keys or revoking claims or Adding new keys, etc. You won't be spending any gas Okay, so then pulling it together, right? um I believe maybe sasha you want to comment on on how the there's an interplay between these three miracle trees And the hashing that takes place Yeah, um, so from the very beginning Identity is created on a user's device in the wallet. Um, our user generates his public and private key and The first claim in this claims tree is actually a public key that belongs to this user. So from from this We just generate Hashes of this miracle tree not miracle trees. We hash them together And it becomes an identity state of of this identity Which becomes an identifier of this identity from the very beginning and Actually, we can prove Just from from this Identifier That user has control over over this key user can can prove that So he doesn't have to be on chain published or or somehow registered To be able to use this identity to prove something and Then over time user can issue credentials to himself to others And also rotate keys or add revoke keys, which are essentially just special type of credential that user has and Yeah, when user is revoking What he's actually doing he's adding revocation on so that is inside the credential He's adding it into the revocation tree And he needs to publish his identity state At that moment So that it takes into force so when others are checking That Proof is correct and credential is not revoked They are referring to issuers identity state. They see Check that it's The one that is published on chain Yeah And third tree is a root of It's a root three it just has History of older Claim tree roots that we had It allows us some interesting things to do in in the future like Possibility to prove that credential was issued at some point in time In the past but without revealing identity state when it happened So it's Another privacy feature of our protocol. Okay, perfect Yes, so moving on We'd like to also contrast a little bit of the usage of zero knowledge proofs and identity Uh, you can see some information here. Uh, just to contrast You know, the proof type is is different. Obviously when you compare polygon ID to anon crits, right? We're using g16 With snarks, we do have the option to eventually migrate over to starks Whereas anon crits use cl and bbs plus as its own signature scheme Also, the keys that can be used. We have baby job job and then more recently We've also introduced compatibility with the theorem controlled identities Anon crits uses this link secret for identity binding and the rsa for the cl RSA signatures Whereas bbs has this pls scheme here Selected disclosure can be done by all of them predicate proofs Well, as far as I know currently only supported by polygon ID and anon crits Uh, the private non revocation proofs, uh, we've implemented using sparse medical trees, which are computationally efficient Anon crits does it using the crypto accumulators, which are a bit heavier and more storage was required Uh credential issuance, uh, we've issued in the very fabrication format against the identifier. It is non interactive Um, this can be generated either from a mobile device with our c libraries that are heavily optimized or from a server Uh, the anon crits uses a custom format against the link secret commitment And it does require the interaction with the identity holder Um Also bbs plus is issued in a vc format against the identifier is non interactive The off-chain verifiability for us it is possible if you do cache the Um on-chain issuer state as well. So, um So, yeah, some some sorry. Sorry actually on-chain verifiability It is possible for us to feed the proof into a smart contract to take an action. Um, because yeah, we can we can feed it into a So that it is my contract okay, um This part here, um I I don't want to come this across as as like, uh We're attacking hyperledger indie by any means. Uh, this is just a comparison of scalability. Um, again polygon id we've, uh, anchored it to the polygon pos chain for this example, but it could be anchored to any other ebm chain um, and also this this is probably Um, a little bit unfair. I would say because I believe I heard that hyperledger indie might be moving onto a besu Network, but so just bear in mind that we are assuming the current state of indy here. And so you can see some of the comparisons on the blockchain network, right? We set a public interoperable network in a theory with l2 chains Um, in the case of hyperledger indie, it could be either permissioned or public on the sovereign network Um, we do have the ability to do interoperability with other evm chains as far as I know That's currently not possible in indy the on-chain verifiability Uh, we do have that ability. Uh, whereas indy doesn't at the moment Then there's a little bit greater decentralization on the polygon pos chain, right? Um, I do understand there's some limitations as well with the number of nodes that indy can support Um smart contracts. We uh support them via solidity And credential issuance Um, I'd say pretty pretty large still, right? Um, except maybe in our case because of the segment that it potentially might be unlimited Um, the credential issuance cost. I think also there's not A huge difference. Maybe we're slightly cheaper Um, so yeah, so it just I think there's you know, a little bit of a difference there, but not not significant The schema hosting is interesting though. However, because we do allow schemas to be hosted in ipfs or http Whereas hyperlegio indy would require that The schemas are hosted on chain So, yes, um that's um all I had um, maybe just looking at our our ecosystem, right and the Elements that are available today. So for users, we have a polygon id app Which is a reference identity wallet to manage identity Um, you can generate claims generate setk proofs But it's not the only wallet, right? We're not in the game of controlling people's Identity wallet experience. So we actually have Other wallets in the ecosystem including alt me verita wall id and clv So they've integrated the polygon id sdk's um so, yeah The sdk's as well. You can have them in flutter Um, they do have an android and ios native wrappers The javascript sdk Um, it's also available if you wanted to use that instead of the flutter Um to integrate for issuers We do have the issuer node Which is a server that you run in your infrastructure and enables you to issue credentials You can host that yourself or you can host that in google or aws, right? Actually, it's also available on the google cloud marketplace We also have sass providers Including doc monarchy and kaleido that you can use to host that issuer node They are currently providing that service and then for verification of the Presentations you could use our off-chain libraries In golang and javascript or the on-chain templates that we provided in solidity, right? So, yes, um, you can take a look at our ecosystem. Probably some familiar names here You know another nice one. I would just take a moment here to highlight is masca Which the plugin for metamask enables you to Have a polygon id working inside of metamask So I think that's a nice feature But yes, we also have other other players and you know, I'm not going to name them one by one, but we're happy to See this ecosystem grow and we do have a marketplace of credentials that is coming up as well So, yes, uh, that's all that I had. I leave the contacting for here And also our links to our um tutorials that you can check on your own Uh, and then I guess I'll jump into questions Um, yeah, so just go ahead and take questions First question is there a link to this presentation? Um, yes, we will provide a a public link, uh to this presentation I'll share that with uh with the folks here after the call. Okay. I think there was a Yeah, go ahead I mean, I don't know much about polygon It's the p.o. What's the chain is is um, p.o.s Is this for like is in production use case of this use of this right now? Is it more development or where are you at in actual adoption? Yes, we have Two global banks and an australian bank Uh, deploying production use cases Uh, I can't name names yet, but uh, it will be going live soon Uh, and then we also have a couple of gaming use cases, uh coming out next year currently actually you can get Some gaming credentials, uh, which is actually nice. You can port over some steam id credentials Um, and then use that in a a third party Uh, community doubt to have a specific access to a discord Um, so yeah, it's been growing. Um And yes, we do have some I would say web three and web two use cases It's it's sort of a mix perhaps initially we would be more focused on the web three world Kind of providing solutions to dowels and d5 protocols, but we're also getting interest from the web two space as well Hey, great. Thank you Okay Yeah Yeah, thanks for the great presentation. Could you talk a little bit about performance? Um, it's been a while but the last time I tried the polygon id wallet I mean, you know the the demo wallet, you know, it all worked great, but I did notice that um, you know a lot of things took I mean, like a lot of zero knowledge architectures like when the interactions themselves take time as in like seconds five seconds 10 seconds What does that look like today? Um, like what do the what what does the speed of transactions look like? Like, you know the the verification or issuance or things like that. Yeah. Yeah uh for for the verification there are things that you noticed is Uh, actually it takes much more time to Get schemas from the internet Check revocation status from from the issuer or from on chain And so on then generate zero knowledge proof like zero knowledge proof generation takes about two seconds right now To to generate zero knowledge proof itself the rest takes this getting revocation status getting um Credential schema from ipfs or from HTTPS that could be pretty slow in case of ipfs And and we are currently working on caching the schemas so that we Do it much much faster With with caching so yeah Performance will be improved a lot Thank you Yeah regarding regarding issuance. Um, there is no like Hard limitations on on scalability like you you can scale it very much There are things that you need to do. It's it's just ddsa signature and And posidom hashes that you that you need to do so You can put a lot of machines and do it in parallel. No problem. So um, there is no limit on on how many it's just a performance of a single machine. So You you can scale it Yeah, we're getting better We've optimized our c libraries even more. I think It'll get better over time Uh, I've got a question. Um, the on chain issuance and verification requires the The attributes themselves to pass through a smart contract, correct? No, um for the verification Part so what what we are doing is we are actually Rock-redential is Stored on users device Then, um We Split all the fields of these jsonl documents into keepers they are added into into the merkle tree and when user wants to prove something based on on this credential To the verifier verifier asks a specific question. I want to know that users birthday is less than 2000 Uh Let's say, yeah, uh year and And so on and and then a user just has this input in in form of the key query And generates proof on his device And sends this to to the verifier this proof And he is not sending credential or are Um, he's not sending any other data Other than this is your knowledge proof with the reference to to the issuance identity state Right, but you but for on chain verification That requires the verifier. Yeah to use the chain to verify that, correct? Yes, yes, it's uh, so if it's not a predicate proof, so it's So if it's not a predicate proof and I'm actually want to reveal an attribute Then the attribute that I'm revealing does travel to the smart contract for verification Yeah, if if you're doing selective disclosures and obviously, yes Right, okay And same thing for issuance, obviously can't issue the credential that the attributes in play So on issuance, you would also have to pass the You mean for contracts for on chain issuance, you would have to pass the attributes to the smart contract? Yes. Yeah, so for for the on chain issuance, we have actually Two major ways of doing it One is when you're collecting data from from the data that is actually on chain Let's say it's your serial balance or some token balance or that you own NFT or you have a trade volume of some amount on uniswap or whatever and then You as as a user you are just calling this smart contract that fetches this data Embed sit into data structure that We call core claim and and then add sit into the Merkle tree of this identity on chain identity issue and and then yeah user is able to to use it to prove something in private to other smart contracts or To off chain verifiers, but he can do that from another. Let's say a serum address and in this way he can break this link between Yeah, I own this amount of money. Let's say on on one a serum account, but I don't want to reveal it and link my identity Another a serum address To to the one that has this amount of money and and then I can use it and with just zero knowledge proof I can prove that I have this amount more or Like whatever requirements are on the verifier side and another way of issuing Is actually with zero knowledge proofs. So smart contract can actually verify that uh user have generated Credential to himself in a correct way based on data that is verifiable somehow and this could be For example, uh user can have a digital document that is digitally signed by a government For example, he can have a biometric passport. Yeah, then he may FH this data from biometric passport Generate zero knowledge proof that he has it. He has That it's digitally signed by valid Key of the government and then that he transformed and put Fields from from this data blob that was signed into correct places in in the Our binary claim structure And and just provide this zero knowledge proof to the contract. So This on-chain issuer would then just verify that zero knowledge proof is correct and that Hash of the claim is this One so it's it's not revealing any data to the on-chain issuer in this way just the credential hash, but it has a lot of fields that Let's say user can have a One field with with random numbers just for to Prevent brute forcing So that then this hash is Together with zero knowledge proof is sent to smart contract it does verification that The process was done correctly and yeah, then it is issued in this way without revealing any Uh data actual to to the to the smart contracts that performs issuance Thanks All right perfect Yeah, there was there's a question there in the chat. Are there any governments that provide electronic passports? Estonia or mobile drivers? I mean, I think there's a couple of efforts going on to provide mobile drivers license Instead of california and a couple of others in the u.s Um Yeah, I think there's there's some I don't know about the electronic passports Uh, but maybe such a do you know about electronic passports? by Yeah, like Biometric Passports are pretty common in the world. So you You can just read it with nfc in your phone and We've done that before so it's it's pretty easy to get this data from from biometric uh passport or id card and in in many countries As they are available, so yeah Okay, perfect. Uh, Keith Yeah, so I guess my question is so I think like a lot of this technology is really interesting specifically for a lot of the On-chain interactions, but I think my question would be You know, it still kind of strikes me as like, um, I forget my language but like a proprietary identary technology stack And I guess the question is like, how do you guys use standards or standardization? Like do you see like components of this moving through a standardization track? Whether it's, you know Pick your standard's body. That doesn't matter so much, but like, how do you see your technology is like? Moving uh progressing uh moving forward Yeah, first of all, uh all our libraries, uh everything is open source. So you can just use it and There is a few Other projects that have actually built their identity systems on top of identary protocol And so it's not a problem. Um, the the other thing is that yeah, you mentioned, uh standards and of course this zero-knowledge proofs way of presenting this proofs and querying them and signing credentials and so on. It's not Standards, but we aim to eventually standardize them As this is the idea And just I mean, do you have any ideas right now where you would potentially standardize them because I You know, it's a complex question, but I just wanted to be at any early thoughts Yeah, through w3cd from and so on Yeah, I think like the the jwp might be for instance, uh, a logical Right, we created the jwz, but that was before the jwp came over the proposal for microsoft for that Um, I think we we are very much still aligned with didcom, right? So our our proprietary identary com flavor We could integrate that into the larger didcom spec So yeah, I mean there there could be some engagements like actually we have a meeting coming up with the didcom group Later this month to present them the identary com Format protocol that we've created so Yeah, we're we're open to these sorts of things also. We're becoming more cross-chain where we used to be heavily polygon Chain biased. So we're we're also working towards that uh, yes, um There's a comment here from vipin Neutronic fast forward sin axis mdl still being born eventually integrating with kyc. Oh, yes I remember you had a question around um other kyc or issuance providers I just wanted to provide a quick flavor on that Before we wrap up here. So you can see here some of the providers of of credentials in our ecosystem um Yes, some familiar names, perhaps some provide for the personhood liveness Uh, some provide free proof of personhood such as the case of synapse Uh, civic actually almost near free proof of personhood Uh, reputation credentials credit scoring Right various various use cases. So yeah, some folks there um in the ecosystem. We do have a larger Uh selection that you can see in our ecosystem page. Yeah, but just wanted to give some some flavor of that All right. Well, uh seeing as there's no additional questions Uh, I just wanted to thank everybody here for the invitation and also daniella who Told me that she would see this recording later Uh, and just reiterate that yes, uh, we very much, uh, like industry engagement Um, we do value open source. That's more of a personal statement. I I love linux. I love open source I know Sasha loves linux too. So we're all about, uh, you know contributing this to the The rest of the world and and hopefully we can start engaging more actively in that space Awesome. Yes, excellent presentation. Thank you both If you could just make sure that uh, you either send me or char that link to the public presentation We'll make sure to put that on the On the page here. So Um, but yes, that brings us to the end of the meeting. Uh, the recording's on youtube I think the the link was sent out in the chat earlier Uh, but we'll go ahead and post The link one more time just in case anyone wants to see it And uh, thank you all for coming. We'll see you in a couple weeks Thank you Thank you Thank you. Bye. Bye