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 4efd964 and 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:
One way to split work, which connects naturally.
Verification, assuming KERI DID
Assume that a DID an event log for did:keri:x can be resolved, make other dependent features (like validation of signed refs) work using did: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 patch 6024785.
We'll watch progress on kentbull/keride which might replace keriox.
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.