Update abstract to build bigger tent / weaken "decentralization" requirement

[msporny]

---

Preview | Diff

[ChristopherA]

As the one that probably put "self-sovereign" into the original version of this, I do still +1 this change ;-)

[dlongley]

LGTM -- though it may be redundant to say DIDs are "globally unique" after saying they are a type of URL.

[msporny]

As the one that probably put "self-sovereign" into the original version of this, I do still +1 this change ;-)

:)

I'm attempting to update the specification to build a bigger tent. I'm trying to accomplish 3 things:

1. Make it such that we are inviting to folks that want web-based DID methods to collaborate with us.
2. Make it easier for our colleagues in non-western countries to talk about DIDs.
3. Not compromise the self-sovereign bits by setting that as the expected bar (at least, in the western world).

[msporny]

LGTM -- though it may be redundant to say DIDs are "globally unique" after saying they are a type of URL.

Fixed in 24068dd

[peacekeeper]

Although I understand the political and technical motivations for a "bigger tent", I am critical of weakening the "decentralized" property of DIDs, as has been discussed e.g. in w3c-ccg/did-method-registry#25. After this change, a did:https: method and perhaps even a did:facebook: method would be legitimate. The meaning of the did URI scheme would have to be re-defined and its provisional IANA registration would have to be changed. If "Decentralized Identifiers" are not required to be decentralized, this would create a risk for the identity community to be thrown back from self-sovereign identity to "only" user-centric or even centralized identity systems.

[peacekeeper]

As the one that probably put "self-sovereign" into the original version of this, I do still +1 this change ;-)

@ChristopherA, as the one who started the Rebooting-the-Web-of-Trust movement, are you not worried that weakening the language around "control" and "decentralization" may be the beginning of a reactionary Shutting-down-the-Web-of-Trust countermovement? :-)

[mwherman2000]

One solution is to factor out the did-uri grammar into its own specification so that it become a shared piece of technology across many application domains. This is what I'm specifically advocating for here:

Hyperonomy Universal Decentralized Identifier URI Specification (did-uri-spec) v0.14

• Webcast: https://www.youtube.com/playlist?list=PLU-rWqHm5p45c9jFftlYcr4XIWcZb0yCv
• PPT: https://github.com/mwherman2000/did-uri-spec

[ChristopherA]

@ChristopherA, as the one who started the Rebooting-the-Web-of-Trust movement, are you not worried that weakening the language around "control" and "decentralization" may be the beginning of a reactionary Shutting-down-the-Web-of-Trust countermovement? :-)

I am quite worried about the weakening of the language, allowing centralized DIDs (and also allowing non-updatable DIDs (aka CIDs)). But I also want to see the DID WG chartered. Do you see a way to add back in the word decentralized into the text of the charter (not just the name) in a way that will not cause the charter to fail?

-- Christopher Allen

[mwherman2000]

Here's a proposal for creating Domain-Specific DID Grammars (DSDGs) enabling DIDs to be used in an infinite number of application domains...

As part of the did-url-spec specification work described in this original webcast…

Hyperonomy Universal Decentralized Identifier URI Specification (did-uri-spec)
Webcast: https://www.youtube.com/playlist?list=PLU-rWqHm5p45c9jFftlYcr4XIWcZb0yCv
PPT: https://github.com/mwherman2000/did-uri-spec/tree/master/src
FAQ: https://github.com/mwherman2000/did-uri-spec/blob/master/FAQ.md

…(which emphasized the different application areas or domains that use DIDs and how they can be supported with the did-url-spec grammar), an interesting extension of the did-url-spec specification is the ability to easily customize the generic/baseline did-url-spec grammar to support Domain-specific DID Grammars (DSDGs).

Here’s a short webcast (16 minutes) that describes this capability:

Creating C.U.T.E. Domain-Specific DID Grammars (DSDG) and Parsers v0.3
Webcast: https://www.youtube.com/watch?v=IdLm2jHuADg&list=PLU-rWqHm5p45c9jFftlYcr4XIWcZb0yCv&index=3&t=0s
PPT: https://github.com/mwherman2000/did-uri-spec/tree/master/src

