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

On 04/03/2018 09:35 AM, Reto Gmür 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 DID spec does not make ledgers mandatory.

"A DID method specifies the set of rules for how a DID is registered,
resolved, updated, and revoked on that specific ledger **or network**."

Emphasis added. There are no hard rules, such as Decentralized Ledger
Technology (DLT), on the infrastructure used to support DIDs. Several
implementers happen to be using DLT for a variety of reasons. "Network"
is as generic a term as we could find.

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

I do recommend we change *something* with the DID spec if for no other
reason than preventing further confusion as seen here. One reason the
the suitability of DLT is not discussed in the spec is because you do
not need to use a ledger to implement a DID method -- as stated above in
the spec. The spec mentions ledgers because most implementers have
chosen to use DLT. Implementers drive specs.

Note that the work actually started, originally, from a WebDHT model
that was found to be insufficient.

A very old preliminary spec that no longer renders properly can be found
here:

https://opencreds.org/specs/source/webdht/


The very same ideas you put forward here were some of the reasons for
trying to avoid DLT. But, as it turns out, DHTs bring their own
challenges as well, some that are solved by DLT. There's more to DLT
than Bitcoin and more to ledgers than tracking balances and ordering
financial transactions. There is a danger that this perspective itself
is a cargo cult view.

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

There are infinitely many better systems to be conceived of. The
question is whether or not they amount to more than platitudes against a
harsh reality. Or, put another way, there are always trade offs.
Everyone is interested in making a better system, so if you provide the
details (and implementation if possible) for how to achieve it I would
expect a welcome response.

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

Again, there are trade offs. How much additional complexity would be
needed to provide stable, resilient identifiers with key rotation by
taking another approach?

Is the namespace size merely insufficient? It seems like you could pick
a method name at random out of the ~52M options and then implement the
system you propose below with public key identifiers. Is that approach
somehow prohibited now by the DID spec? Are you concerned that someone
else will pick the same name and use it for another purpose? This can
already be done with your public key solution -- or any string for that
matter. We do not control others, we merely recommend a path for
interoperability.

The first implementation of DIDs did not use "methods" and used a DHT.
Implementation experience and debate within the community found the
solution lacking for a variety of reasons, some of which have been
captured over the years in the minutes which are publicly available.

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

If you do not think that the current technical work is headed in the
proper direction, then please put forward specific change proposals and
specification text for alternative directions. If there is a reason that
a DID method you think would be superior would not be compliant with the
existing DID spec, please file a PR with requested changes.

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

I think most of the community is in agreement with this statement. I
would also venture to say that many disagree with the implication that
this is not the goal of specifications being worked on by the Community
Group (including the DID specification).

That being said, as the goal is interoperability between systems
designed by *humans*, business and politics interests will always be a
consideration despite our strong desire to minimize their influence on
technological concerns.


-- 
Dave Longley
CTO
Digital Bazaar, Inc.
http://digitalbazaar.com

Received on Tuesday, 3 April 2018 19:32:53 UTC