With a #DID derived from a secret key you can truly own your identity. Unfortunately, key rotation is not supported, and if you lose your key, you lose everything. This can be partially mitigated with distributed key generation techniques that make key recovery possible if only M of N shards are available, but they are complicated.
Servers can rotate keys, but they can also suddenly disappear, and again you lose everything.
Blockchain-based systems support key rotation and don't have a single point of failure (if done right). Sometimes they are called "servers with superpowers". However, popular ones are not suitable for the job because writing to them is very expensive and their clients need powerful computing devices and a lot of storage.
Is there a way around that? Yes. Blockchains can be very lightweight and they don't actually need a cryptocurrency, miners or stakers in order to work. There is a simple consensus algorithm known as Proof of authority, and one of the Fediverse competitors, Bluesky, seems to be planning to build such system:
>We are actively hoping to replace it with or evolve it into something less centralized - likely a permissioned DID consortium.
They are afraid to say the B-word, but "permissioned consortium" is exactly what it is. Of course, their identity #blockchain doesn't have to be the only one in existence. I think in the future we might see quite a lot of "identity cooperatives" of different shapes and sizes. Perhaps even a universal client, curl for identity, can be developed.
@silverpill
Maybe also look at how #SafeNetwork can provide this. It uses BLS keys (so M of N) to access encrypted account data stored on a permissionless (autonomous, p2p storage network) that stores data forever.
I'm investigating use of human readable decentralised identity for a DNS type system on this network, but these identities will be usable for anything of course. So details are up to anyone wanting to build an identity system on Safe Network, but it is going to be interesting.
The “central directory server” here, is a whole-ass decentralized blockchain. Contrast with did:plc for a rekeyable identity.
“Identities” on the Chia blockchain can be treated like [the original, actually useful vision of] non-fungible tokens, so re-keying an identity becomes the same operation as re-keying your [Chia] wallet (which can also store other identities / coins / NFTs / etc)
@silverpill while I’m clueless about this stuff at the low level, it seems to me like did-plc is Good Enough for a starting point that works today.
It is transitory by design, so whichever next-stage direction the Bluesky devs take it in can be diverged from if it doesn’t align with the requirements for #NomadicIdentity in the fediverse.
I’m afraid that if we wait around another year++ for the perfect solution to come along, Good Enough alternatives will be deeply entrenched by that time.
@silverpill experimenting with fedi-ID built on did-plc would also open another door for cross-protocol interoperability.
I don’t really mind sending messages via two different social-post services, or even keeping two different post boxes. But I sure would love to have a singular digital-home address for both of these post boxes to be listed under.
@erlend No, did:plc is not good, it is just a centralized and vendor-locked version of did:web. Even if they manage to switch to a distributed architecture, fediverse developers should avoid did:plc because it is owned by a company that develops competing social network.
Good Enough solutions are did:web and did:key.
did:web is equivalent to what we already have in Fediverse: keys are controlled by instances. But FEP-ef61 separates identity and data, so you can have data portability even though identity is still attached to a single server.
did:key is equivalent to what Nostr does: keys are controlled by users
@silverpill@erlend Indeed:
“A central directory server collects and validates operations, and maintains a transparent log of operations for each DID.”
Ironic for a Decentralized ID to be anchored around “a central directory server,” for sure. Is did:plc actually a “Must” implement for DID 1.0 compatibility?
@cmdrmoto@erlend No, DID 1.0 specification doesn't require central directories. Many DID methods depend on some kind of registry, but I think in most cases it is based on distributed ledger technology aka blockchain, so when developers make claims about decentralization, they are not completely untrue.
did:plc is not like that, it is literally a single server, and I have no idea why Bluesky team uses the term "DID". Fake-it-until-you-make-it, I guess.
@silverpill@erlend@cmdrmoto PLC today works with centralized servers for convenience, but it doesn't have to stay that way. the core of the method is self-certifying identities, and that info could be distributed any number of ways.
In a permissioned setting (assume 0 malicious actors, and only need to be crash fault tolerant rather than Byzantine fault tolerant), just use Raft or something.
As far as N-of-M threshold signatures goes, FROST isn't too bad to implement.
@greyarea Thanks for the pointers. I probably won't work on this myself, my job is to pick a winning technology and integrate it. The winner is going to be the most resource efficient solution that supports key rotation and has redundancy while being user friendly.
It is a lightweight blockchain-based naming system without cryptocurrency. Great idea, but it's PoW-based. There is gap between this and regular servers, and I think it needs to be filled.
Add comment