- From: Adam Lake <alake@digitalbazaar.com>
- Date: Sat, 27 Apr 2019 21:50:21 -0400
- To: public-credentials@w3.org
- Message-ID: <e55bc3e1-08e6-16cc-4cf1-782862d5669d@digitalbazaar.com>
This is an interesting discussion. As with many of you I share a deep desire to see the Web redecentralize and for this community to help deliver on the promise of SSI. I am concerned though that if we become ideological about methods we will unintentionally block benefits of certain methods while putting up blinders to the negatives of other methods. For example, blockchains are not purely decentralized, that is a myth. There are always governance/power dynamics whether they be intentional/unintentional or explicit/implicit. Do miners have power, currency owners, node operators, a select group of trusted governors, or some combination of these? Blockchain immutability and distributed consensus is compelling but the persistence of blockchain networks, in other words the stability of the network dynamics, has yet to be demonstrated. It’s hard to be to think that we should confine DIDs to distributed ledgers. What if a democratically run cooperative wanted to use did:web to issue and manage very affordable DIDs rooted in a single domain? Do we want to prevent that? Is it less self sovereign than a blockchain? My perspective at this stage of DID development is that we should enable a healthy interoperable ecosystem of different methods because the space is not mature enough to know what the best methods are for different use cases or different values. If the spec can support your preferred method than what is the harm of supporting others? Don’t we want an open marketplace ideas/methods? It also sounds like a did:web method could increase adoption of DIDs in general, which seems like a good strategy to get this technology deployed into the mainstream. It might also make sense for our digital identities to be rooted in several DIDs, providing a bit of redundancy to mitigate against the lack of persistence almost certain with these emerging technologies. With all of its flaws DNS has demonstrated staying power. Just a few thoughts to add into the mix. Adam On 4/27/2019 3:17 PM, Dmitri Zagidulin wrote: > 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 > <mailto: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 <http://twitter.com/mrinal> > > > On Sat, Apr 27, 2019, 11:15 AM Dmitri Zagidulin > <dzagidulin@gmail.com <mailto: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 <mailto: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> <mailto: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 >>> >>> >>> >>> > -- Adam Lake Director, Business Development Digital Bazaar Veres.io 540-285-0083
Received on Sunday, 28 April 2019 01:50:53 UTC