- From: Dmitri Zagidulin <dzagidulin@gmail.com>
- Date: Sat, 27 Apr 2019 14:14:08 -0400
- To: Credentials Community Group <public-credentials@w3.org>, Markus Sabadello <markus@danubetech.com>
- Message-ID: <CANnQ-L7c48S39UPChOKfOTpO4EVh2Kr=utOX=b-1+m0yL5=gDQ@mail.gmail.com>
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 > > > > > >
Received on Saturday, 27 April 2019 18:14:47 UTC