Re: Prioritizing Individual Sovereignty over Interoperability

As one of the people behind the proposed did:web method, I'd like to
clarify a couple of things.

First, the motivation behind it. As a developer deeply committed to, and
deeply involved in the decentralization of the web, and as somebody
concerned about individual sovereignty and dignity of users above all other
principles, I strongly feel that a did:web method has an important role to
play in this ecosystem, and will increase rather than take away individual
user dignity and choice.

If I'm an individual developer, or a small company (or a medium or large
one), or an after-school theater club, or whatever, a method that allows me
to put my DID document on my own website (and cryptographically protect it
with a hashlink) is way simpler, more self-determined and self-sovereign
than many other methods we're touting as 'more decentralized'. It allows me
to capitalize on all the effort I've spent over the years building my
website's reputation and trust among users, etc.

Second, the proposed did:web method, in conjunction with the complementary
Hashlink standard,
fulfills at least TWO of the four properties mentioned in the DID Design
Challenge, namely:

1. Resolvable (this part is fairly obvious, and I don't think is in

2. Cryptographically verifiable. A hashlink to a DID Document stored on the
web is perfectly cryptographically verifiable; regardless of who hosts it,
it is impossible for the hosting party to alter its contents without the
resolver's detection.

3. Persistent? Technically, this method does not fulfill this criteria.
However, I'm not entirely convinced that this is a helpful separate
distinction (in that, it can be merged with the previous one). The
explanation given in the original essay "The identifier will always refer
to the same real-world entity (the subject) and never get reassigned." can
essentially be reduced to #2, Cryptographically verifiable. As in, how can
you tell that the identifier was not reassigned? (Regardless of whether
it's on a ledger or on the web) -- well, the only way is to ask for a
cryptographic proof.

4. Decentralized? But which kind of decentralized? There are many kids of
decentralization -- political, technological, architectural,
administrative, and so on. The web method is less decentralized than
ledger-based DID methods according to _some_ of the types of
decentralization, but far more decentralized according to other types. I
think any sort of heated discussion about which of the proposed DID methods
are more or less decentralized can quickly point out that some of the
proposed method are controlled by a single parent company, or are
incredibly technologically centralized and homogenous (core libraries in
the hands of a small team of developers), etc.

(I'd love to see a mapping of all the proposed DID methods among at least
these four criteria, plus a couple of others, to provide sanity and
perspective to this discussion.)


On Sat, Apr 27, 2019 at 10:42 AM Markus Sabadello <>

> Stephen,
> In my opinion, the proposed "did:peer" method fulfills all the key
> properties of DIDs (decentralized, persistent, cryptographically
> verifiable, resolvable).
> Peer DIDs are self-sovereign, they are under exclusive control of the
> subject, and they don't require a central authority.
> Note that "globally resolvable" is NOT a requirement for DIDs.
> Peer DIDs are a perfect example how fully compliant DID methods can exist
> that don't require a blockchain/DLT (also see this thread
> <>).
> Markus
> On 4/27/19 4:22 PM, Stephen Curran wrote:
> Related to this topic, is the proposed  "did:peer" (
> method
> considered to be in the same non-decentralized camp as "did:facebook" and
> "did:google"?  While I get that "did:peer" is (intentionally) quite
> different from the globally resolvable did methods rooted in a blockchain,
> I think it is a crucial component of the decentralized identity landscape.
> My thought it is a separate discussion from the "did:facebook" discussion,
> but one that should be had in the did spec community. If it is part of this
> topic, I would request commenters consider it so it is not lost in the
> "bigger tent" debate.
> Stephen Curran
> Principal, Cloud Compass Computing, Inc.
> Hyperledger Technical Ambassador
>  -
> Calendar:
> On 4/26/2019 11:46:12 AM, Markus Sabadello <>
> <> wrote:
> Hello list,
> In light of the discussions in the W3C CCG, DIF, and recent threads on
> GitHub concerning proposed changes to the W3C DID spec (related to
> "decentralization" and the "big tent" idea), Joachim Lohkamp (Jolocom),
> Kai Wagner (Jolocom), Eugeniu Rusu (Jolocom), Sean Baldwin-Stevenson
> (Jolocom) and myself (Danube Tech) have prepared an open statement and
> call to action for the community.
> We invite you to read, share, and add your perspectives on that blog
> post with the aim of broadening the discussion and developing a more
> comprehensive and rigorous assessment of how to address the challenge of
> achieving interoperability without diminishing user sovereignty.
> Even though I won't be at IIW, I know sessions around this topic will be
> held, and I hope this statement will serve as useful input.
> Markus

Received on Saturday, 27 April 2019 18:14:47 UTC