Decentralized identity meets MetaMask

Transcript

thank you hello can you hear me yeah thank you um so my name is vit I'm from the blockchain lab um and today I'm going to talk about the project we are working on which is called maska and it's a way to bring decentralized identity um constructions directly to the metamask so first I'm going to talk about decentralized identity I hope that you attended the previous Workshop which was about polygon ID which is also the centralized identity protocol so I don't have to go to go into many details then

I'm going to talk about Moscow which is a metamask snap is anyone here already familiar with metamask snaps okay um then I'm going to talk about architecture of maska some of the use cases that you can Implement in your decentralized applications I'm going to Showcase some of the library package packages and tools and then I'm going to show some of the links um so after the presentation I'm going to do a live demo um I wasn't smart Estonia in the previous presentation so we were going to do it live I don't have a recording um but hopefully the internet will work um so what are uh the what is decentralized

identity So currently today there are like two main approaches to decentralized Identity one is the OWN chain approach and the other is off chain so for the own chain usually we have nfts or zero knowledge badges which are tied to the blockchain addresses or smart contract wallets we can represent public and private data in this forum but there are some problems using these Primitives for the identity so one thing is there are fees associated with issuing nfts so if you if you want to like issue all our identity data for everyone on the uh on this world with nfts it would not be very scalable because someone would have to pay for all the fees but there is like Advantage is that data is always available on chain so if

we are trying to use the identity data in some of the smart contracts we can always access this data and then the the other approach is off-chain data so we're here we have verify the credentials and dids so here we don't store the data on chain we are storing it off chain in different forms we can also represent public and private data so we can we issue the data off chain but if we want to make this data public we can still put the data on chain there are no fees associated with issuing the data so this approach is much more scalable but the data must always be shared with the with the entity that we are that we will that we want to share

the data with and there is also the question if we also if we need Global consensus on all private data which means for all the identity data which maybe is just important for us and like one other person on this Earth do all the Glo uh does it make sense that all the nodes of the blockchain need to like made make the global consensus on all this data so what are some of the challenges with off-chain Solutions so now we are not storing the data on chain we are storing it off chain and we have like many options so one of the option is to use ceramic Network the other option is to just store verifiable credentials in your wallets we can also store very fiber credentials on ipfs or we can store them on verida network or like

there are many different ways to store this data um and also in decentralized identity which was also discussed in details in the previous Workshop is that we can do like some very interesting things with New cryptographic Primitives we have new ellipticals like baby job job which is used by polygon ID and we can do some very interesting things with zero knowledge proofs so the question is if wallets support these all new features out of the box or do we need to use one wallet for our web tree identity uh for our interaction with smart contracts and then we need to use another word for the identity which means that the users in at the end will have to use two different wallets

or also if there is a question if we need to implement all that logic for different data storage solutions and for different cryptographic Primitives on each dap which means that the code that is handling the decentralized identity needs to be repeated on each step but there are many upsides to use decentralized identity um basically we can enable new use cases by with new cryptography we have more control over our date data so our data is not on chain it is controlled by us and we share only with the we share the data only with the with the entities that we want to share the data with and the Privacy is much more enhanced in

this way so here is the truss triangle for decentralized identity we have issuers holders and verifiers so for example issuer can be ethereum friends which issue you the ticket for FCC so the holder gets the ticket it stores the ticket in the wallet and the verifier is then um the guy at the entrance which just verify the ticket and for this verification the verifier needs to check the cryptographic signature of the verifiable credential and to get the public key of the issuer it needs to go to the identity registry so blockchain is basically used only for storing the metadata of the identities so this Enterprise identity can be

divided into two main parts so first are the unique identifiers and the other is data itself so for The Unique identifiers we have decentralized identifiers and for the data we have verified the credentials so for the decentralized identifiers we have different did methods we can use the Deep method public key hash which is basically just your ethereum address we can use the did method ens which is your ens handle or you can use did method provided by polygon ID so we have like for our identity we can have multiple different the idea identifiers which are defined by different bit methods but what this did identifier tells you is that you can

