R: Prioritizing Individual Sovereignty over Interoperability

Dear all,
the discussion brings me to an issue I need to clarify to myself – apologizes for my partial understanding.

The most similar thing to a DID document in traditional PKI settings is probably a pseudonymous X.509v3 certificate, which associates a public key with some custom identifier. Certificates may be signed by a CA or self-signed.
They are not necessarily published, it is often the user herself who hands over her certificates to third parties whenever required (e.g., certificates are normally embedded in digital signed files, or they are transmitted in TLS flows).
Sometimes certificates are published (e.g., certificate transparency logs, which are now becoming almost mandatory for TLS/SSL certificates) – to enable cross-checking. Certificate transparency is kind of “replicated centralized ledger”.

Now, why do we publish DIDs/DID documetns on some “public space”?
My understanding is that the fundamental reason is not to make DID documents available - this is an utility, but can be done in different ways - but to grant DID uniqueness. What should be avoided is that someone else replicates my DID, associating it to a different key.  Correct?
If this is the case, a single ledger (either centralized or distributed) is optimal. Multiple ledgers are ok if they act on different namespaces. Web methods would only work for the “DID document publishing” part, not for the “DID uniqueness” part.

Thanks for any clarifications,
--luca



Da: Adam Lake <alake@digitalbazaar.com>
Inviato: domenica 28 aprile 2019 03:50
A: public-credentials@w3.org
Oggetto: Re: Prioritizing Individual Sovereignty over Interoperability


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