"Decentralized Identifiers": Bitcoin Cargo-Culture and Land Grabbing for the Top Level Names

The Work of the verifiable claims working group promotes the concept of Decentralized Identifiers drafted by the Credential Community Group. While I think that having Decentralized Identifier is indeed very desirable the idea of coupling this identifies to a ledger is both unnecessary and not helpful to decentralization. 

The Bitcoin network is fascinating example of the potential of a decentralized infrastructure. The Network maintains a ledger duplicated among many hosts and the proof-of-work consensus algorithm resolves synchronization issues by coupling decision power to the amount of energy spent on solving cryptographic puzzles. Miners are rewarded for ensuring consensus on the ledger. In the wild west a duel might have resolved a conflict on the content of the shared ledger on the wall of the saloon, Bitcoin clients simply accept the ledger for which most energy has been spent. While for a decentralized currency it is of uttermost importance to have the list of transactions complete and in the right order to prevent double spending, the infrastructure contributions that a decentralized network for storing identifiers should reward, are quite different: to make sure that an identity document is stored forever the system should reward storage capacity. The Bitcoin protocol doesn't reward storage and there is no reward for miners not to prune transactions that serve as decentralized identifiers.

The DID spec draft mentions the term "ledger" 33 times but never explains why a ledger should be a particular suitable model for decentralized identifier, that's what I identify as Bitcoin Cargo-Culture: a piece of the technology that is very useful somewhere else is copied, without it actually serving a purpose in the new place. Bitcoin is fascinating but we don't get a reasonable infrastructure for decentralized identifier by imitating the technology used there. For decentralized identifiers there is no strict requirement on an order of identifiers nor is there an equivalent to the need of preventing double spending. The DID specification is centered around the idea that identifiers are added to a method specific ledger following some method specific rules and restrictions, the DID-URI then contains a token with which the DID-Document can be retrieved. Certainly a decentralized technology can well serve to that purpose but a DHT or similar approach (IPFS, Arweave, Freenet, DAT, etc.) is probably more suitable to the task than a ledger. 

However I question the proposed approach of identifiers that dereference to a document containing the public key via a method tied to a storage mechanism more fundamentally. DIDs require a method name which should be identified by a short string of no more than five characters, from a user or market perspective this is the equivalent to the top level domain. While a central registry is not foreseen, a particular method name will have succeeded when it is supported by the leading client libraries. So for a method name to be successfully "registered" acceptance by the community of implementors is required. That's where the "land grabbing" of the names is happening, organizations and companies that manage to establish a method name right now have a massive competitive advantage in an emerging market of privatized identifier assignment. In this context "decentralized" is merely a marketing instrument, a user obviously has an interest in high redundancy of the data and that there is no single point of failure but this doesn't mean that there is no (inherently central) governing authority that rules how a particular token is assigned to a DID document. That the Veres One method will have a "diverse (both gender-wise, ethnically, culturally and geographically) board of governors" is laudable but not as good as a truly decentralized system that needs no central "board of governors".

Such criticism of an single system might not be welcome right now. The space of short an practical names of five characters or less is big enough so that it can now be peacefully conquered without mudslinging (as the invitation to the Internet Identity Workshop asks for), in the long term however even a limited control over an established DID-method is a highly valuable business asset in the emerging identifier market, as it will then be much harder for new competitors to enter the market.

Now it would be possible to have truly decentralized methods that fits into the DID scheme, an IPFS based method for instance would fulfill this criterion even if it doesn't satisfies the ledger requirement set in the DID-spec, the "bitcoin" method is also truly decentralized but is energy inefficient and long term storage is merely a side effect of clients not pruning their data, as there is no economic incentive to store the data indefinitely. However I question the need to have identifiers tied to the storage of the document. A truly decentralized identifier can be generated a hash of the public key, if the key is then accessed via a central repository, stored on a decentralized infrastructure or kept offline doesn't matter. A credential referencing an URI that contains a strong hash of a public key unambiguously refers to the holder of the respective private key (modulo some revocations and guardian-mechanisms which can also be designed without the need of specific storage layer specific methods). The specification work needed for that is a URI scheme for public keys and a generic graph signing mechanism, so that the owner of a key can for example sign revocation and delegations directives. There is no need to indirectly identify subjects with a locator of an identity document on ledger, nor for a specific scheme for verifiable credential (a credential is verifiable if it comes on a signed document, graph signing is the generic solution).

I would like the W3C developing standards based on technological soundness rather than driven by trends and particular business interest.

Reto

Received on Tuesday, 3 April 2018 13:36:26 UTC