Propose to change the quorum rules to allow for identities to be
created with multiple delegations and be considered verified.

Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
---

A short RFC to ammend the quorum rules for creating an identity with
multisig and consider it verified.

Published-as: https://github.com/FintanH/radicle-link/tree/patches/rfc%2Fsimplify-multisig-identity%2Fv1

 docs/rfc/0703-simplify-multisig-identity.adoc | 53 +++++++++++++++++++
 docs/spec/sections/identities.adoc            |  9 +++-
 2 files changed, 60 insertions(+), 2 deletions(-)
 create mode 100644 docs/rfc/0703-simplify-multisig-identity.adoc

diff --git a/docs/rfc/0703-simplify-multisig-identity.adoc b/docs/rfc/0703-simplify-multisig-identity.adoc
new file mode 100644
index 00000000..6c47f85c
--- /dev/null
+++ b/docs/rfc/0703-simplify-multisig-identity.adoc
@@ -0,0 +1,53 @@
+= RFC: Simplify Multisig Identity Creation
+Fintan Halpenny <fintan.halpenny@gmail.com>
++
+:revdate: 2022-05-20
+:revremark: draft
+:toc: preamble
+:stem:
+
+* Author: {author_1}
+* Date: {revdate}
+* Status: {revremark}
+
+== Motivation
+
+The current situation for creating an identity document allows
+multiple delegates to be specified up-front, but the document will not
+be verified until all those delegates reach a quorum. Thus, a new
+identity will only be considered a verified document if and only if
+it is created with a single delegate where the local operator is the
+delegate themselves.
+
+To allow an identity to be considered verified upon creation with
+multiple delegates, it is necessary to ammend our definition of an
+initial quorum.
+
+== Terminology and Conventions
+
+The key words "`MUST`", "`MUST NOT`", "`REQUIRED`", "`SHALL`", "`SHALL NOT`",
+"`SHOULD`", "`SHOULD NOT`", "`RECOMMENDED`", "`NOT RECOMMENDED`", "`MAY`", and
+"`OPTIONAL`" in this document are to be interpreted as described in <<RFC2119>>
+and <<RFC8174>> when, and only when, they appear in all capitals, as
+shown here.
+
+== New Quruom Rules
+
+To allow for the identity to be a verified document with multiple
+delegates upon creation, an extra rule must be added when checking the
+quorum. When checking the quorum of the identity and the revision is
+the root revision, then a quourum is considred reach iff there is one
+eligible signature from a delegate.
+
+More formally:
+
+[text]
+---
+The identity carrier passes the signature check, and:
+
+* The document does not refer to a previous revision, no previous
+  revision is known, and their is a single signature from the
+  delegations.
+* *Or* the document is signed by a quorum of the keys specified in the
+  delegations of the document (`Q > D/2`).
+---
\ No newline at end of file
diff --git a/docs/spec/sections/identities.adoc b/docs/spec/sections/identities.adoc
index 49b76744..eebf4733 100644
--- a/docs/spec/sections/identities.adoc
+++ b/docs/spec/sections/identities.adoc
@@ -198,8 +198,13 @@ The identity carrier passes 1., and is signed by at least one key specified in
 the delegations of the document.
 . *Quorum*
 +
-The identity carrier passes 2., and is signed by a quorum of the keys specified
-in the link:#delegations[delegations] of the document (`Q > D/2`).
+The identity carrier passes 2., and:
+
+    * The document does not refer to a previous revision, no previous
+      revision is known, and their is a single signature from the
+      link:#delegations[delegations].
+    * *Or* the document is signed by a quorum of the keys specified in the
+      link:#delegations[delegations] of the document (`Q > D/2`).
 . *Verified*
 +
 --
-- 
2.31.1

On 20/05/22 03:20pm, Kim Altintop wrote:
> The same effect can be achieved by introducing a threshold field which allows to
> specify the exact number of signatures (clamped to (0,n] where n is the number
> of delegations).

Would the workflow to achieve the same outcome as this proposal then be
to publish an identity document with `n` signatures on it but a
`threshold` of `1` and then publish an update which changes that
threshold to `n/2`?

The same effect can be achieved by introducing a threshold field which allows to
specify the exact number of signatures (clamped to (0,n] where n is the number
of delegations).

It is not always obvious what value to pick for the desired semantics (`n` is
almost always a bad choice), which is why I went for a predefined quorum
initially. I think this is still the best choice for project identities, but
personal ones may prefer 1 or 2.

