Delegated Multisig AID Creation

[pfeairheller]

Delegated Multisig AID Creation

Introduction

This document attempts to document the steps targeted for an interop exercise between various signify clients, KERIA agents
and KERIpy command line. Completion of the following steps with the result of a 3 participant multisig AID that is delegated
from a 4th AID using any combination of different Signify clients and one KERIpy participant closely resembles the first procedure
required by a Qualified vLEI Issuer in the vLEI ecosystem. That is, create their issuing AID that is at least a 3 participant multisig
AID, delegated from the GLEIF External AID. The functionality needed for this procedure includes local (single sig) AID creation,
OOBI exchange (generation and resolution), challenge phrase exchange (generation and signing), multisig AID initiation and joining, delegation request and approval. The ability to interact with witnesses and agents as message recipients is assumed for all participants.

Participants

The following list is the suggested breakdown of participants in this interop exercise.

Witness Network

A publicly available witness network of at least 5 witnesses will be made available for this interop exercise. It is anticipated that
the KERIpy implementation of a Witness will be used to launch the witnesses. The witnesses will be launched in promiscuous mode accepting witness requests from any AID.

Delegator

The Delegator AID should be created using the KERIpy command line as a single sig AID using a publicly available set of witnesses. Most of this functionality current exists in the KERIpy command line but the following functionality needs to be verified:

1. Ensure the KERIpy command line works exchanges messages successfully with Agent based roles.

Mulisig Participants

Ideally we would like to have the 3 participants for the multisig AID each participate using a different Signify client against
a single KERIA multi-tenant service (an alternate configuration allowing for multiple KERIA services may also be tried). The clients
targeting for the first implementation are:

1. SignifyPy - Signify Python Client (https://github.com/WebOfTrust/signifypy)
2. Signide - Signify Rust Client (https://github.com/WebOfTrust/signifide)
3. Signify-TS - Signify TypeScript Client (https://github.com/WebOfTrust/signify-ts)

The "user interface" for the interaction with the Signify client will differ for each client type and may be as simple as a script
that completes the necessary steps. The intent of this interop exercise is not to focus on user interface but the underlying
capabilities of KERIA, each client and interoperability between the implementations.

Detailed Interop Script

The following list of steps is an attempt to capture all steps needed to create the delegated multisig AID and demonstrate
interoperability. It is also intended to be a blueprint for Signify clients and KERIA agent development to achieve compatibility. The
steps are listed in order for each participant for clarity, but it is expected that many of the steps will be performed in parallel and
interleaved with each other. The lists below are descriptive of the functionality required, not prescriptive of the order.

Delegator

1. Create local datastore (key store encryption optional but recommended).
2. Resolve OOBIs for publicly available witnesses (may be done in the configuration file used in step 1).
3. Create a local single sig AID using at least 3 of the witnesses from the witness pool.
4. Generate a "witness" role OOBI and share (probably via Zoom chat) with all multisig participants.
5. Resolve OOBIs from each of the multisig participants.
6. Generate 12 word challenge phrase for each of the multisig participants and share.
7. Confirm the signature on their unique challenge phrase of each multisig participant.
8. Sign and send a unique (received from each participant) 12 word challenge phrase to each of the multisig participants.
9. Wait for delegation request from multisig AID and confirm that the public keys match the expected order of the multisig participants.
10. Approve the delegation request from multisig AID.

Multisig Participants

Key Generation Algorithm

The KERIA agent service supports three different key generation algorithms for local AIDs: Salty, Randy and HSM. It would be ideal if we could have an implementation of each used for this exercise but that is beyond the scope of interop. Therefore, it will
be up to each participant to use any one of Salty, Randy or HSM even if all three participants end up using the same key generation
algorithm.

Steps to be Perform By Every Participant

1. Provision Agent Worker on KERIA server using out-of-band /boot API call.
2. Create local single sig AID using at least 3 witnesses from the witness pool.
3. Create an End Role authorization for the KERIA service to act as an "Agent" on behalf of the AID.
4. Generate an "agent" role OOBI and share (probably via Zoom chat) with all multisig participants and delegator.
5. Resolve OOBIs from each of other two multisig participants and the delegator.
6. Generate 12 word challenge phrase for each of the other two multisig participants and the delegator and share.
7. Confirm the signature on their unique challenge phrase of each multisig participant and the delegator.
8. Sign and send a unique (received from each participant) 12 word challenge phrase to each of the multisig participants and delegator.

Steps to be Performed by the Multisig Lead Participant

1. Generate Multisig Group AID configuration specifying your AID and the AID of each of the other participants, at least three witnesses from the witness pool and the Delegator's AID as the delpre.
2. Sign the inception event for the multisig AID and share with the other participants in the group.
3. Wait for the signatures from the other participants.
4. Share fully signed inception event with Delegator and wait for approval (anchoring in delegator's KEL).
5. Distribute fully signed and anchored inception event to all witnesses, collect and propagate receipts among all witnesses.

Steps to be Performed by Non-Lead Multisig Participants

1. Wait to "join" multisig group by receiving the proposed inception event, confirming the other participants and agreed upon configuration
2. Sign multisig inception event and send to all other participants
3. Wait for fully signed, anchored and witnessed inception event for multisig AID.

Bonus Points

The next steps to be tested include AID interaction events (used for credential registry creation and credential issuance), AID rotation events (which will require delegation approval) and various contact operations for associating human-readable information to the AIDs that have been resolved.

[2byrds]

Great details/challenge @pfeairheller !

[pfeairheller]

This procedure has been completed in a series of scripts and documented in full in Discussion #95