How do I establish and maintain a multisig group for one human?

[edeykholt]

What is a good UX flow where a user can set up multiple devices, perhaps with distinct KERIA service providers, for routine multisig signing and exceptional recovery in case of loss of device or passcode?

[nkongsuwan]

I would like to add that the problem gets significantly more complex if the AID of that one human is also part of a multisig group of an organization, basically two layers of multisig where members of a multisig group are themselves multisig groups.

[iFergal]

In attempts to make this a little more user friendly, so far what we've done in the CF wallet is this:

• An "initiator" creates a multi-sig in the UI, which in reality creates the single-sig smid/rmid for that device, and the OOBI for this single-sig has a query param of groupId=<uuid>. The uuid is randomly generated and not a hash of anything in particular.
  • The single-sig appears as a draft multi-sig in the UI to the user.
• When the other devices scan this OOBI (which contains the groupId query param), if accepted it will set up the single-sig on that device with a similar OOBI (same uuid).
  • These contacts will not appear in the list of connections/contacts in the wallet - they are special contacts only for this multi-sig, identifier with the uuid.
• Once all devices are ready, the initiator device can click initiate which will create and distribute the inception event to the other devices.
  • The initiator can remove devices from the multi-sig before initiating, and set the threshold.
  • At this point, the single-sig will disappear from the UI and will be replaced with the pending multi-sig (with the same display name, theme etc)
• Once at least threshold devices have accepted, the multi-sig goes from pending to complete and ready.

This works quite well assuming all devices are nearby for QR code scanning, and ensures the "single-sigs" behind each multi-sig only get used for this particular multi-sig. It is bespoke to our wallet though, so it would be good if there was a common standard for all wallets.

In my opinion, a more ideal solution in the long term would be if existing contacts could run some mini protocol to auto create and share the smids/rmids, like a preparation protocol or something.

[edeykholt]

I've been thinking of another potential solution that would involve WebAuthn, e.g. with FIDO2 keys. For this discussion, let's assume a design goal is for a person to have 3 or more signing keys with a threshold of 2. Perhaps the first key is unlocked when the app is in use on a device. Maybe the device secure enclave has a second. A FIDO key would provide an excellent second factor or backup key.

At an IIW a while ago, perhaps October 2023, someone very knowledgeable about Chrome was discussing a use case where someone walks up to a shared browser/computer at a library (or wherever) and needs to authenticate in a secure way. They could stick in their FIDO key enter their password/passkey and tap their FIDO key to gain all the access they need. Then when done, they pull out their FIDO key and the browsing session would ideally end.

Quoting from an article (here):

Emerging use of passkeys for end-to-end encryption with the PRF WebAuthn extension (Explainger: PRF extension, Webauthn PRF-extension) which is used to provide access to anf encryption key from a passkey for particular site, which can then be used to reliably encrypt and decrypt data. One of uses for this is to provide the client with vault data ( Bitwarden log in with passkey).

Here's another interesting article: encrypting-data-in-the-browser-using-webauthn

A relying party identifier (RP-ID) could be a browser extension ID, or the web page origin that it is integrating (with host permission).

My additional thought with a browser extension or website (example at https://webauthn.io/), use WebAuthnn, register a security key, e.g. FIDO2.
Then use PRF extension to send webauthn a seed (always the same for a given relying party) and get back the result of a predictable random function result that is always the same for that security key and relying party identifier, and it could be used as an encryption key (as described above), or perhaps even a signing key! So the browser extension (or other webauthn client) would have the signing key in memory for a while, but it wouldn't be persisted. That would open up some interesting possibilities.