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

Reto,

I agree completely with your bottom line. But a Community Group report is a
long way from a W3C specification.

It worries me that nowadays it seems to be enough to put together some
loose prose descriptions, a few JSON examples for a document to qualify as
a W3C standard. This puts interoperability of the future Web at risk.

The RDF/OWL/SPARQL stack is a solid stack with sound logic, but the specs
that came after that are not so much. It seems that their editors are not
interested in (and likely not capable of) producing abstract, provable
definitions (imperative algorithms don't count) as part of the specs, and
more interested in getting a W3C stamp on a technology originating in their
company.

On Tue, Apr 3, 2018 at 3:35 PM, Reto Gmür <reto@factsmission.com> wrote:

> 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
>