Enable "unmanaged wallet" mode in aca-py multitenancy

[ianco]

This is dependant on persistent queues (PR https://github.com/hyperledger/aries-cloudagent-python/pull/1604) and giving aca-py the ability to "hold" inbound messages until the unmanaged wallet can be activated.

See the original multitenancy design: https://hackmd.io/Rpx9CahTRJKtPAJxxqqYRQ

[swcurran]

FYI - reading that document, I don't see a definition of "managed" and "unmanaged" wallets and the ramifications of not having unmanaged. Could you add a section to that to cover what it means? It seems it would be important, but I can't tell why. It looks like it means that a controller using a multitenant wallet has to make multiple updates to use a managed multi-tenant wallet vs. a single tenant, whereas if we had unmanaged support, the controller would (barely?) know the difference. Is that right?

Will we need unmanaged for Traction support that is planned?

[ianco]

"managed" means the base wallet stores the wallet key for each sub-wallet, along with all other wallet information. "un-managed" means it doesn't store the wallet key.

For "managed" wallets, since aca-py knows the key, it can process inbound messages as they are received. API requests (from the controller) use the JWT token to authenticate.

For "un-managed" wallets, since aca-py doesn't know the key, it has to "hold" inbound messages until the sub-wallet can be "un-locked". The assumption is that the wallet will be unlocked when aca-py receives an API request from the sub-wallet owner (API requests must include both the JWT token as well as the wallet key), or the document proposes an additional /wallet/unlock endpoint that an owner can use to temporarily unlock the wallet and allow inbound messages to process.

[darapich92]

Hi @ianco, your document is very important to understand the definition of each function of the Multi-tenant API. But I notice that in that document, it has the function to export the sub-wallet while I cannot find it when I run multi- tenant mode using Docker. Could you tell me why?

[ianco]

I don't think the wallet import/export were ever implemented in aca-py. You can import/export an Indy wallet using the indy CLI, I don't think askar wallet type supports import/export (yet)

[darapich92]

@ianco After you said like this, I will have another question. The arguments to run the ACA-py via docker does not have the option to run Indy-CLI. I remember that to run Indy-CLI, I can run it via VON-Network. So, could you guide me if i am wrong on the implementation of importing the wallet to ACA-Py:

1. Run ./manage indy-cli and create the wallet
2. Import that wallet when initial the ACA-Py (but you said import/export wallet is not implemented in ACA-Py) So, what should I do on ACA-Py in order to import new creating wallet using Indy-CLI with ACA-Py? Thank you very much, your answer is very important for me.

[ianco]

If you are using a postgres wallet, then you can use indy-cli as you describe above. You can create the wallet using indy-cli and then connect using aca-py, or create the wallet using acca-py and then connect using indy-cli to import/export etc. (For "indy" wallets only, not "askar".)

If you are using a SQLite wallet, then you need to manually copy the database file between docker images (assuming you are running aca-py in a docker image), or else you can use docker volumes to mount the database file from your local filesystem.

[darapich92]

@ianco thank you and I think I can do it. But I would like to ask a question about the IndyPostgres plugin. I tried cargo build in that plugin folder in indy-sdk but I could not succeed it for generating a .so file.

It is the error. I am sorry to ask you but I could not find the answer. for your info. I use Ubuntu 20.0.4. Thank you very much!