Replies: 2 comments 2 replies
-
We will be working on an example of how to do this using the companion dapp for onboarding (so the user would use the Masca website to initiate the signing flow) but we will also revisit this issue in a future API update |
Beta Was this translation helpful? Give feedback.
2 replies
-
To my knowledge this only works at the moment, but in main extension Snaps wont have access to |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hey.
We're the team behind Masca (previously SSI Snap). Recently we learned that using private keys will no longer be an option for us and are looking for your feedback on our best options moving forward.
With the removal of Ethereum private keys, we will lose the ability to seamlessly switch between DIDs using the "select account" dropdown in the MetaMask extension, because there will no longer exist a way of getting an account index (for deriving private keys) in Snap. We were hoping for some feedback regarding this problem.
For a better understanding of our problem, here is a short description of Masca and why private keys are needed.
Masca is a snap used to manage DIDs and store VCs. DID (decentralized identifier) is a unique identifier, which is used to prove facts about yourself to other parties (e.g. sign a VC). VC (Verifiable Credential) is a tamper-evident credential that can be verified cryptographically and can be presented (exchanged between parties) in a form of a VP (Verifiable Presentation), signed by a DID.
DIDs are strings, similar to Ethereum addresses. There are multiple methods of resolving and deriving said DIDs, named DID methods. DIDs are resolved into DID Documents, which in simple terms are objects that contain facts about the DID (public keys, delegated keys, controller keys, websites, arbitrary information, and so on). Some DID methods use Ethereum addresses as identifiers and Ethereum blockchain for updates (adding a service endpoint to DID document is done via an interaction with a smart contract).
Behind every DID there is a private key that is used for signatures (Credentials, Presentations, updates, etc.). Just like an Ethereum address, a DID is derived from a private key.
Our goal is to join Ethereum Accounts and DIDs so that there is one private key controlling both DIDs and an Ethereum Account. We believe this produces the best user experience and is the easiest form of understanding how to use DIDs. This way switching between different DIDs can be as easy as switching from Account 1 to Account 2 in MetaMask. Not only does this give you the option to use your primary MetaMask accounts for work with DIDs it also allows you to create new DID-exclusive accounts in MetaMask.
With access to Ethereum private keys gone, some problems occur. A solution for these could be using a custom
coin_type
, as there is no need for private keys to be shared. Furthermore, this even increases security as DIDs and Ethereum accounts are decoupled, but still connected by a MetaMask Account index. But a new problem occurs here. There is no way to know what index to use when deriving a private key.Until now we've done this like it is done in the Starknet Snap. By iterating through indexes until we found a matching address. With addresses and Ethereum private keys being removed we lose the option to connect the derivation index with the selected MetaMask Account, which in our opinion greatly reduces the user experience and usability of Masca. A solution for this problem could be a Snap-exclusive RPC method that returns a derivation index for the currently selected account. This would also mean that DIDs stay the same on a new MetaMask extension when importing seed phrase.
With that being said, we'd love to hear your thoughts on this matter. Have we missed anything? Would a new Snap RPC method be an option?
If there is anything that doesn't make sense feel free to ask.
Thanks
Beta Was this translation helpful? Give feedback.
All reactions