Re: Prioritizing Individual Sovereignty over Interoperability

Mrinal,

Excellent point. It will be crucial to get this aspect
(expiration/staleness) right, when proposing this method.

In general, being able to tell if an object is stale (or revoked) is a
really hard problem, in distributed systems. Fortunately, there is a
handful of standard solutions to this, some combination of which would have
to be used with the did:web method. For the "eventually consistent" class
of systems, and all of the DID methods proposed so far fall under this
category, these all basically boil down to "check the expiration date" or
"consult a revocation mechanism". And most systems (including the various
blockchains and DHTs) will use a combination of those two.

Dmitri



On Sat, Apr 27, 2019 at 3:04 PM Mrinal Wadhwa <mrinal.wadhwa@gmail.com>
wrote:

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