resolve this did identifier and you get the did document and this the document is usually stored on the blockchain or it can be constructed locally based on the did method and it can it contains your meta metadata for your identity which is most of the time your public key so when you sign the data you show the data to someone else the other person can resolve your did gets the did document and it gets the public key and then he can check the cryptographic signature of your data and for the verifiable credentials again we have different formats so this is like example verifiable credential um it's a GM credential which is used by

the project discon um so we have different formats so we have Json web tokens these very fiber credentials are often used in more traditional systems which rely on Json web tokens we can have Json LD credentials we can have eip71 credentials or we can have Json web zero knowledge credentials uh but which is used by polygon ID so for Dev developers that's a lot of things to handle that developers need to decide which deep methods to support and then when they decide for did method they need to implement resolving the dids updating the documents they need to decide which verifiable credential for format to support they need to decide which

storage solutions they want to support do they want to connect to the ceramic Network or ipfs or support like additional identity wallet there are also different data exchange protocols so you can share the credentials over open ID connect or you can share the credentials over ditcom oh and then there is a question if the dev developers should just support additional word but then the wallet but then the users need to use two wallets um on their application so what is mascot trying to do is trying to reduce the hours of the develop developers to get the decentralized identity support so maska is metamask snap so metamask

Snaps are basically a way to write plugins or extensions for a metamask you can write your custom JavaScript code there it runs in the separate execution environment and you can basically Implement any use case you want and then you just provide the new RPC methods so metamask itself provides RPC methods for the on-chain interactions and with metamask snaps you can just add new RPC method to the metamask so this is the architecture for damasca so Moscow is running inside metamask um so basically I put the purple Forks here because they are currently available on your met mask flask which is the development version but they are coming to the main metamask browser

extension in September or October um we are using the same key management system uh for the cryptographic keys so basically all the keys for your identity are generated from the same seed phrase which is in metamask which means that if you migrate to another computer you can just migrate with your seed phrase so inside mask we are using the library veramo for orchestrating the identity things so verama is a very good open source library for decentralized identity uh and inside we support different did methods and we also support different Storage Solutions so so if you are a web developer when you want to store the verifiable credential you can just call

the one RPC method of Moscow and you specify to which storage solution you want to store verifiable credential and we also have this configuration so the users can decide uh where they want their very fiber credentials to be stored so for example if I want to store my passport is verify the credential I personally wouldn't put that to ceramic for example but maybe I would want to keep this credential locally but if it's like the credential for like attending a conference it's not so private so it's fine to put it on the ceramic um so we offer different RPC methods like save verify the credential get verifiable credentials create verified presentation switch this method available did methods and many more so what are benefits of maska so you'll

be able to use mosca always when you will use metamask you won't have to use another wallet we are trying to develop Universal decentralized identity Solution by supporting different bit methods and aggregating different very fiberglasses Storage Solutions and it's also highly configurable by users so the moment each application is trying to stick to one bit method because it's kind of hard to support additional deep methods um but what we are trying to do is that the user can select which method he wants to use and then when he connects to some decentralized application he is already using the did method he wants to use and we are also trying to avoid backend apis for these functionalities so for

example verifying the credential happens inside the snap which runs in your browser extension so there are no external dependencies to any servers so what are some of the use cases so one use case is credential gated communities so in the live demo that I'm going to show you it's it's going to be like the chat that you can access only if you show the correct verifiable credential there are also some other use cases like dollar governance based on reputation offline peer-to-peer sharing of order stations because for verifiable credentials they're off chain when you share the credential you don't have to have interaction with blockchain you can share them directly in person there are also like other use cases like

social profiles and basically every other use case the developers come up with so we implemented the mask connector Library which is important for web developers so basically it's the SD SDK designed for the effortless integration of Moscow uh so this means that um you don't have to call the RPC methods of metamask directly but it just provides the abstraction so you can call the functionalities of Moscow like a normal JavaScript functions and yeah this one uh so here we are open source so everything is open source um you can check the code on the GitHub