If you have an idea for DID application domain (in addition to DID Documents), I’ve love to hear from you and help you understand how the did-url-spec specification and grammar can help you and your project.

[rhiaro]

This PR resolves #112

[msporny]

@ChristopherA wrote:

I am quite worried about the weakening of the language, allowing centralized DIDs (and also allowing non-updatable DIDs (aka CIDs)). But I also want to see the DID WG chartered. Do you see a way to add back in the word decentralized into the text of the charter (not just the name) in a way that will not cause the charter to fail?

To be clear, this is a PR against the DID spec, not the charter. The charter is pretty clear on what the desired outcome is wrt. "decentralization". So, I don't think that's at risk. To refresh your memory on what the charter currently says, take a look at the introduction: https://w3c-ccg.github.io/did-wg-charter/

It takes a much stronger stance than the abstract in this PR does.

Good standards can, and often do, attempt to find the right balance -- build a large enough tent so that innovations can happen without having to coordinate with the group that created the standard while also signalling what the expected "ideal mode" of implementation should be. If you look at all of the DID Methods today, almost every one is based on a DLT of some kind, so I don't think the whole "decentralization" thing is at risk.

To go at it from another direction, what the spec states, even if normative (e.g. MUST utilize a DLT) can be entirely ignored by the "did:facebook" method and there is nothing a small group of companies can do against a multi-billion dollar company that is dedicated to co-opting the technology for purposes that are not aligned with the community.

The goal here is to build a big tent and enable the folks that want to use web-based methods, even though they are based on "centralized DNS", to be in the tent with us and collaborate and innovate. The alternative places them squarely outside of the tent and puts the group at odds with the folks that want to create Web-based DID methods (which will create massive political problems for us down the line).

I think our approach to all of this should be the "Is Your Linked Open Data Five Star?" approach: https://www.w3.org/DesignIssues/LinkedData.html#fivestar

Our "Five Star DID" approach could be (I'm pulling this out of thin air, not suggesting that these are the 5 things):

1. Enable individuals to directly self-administer their identifiers on the network.
2. Comply with local and global data privacy regulations, such as GDPR.
3. The governance mechanism does not enable the targeting and censorship of individuals or organizations.
4. The technologies do not enable the targeting and censorship of individuals or organizations.
5. The network is operated as a global public utility.

So, did:facebook could achieve 1 and 2 above, but not 3, 4 or 5. did:http could do 1, 2, and 3, but not 4 or 5.

Clearly, some of the items above need definitions (e.g. global public utility), but the idea would be to nudge implementers in the right direction instead of using an ineffective specification MUST requirement.

Does this work for both of you @ChristopherA and @peacekeeper?

@mwherman2000 -- Perhaps I'm being dense, but I don't understand how your proposals (which I read through twice) are related to this specific PR?

[mwherman2000]

@msporny I'm advocating an approach where a generic/baseline did-uri grammar is defined inclusive of but independent of any particular application domain ...including treating the did-spec and did-resolution specs as two of these application domains.

There's now a family of webcasts (with a fourth to be published tomorrow): checkout https://www.youtube.com/playlist?list=PLU-rWqHm5p45c9jFftlYcr4XIWcZb0yCv (they're getting shorter - 20 minutes or less). Thank you for inquiring.

HINT: When you're watching a YoiuTube video, you can click on the gear settings icon and ask YouTube to play the videos a 1.5x or 2x speed. This works well because I deliberately talked slowly when recording this series of webcasts.

[peacekeeper]

To go at it from another direction, what the spec states, even if normative (e.g. MUST utilize a DLT) can be entirely ignored by the "did:facebook" method and there is nothing a small group of companies can do against a multi-billion dollar company that is dedicated to co-opting the technology for purposes that are not aligned with the community.

