iOS wrapper: Cannot register custom wallet anymore

[animeshworkday]

Hello, the indy SDK 1.5 updated the custom wallet registeration call https://github.com/hyperledger/indy-sdk/blob/78cd7625a03c7a9d64d5d63e143eeb8344d59b0d/libindy/src/api/wallet.rs#L42.

But the iOS wrapper is not updated to use the new call. https://github.com/hyperledger/indy-sdk/blob/78cd7625a03c7a9d64d5d63e143eeb8344d59b0d/wrappers/ios/libindy-pod/Indy/Wrapper/IndyWallet.mm#L29

So that is causing the registration call to iOS wrapper to fail.

Can you please update the iOS wrapper to be in-sync with the indy sdk?

[esplinr]

@animeshworkday You closed this issue without an explanation, so for future reference we want to document here this behavior.

It is intentional that the iOS wrapper does not have a function for registering wallets. With the release of Indy SDK 1.5, we no longer allow custom wallets. Instead we support plug-able wallet back-ends that allow people to implement their own approach to storage.

Thanks for pointing out that registerWalletType was not removed as part of this change. We created an issue to track that work: https://jira.hyperledger.org/browse/IS-904

[animeshworkday]

@esplinr I closed this ticket as I was told that the ticket should be logged in jira. I was registering custom wallet because I needed IndyWallet to use my implementation of IndyWalletProtocol protocol. So now if "IndyWallet.sharedInstance().registerType" method will be gone, then how to have IndyWallet use my implementation of storage?

[vimmerru]

@animeshworkday

It is better to write storages in some C-compatible language and distribute them as a shared library. Storage library should provide some init function that will call indy_register_wallet_storage internally.

In this case you can use this storage implementation with any Indy based application independent on a language it is written and load this as plugin for Indy CLI. See https://github.com/hyperledger/indy-sdk/tree/master/doc/design/006-cli-plugins

Due these reasons we decided to don't expose indy_register_wallet_storage in wrappers.

If you want to implement plugin in ObjectiveC you can (ObjectiveC provides good C interoperability), but need to just cal indy_register_wallet_storage directly may be with some ObjectiveC types to C types conversion.

[animeshworkday]

@vimmerru @esplinr In 1.4, the class IndyWallet in iOS wrapper used to call indy_register_wallet_type. Is there any plan to update the iOS wrapper and add a method that calls indy_register_wallet_storage? That way individual iOS developers won't have to do the same thing again and again (i.e write iOS code that calls indy_register_wallet_storage).

Also, I am a bit preplexed by the design change in 1.5.

In 1.4, providing a implementation of interface IndyWalletProtocol involved providing implementation of methods like create, open, delete, setValue, getValue etc and then registering this implementation by calling iOS wrapper method "IndyWallet.sharedInstance().registerType". Once that is done, then Indy used to call the methods of the implementation whenever it needed to save or retrive any value from storage.

That seems very similar to what is being done now via indy_register_wallet_storage.

So what is the main difference between what was happening in 1.4 and what is happening in 1.5?

[vimmerru]

1. Libindy 1.5 allows efficient search of entities in wallet. It makes secure implementation of wallet protocol very complex and forces big probability of vulnerabilities in custom wallet implementations.
2. Community decided to allow usage only one wallet that is shipped with libindy. You can see corresponded accepted HIPE here: https://github.com/hyperledger/indy-hipe/blob/master/text/0013-wallets/README.md
3. Libindy walllet allows to plug different storages to cover different use cases. See HIPE and design https://github.com/hyperledger/indy-sdk/tree/master/doc/design/003-wallet-storage for details. Storage is responsible only for data access and search, but doesn't cover any encryption.
4. In our vision storages should be implemented as plugins to libindy and not as part of applications written in application language to allow usage of storage code for applications written in different languages. See https://github.com/hyperledger/indy-sdk/tree/master/doc/design/006-cli-plugins

As result we don't have short-term plans to expose indy_register_wallet_storage as part of any wrappers interface as the most of applications will call plugin_init API provided by plugin instead of calling indy_register_wallet_storage directly.

If you think that you still need this functionality you can create ticket in JIRA and describe your use case. We are also welcome for contribution. I suggest also consider usage of default SQLite based storage for iOS agents use cases as it was designed to cover this.

[animeshworkday]

@vimmerru I was using the custom storage in 1.4 to encrypt the data using a key that is never accessible outside the specific device. This essentially "tied" the wallet to the device. How can I achieve that using the new design?

Few questions 1) Where does the default implementation of wallet store its data? In file? In keychain? or somewhere else 2) Can we specify the encryption key and the encryption algorithm, somehow?

[vimmerru]

1. Where does the default implementation of wallet store its data? In file? In keychain? or somewhere else?

• It stores data as sqlite database file inside of application storage (you can customize the place where file is stored)

2. Can we specify the encryption key and the encryption algorithm, somehow?

• When you create/open/delete wallet you need to provide master key or passphrase used for key derivation and the method of key derivation (raw or pwhash/argon2i with different settings). To achieve your use case you can store this key or passphrase inside of phone key chain.

[animeshworkday]

Thank you @vimmerru. I appreciate your time and help.