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


Dave,

You argue that I misrepresent DID in that it also allows for DHT based methods and that the spec might be adapted to support hash(pubkey) based DIDs.

But what's left of standardized decentralized identifiers? DID is a URI super scheme that neither fits the URL nor the URN category of URIs, in that it is both a persistent name and allows dereferenciation. My impression is that the 2001 distinction between URLs and URNs is quite obsolete, as HTTP-Range 14 has clarified HTTP URIs can be used to denote any kind of resource. It is also possible (and foreseen in the RFC) to implement decentralized and centralized URN resolver infrastructures.

So why use:

did = "did:" method ":" specific-idstring

rather than the generic URI syntax

scheme ":" hier-part [ "?" query ] [ "#" fragment ]

?

The former poses several restrictions:

 * DID identifiers must be persistent and immutable
 * The range of DIDs is somehow restricted to human and non-human agents that can fully control their DIDs, so basically agents that can make cryptographic signatures and control their DID according to the specification of the method. The spec is not very clear but it seems clear that a DID should not be used to identify a place, a book or a webpage.
 * A DID has to dereference to JSON document which SHOULD contain the public key of the entity identified by the DID
 * DIDs can be registered directly on a distributed ledger or network (what this means and how this is restricted is left to the method definitions).

Could did:http://www.w3.org/People/Berners-Lee/card#i be a valid DID? The DID method specification for HTTP would have to mandate transformation of the various RDF formats common on the web to JSON-LD. Such a scheme would however violate the SHOULD level requirement of the DID spec because of the reliance on the Domain Name system (even if since RFC 7686 these can be decentralized as well). Also there is no guarantee of persistence and immutability but only a best practice of not changing "cool" URIs. But if these requirements would be loosened, how would did:http be more interoperability than http? Essentially did:http would be different from http in that it would remove support for multiple formats and limit the range to person-like resources.

I'm enthusiastic about approaches that bring decentralized alternatives to HTTP/DNS, that is specification that introduce URIs that can be dereferenced to documents without requiring centralized infrastructure. Such URI schemes have been proposed, for example dat: (beaker) and ipfs:, but I don't see a need for a super-scheme specific to agent-identity as little as I see a need for any other range-specific super scheme (like "image:<authority>:<id>").

Even if I disagree with it and think that the variety of formats and the use of abstract data models are strengths of the web architecture, the reduction of formats to JSON might represent an interoperability advantage in that users of libraries implementing the various DID format only need to deal with JSON. This questionable interoperability requirement is however completely Independent of all the talk, non-testable and vague requirements on decentralization and self-sovereignty. That is independent of everything that justifies the name "decentralized identifiers" and all the buzz around it. 

So what are the advantages of DIDs:

 * The claim that the identifiers are based on ongoing work at the W3C is a marketing advantage
 * The separation from the DID specification which makes bold promises, from the actual implementations that only partially fulfill these promises allows for strong marketing claims that cannot be falsified
 * Use synergies of various parties interested in assigning IDs.
 * By agreeing on a super scheme ID assigners create a community of implementors that legitimates the scheme and its standardization.
 * Much more lightweight process to specify a method rather than registering a URI scheme or special use domain name like ".onion"

None of these advantages is technological advantage nor an advantage to the broader community of web users. Decentralized identifiers might indeed be for the greater good, but for that we should have testable technological proposals rather than a super-scheme and some vague promises.

Cheers,
Reto

FactsMission AG
Linked Data for more facts and less noise.


> -----Original Message-----
> From: Dave Longley <dlongley@digitalbazaar.com>
> Sent: Tuesday, April 3, 2018 9:32 PM
> To: Reto Gmür <reto@factsmission.com>; W3C Credentials CG <public-
> credentials@w3.org>; W3C Verifiable Credentials Working Group <public-vc-
> wg@w3.org>
> Subject: Re: "Decentralized Identifiers": Bitcoin Cargo-Culture and Land
> Grabbing for the Top Level Names
> Importance: High
> 
> 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 Wednesday, 4 April 2018 11:40:30 UTC