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!

[ff137]

By the way, I notice that "unmanaged" is still not permitted in the CreateWalletRequestSchema:

class CreateWalletRequestSchema(OpenAPISchema):
    """Request schema for adding a new wallet which will be registered by the agent."""

    wallet_name = fields.Str(
        metadata={"description": "Wallet name", "example": "MyNewWallet"}
    )
...
    key_management_mode = fields.Str(
        dump_default=WalletRecord.MODE_MANAGED,
        validate=validate.OneOf((WalletRecord.MODE_MANAGED,)),   # <---
        metadata={
            "description": "Key management method to use for this wallet.",
            "example": WalletRecord.MODE_MANAGED,
        },
    )

I checked the previous blames, and there used to be a TODO here (https://github.com/openwallet-foundation/acapy/commit/d90c141b9223e7be81b2b19101e79cba389e65e8), which got lost when I updated marshmallow to fix deprecation warnings.

Now I wanted to test unmanaged mode, and see that validate.OneOf((WalletRecord.MODE_MANAGED,)), prevents that.

What's the latest status of this? Can I add unmanaged as an option in the PR I'm working on? Or is there still more to do? @swcurran @jamshale

edit: I re-added the todo comment in my PR here: e2cddee

[jamshale]

I'm not really sure of the unmanaged mode feature. If it actually works correctly, then this should be enabled. I've only looked into it a little bit and wasn't sure if it was completed or not.

[ff137]

It's covered in the Multitenancy doc, with the following note:

:warning: Although support for unmanaged mode is mostly in place, the receiving of messages from other agents in unmanaged mode is not supported yet. This means unmanaged mode can not be used yet.

But that was written 4 years ago :-)

I assume there's still some more work to do for it.