On Fri May 20, 2022 at 2:23 PM IST, Alex Good wrote:
> On 20/05/22 03:20pm, Kim Altintop wrote:
> > The same effect can be achieved by introducing a threshold field which allows to
> > specify the exact number of signatures (clamped to (0,n] where n is the number
> > of delegations).
>
> Would the workflow to achieve the same outcome as this proposal then be
> to publish an identity document with `n` signatures on it but a
> `threshold` of `1` and then publish an update which changes that
> threshold to `n/2`?

Ya, it might be important to note here that this is only fulfilling
the want for initialising a document with multiple delegates and
consider it verified. We do have another task for allowing
configurable thresholds for personal identities.

I dunno if it would be desirable to have something like:

---
struct RootThreshold(pub Threshold);

struct Threshold {
  signatures: usize,
  threshold: usize,
}
--

So that this scenario being proposed is configurable too.

Perhaps I could propose both these mechanisms as one RFC?

On Fri May 20, 2022 at 3:35 PM CEST, Fintan Halpenny wrote:
> Ya, it might be important to note here that this is only fulfilling
> the want for initialising a document with multiple delegates and
> consider it verified. We do have another task for allowing
> configurable thresholds for personal identities.

Why do two things when one does the job?

> I dunno if it would be desirable to have something like:
>
> ---
> struct RootThreshold(pub Threshold);
>
> struct Threshold {
>   signatures: usize,
>   threshold: usize,
> }
> --
>
> So that this scenario being proposed is configurable too.

I don't understand what this solves. The case where you already have obtained
the required signatures out-of-band? How is a root threshold different from a
non-root one?

On Fri May 20, 2022 at 3:23 PM CEST, Alex Good wrote:
> On 20/05/22 03:20pm, Kim Altintop wrote:
> > The same effect can be achieved by introducing a threshold field which allows to
> > specify the exact number of signatures (clamped to (0,n] where n is the number
> > of delegations).
>
> Would the workflow to achieve the same outcome as this proposal then be
> to publish an identity document with `n` signatures on it but a
> `threshold` of `1` and then publish an update which changes that
> threshold to `n/2`?

Well, if you already have n signatures, then the quorum rule holds. The issue is
when you crate an identity document with n delegations, but only one signature.
Otherwise, yes.

On 20/05/22 04:52pm, Kim Altintop wrote:
> On Fri May 20, 2022 at 3:23 PM CEST, Alex Good wrote:
> > On 20/05/22 03:20pm, Kim Altintop wrote:
> > > The same effect can be achieved by introducing a threshold field which allows to
> > > specify the exact number of signatures (clamped to (0,n] where n is the number
> > > of delegations).
> >
> > Would the workflow to achieve the same outcome as this proposal then be
> > to publish an identity document with `n` signatures on it but a
> > `threshold` of `1` and then publish an update which changes that
> > threshold to `n/2`?
>
> Well, if you already have n signatures, then the quorum rule holds. The issue is
> when you crate an identity document with n delegations, but only one signature.
> Otherwise, yes.

Yeah I mistyped, I meant if you have `n` delegates. This scheme has one
disadvantage vs modifying the original quorum rules: any of the
delegates could fork the project before the update modifying the quorum
threshold right?

On Tue May 24, 2022 at 11:37 AM CEST, Alex Good wrote:
> This scheme has one disadvantage vs modifying the original quorum rules: any
> of the delegates could fork the project before the update modifying the quorum
> threshold right?

The quorum (or threshold) must hold for both the focused revision and its
parent. So, unless I'm missing something, this issue exists under both
proposals.

One solution could be to require signatures from the actual signers (as opposed
to the set of delegations) of the parent to be present in the set of signatures
for the focused revision. This would, however, prevent to rotate the entire set
of keys between revisions. I am not sure this would be desirable, so would
probably need to be constrained to the root revision. Which turns out to be
isomorphic to the current scheme, heh.

I'd like to go back and reiterate what my thinking is just so I can
make sure it's clear :)

So we have two TODO items[0]:

---
* [ ] Simplify initialising a multisig identity

  > Verification may allow the initial revision to have only one signature,
  > regardless of the number of delegations.

* [ ] Quorum overrides for personal ids

  > Cross-signing from multiple devices is inconvenient for personal ids.
  > Macaroons could be issued which allow to confirm a change using only one
  > second factor (HSM, password manager, ..). Or maybe just make the quorum
  > threshold configurable.
---

This proposal was aiming to tackle the first one of this list. I can
see three different solutions based off of this conversation.

1. During verification, we ignore the quorum -- configured or
hard-coded -- iff:
  a. we are looking at the initial revision
  b. it has a single delegation signture
Note that this was what I was proposing in the RFC and implementation.