and the code for the workshop is also open sourced uh we also have a Discord Community if anyone has any questions um and here is the link to the workshop I'm going to show you um so if you want to follow along you have to use your computer because metamask flask is currently available only on PC it's not available on mobile yet so but hopefully it will be at the end at the end of the year okay let's just wait a few seconds

Because the Internet is slow okay so you can so we also implemented the decentralized application which can showcase uh you the data you have saved you have stored in snap so it's easier to get started so we have to do is connect with wallet so this basically connects to your metamask flask

and as you can see we implemented the interface which is very similar to the same user experience that is currently on the decentralized applications so you can see that you are connected with a certain metamask account and you can see the same did methods so basically the crypto cryptography behind this blockchain account is the same as behind this method so we also support different networks for the ID methods like ethereum and polygon and we also enable the switch between different edit methods so we have this load verified the credentials so when you click this button it actually gets your verifiable credentials which are stored locally in

your snap and also in your on the ceramic Network okay so I have one verifiable credential killer here uh we implemented the card view which is more familiar to the actual documents we have in our real life and also tableview view which just showcase you more information so as you can see these verifiable credential is at the moment stored locally on Snap but if we clicked on the verifiable credential you can see the verify the

credential you can see the issuer of the verifiable credential and the signature and you can go to the settings and just put this verifiable credential on the ceramic Network this is probably going to take a few seconds you need to approve with metamask and it's successfully stored and the data stores are now updated so we have these credential now also stored on the ceramic Network and you can also create verifiable presentations for the credentials you can select more of them or one or one and you can also decide which proof format you want so for

example some issue some verifiers may rely only on Json web tokens while some verifiers might accept only Json LDS so basically we support uh different formats so this is the dab that we developed and then we just wanted to Showcase how to do integration of masking to any decentralized application so we implemented this Workshop demo and I'm going also to show you the code of the for the integration so here I have the react project created with nexjs so for the for the development all you need to do is you need to install the dependency mask connector which contains all the functionalities for the

integration so here we also have the connect button which connects with the metamask flask so in the code this looks like we have this navigation bar and basically what happens is in this function you call the metamask RPC method request account you get the currently selected account of metamask and then you need to enable mask which is imported from The Mask connector you you can the dev developers can insert which did methods are supported on this dab and then you get the the get the mask API from this which is returned by the

enable mask on and then you can call the get the ID we just like one line of count you get the ID of the user and then you can call get selected method and you also get the method that is selected by the user so I can query verifiable credentials here so in the code if we go to this page file we have this query verifiable credential function so here we are defining the filter this means that for example user have 100 credentials in their snap or mask so for certain decentralized application you are maybe interested only in one certain verifiable

credential that is issued by the a host of these verifiable credentials so here we are checking the correct issuer of the verifiable credential and we are checking that the verifiable credential is of the correct type and then we just call the query verifiable credential function with this filter so here for example this function is querying over over all the storages and maybe the certain decentralized application is maybe interested only on ceramics so here we could add options and we could put store ceramic and now the verifiable credentials would be queried only from ceramic Network

and this is this may be necessary because some other application which is working with different decentralized applications are maybe working together and some supports only ceramic for certain reason some you can just check the ceramic and add the ceramic constraint here so I queried my verify credential I don't have the workshop credential yet so you can try this at home so the password Here is mosca at if cc6 I hope I get got that wrong correct so now I'm getting the credential from

the issuer and when we issue returns these verify the credential I will be able to store it in Moscow so it's here the password was correct and I can store this credential in metamask snap so here the credential you can see the credential and what's interesting here is that if I go back to the muscad app if I refresh this page the verifiable credentials now appears here because it's stored in our wallet so the code for storing verifiable credential it looks

very similar to other functions so basically what you need to do is call Api dot safe verifiable credential first parameter is credential and then you just need to specify to which store these credentials should be stored now I can go to the restricted chat room so now I have the correct verifiable credential I can go to the Gated chat room which is accessible only if I have the workshop credential and what happens here is that I create verifiable presentation with the correct verifiable credential and that's interesting okay let me refresh maybe I will just

