HAMI: human agreement for multisig issuance

[dhh1128]

Feature request description/rationale

This is the beginning of a discussion about the leadered application-level collect-multsig-inputs protocol that @SmithSamuelM proposed in reaction to #899 . For brevity, I'm using the acronym HAMI [edit; used to be "HIMA" because I can't parse my own acronyms :-)] to refer to this protocol until we pick a better name.

Goal

Robustly coordinate multsig approval to issue a credential., where "robust" is defined in requirement 4 below.

Requirements

1. MUST issue a credential from an AID that is controlled by a multisig group of arbitrary (but reasonable) complexity and signing policy. "Arbitrary" includes degenerate schemes (1-of-N, including 1-of-1).

2. MUST condition the issuance on achievement of the multsig group's threshold, not on achieving KAWA threshold or any other bar.

3. MUST have a leader. MUST NOT require external/prior coordination or voting to choose a leader. MUST allow a party to nominate self as leader. If two parties nominate themselves to lead "the same action" (defined as signatures over data that is identical except for the dt field), one party's proposal MUST fail deterministically (e.g., whichever party has the AID that sorts second lexicographically).

4. MUST be an application-level protocol with robust handling of unhappy paths. MUST tolerate the fact that, due to KATE, actual humans are likely necessary to provide input to advance the protocol -- and humans are not necessarily paying attention or connected at any given time, Thus, the expected runtime of the protocol is days or even weeks, not minutes. This means that simply running through a sequence of IPEX messages is not enough; MIHA MUST include retries when lower-level processes time out, and MUST NOT depend on artificially inflated escrow timeouts at a lower level.

5. MUST model a high-level timeout concept that is different from low-level timeouts. This is the time after which it is pointless to continue, from an application- or user-level perspective. (E.g., "We have to issue this credential by next Monday, when Alice boards a plane and travels to her conference. If we don't succeed by then, we should give up because there will be no point in her receiving the credential after the conference.")

6. MUST distinguish between non-participation (passive lack of response) and active denial ("I see your request but I am affirmatively declaring my refusal to sign"), with configurable actions (specified by leader) on active denial.

7. MUST make a best effort to notify multisig participants of the outcome of the protocol.

8. It MUST be possible to run multiple instances of this protocol in overlapping fashion, with the same or different leaders, and have more than one succeed. That is, the multisig group should be able to work on achieving threshold on more than one question at a time, and possibly to achieve threshold in a different order than proposals were made.

Non-requirements

• Does not need to have a separate stage or separate data artifacts that represent negotiation about whether an issuance is actually desired. It is assumed that human communication will address this need.

Possible impl

I discussed this with Sam, and here's my best attempt to capture our thinking. Any errors are mine, no doubt.

This probably resembles very closely the current multsig key rotation logic written by @pfeairheller , and maybe the low-level multisig IPEX progression we already have. The leader probably sends a propose message that contains a TEL event showing the potential ACDC; participants get back to the leader with signatures. Partly quoting Sam: The EXN is sourced by the AID of a group member, NOT the AID of the group. The receiver then needs to validate that the sender AID is a member of the group, or at least that the signing public key of the sender's current key state is one of the signing keys of the Group AID's key state (for an issuance) or the current key state (for a presentation). The multisig needs to be on a reference to the issuance being presented, which is the payload of the EXN not the EXN itself. Any member of the presenting multi-sig can singly sign the EXN. But there needs to be attached or embedded a threshold satisfycing number of signatures on the reference to the issuance being presented. These can be collected at a higher layer collection protocol -- similar to the collection protocol for issuances.

Possible sequence

• [starting] leader: creates TEL event and sends propose, which includes application-level timeout, probably a description or justification field, sigs that have already accumulated [e.g., from self], refusals that have already accumulated (likely empty), current keystate in KEL, maybe other fields I'm not thinking of.
• [collecting] participant: can send a refuse message to actively deny; can send a join message to agree.
• [collecting] Leader can resend a propose message if original message times out and disappears from escrow. On errors, leader can skip ahead to [finalizing]. On threshold achieved, skip ahead to finalizing.
• [finalizing] If abandoned, timeout, or key state of multisig changed, send outcome failure with reason. If succeeded, commit change to KEL and distribute to witnesses, then report outcome of success to other participants.

After this step completes, the grant message of IPEX can be sent (or resent) as much as needed so the issuee (if any) receives what was issued. Possibly IPEX could start at the offer message instead.

[dhh1128]

Phil, how close is this to what you already implemented? Is it just a minor variation on your current Doer?

[pfeairheller]

Isn't it HAMI?

[dhh1128]

Hah! Good point. :-) HAMI then....

…

On Tue, Dec 17, 2024, 5:08 PM Philip Feairheller ***@***.***> wrote: Isn't it HAMI? — Reply to this email directly, view it on GitHub <#911 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQ3JCHOIA7YPVP2JAGWMQL2GC4IVAVCNFSM6AAAAABTZPU5BOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBZHE2TCMBWHE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[daidoji]

What is HAMI?

[pfeairheller]

What is HAMI?

The acronym proposed in the title of this issue?

[dhh1128]

Hami is what you eat with eggies.

[pfeairheller]

With cheesie!

[pfeairheller]

This sounds quite similar to what is currently implemented for credential issuance from multisig, exn message sending from multisig (designed for IPEX messages, but probably generalizable to any exn), inception and rotation with more formalization around the "leader".

You identified the core logic of initiating a "proposal" to do something by sending an exn with a route rooted in /multisig/* from a group member AID (not the group AID) with the something being defined by an embedded message. Members can then decide to "approve" it by signing the embedded message and sending their own "proposal" the same way. Key to this working is pathed signatures. Each group member not only signs the outer "proposal" exn from their single sig member AID but also the embedded something payload as the member of the multisig AID and attaches that signature with a path designation pointing at the embedded message. The net result is that every member's outer proposal exn message has a distinct SAID, but the embedded something message all have the same SAID.

This allowed for the code to be nearly identical between being the leader initiating a proposal and a follower approving someone else's proposal.

As far as I remember, 3 things are missing from the current implementation. First is any kind of "concluding remarks" type message that lets everyone know that it is finished. Second is any mechanism for recognizing conflicting proposals (which I think is handled by your leader logic). The third missing component is an easy mechanism for rolling back a proposal in the face of failure.

I love the idea of formalizing this into a higher level protocol and roughing out the sharp edges in the current implementation. Thanks for kicking this off!

[pfeairheller]

One final point. I punted on logic for recognizing conflicting proposals because it occurred to me that this sort of logic would have to be implemented on a case by case message dependent on the embedded proposal. What I mean by that is that I couldn't come up an approach to having general logic to identify a conflict between credential issuance or IPEX spurn message. Each embedded message type would have to define what constitutes a conflict.

[edeykholt]

I sketched up a "choreography diagram" of interacting state machines, in attempts to add some application-level precision this discussion. @dhh1128 I'll send you a link to your gmail for to this lucidchart diagram, which if you'd like to, you can change as desired.