The argument that someone could create a did:facebook method anyway and that therefore we should "allow" it in the spec/charter in the first place, is not convincing to me. Neither is @jandrieu's argument that it's still all decentralized because there are many DID methods to choose from, and that therefore it doesn't matter if some methods are not decentralized. I believe that what we write in the spec/charter to describe the nature of the identifiers WILL have an impact on the applications and services that get built and deployed, and those will affect the people who use them.

The goal here is to build a big tent and enable the folks that want to use web-based methods, even though they are based on "centralized DNS", to be in the tent with us and collaborate and innovate. The alternative places them squarely outside of the tent and puts the group at odds with the folks that want to create Web-based DID methods (which will create massive political problems for us down the line).

I really see the benefits of the "big tent". I see the value of having a did:https method, even though there are already other discovery methods for DNS-based identifiers. Web people could already use WebFinger or WebID to do pretty much the same thing as we do with DID Resolution (discover keys and service endpoints), but I understand that using DID syntax and DID Resolution functionality for DNS-based identifiers is attractive for technical reasons, interop, etc.

The dilemma is that the whole DID concept basically offers 3 things: 1. A set of values around decentralization and sovereignty, 2. The DID syntax, 3. DID Resolution.

Methods such as did:https and did:facebook want to make use of 2. and 3. without fulfilling 1. Nobody is saying that such identifiers don't have value. But they are not self-sovereign, and by the measure of the original DPKI paper, or Zooko's triangle, they cannot be called "Decentralized Identifiers".

I think in theory the right thing to do would be to decouple 1. from 2.+3. above. If DID syntax and DID Resolution are so attractive to a "big tent" community, then we should call them something else that doesn't imply decentralization and sovereignty. We should rename "did" to "id" (or "acct", remember that one?), and we should rename the "DID Document" to "Identifier Resource Descriptor" or something like that (= more modern version of XRD/JRD/WebID-profile). Then we would have a system that allowed all kinds of identifiers (whether decentralized or not) to use a shared syntax and resolution infrastructure.

Since such a major change isn't realistic, we're faced with the question of whether we are willing to (partially) sacrifice decentralization and sovereignty principles in order to enable a "big tent" and increase political support, adoption, interop, etc. Personally, I'd rather not do that. I have a strange feeling about this; the same strange feeling I had when years ago David Recordon announced at IIW that he had joined Facebook, and the same feeling I had more recently when Sovrin authorized IBM to host multiple nodes on their public ledger. So my personal preference is to take a more radical position and require Decentralized Identifiers to actually be "decentralized". It's hard for me to understand why this would cause the charter to fail (but I haven't been close to that process).

If the community consensus is to indeed weaken the "decentralized" requirement in the interest of the "big tent", then I will support it too, but I wanted to be a warning voice that a line is being crossed here.

If we end up going ahead with this, then I agree something like the "Five Star" approach to characterize and compare DID methods would be very useful.

[msporny]

So my personal preference is to take a more radical position and require Decentralized Identifiers to actually be "decentralized".

How can we effectively require that?

It's hard for me to understand why this would cause the charter to fail (but I haven't been close to that process).

If we take the radical position and require decentralization and make any Web-based DID method illegal, we are effectively stating that anything based on DNS or the Web is not conformant. Do you see the political issue with making that sort of statement and then requesting the creation of a DID WG at the World Wide Web Consortium. :)

Now, to be clear, I don't think you're saying that... but I do want to understand what we could do that wouldn't make you feel as uncomfortable as you do right now.

[jandrieu]

I think many of the advocates of requiring decentralization miss the key fact that by allowing methods, the DID spec itself ensures a decentralized platform, even with DID:facebook and DID:DNS. In fact, the very ability for Facebook to create a DID method means that we have done something profoundly important: we have created a decentralized identity platform that no single entity controls.

Today, URLs depend on IANA, ICANN, and DNS. Even the mighty Facebook is dependent on this architecture.

With DIDs, literally anyone can create a DID method, by design. We maintain a registry for ease of discovery, but that registry is not the exclusive list, and should never become one.