show you the code in the meantime so here I'm creating the verifiable presentation again you can call the API dot dot create verifiable credential I insert the credential and the correct proof format and the issuer lets me in the gate the chat room so on the API site this is how the verifying the verifiable presentation looks like so basically the very the verifier checks that he issued this credential that it is of the correct type and that the verifiable presentation holder is actually the verifiable credential subject okay so enter chat this is how the look

for entering the chat looks like so basically what happens here is that we are creating this verifiable presentation and we are sending the verifiable presentation to the chat room backend API I'm gonna try getting to the chat group again we're doing some changes in the last evening so it's maybe it's not it's not going to work correctly okay sorry about that

um so basically what would happen is that it would look like the same as the public chat room but we took the Gated chat room you can only access it with the correct verifiable credential we are going to fix that so we will be able to try that at home and that's it for myself um no that shouldn't be the problem yeah thank you [Applause] hey thanks for the talk

um I think at the beginning of your presentation and and I also think in the architecture diagram you kind of alluded to openid connect oidc can you elaborate on the use case yeah so uh at the moment the open ID looks like that for example if you go to the issuer the issuer shows you the QR code and you have to take the mobile application which supports the open ID connect protocol and you scan the QR code and then the protocol happens so the protocol consists of multiple steps first you need to do proof of possession key and then you need to show the the issuer that you are actually the holder of this date and then the issuer issues you the verify the credential so for our example for example if you go to the issuers application issuer doesn't have to show the QR code to the user it can

just get it can just we so in the Moscow we support an additional RPC method which handles the open ID connect so basically the issuer could Implement on the application the call to the Moscow RPC node with the data that is relevant for the open ID connect and the open ID connect would happen uh from Oscar to the issuer and we are doing very similar thing with a polygon ID so at the moment polygon ID if you want to get the credential basically on the application you get the polygon ID QR code you scan the QR code with the polygon ID app and then you need to scan another QR code for receiving the verifiable credential so for example we are also adding the new RPC method for polygon ID so basically the application developer doesn't have

to show two QR codes it can just call the mask RPC method so the user can just use metamask for that thank you um for verifiable presentation have you consider using a z z Cape 708 proof for disclosing only a certain information um yeah so basically for zero knowledge proofs uh we are supporting in kind of for the polygon ID but this is relevant for the polygon ID only at the moment we are currently most focused on the

selective disclosure methods so one method that is currently being popular is selective disclosure in combination with Json web tokens so basically uh the there are not really zero knowledge proofs they're like selected disclosure you can just disclose part of the credentials Without Really revealing all the data so for example if you get your passport you have first name last name and H and when you want to buy something in store you can just reveal your age because the store doesn't care about your first name and last name so basically select disclosure and for Zeal knowledge proofs we are supporting polygon ID but for other methods we are not that doing that hi um I may have missed it in the

workshop demo but does Moscow also provide a um a UI or an SDK for the verifier site for them to manage which credentials they want to like verify for their use case um yeah so basically Moscow is only the wallet part so basically it's for the users and for application developers to add the wallet capabilities to it to their depths for insurance and verifiers we have like the separate projects we are where we spawn like the issuer as a server and verifier as a server so you can configure that in other repos oh perfect so it's it's open source but so it's on on our GitHub okay got so you guys offer also for the whole trust triangle basically but for today you basically showed the wallet yeah exactly

more question still have time um any questions yeah there is yeah um I'm coming as a non-techie to expose myself I'm not a tag person but I want to build a product for users that are not used to web3 so they're not used to going through different apps to get an ID um do you have a way to not have the metamask popping up every time I have to store an ID

can I can you brand it in a way that it's interesting for a user and that they think it's one system how do you approach this yeah so in Moscow we have in settings the option to toggle pop-ups so basically you can you can basically what you can do is disable pop-ups so all these pop-ups that I got are happen automatically but it's like you get the best better user experience but safety is then more problematic because you can just sign something that the depth throws you and it's not really safe so there is always like between security and user experience trade-offs so we're kind of trying to do that with pop-ups so the users can decide if they want to have maybe worst user experience but I

know what they're doing um but they can also disable pop-ups if they want no more questions thank you thank you [Applause] foreign [Music]