Joined member of multisig can't access registries
There’s no way for a new member in a multisig to catch up with all previously created registry in a multisig.
version: Current stable release latest/0.2.0-dev4 (2024-11-05)
I’ve created a test case to highlight that there’s no functionality for a multisig to extend or change their members and continue normal issuance operations.
Steps to reproduce
- Create multisig with member A and B
- Member A and B creates a registry for the multisig
- Member A and B adds new member C to the multisig
- Member C successfully joins the multisig
- Member C lists the registries for the multisig
Expected result
Member C gets a list with registries belonging to the multisig.
Actual result
Member C gets an empty list of registries for the multisig.
Reproduction
https://github.com/nordlei/vlei-sandbox/blob/multisig-join-credential/src/issues/multisig-join-registry-problem.test.ts
Related
https://github.com/WebOfTrust/keria/issues/283
@m00sey and @Arsh-Sandhu maybe you can help us know how this is done in KERIA/keripy? Perhaps there are scripts to update the underlying database? Any inspiration is welcome.
@Arsh-Sandhu will add details for how he did this here
To migrate an existing registry of the multisig AID to the wallet of a newly added member, follow these steps:
- From the wallet of an existing member of the multisig, export any or all
issuedcredentials of the multisig AID in CESR format. In Signify, you can use theGetmethod of theCredentialsclass and pass argincludeCESR=true. - Send a
PUTrequest tohttp://<keria-agent-address>:<keria-agent-port>/with the headersCESR-DESTINATION: <local AID of the newly added member in the multisig AID>andContent-Type: application/octet-stream, and include the exported credential data in the body. For example:curl -X PUT http://<keria-agent-address>:<keria-agent-port>/ --data-binary @credentials.cesr -H "CESR-DESTINATION: <local AID of newly added member into multisig AID>" -H "Content-Type: application/octet-stream" - This will store the exported credential(s) and the registry in the new member's wallet.
- At this point, the registry does not have a name.
- In Signify, to update the name of the registry, use the
renamemethod of theRegistriesclass:rename(name: string, registryName: string, newName: string). Pass the following argumentsname: Alias of the multisig AIDregistryName: Registry prefixnewName- New registry name
To migrate an existing registry of the multisig AID to the wallet of a newly added member, follow these steps:
- From the wallet of an existing member of the multisig, export any or all
issuedcredentials of the multisig AID in CESR format. In Signify, you can use theGetmethod of theCredentialsclass and pass argincludeCESR=true.- Send a
PUTrequest tohttp://<keria-agent-address>:<keria-agent-port>/with the headersCESR-DESTINATION: <local AID of the newly added member in the multisig AID>andContent-Type: application/octet-stream, and include the exported credential data in the body. For example:curl -X PUT http://<keria-agent-address>:<keria-agent-port>/ --data-binary @credentials.cesr -H "CESR-DESTINATION: <local AID of newly added member into multisig AID>" -H "Content-Type: application/octet-stream"- This will store the exported credential(s) and the registry in the new member's wallet.
- At this point, the registry does not have a name.
- In Signify, to update the name of the registry, use the
renamemethod of theRegistriesclass:rename(name: string, registryName: string, newName: string). Pass the following arguments
name: Alias of the multisig AIDregistryName: Registry prefixnewName- New registry name
You are a gem @Arsh-Sandhu !
@Arsh-Sandhu I just tried this and I'm not really sure which endpoint this will invoke. Which version of KERIA did you use for this?
@daviddm we used KERIA v1.1. This endpoint is also in the latest code of main branch. It is in HttpEnd class of indirecting.py
@daviddm suggests to resolve this, it would good to have a test case that executes this on the admin/3901 API so that the controller can execute the equivalent steps listed by @Arsh-Sandhu
You can generalize this into a multisig catch up functionality for synchronizing the entire multisig group state to a new participant. This goes beyond simple KEL catch up (kli local watch and kli multisig update) to include the following things:
- KEL (from
kli local watch&kli multisig update) - Registries
- All ACDC TELs
- any other multisig state that every group member should have.
The existing functionality in kli local watch and kli multisig update is not sufficient to synchronize all of the multisig state so we will have to write more synchronization code.
This sort of functionality needs to exist in KERIpy for multisig groups in general. It applies to GroupHabs as well as SignifyHabs and SignifyGroupHabs.