The very fact that we can't stop Facebook from creating a DID method should be championed by proponents of decentralization. We shouldn't be able to stop that. That would make US the centralized point of control.

The entire point of DIDs is to create an architecture that is robust against the failings of any particular power structure. One that, regardless of who is "in charge" allows anyone to participate fully in the platform.

And, yes, no matter how distasteful it might seem to some, that includes Facebook.

"The only way to make sure people you agree with can speak is to support the rights of people you don't agree with." -- Eleanor Holmes Norton

[peacekeeper]

So my personal preference is to take a more radical position and require Decentralized Identifiers to actually be "decentralized".

How can we effectively require that?

Well of course we can't enforce it, but the spec can still require it in order to be compliant. Isn't that true for all specifications? Someone can always ignore requirements.

It's hard for me to understand why this would cause the charter to fail (but I haven't been close to that process).

If we take the radical position and require decentralization and make any Web-based DID method illegal, we are effectively stating that anything based on DNS or the Web is not conformant. Do you see the political issue with making that sort of statement and then requesting the creation of a DID WG at the World Wide Web Consortium. :)

Now, to be clear, I don't think you're saying that... but I do want to understand what we could do that wouldn't make you feel as uncomfortable as you do right now.

If we want the DID specification to be compatible with DPKI and SSI principles, and the "decentralized" property of Zooko's Triangle, then yes DNS-based DID methods would be non conformant. But hey is "DNS-based" really the same as "web-based"? I always thought that the Web as a concept was not limited to a single type of URI. Especially the Semantic Web. At least in the Solid community there seems to be support for DIDs in addition to HTTP URIs, see this recent meeting. Rather than turning DIDs into a bigger tent to be compatible with the Web, shouldn't the Web already be a big enough tent to be compatible with non-DNS based DIDs?

[msporny]

@peacekeeper said:

Well of course we can't enforce it, but the spec can still require it in order to be compliant. Isn't that true for all specifications? Someone can always ignore requirements.

Define "it", and by that I mean "decentralization". What is good enough? What bar do you have to hit? What is the exact spec text you want to ensure is in the specification? I have a feeling we're going to agree, but I want to work from your text (not mine).

yes DNS-based DID methods would be non conformant. But hey is "DNS-based" really the same as "web-based"?

To some people, yes, DNS-based is really the same as web-based. That is the point of contention. :)

Do we say "MUST NOT utilize the Domain Name System" or do we say "SHOULD utilize decentralized ledger technology or equivalent that is not susceptible to single-point failures"... and if we do that, is a replicated database w/ DNS fail-over to multiple IPs good enough?

