You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While it could be adapted quite well to Askar, current Wallet interface is significantly inspired in Indy SDK and therefore it may be interesting to update it to fit
Some remarks I can think of:
generateWalletKey could become a generic generateKey that receives a key algorithm and seed or any other parameter needed to securely generate a cryptographic key for the calling entity
import and export need a path and a key and we need to go to Indy documentation to see how they are supposed to work. IMHO, export must work on a Wallet instance and create a common dump that can be later imported by the same wallet class or another one. For instance, it can convert all wallet records to JSON in such a way that they can be read without the need of knowing the internals of the wallet class that generated the dump
rotateKey actually acts in a wallet that is not opened, so it's more a Wallet static or WalletApi method. I think it's more natural to simply do the rekey to an instance that is already opened.
pack and unpack are absolutely focused in DIDCommV1 right now. I think it will be nice to think on extracting these methods to a Packer/Unpacker class and leave in the Wallet interface everything needed to support that packing and unpacking (basically, generate keys and nonces, cryptobox sealing, etc.)
As discussed in feat: add initial askar package #1211, maybe WalletConfig can be left as generic as possible and leave each Wallet kind to define their own interfaces to identify and configure the wallets
The text was updated successfully, but these errors were encountered:
While it could be adapted quite well to Askar, current Wallet interface is significantly inspired in Indy SDK and therefore it may be interesting to update it to fit
Some remarks I can think of:
generateWalletKey
could become a genericgenerateKey
that receives a key algorithm and seed or any other parameter needed to securely generate a cryptographic key for the calling entityimport
andexport
need a path and a key and we need to go to Indy documentation to see how they are supposed to work. IMHO, export must work on a Wallet instance and create a common dump that can be later imported by the same wallet class or another one. For instance, it can convert all wallet records to JSON in such a way that they can be read without the need of knowing the internals of the wallet class that generated the dumprotateKey
actually acts in a wallet that is not opened, so it's more a Wallet static or WalletApi method. I think it's more natural to simply do the rekey to an instance that is already opened.pack
andunpack
are absolutely focused in DIDCommV1 right now. I think it will be nice to think on extracting these methods to a Packer/Unpacker class and leave in the Wallet interface everything needed to support that packing and unpacking (basically, generate keys and nonces, cryptobox sealing, etc.)WalletConfig
can be left as generic as possible and leave each Wallet kind to define their own interfaces to identify and configure the walletsThe text was updated successfully, but these errors were encountered: