Multitenancy and public DIDs

[matgnt]

Hi all,

as I'm looking into acapy multitenancy a bit, I had some trouble registering public DIDs for sub-wallets.
It looks like I'm not the only one as there have been some issues here:
#1460
and there
#1358

I'm trying to summarize what I've learned so far:
Most important to understand:

• /wallet/did/create and /wallet/did/public endpoints are NOT enough.
• You need to use /ledger/register-nym IN BETWEEN those endpoints!

So far so good. The issue is, that:
Using this endpoint is not possible when using multitenancy. I think there are Options here:

1. Having a separate agent running that does the endorsement for you
2. Having a sub-wallet with endorser rights doing this for you
3. Maybe let the base-wallet do this for you

Currently I only see option 1.
Option 2 does not work because I would need to be able to pre-seed / fill the DID I create in a sub-wallet - which seems not possible right now.
/wallet/did/create does not allow to add a seed or existing (on the ledger) DID
/wallet/did/public does not allow to add seed, so I can NOT add an existing (on the ledger) DID

Option 3 would have been my first guess, but with multitenancy enabled, it requires authentication, and this I get only for a sub-wallet.

Can someone confirm my observations or give some hints where I might have some misunderstandings?

Thanks a lot!
Matthias

[etschelp]

Last time I checked all the base wallet could do was create sub wallets. So I would say yes you need another agent, sub wallet or standalone, that does the endorsement for you.

As a remark there is also an open PR that endorses an ATTRIB transaction to set the endpoint on the ledger: #1616 For holder wallets this is the best option imho.

In the end it depends on where to place the orchestration of the api calls. If I remember correctly the consent was to keep such logic in the controller (not aca-py). But what seems odd right now is that one part of the wallet initialisation logic lies in the sub wallet and one part in the base wallet. This means that there is a difference on what a freshly initialised sub- wallet controller must do vs a standalone controller. So maybe it would make sense to have the option to provide a did/seed when calling POST /multitenancy/wallet and as a second step have the option in the base wallet to write a NYM or ATTRIB transaction to the ledger (either directly or via an endorser). Like this all api calls would be in one place.

[matgnt]

Thanks @etschelp
I've now pushed a simple proposal for Option 3. I don't oversee all possible implications here and I hope someone could have a look into this.

I personally would prefer to have just 1 instance running.

[matgnt]

Short remark for others:
After the change in access to the register-nym endpoint (see PR above) I'm able to work with option 3 now. Only thing to also take care of, is the configuration of your sub-wallets. Default does NOT work. Here I had trouble because updating the endpoints on the ledger did not work because of wrong sigs (base wallet vs. sub wallet?).
I think this was the error I received:

aries_cloudagent.ledger.error.LedgerTransactionError: Ledger rejected transaction request: client request invalid: UnauthorizedClientRequest('8VJCEZVNBXiKczknddXjQX', 1646841254878282717, 'ENDORSER can not touch raw field since only the owner can modify it')

The 8VJC... is the one from the base wallet.

After debugging a lot, I switched to askar and now it seems it does everything I need (in combination with the mentioned PR)
"--multitenancy-config", "{\"wallet_type\":\"askar-profile\"}",

I think the initially described options still need to be discussed and decided what should be the desired behavior.
@ianco any comments on the options above? Question is related to #1632

[ianco]

#1 is the recommended option. With PR #1616 (should be completed soon) the sub-wallet can self-register their new DID via an endorser. Right now it's recommended that the endorser be a separate aca-py instance (not another sub-wallet and not the base wallet) because it will have different startup params (you can start up an aca-py instance configured as an author or as an endorser) - in a multitenant scenario the aca-py startup params apply to all sub-wallets, there is no way to configure one sub-wallet differently from the others.

(Note - you can start up aca-py without any of the endorser parameters, but then author sub-wallets need to call all the aca-py endpoints with all the endorser parameters explicitly provided.)

So, as above, #2 is possible but will require some extra care and attention for the author in calling the aca-py endpoints

For #3, this relies on the controller calling the base wallet, so I'm not sure this would count as a "self serve" model (whereas connecting to an endorser would allow the author to manage their own ledger updates, and would be required for the schema and cred def updates anyways)

[ianco]

Closing, replaced by Issue #1682