I'd like to see a concrete spec text suggestion so that we can focus on language that we can get consensus on (instead of spending too much time having a higher level discussion without concrete spec text/language). I think I understand and appreciate your viewpoint @peacekeeper (and @talltree)... I'm just trying to figure out what would need to change in this PR to get it into the spec given both of your viewpoints (which again, I'm supportive of).

[peacekeeper]

I think many of the advocates of requiring decentralization miss the key fact that by allowing methods, the DID spec itself ensures a decentralized platform, even with DID:facebook and DID:DNS. In fact, the very ability for Facebook to create a DID method means that we have done something profoundly important: we have created a decentralized identity platform that no single entity controls.

I think there's also the argument that syntax and semantics of a URI scheme (in our case did) have to apply to every single identifier of that scheme. In other words, I don't think it's good enough that control over methods is decentralized - instead, control over each identifier in each method must be decentralized, in order to fulfill the semantics of the did scheme.

I guess it's also possible to argue otherwise, i.e. to say that the did URI namespace as a whole is decentralized, and individual methods and their identifiers don't have to be decentralized. But that would be a huge shift from how we have understood DIDs in the last few years.

With DIDs, literally anyone can create a DID method, by design. We maintain a registry for ease of discovery, but that registry is not the exclusive list, and should never become one.

Fully agreed.

[peacekeeper]

What is the exact spec text you want to ensure is in the specification?

I like the way it is now, I don't think there's a need to change it:

Decentralized Identifiers (DIDs) are a new type of identifier for verifiable, "self-sovereign" digital identity. DIDs are fully under the control of the DID subject, independent from any centralized registry, identity provider, or certificate authority.

We could say "decentralized" instead of "self-sovereign", if that is a problematic term.

I also like the definition at https://w3c-ccg.github.io/did-spec/#dfn-did:

Decentralized Identifier (DID) - A globally unique identifier that does not require a centralized registration authority because it is registered with distributed ledger technology or other form of decentralized network.

[RieksJ]

Having seen the discussion too late, I was still wondering about what it takes to be (de)centralized: if it is about governance bodies, then how is Sovrin (where the Sovrin Foundation is the central body and Stewards are around it) fundamentally different from Facebook (that has an 8-member Board of Directors as the central body and shareholders around it)? If, however, decentralization is a matter of technology (DLT), isn't the centralized control of the Git repo the central control? Yet if it is not, and facebook were to implement a decentralized DLT, and define its own method to use it, then why not?

[jandrieu]

Actually, I share @peacekeeper's concern on this one. I don't like requirements for "decentralized"--because I don't believe there is a suitable definition across all the work being done in this area.

However, we do need a better definition than the one presented in this PR. The insight I shared on the call today is that perhaps a component of such a definition is "provably under the control of the DID Controller". Today we have some decentralized ways to do that (DLTS, IPLD/IPFS/IPNS) but there may be other ways to achieve provable control.

[dlongley]

The insight I shared on the call today is that perhaps a component of such a definition is "provably under the control of the DID Controller".

That is the primary component of "decentralization" behind the original naming of DIDs so I'm a +1 for using it to drive understanding and requirements. It's an important aspect of independent existence.

[jandrieu]

After the long discussion to date, I'm concerned with the shift in language from "independent from any centralized registry", although I understand and support the goal to be more inclusive.

Perhaps "independent from a single centralized registry" would split the difference.

IMO, it is vital that the DID architecture allow any root of trust to be specified in the DID itself. Because it can contain any root of trust, any DID is free from a "single centralized registry". Unlike names based on DNS or IP addresses, the root is specified in the URL itself.

This is fairly unique in the world of identifiers and we should make it clear that ALL DIDs allow specifying the root of trust, and therefore DIDs as a whole have no dependency on a single central registry.

[peacekeeper]

@jandrieu

IMO, it is vital that the DID architecture allow any root of trust to be specified in the DID itself.

+1, I agree that being able to choose one's root of trust while maintaining interoperability is a hugely important feature of DIDs.

Because it can contain any root of trust, any DID is free from a "single centralized registry".

Permit me to disagree with this statement. In my understanding a did:facebook: DID is not free from a "single centralized registry".

DIDs as a whole have no dependency on a single central registry.

I would agree that the DID namespace as a whole has no dependency on a single central registry, and that this is a big innovation for identifiers. But I doubt that this aspect is what the majority of the community thinks when they hear "D"ID. I believe most people think "D"ID means that every single DID is decentralized, not just the method namespace.

[dlongley]

See charter language for language that does a better job of just talking about what DIDs "enable":

Decentralized Identifiers (DIDs) are a new type of identifier for verifiable, decentralized digital identity. These new identifiers are designed to enable the controller of a DID to prove control over it and to be implemented independently of any centralized registry, identity provider, or certificate authority. DIDs are URLs that relate a DID subject to means for trustable interactions with that subject. DIDs resolve to DID Documents — simple documents that describe how to use that specific DID. Each DID Document may express cryptographic material, verification methods, and/or service endpoints. These provide a set of mechanisms which enable a DID controller to prove control of the DID. Service endpoints enable trusted interactions with the DID subject. This document specifies a common data model, format, and operations that all DIDs support.

https://w3c-ccg.github.io/did-wg-charter/

[msporny]

Make change that @dlongley suggested, the TF agreed to merge the language in the Charter and then merge this PR. @msporny to make the change and then merge.