Re: Prioritizing Individual Sovereignty over Interoperability

> A hashlink to a DID Document stored on the web is *perfectly* cryptographically
verifiable

Dimitri

I agree with your motivation behind did:web but feel its important to
highlight that a hashlink to a DID doc leaves open the possibility of stale
DID docs being presented as valid. Public blockchains mitigate against this.

The hashlink on a website approach takes away from the key/endpoint update
& delete benefits from the DID spec design .. its more akin to hosting your
public key on your website.

Cheers,
Mrinal

twitter.com/mrinal

On Sat, Apr 27, 2019, 11:15 AM Dmitri Zagidulin <dzagidulin@gmail.com>
wrote:

> 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 https://tools.ietf.org/html/draft-sporny-hashlink-02 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
> question)
>
> 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.)
>
> Dmitri
>
>
>
>
>
>
>
>
>
> On Sat, Apr 27, 2019 at 10:42 AM Markus Sabadello <markus@danubetech.com>
> wrote:
>
>> 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
>> <https://github.com/w3c-ccg/did-spec/issues/113>).
>>
>> Markus
>> On 4/27/19 4:22 PM, Stephen Curran wrote:
>>
>> Related to this topic, is the proposed  "did:peer" (
>> https://dhh1128.github.io/peer-did-method-spec/index.html) 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
>>
>> https://cloudcompass.ca  - https://twitter.com/scurranC3I
>> Calendar: https://calendly.com/swcurran
>>
>> On 4/26/2019 11:46:12 AM, Markus Sabadello <markus@danubetech.com>
>> <markus@danubetech.com> 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.
>>
>>
>> https://stories.jolocom.com/prioritizing-individual-sovereignty-over-interoperability-95ec17a36c9b
>>
>> 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
>>
>>
>>
>>
>>
>>