2. We implement the configurable threshold, where the initial creation
can set the threshold to 1 signature and the threshold is subsequently
updated.
This seems to have the downside that you MUST trust the other
delegates to not change the history during the quorum threshold
update. They only need to change the document and sign it, passing the
threshold of 1. That is, unless I've misunderstood and the update of
the quorum would take immediate effect, which is what you were saying
here:

On Tue May 24, 2022 at 11:28 AM IST, Kim Altintop wrote:
> The quorum (or threshold) must hold for both the focused revision and its
> parent. So, unless I'm missing something, this issue exists under both
> proposals.

3. We do nothing (or add the threshold but forget about the
initialisation task). The creation of a document is signed by the
initial delegate -- so it is considered verified. They can then update
the document with new delegate ids, the document is replicated and
x-signed by the delegate set. I think this is isomorphic to getting
signatures out-of-band.

On Tue May 24, 2022 at 11:28 AM IST, Kim Altintop wrote:
> One solution could be to require signatures from the actual signers (as opposed
> to the set of delegations) of the parent to be present in the set of signatures
> for the focused revision. This would, however, prevent to rotate the entire set
> of keys between revisions. I am not sure this would be desirable, so would
> probably need to be constrained to the root revision. Which turns out to be
> isomorphic to the current scheme, heh.

Sorry, I don't think I understand what you mean here. What's the
difference between "actual signers" and "the set of delegates"?

[0]: https://github.com/radicle-dev/radicle-link/blob/master/TODO.md#identities

As Alex reminded us, the threshold is exactly the number of keys an attacker
would need to compromise in order to gain control over the identity history. Any
scheme which permits a threshold of one (i.e. all that are being discussed) is
fairly bad thus, unless that single key is rotated out immediately and then
destroyed. Note that this is not a matter of trust (if you delegate trust to
keys you don't trust, then. Well. Have you tried turning it off and on again?),
but a matter of finality; which is undefined within link.

So, we have gained nothing.

I don't think exchanging signatures oob is bad per-se, as the public keys need
to be exchanged anyway. It would also not require a second transaction. Perhaps
an "experience" can be created around that, which involves comparing random
sequences of emojis or something like that?

Alternatively, I think an explicit threshold > 1 would work too, if the creator
has a second singing device at hand. Observe:

    revision = 0
    delegates = [A, A', B, C, D]
    threshold = 2
    signatures = [Sa, Sa']

Where A and A' are in fact controlled by the same person.

Practically, however, "second factor" signing keys would require supporting
weaker^H^H alternative signature schemes. Which in turn would require
generalising network identity, or else labelling them as second-factor-only. Oh
and baroque encodings. I got a new hammock, perhaps I should try that out right
now.

On Thu May 26, 2022 at 1:27 PM IST, Kim Altintop wrote:
> As Alex reminded us, the threshold is exactly the number of keys an attacker
> would need to compromise in order to gain control over the identity history. Any
> scheme which permits a threshold of one (i.e. all that are being discussed) is
> fairly bad thus, unless that single key is rotated out immediately and then
> destroyed. Note that this is not a matter of trust (if you delegate trust to
> keys you don't trust, then. Well. Have you tried turning it off and on again?),
> but a matter of finality; which is undefined within link.
>
> So, we have gained nothing.
>
> I don't think exchanging signatures oob is bad per-se, as the public keys need
> to be exchanged anyway. It would also not require a second transaction. Perhaps
> an "experience" can be created around that, which involves comparing random
> sequences of emojis or something like that?
>
> Alternatively, I think an explicit threshold > 1 would work too, if the creator
> has a second singing device at hand. Observe:
>
>     revision = 0
>     delegates = [A, A', B, C, D]
>     threshold = 2
>     signatures = [Sa, Sa']
>
> Where A and A' are in fact controlled by the same person.

Ya, so I think the initial task of making the initialisation process
with multiple delegates easier is not worth it. I think a combination
of the `lnk identities project update` and `lnk sync` commands with
some seeds will be the way to go initially.

So I'll mark this RFC as rejected.

> Practically, however, "second factor" signing keys would require supporting
> weaker^H^H alternative signature schemes. Which in turn would require
> generalising network identity, or else labelling them as second-factor-only. Oh
> and baroque encodings. I got a new hammock, perhaps I should try that out right
> now.

Why would they require weaker schemes?

Also: blockchains

> Why would they require weaker schemes?

ed25519 is not very widely supported on key fobs f.ex.

On Mon May 30, 2022 at 12:10 PM IST, Kim Altintop wrote:
>
>
> > Why would they require weaker schemes?
>
> ed25519 is not very widely supported on key fobs f.ex.

Funnily enough, I just came across this[0] today

[0]: https://xeiaso.net/blog/yubikey-ssh-key-storage