RFC: Identity Proofs

Signed-off-by: Kim Altintop <[email protected]>

Author: kim

docs/rfc/identity_proofs.md

@@ -0,0 +1,214 @@
+# RFC: Identity Proofs
+
+* Author: @kim
+* Date: 2021-02-23
+* Status: draft
+* Community discussion: n/a
+
+## Motivation
+
+A `radicle-link` [identity][ids] is a hash-linked sequence of signed statements
+about public-key delegations: if an entry in this sequence is found to conform
+to a quorum rule of cryptographic signatures, the set of keys it delegates to
+can be considered trustworthy _iff_ the previous set was. Yet, how can we trust
+the initial set of keys in this chain?
+
+## Overview
+
+We consider it impractical for most participants in the `radicle-link` network
+to exchange public keys out-of-band, given a pattern of casual interaction with
+others. While the protocol mandates connections between participants, similar to
+"following" relationships found in social media, we thus consider it
+insufficient to infer a [web of trust][wot] from those relationships.
+
+To lift the requirement for physical authenticity checks, but still increase
+confidence of a given public key being associated with a particular person,
+[keybase] have popularised a scheme dubbed "Social Proofs": a statement claiming
+ownership of a particular account on a social media site is written to the
+keybase "sigchain" (which has properties similar to a `radicle-link` identity).
+This claim (implying also the history of the sigchain) is signed using a key
+currently valid according to the chain, and the signature (along with the public
+key) is stored at the social media site. To verify the claim, the signature is
+retrieved from the social media site in such a way that it could _plausibly_
+only be created by the owner of the claimed account. If both the sigchain
+integrity and the claim signature can be verified, the association is proven.
+
+This mechanism can be considered a practical application of the [Turing test]:
+even though it can not be proven beyond doubt that the account is indeed
+associated with a real person, the evidence of others accepting it as such, as
+well as conversational behaviour, can increase the confidence in the
+authenticity of the online persona. Because key and account ownership at a given
+point in time can be cryptographically verified, this confidence can be extended
+to the proving side.
+
+We conclude that this mechanism would be a good fit for `radicle-link` (due to
+the similarities), and a desirable feature of applications built on top of it.
+
+The following sections describe how such claims shall be stored in the identity
+payload of a `radicle-link` identity, how to obtain a publishable proof, and how
+to verify it.
+
+## Claims
+
+Claims can only be made by identities of kind `Person`, and claim a single
+external account identifier. They are introduced by defining a new payload type,
+identified by the URL:
+
+    https://radicle.xyz/link/claim/v1
+
+The shape of the JSON structure is:
+
+```json
+{
+    "service": {
+        "name": "STRING",
+        "account": "STRING"
+    },
+    "expiration": {
+        "created": INTEGER,
+        "expires": INTEGER
+    },
+    "proof": "URL"
+}
+```
+
+Where the fields denote:
+
+* `service`
+    * `name`
+
+      A conventional identifier of the external service, e.g. "github",
+      "twitter", "radicle-ethereum"
+
+    * `account`
+
+      The unique account identifier within the service, using the service-
+      specific canonical string representation e.g. "kim",
+      "0x32be343b94f860124dc4fee278fdcbd38c102d88".
+
+* `expiration` (optional)
+    * `created`
+
+      Creation timestamp of the claim, in seconds since 1970-01-01T00:00:00Z.
+
+    * `expires`
+
+      Seconds relative to `created`, after which the claim should no longer be
+      considered.
+
+* `proof` (optional)
+
+  A URL to assist verification tooling in retrieving the proof from the external
+  system. This is mainly a convenience, and obviously requires creation of a new
+  revision after the fact.
+
+## Proof Generation
+
+The above claim payload is committed to the identity history as a new revision.
+Technically, this revision needs to be approved by all key delegations for
+verification to pass later on, but since we assume that eligible keys are held
+by the same person, it may be acceptable to publish the proof right away for
+user experience reasons.
+
+The actual proof consists of the following tuple:
+
+    (root, revision, public key, signature)
+
+> TODO: include a protocol bit (denoting "git"), for forwards compat?
+
+The values `root`, `revision`, and `public key` are specified in
+[identities][ids], and it is RECOMMENDED to follow the serialisation formats
+devised there. `signature` is the Ed25519 signature over `revision`, in much the
+same way as the actual revision is signed. All values can thus be obtained by
+inspecting the identity storage.
+
+It is beyond the scope of this document to devise the exact external format to
+serialise the tuple into, as this is expected to vary from service to service.
+
+## Revocation
+
+A claim can be revoked by creating a new identity revision which simply does not
+contain the claim payload. Likewise, a later claim describing the same `(service
+name, account)` mapping invalidates an earlier one.
+
+> NOTE: claiming multiple accounts per service is permissible in principle, but
+> might be undesirable for certain services. In this case, service-specific
+> post-validation is required.
+
+## Verification
+
+1. Given the 4-tuple specified [above][#proof-generation], it is first verified
+   that the signature is valid for the given `revision` and `public key`.
+
+2. If it is, the identity history needs to be resolved from local storage, or
+   the network.
+
+  2.1 If persistence of verification results is available, the identity document
+      at the given `revision` is retrieved, its `root` compared against the
+      supplied one, and it is verified that the given `public key` is a member
+      of the `delegations` set. If expiration is specified in the claim, it is
+      determined if `expiration` seconds already elapsed since `created`
+      according to the clock, in which case verification fails.
+  2.2 Otherwise, the identity verification procedure is run first, after which
+      the history is walked backwards until the `revision` is found. Then, step
+      2.1 is performed.
+
+3. Lastly, the identity history needs to be examined for revocations.
+
+## Discussion
+
+The inclusion of the `revision` in the proof allows to assert that `root` is
+indeed an ancestor, which opens up another way to detect "forks" of the identity
+history: due to the peer-to-peer nature of the `radicle-link` network, it is
+vulnerable to attacks which involve withholding data from other participants, in
+which case a fork may go unnoticed.
+
+It should be noted, however, that refreshing the proof from time to time in
+order to ensure freshness of the data retrieved through `radicle-link` is not
+always practicable.
+
+In order to prove that the(ir own) server is not lying by omission, Keybase
+[anchors a merkle root][keybase-stellar] on a blockchain, which includes all
+sigchains registered in the Keybase directory. Because `radicle-link` does not
+have such a central directory, this approach could only be applied to a partial
+view of the network.
+
+While conceivable that, given the right incentives, such a directory service
+could be operated independently (similar to what the [ceramic] network devises),
+it is unclear what value blockchain anchors of individual identities have, given
+that transaction costs discourage frequent updates.
+
+It has also been proposed to employ a mutual attestation scheme with a
+blockchain (namely the [radicle-contracts]), but we haven't been able to
+convince ourselves that this is practical (or even beneficial) because:
+
+1. the verification obligation becomes more complex
+2. the creation procedure becomes more complex
+3. it is unclear what to do in case of conflicting statements (in the presence
+   of revocations)
+4. the lying by omission problem is not solved, due to the disincentive to
+   refresh proofs
+
+We thus RECOMMEND to either:
+
+* incentivise bulk anchoring
+
+* integrate with an existing bulk anchoring service
+
+  Note that in this case the external service becomes authoritative, and no
+  extension to the `radicle-link` protocol as described here is necessary.
+
+* treat "web3"- like any other web-service
+
+  This may entail finding ways to reduce costs, for example by storing the proof
+  payload in transaction logs (which can be verified separately).
+
+---
+
+[ids]: ../spec/identities.md
+[wot]: https://en.wikipedia.org/wiki/Web_of_trust
+[keybase]: https://keybase.io
+[tt]: https://en.wikipedia.org/wiki/Turing_test
+[keybase-stellar]: https://book.keybase.io/docs/server/stellar
+[ceramic]: https://github.com/ceramicnetwork/ceramic/blob/master/SPECIFICATION.md#blockchain-anchoring
+[radicle-contracts]: https://github.com/radicle-dev/radicle-contracts