RFC: Identity Proofs

[kim]

Rendered

[kim]

It is actually somewhat hilarious how inefficient this is in theory. Either I'm missing something, or life was a little easier on MySQL.

[kim]

It has been concluded that for the use-case of radicle-dev/radicle-upstream#965, a simple one-way attestation in the other direction suffices, and can be expressed with a much more compact proof:

Consider a contract which allows to claim (and unclaim) some Radicle ID (URN). No two claims for the same ID at the same time are permitted. After a successful claim, the transaction ID is included in the claimed URN's identity history.

If either the Ethereum address or the radicle-link identity is trusted, only the inclusion of the transaction in a block on the main chain needs to be verified. Navigation from address to URN entails inspecting the transaction payload. Navigating from radicle-link identity to address entails inspecting the transaction sender.

Note that no elevation of trust results from this, nor assurance of an association with a "real" person. Neither does it improve the fork resiliency of the radicle-link identity, nor defend against hiding of updates. I therefore think that this RFC has a justification in its own right.

Since the identity document payload can be freely extended by library users, and both the payload and the verification semantics are entirely defined by the external system, I don't think a subsequent RFC is required. I also don't think any changes to radicle-link are required, except perhaps for convenience or code organisation reasons. #464 would not hurt, though.