This issue is to gather references and track the discussion of a decentralised
identity, beyond the use of did:key, in Radicle. @lorenz will be aiding me
(@fintohaps) in the exploration of this, but everyone is free to chime in with
helpful suggestions and pointers :)
The general approach will be to find a DID method that we can effectively use in the Heartwood protocol. So the first part of the exploration will be to find one that is appropriate, and failing that create our own. In my opinion, this automatically rules out any DID methods that rely on blockchain technology. It will have to be a method that can be accessed locally from the Git repositories (Git is our blockchain :)) – either verified in the repository itself or some kind of attestation.
From there, we need to also think about how having multiple keys fits into the existing architecture of the Heartwood protocol. A person will want to be able to easily unify their experience working from separate machines, but necessarily, the protocol will need to identify those machines as different. We will want to be able to have the identity being transmitted alongside repositories, but not duplicate the work of storing the identity history per project repository. We will want to be able to have secure features around revocation and rotation. And there’s probably lots more lying underneath that we can’t think of right now :)
I went through the list of DID methods in the w3c/did-spec-registries repository as of
4efd964and checked all of them for relevance. My conclusion is th KERI is the best candidate in this list. Most of them are related to and dependent on blockchains. Others are dependent on DNS and/or a stable HTTPS endpoint to fetch the DID document.Interesting finds are:
Note that there are some notes (last changed 2022-11-08) about using KERI in Radicle. Most of these are still relevant, but not up to date.
One way to split work, which connects naturally.
Verification, assuming KERI DID
Assume that a DID an event log for
did:keri:xcan be resolved, make other dependent features (like validation of signed refs) work usingdid:keri:x.Storage
Implement storage of a DID and event log within Radicle.
I started working on a proof of concept based on
THCLab/keriox. See patch6024785.We’ll watch progress on
kentbull/keridewhich might replacekeriox.It would be quite cool if multiple of these were supported, to more flexibly address different kinds of projects/organisations.
For example, for TVL we might want to move our repo to Radicle in the future (it’s only mirrored there right now), but we’d want to have it be as “recoverable” as possible if something goes wrong (see also issue 7bdbbef).
Having a recoverable key in DNS, for example, would at first glance be quite nice. It raises the same question about what’s going on with historical data though, as DNS is obviously mutable.