Add a DID web method as a work item

[dmitrizagidulin]

New Work Item Proposal

See W3C-CCG New Work Item Process

Include Link to Abstract or Draft

The current draft for the web-based DID method is here (and the point of this Work Item is to move it to a repo under the CCG github org):

https://github.com/uport-project/specs/blob/develop/did-methods/https-did-method.md

Things to note:

• The name of the DID method is still under discussion
• This is emphatically not a uPort- or Ethereum-based method, and the Secp256k..etc keys in the examples are just arbitrary keys. We're in the process of adding other types of keys to examples
• As discussed in previous calls, we realize that a web-based method has different security and decentralization properties as other ledger-based methods do, but also recognize that a method like this would be important in terms of bridge-building to other communities.

List Owners

Identify 1 lead (person responsible for advancing the work item) and at least 1 other owner. Ideally, include their github usernames:

• Oliver Terbu (@awoie)
• Dmitri Zagidulin (@dmitrizagidulin)

[peacekeeper]

I remain opposed to this, because domain names are not decentralized identifiers, any DID method that depends on DNS and/or the CA system is incompatible with the (current) DID spec and the proposed DID WG charter, violates the principles of the RWoT#1 DPKI paper, and undermines the self-sovereign identity paradigm. Centralized, human-readable names can be used to discover DIDs, but they are not DIDs. I understand the political and technical motivations but still believe the risk of what this might entail is too great. You're both my friends and highly accomplished community members, but I'm sorry, I think you should at least try to write something in the Security Considerations section other than "use a strong TLS config".

[jandrieu]

Markus,

I suggest the DID spec is inconsistent.

Yes, it says

DIDs are fully under the control of the DID subject, independent from any centralized registry, identity provider, or certificate authority

Unfortunately, it also says

In a decentralized identity system, entities (in the sense of discrete identifiable units such as—but not limited to—people and organisations) are free to use any shared root of trust.

So... which is it? Are people free to use any shared root of trust, or not?

If you want to require that DID methods themselves be based on "true" decentralized systems, then you must 1) define exactly what it means to be decentralized 2) define a test that can conclusively demonstrate whether or not any given "decentralized system" meets that definition

I posit that you cannot make such a definition. Not one that has both the consensus of the credentials community group and includes permissioned and non-permissioned ledgers.

Despite @talltree's impassioned defense in the weekly call a couple weeks back, it does not matter how hard someone tries. Effort alone does not make something decentralized.

If you want the test for inclusion as a DID method to be that the underlying registry be "decentralized" then define that, and give us a test.

[talltree]

Joe, you make a good point—the spec can't have it both ways. So I have two concrete suggestions.

The first one is for the DID spec to include—perhaps as an appendix—a set of general tests for decentralized systems that we (the CCG) can agree on. Note that I said "tests"—plural—because I think you are right that there is no single test we could all agree on to define decentralization. But I believe we could agree on a set of tests that broadly characterize the differences between a decentralized system and a centralized one. As a starting point, I am including at the end of this message the set of principles the the Sovrin Governance Framework Working Group developed to define "Decentralization by Design" in the Sovrin Governance Framework V2.

The second suggestion is that, rather than try to prohibit DID methods that clearly do not meet these tests (which we could never actually prevent in the wild), at least in the CCG DID Method Registry we could require one or both of the following:

1. That these DID methods be listed in a separate section labeled something like DID Methods for Bridging to Centralized Systems with a preamble providing the appropriate warnings.
2. That these DID methods be registered as subnamespaces under a DID method namespace reserved for these "bridge methods". Such a namespace could be called did:centralized:, did:bridge:, did:warning: or something that we felt sent the right message about the danger of relying on DIDs from centralized systems. So the proposed web method might be named did:centralized:web for example (but still have its own DID method specification).

The SGF V2 Decentralization by Design principles are defined in section 2.8 of the Sovrin Governance Framework V2 Master Document. They are copied here for easy reference. Note that I am not proposing the CCG adopt these exact principles—they are written expressly for the Sovrin Network. But I am suggesting that we could adopt a generalized set of principles based on these, and those discussed in the Wikipedia page on decentralization, and other sources.

2.8​ Decentralization by Design

​2.8.1​ General Sovrin Infrastructure shall be decentralized to the greatest extent possible consistent with the other principles herein. As the business, legal, and technical limitations of decentralization may change over time, the Sovrin Foundation shall continuously examine all points of control, decision, and governance to seek ongoing conformance with this principle.

​2.8.2​ Diffuse Trust Sovrin Infrastructure shall not concentrate power in any single Individual, Organization, Jurisdiction, Industry Sector, or other special interest to the detriment of the Network as a whole. Diffuse Trust shall take into account all forms of diversity among Identity Owners.

​2.8.3​ Web of Trust Sovrin Infrastructure shall be designed to not favor any single root of trust, but empower any Sovrin Entity to serve as a root of trust and enable all Sovrin Entities to participate in any number of interwoven Trust Communities.

2.8.4 Censorship Resistance Sovrin Infrastructure shall be designed to resist censorship of any Entity while remaining compliant with all applicable laws.

2.8.5 High Availability Sovrin Infrastructure shall be designed and implemented to maximize availability of the Sovrin Network.

​2.8.6​ No Single Point of Failure Sovrin Infrastructure shall be designed and implemented to not have any single point of failure.

​2.8.7​ Regenerative Sovrin Infrastructure shall be designed so that failed components can be quickly and easily replaced by other components.

​2.8.8​ Distributive Sovrin Infrastructure shall be designed and implemented such that authority is vested, functions performed, and resources used by the smallest or most local part of the Sovrin Community that includes all relevant and affected parties. Deliberations should be conducted and decisions made by bodies and methods that reasonably represent all relevant and affected parties and are dominated by none.

​2.8.9​ Innovation at the Edge The continued development of the Sovrin Infrastructure shall encourage innovation to take place at the edges of the network among the members of the Sovrin Community most directly involved or impacted.

[awoie]

Because I am one of the authors of the DID method spec, I will obviously support this work item.

Nevertheless, I agree with @talltree proposals that pointing out that the given DID method is not a complete DID method makes sense. I believe both options are viable whereas my initial thought was to have a separate section in the DID registry makes more sense. This would allow readers to easily identify bridge DID methods.

@peacekeeper the "DID" method spec was probably copied from the initial proposal. I fully agree that the spec should contain clear language about security and privacy considerations.

[peacekeeper]

@jandrieu I find the argument "we can't define decentralization, therefore we allow all centralized identifiers" really strange. If we have no (even rough) concensus on what decentralization means, then how can we possibly standardize "Decentralized Identifiers"? I don't think we need new tests, we already have some really good community resources that have guided us in the last few years and explain "decentralization" in the context of identity, e.g.:

• RWoT#1 DPKI paper
• Christopher's SSI principles
• Zooko's Triangle
• Sovrin Decentralization by Design principles

None of the above sources provide a basis for calling domain names "decentralized".

[peacekeeper]

The only way I could see to make this work is to:

• Follow the argument that even though domain names are clearly not decentralized identifiers, the "did" URI space as whole is still somewhat "decentralized", since you can choose which method DID you want to use. I think this is still a super weak argument, but somewhat possible to argue.
• Mark the "non-decentralized Decentralized Identifiers" in a special way, e.g. as proposed by @talltree as "bridge" methods or something like that.

[peacekeeper]

BTW besides the centralized DNS registry, the "web/https" identfiers would also depend on centralized cryptographic trust (CAs), and the identifiers are not designed to be persistent; so we would be sacrificing those secondary aspects as well.

[dmitrizagidulin]

Markus,

I completely understand and agree with your concerns. From your previous comments, though, it sounds like you may be less opposed to this work item if we:

• Went out of our way to list the concerns and possible threats (with regard to centralization etc), as well as advice for their mitigation and migration to more decentralized methods, in the Security Consideration section
• Made it clear that this is intended as a bridge technology, for a narrow set of use cases

Is that accurate?

On Tue, Apr 16, 2019 at 5:43 AM Markus Sabadello notifications@github.com wrote:

BTW besides the centralized DNS registry, the "web/https" identfiers would also depend on centralized cryptographic trust (CAs), and the identifiers are not designed to be persistent; so we would be sacrificing those secondary aspects as well.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c-ccg/community/issues/65#issuecomment-483589122, or mute the thread https://github.com/notifications/unsubscribe-auth/AA5zPbESjys036rkOisD2FjSk5tRoKXMks5vhZtXgaJpZM4cw4m_ .

[jandrieu]

Our job isn't to fix all the centralized things.

Our job is to specify, in clear, unambiguous, and testable terms, a system of decentralized identifiers.

If you cannot test it, you cannot put it in a normative section of a specification.

If you cannot define it and refuse to do so, then there's no need for a specification--because without a definition, such a specification would be meaningless. The whole point is to put in writing what it takes to use, create, and manage DIDs.

I'll restate my primary points, about which you and I are apparently at irreconcilable differences.

1. Decentralized does NOT mean distributed. Your demand that all methods themselves meet some unstated standard for decentralization doesn't even sync with the definition of decentralized and is far more closely demanding that every multiply connected node is somehow itself further decentralized.

https://www.rand.org/about/history/baran.html https://www.peacebiennale.info/blog/paul-baran-centralized-decentralized-and-distributed-networks-1964/

The use of methods themselves meet the platform requirement for decentralization. There is no single authority through which all systems must travel. It's like a DNS where the URL itself can identify WHICH DNS root server(s) to trust. THAT's decentralized.

By its nature, a decentralized system still has centralizing nodes--which connect on their own terms to multiple different nodes, which may in fact serve as gatekeepers or controls in the larger system. You can see them in Paul Baran's diagram. They are the nodes that are multiply connected.

If on the other hand, you envision some amorphous, unspecified definition of "decentralized" arbitrarily enforced by a self-selected group of well-meaning technologists, then you are in fact increasing centralization. This is a trap that can only be avoided by defining, unambiguously, in writing, what does and doesn't not qualify. Do not imagine that the current governance structure for the DID Method registry is a long term solution. This role will almost certainly migrate to some other form or organization. If you cannot define "decentralized" enough to survive shifts in governance of that order, then you don't have a specification, you have a manifesto, not unlike the citations you reference. Self-sovereign identity != decentralized identifiers. Please stop conflating the two. I'd wager good money SSI will never be standardized precisely because so many people prefer their own variations on the theme.

2. There remains no definition of decentralization that will satisfy both the supporters of permissioned systems like Sovrin and unpermissioned systems like BTCR. I'm willing to be proven wrong here, but denying that a definition matters is to ignore how standards work, and in particular what it means to have normative requirements: you must be able to test the requirement.

IMO, the only thing to be gained by trying to force a definition of decentralization is a schism between those who think permissioned systems can somehow magically become "decentralized" with enough hard work and those who believe in rigorous metrics to understand the attack vectors on any given underlying registry. Every system has its factors of centralization. Is multiple interoperable, deployed code bases by multiple groups of independently-funded developers sufficient? Perhaps. Does miner (or consensus) density matter? In what way? What sorts of checks and balances are sufficient to deem a protocol sufficiently decentralized? If a lawsuit or a government can bring pressure on a single organization--perhaps behind sealed court orders, is that sufficient to demonstrate a non-decentralized platform? If all you are doing is adding hoops to jump through and barrels to jump over, but in the end a single lawsuit could bring a network to halt--that's not decentralized, that's just decentralhope. It doesn't mean the network is useless, it just doesn't meet the requirements many have for "decentralized".

In the long run, it is the narrative that matters. EVERY single one of our implementations will have bugs, both technical and logical. Our initial products, our initial networks, our initial specifications are going to have mistakes and errors and outright omissions of vital components.

If you can't define decentralize clearly enough to survive those mistakes, then it has no place in a normative section of the specification.

[victorgrey]

It seems to me that the meaning of "decentralized" is that the locus of control is decentralized, i.e. it resides with each data subject. DIDs are always going to be dependent on the continued existence and accessibility of various technologies, including the internet as a whole, so there is really a continuum of of degrees of decentralization.

If one data subject is ok with assuming that they can maintain control of a domain name and a web server, while another wants to be dependent on nothing more than that someone will continue to provide them with an internet connection -- why should we restrict that choice?

[jandrieu]

On a less confrontation note, isn't the proposed decentralization requirement problematic for private DIDs on private ledgers?

https://twitter.com/darrello/status/1118552392583254016?s=19

[peacekeeper]

@jandrieu

Your demand that all methods themselves meet some unstated standard for decentralization doesn't even sync with the definition of decentralized

What definition do you mean? The ancient Baran diagrams were useful 7-8 years ago to explain the need for (re-)decentralization, but don't reflect how most people understand it today. The "decentralized" diagram has a central node in the middle. Yes with this diagram you could call DNS "decentralized", but based on all the (much more recent) sources I listed you couldn't.

The use of methods themselves meet the platform requirement for decentralization.

I agree we could make this argument. But let's be clear that this would be a major deviation from what the DID spec currently says, and from how most people understand DIDs. You are proposing that it's okay for an identifier that starts with "did:" to be managed by a central registry. I agree methods provide a form of decentralization, but I would claim that 99% of people who have heard about DIDs think that decentralization is a feature of every single DID, not only of the identifier space as whole. (BTW your "methods" argument may partially work for the "decentralized" property of DIDs, but it doesn't work for the "persistent" property.)

Self-sovereign identity != decentralized identifiers.

Who decides this? The current spec still says DIDs are a new type of identifier for verifiable, "self-sovereign" digital identity. The very innocent looking PR https://github.com/w3c-ccg/did-spec/pull/179/ is proposing to abandon this. Many people in the SSI / decentralized identity community think DIDs are for SSI. I had several conversations in the last few days and weeks about this, and people cannot believe this change is happening. And as we know from Heather's and Karn's survey, many people who are affected probably don't even know that this fundamental change is happening, and how they could contribute to the discussion.

In the long run, it is the narrative that matters. [..] If you can't define decentralize clearly enough to survive those mistakes, then it has no place in a normative section of the specification.

I admit I have no idea how to define decentralization in a normative section. But the narrative (e.g. in the Abstract) should continue to be about things like "fully under the control of the DID subject", "independent from any centralized registry", etc., and we shouldn't so easily sacrifice this narrative.

[peacekeeper]

@dmitrizagidulin and @awoie

Markus, I completely understand and agree with your concerns. From your previous comments, though, it sounds like you may be less opposed to this work item if we: [..]

I still don't feel good about it, but I do understand the motivation, and I recognize there's strong interest for this by people like you whose judgment I trust. So yes I think I could agree if we:

• Don't dilute the general DID narrative about decentralization, persistence, user control, independence from central registries.
• Explain that https/web/facebook DID methods are bridge technologies that don't fulfill some of the main design principles of DIDs.
• List concerns and threats in the method spec.
• Mention alternative ways of bridging technologies, e.g. discovering a DID from a domain name.

[jandrieu]

@peacekeeper SSI != decentralized identifiers because they are two different things. In fact, SSI != decentralized identity either.

SSI is the ideology that people should control their identity. Decentralized Identity is one architecture that enables a certain set of controls how others recognize, remember, and respond to specific individuals. It provides for individual driven credential creation (by providing IDs to attribute providers who bind the attribute to the ID in a verifiable way) and credential sharing (by opt-in disclosure of verifiable attributes). These are only two of the elements in a stack that also needs to cover issues of governance (terms of use, consent requests, consent receipts, etc.) as well as analytics and assurance, at a minimum.

SSI is in effect saying, "Users should have control over their identity" DI says "Here's one way to do that" So most SSI advocates are, today, saying "Users should have control over identity; give us DI" And DID Advocates say, "Let's get these standardized so we can build DI-enabling systems"

Decentralized Identifiers are just one component--a keystone component to be sure, but just one component--in an emerging stack to realize decentralized identity so that those who advocate for SSI actually have a technical option to champion.

So, yes, DIDs are for SSI. But DIDs by themselves do not make SSI real. They aren't magic fairy dust that restructures how organizations manage information about people. DIDs are just are a tool in a toolkit. The rest of the work needs not just a design and a plan, but governing policy that drives the ideological goals of SSI.

The most powerful thing about DIDs and the DI stack is that, for the first time, we actually have a tool that allows organizations to rid themselves of the burden of managing identity on behalf of their customers and employees. Now we actually have a way to rebuild the IT systems because we don't need to presume that every single corporation is going to source identity--and neither are third party service providers. Users and user's agents (human and organization) can now manage identity directly so companies like Nike and FORD, and Texaco and Ralph's can get the benefits of strong identity without having to build surveillance and ID management systems. Given the choice, the vast majority of companies and even government agencies will take it. It reduces fraud. Reduces support costs. It reduces exposure from toxic data.

So, yes, we share a common vision, but the technology only creates the options. The rest of the SSI battle will need to be won by shifting social norms to make it a baseline expectation that OF COURSE individuals control their identity. Anything else is unreasonable.

You can completely decentralize identity, even using DIDs, EVEN using DIDs with decentralized methods, without truly giving users control over their identity. Until you integrate people into the flow of power from those who issue credentials to those who demand credentials, it will remain trivial--even with DIDs and VCs, for issuers to only accept limited DID methods, for verifiers to demand credentials from white listed providers, and even for employers (or border agents) to demand the private keys of individuals. Only once you address the entire decentralized identity stack, AND succeed in the political/regulatory/social norm transformation will you actually have SSI.

What we are doing with DIDs is like the IP standard for and Identity Internet. It should be usable for ALL identity-enable transactions, it should allow higher level constructs and protocols (like VCs and Consent Receipts), and it should be completely agnostic to the sources, targets, and content of its capabilities. It's vital that IP packets route anywhere there's a valid route... on the public internet (firewalls, including the great firewall of China are designed to break that promise). In the same way, any DID method should be able to offer a root of trust to any individual. ANY DID method. Not just the ones Markus likes.

Restricting DIDs to some notion of "decentralized" is like restricting IP content to a specific type of data, or trying to optimize your network with fixed cell size and virtual connections, like Asynchronous Transfer Mode (ATM) attempted. Once you start placing restrictions on your atomic components, you aren't improving the root layer, you are limiting the applications for which the platform can be useful. Since we literally can't know what DIDs will ultimately most be used for, it serves us to be as flexible as possible and "future proof" by simplicity and extendability.

In the future, there WILL be DID methods that you like yet which don't meet whatever current notion of "decentralized" you prefer. Maybe its peer DIDs. Maybe is quantum DIDs. Maybe DNA DIDs. IMO, the right way to handle that is by letting users choose ANY root of trust. If your preferred notion of "decentralized" is in fact better, then it will prevail in the marketplace of usage. The point is to let not only YOU, Markus, experiment with novel notions of how to provide "good" DIDs to create #GoodID, but to allow ANYONE to experiment with the same. That's what open means.

I'm still open to a valid definition. But my expectation is that in defining such a thing, we would slip into feature-shedding around the preferred or required features. And as the guy who aggregated all the submitted DID Use Cases, as a co-chair of the CCG, and as a producer and facilitator of RWOT, I have seen several, mutually exclusive definitions of "decentralized" advocated and used by technologist and entrepreneurs. Finding a definition with real consensus is not a small project.

Even the language you cherry pick doesn't work for several methods I know:

like "fully under the control of the DID subject" [as determined by the Sovrin/V1 governance system] or "independent from any centralized registry" [except if it is a bilateral "peer" DID, or if it requires accessing centralized schema registries]

This is not just nit-picking or semantic anthills. These words matter. I share your political ambition for SSI. What I don't share is the presumption that enforcing an undefinable standard of "decentralization" is possible.

We do seem to agree that there isn't currently an acceptable definition. I'll also posit that if we were to come up with one, the power players that want a DID-like way to consistently look up DID Documents for either centralized or decentralized methods with simply fork the spec or just use it in a non-conformant way. In which case we lose because I guarantee they will use their market power to ensure their DIDs are whitelisted and, well, if those others don't have many users, don't bother supporting classic DIDs...

The only thing to be gained, IMO, from demanding decentralized methods are, first, a schism in the community of folks who have their own religiously held believes about what exactly that means, and second, a short ride to irrelevance as the lessons learned from DIDs and DID Documents get cherry picked by major players who WILL bring to market centralized methods.

The battle won't be won by saying "you can't use DIDs" to those whose approach isn't our favorite. The battle will be won by ensuring that every viable method has its chance to prove itself in the marketplace of adoption.

The war will be won by establishing "decentralized identifiers" as the OBVIOUS way to enable a modern identity layer online and off. Control the narrative, you control the result.

Let's not lose the war from ideological purity around preferences for defining "decentralized".

[peacekeeper]

@jandrieu I'm not saying that an identity system shouldn't be completely open to also support centralized identifiers, or really any kind of identifiers. Of course that should be possible. The technical foundation for that is the URI.

A DID is a kind of URI that is decentralized. Use them if you like decentralized identifiers, use other URIs if you don't like decentralized identifiers. Yes let's be open and let everyone innovate in the marketplace with whatever kind of identifier they want, including Decentralized Identifiers (DIDs) and others.

All I'm saying is that domain names and Facebook usernames are NOT Decentralized Identifiers (DIDs).

I understand your "it's decentralized because we have methods" argument. But you make it sound like that's the current narrative, when in fact it's a major change that you and a few others recently decided to make, while 99% of the DID/SSI community are probably unaware this is even being discussed.

Restricting DIDs to some notion of "decentralized" is like restricting IP content to a specific type of data

No, restricting DIDs to some notion of "decentralized" is like restricting IP to the "Internet".

[talltree]

I personally find this thread thrilling because it's getting right down to the raw motivations that have been driving the development of DIDs for the past three years (yes, it's been that long, almost to the day). And something in Markus' last post in particular resonated with me deeply—his point about the fundamental purpose of the DID scheme.

There are many URI schemes that give us many choices of identifiers to use on the Internet and in our digital lives. All of them are globally unique and all of them conform to a standard syntax (RFC 3986). The reasons to choose a DID should be because DIDs have certain properties that other URI schemes do not.

For the past two years in my talks about DIDs I have been listing these four properties as:

1. Persistent (like a URN).
2. Resolvable (like a URL).
3. Cryptographically-verifiable (like a hashlink).
4. Does not rely on a centralized administrative authority.

Although property #4 is the one that I don't know of any precedent for (and thus the name, Decentralized Identifier), I think it's important that it is not property #4 alone that makes a DID a DID. It's the combination of all four.

So my vote is that the Introduction section of the spec (which should to serve a role similar to—but much shorter than—section 1 of RFC 3986 https://www.ietf.org/rfc/rfc3986.txt) should clearly state that the purpose of the DID scheme is to provide identifiers having the four properties listed above.

Now, precisely because Joe is correct that we can't prevent anyone from using the DID scheme to define a DID method that does NOT have all four properties—what we could do is promote DID methods that do have those four properties.

Specifically, in addition to having an clear statement of purpose listing those four properties at the start of the spec, we could require conformant DID method specifications to include a *conformance *statement about whether the DID method does or does not provide those four properties. Yes, it would be a self-assessment—but at least it would be one that is:

1. Explicitly required to be included in a conformant DID method specification.
2. Publicly available to anyone to read/evaluate.
3. Provide the basis for an explicit rating system that we can use in the CCG DID Method Registry https://w3c-ccg.github.io/did-method-registry/ (and anyone else can use in their registry, reviews, etc.)

That rating system could be very simple: zero to four stars in half-star increments:

• One star if the DID method specification claims—and provides sufficient justification—that it provides "substantially all of the benefits of the property".
• One-half star where the DID method specification claims—and provides sufficient justification—that it provides "some but not all of the benefits of the property".

The CCG DID Method Registry maintainers would be the ones to review a new DID method specification. If they believe the self-assessment is accurate (and of course that the spec is complete), then they approve adding the PR to the registry listed by star rating category (four stars first, 3.5 second, 3 third, etc.). If they do not believe the self-assessment is accurate, they don't approve the PR until they are satisfied.

Thoughts?

On Thu, Apr 18, 2019 at 10:25 PM Markus Sabadello notifications@github.com wrote:

@jandrieu https://github.com/jandrieu I'm not saying that an identity system shouldn't be completely open to also support centralized identifiers, or really any kind of identifiers. Of course that should be possible. The technical foundation for that is the URI.

A DID is a kind of URI that is decentralized. Use them if you like decentralized identifiers, use other URIs if you don't like decentralized identifiers. Yes let's be open and let everyone innovate in the marketplace with whatever kind of identifier they want, including Decentralized Identifiers (DIDs) and others.

All I'm saying is that domain names and Facebook usernames are NOT Decentralized Identifiers (DIDs).

I understand your "it's decentralized because we have methods" argument. But you make it sound like that's the current narrative, when in fact it's a major change that you and a few others recently decided to make, while 99% of the DID/SSI community are probably unaware this is even being discussed.

Restricting DIDs to some notion of "decentralized" is like restricting IP content to a specific type of data

No, restricting DIDs to some notion of "decentralized" is like restricting IP to the "Internet".

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c-ccg/community/issues/65#issuecomment-484771412, or mute the thread https://github.com/notifications/unsubscribe-auth/AAZOITN4ZE7FS6LTG6MOIWTPRFJVBANCNFSM4HGDRG7Q .

[peacekeeper]

we could require conformant DID method specifications to include a *conformance *statement about whether the DID method does or does not provide those four properties.

Yes that's the compromise I could also live with. Let's keep the four properties you mentioned the way they are in the spec and in the proposed WG charter. @dmitrizagidulin and @awoie could go ahead and write the https/web method, but in its conformance statement it would say that it only fulfills the "resolvable" property, not the other three.

[dlongley]

@talltree,

I personally find this thread thrilling because it's getting right down to the raw motivations that have been driving the development of DIDs for the past three years (yes, it's been that long, almost to the day).

I think it's been almost five years actually (nearly to the day as well) since DIDs were coined and the effort to make them a reality started split off into its own concentrated effort. They started off as a way for people to create and control their own identifiers so they could engage in economic activity as an individual (with independent existence) on the Web. They could also make the services they wished to use to do things on the Web discoverable -- and could change these things at will without losing their identifiers, establishing persistent, verifiably user controlled, independent existence.

Some of my thoughts on the name and the meaning of "decentralized" for DIDs I put in another issue after reading a great comment from @peacekeeper:

https://github.com/w3c-ccg/did-wg-charter/issues/20#issuecomment-485137917

[nadalin]

@peacekeeper You would ACTUALLY DEFINE or provide pointer to a specification for a given method that has those properties and prove interop, otherwise those statements become non-normative

[talltree]

Dave, thanks for the correction, I'll update my references to the start of DID work to go back five years and credit the early work you and Digital Bazaar did to plow the ground.

On Sat, Apr 20, 2019 at 9:05 AM Dave Longley notifications@github.com wrote:

@talltree https://github.com/talltree,

I personally find this thread thrilling because it's getting right down to the raw motivations that have been driving the development of DIDs for the past three years (yes, it's been that long, almost to the day).

I think it's been almost five years actually (nearly to the day as well) since DIDs were coined and the effort to make them a reality started split off into its own concentrated effort. They started off as a way for people to create and control their own identifiers so they could engage in economic activity as an individual (with independent existence) on the Web. They could also make the services they wished to use to do things on the Web discoverable -- and could change these things at will without losing their identifiers, establishing persistent, verifiably user controlled, independent existence.

Some of my thoughts on the name and the meaning of "decentralized" for DIDs I put in another issue after reading a great comment from @peacekeeper https://github.com/peacekeeper:

w3c-ccg/did-wg-charter#20 (comment) https://github.com/w3c-ccg/did-wg-charter/issues/20#issuecomment-485137917

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c-ccg/community/issues/65#issuecomment-485138768, or mute the thread https://github.com/notifications/unsubscribe-auth/AAZOITPTGMG2246BANQC54LPRM5LXANCNFSM4HGDRG7Q .

[Joachim16]

@kimdhamilton (reposting this here from https://github.com/w3c-ccg/did-wg-charter/issues/16) I can see your points @kimdhamilton ... and I agree that we need to have this discussion and come to at least "consent". I just would like to point out that we probably have different mindsets around the table: Web2 and Web3. The proposal is understandable from a Web2 perspective. Web2 parties would like to enable interop between centralized systems (Web2) and decentralized systems (Web3) - or at least connect to Web3 in one way or another. What really interests me is the motivation for such proposals. As you described Kim, one argument could be that the "yes" camp believes interop will contribute to the success of DIDs, however the question to every proposal should be who would and should benefit from them. this needs to be made very transparent and then we also can come to a very constructive and proper solution... hopefully in "consent"

[Joachim16]

having read through this thread here as well now it would be really helpful to clearly outline the motivation and goals that each party wants to achieve

[rhiaro]

@dmitrizagidulin @awoie I'm happy to help with this work item (and be listed as an owner / otherwise responsible person) if you would like an extra pair of hands.

[nadalin]

I don't think that s specific "Web" method is appropriate, I would say that DID's in general need to accommodate/work with existing Web resources if the method allows that.

[hawkmauk]

I think that @jandrieu makes a good semantic case for DID Methods defining the decentralisation of identifiers and @peacekeeper proposes that the community stick with the original design goals of the SSI movement that has been driving development of privacy and putting users in complete control of their Identity.

IMO the power of the DID spec does not come in the generation of DID's and resolution of the DID Documents themselves but from the way that they are used in authentication.

With a centralised system we have a similar UX to OAuth, with tracking easy to perform on the networked locations resolving the DID Documents, however it does enable verifiable credentials that increase privacy in other areas and increase security as things like date of birth, address, health care information does not need to be stored / maintained on multiple service providers systems.

I believe that a permission less distributed system for registering DID's is the gold standard for DID's but there are still gains that can be made from other implementations. With permission less systems like BTCR, there is a cost to participate which will exclude some entities from these systems and if centralised systems can offer inclusiveness without a fee then that should be available too.

[friedger]

The proposed did method specification for the method web is incomplete. It is missing important steps for the creation: domain name registration, DNS lookup. (See PR 54). I doubt that these steps can be performed by a client in a meaningful way.

Furthermore, it violates the requirement of the DID spec:

The specific-idstring value MUST be able to be generated without the use of a centralized registry service

Finally, to clarify, "proof of control" for web DID means being able to access the hosting service that is returned by the DNS lookup for the domain name of the DID.

[friedger]

In response to my previous post, I think, I misunderstood the relation between DIDs and target system for the web/https method (see https://github.com/uport-project/specs/issues/55)

Apparently, there is only one DID in the each target system.

In the DID spec, I suggest to reserve web- or x-web- as a prefix of DID method names that belongs to the class of the DIDs with a target system described in the DID web method. (This comes with a change to the charset for method names). A https/web DID could look like did:web-w3c-ccg.github.io:1

This could solve some of the issues discussed here because the centralized DNS becomes now part of the target system. The DID spec does not specify any properties for the target system and there are already various degrees of (de-)centralization in the target system of the currently listed DID methods. The security risk of deletion of a DID through the DNS registrar or DNS lookup service translates now to shutting down the target system.

[cbruguera]

I would like to express my view on the whole "centralized" or "web" DIDs issue.

I think it's clear that the opportunity to bridge this (decentralized) identity layer with central systems (e.g. facebook, etc) could bring many advantages with regard to adoption. I also agree that from the perspective of a DID document as a data model (the way it's currently defined), decentralization could be seen as a "feature" or an "implementation detail" of its backend, no only without a clear way to enforce it, but also apparently functionally decoupled from this data model.

On the other hand, the very reason there is such thing as DIDs and a whole community working on it is decentralized identity. Regardless of how many levels we can define in the "spectrum" of this concept, I think the very minimum that makes a method decentralized is that (by default at least) identity subjects have full control of their identifiers and the information publicly associated with it.

Having said this, perhaps what we're seeing here is two different aspects of these identifiers that at some point we could think of decoupling. One is the identifier (starting with the prefix "did", which by definition indicates that the underlying method provides some level of decentralization) along with its grammar and resolution rules, and the other is the object to which this identifier is resolved according to the data model defined in the specs.

My most (personal) opinion: "centralized DIDs" is an oxymoron. It doesn't make sense, and for the sake of adoption we could be hurting any level of meaningfulness that these identifiers are expected to have.

Now, that doesn't mean that we can't bridge the two paradigms and have them interoperate through some common standard ground. However, maybe we could consider the possibility of other types of identifiers (not mandatorily decentralized) that coexist with DIDs and resolve to a same or similar data model. However, they're not DIDs. They could use a different prefix, for instance. Thus, a Relying Party resolving an identifier starting with "did:" would know what to expect. The DID name and concept wouldn't be polluted with all sorts of centralization, and identity applications could adopt this more "general" approach to identifiers that include DIDs and "non-DIDs" and still be able to utilize them in the same manner.

As for the grammatical implications of this, I leave it to discussion if the idea actually makes sense to the presently involved.

Just for the sake of "thought experiment" and example... We could consider this broader category as "Resolvable Identifiers" (a.k.a. "RIDs"), whereas a more general prefix could be prepended to the original grammar. e.g. rid:did:0x1f293b87a498734234 or rid:web:facebook.com/spam.eggs...

[peacekeeper]

@cbruguera I also arrived at the same idea as one possible solution, i.e. to decouple 1. syntax, data model, and resolution protocol from 2. the decentralization / self-sovereign ideology. As you and others have commented, the prefix "did" may then not be appropriate anymore. The problem with "rid" is that all URLs are by definition "resolvable", so "resolvable identifier" doesn't sufficiently describe what it is.

[dmitrizagidulin]

@cbruguera

I think the very minimum that makes a method decentralized is that (by default at least) identity subjects have full control of their identifiers

Now THAT definition I could get behind :) It's worth pointing out, that according to that logic, this also applies to the did:web method. If I upload a DID Document to my personal website, and use it in conjunction with a Hashlink, I have full control over the resulting DID -- nobody (not my webhost, not the CA authorities, not the internet backbone providers, etc) can alter it without my permission, without it being obvious.

The categorical argument that any sort of website === centralized is FUD, anyways. Let's get specific! Let's get into the details. I'll start: web-based identifiers are administratively centralized (if you're going to invoke ICANN), but are technologically, architecturally and politically decentralized (in many cases, MUCH more so than many of the ledger-based methods being proposed).

[talltree]

Dmitri, I'll just point out that any identifier based on a DNS name is ultimately under the control of the associated DNS registry. This is not to say anything negative at all about DNS—without it the Web as we know it today would be impossible. It is just to clarify that DNS has always been designed to provide registry services based on centralized registries under the control of a single authority. A decentralized registry is based on a decentralized network of some kind (blockchain, DLT, DHT, etc.) that is intentionally designed to use cryptography so that it is not under the control of a single authority.

On Mon, Apr 29, 2019 at 8:13 AM Dmitri Zagidulin notifications@github.com wrote:

@cbruguera https://github.com/cbruguera

I think the very minimum that makes a method decentralized is that (by default at least) identity subjects have full control of their identifiers

Now THAT definition I could get behind :) It's worth pointing out, that according to that logic, this also applies to the did:web method. If I upload a DID Document to my personal website, and use it in conjunction with a Hashlink https://tools.ietf.org/html/draft-sporny-hashlink-02, I have full control over the resulting DID -- nobody (not my webhost, not the CA authorities, not the internet backbone providers, etc) can alter it without my permission, without it being obvious.

The categorical argument that any sort of website === centralized is FUD, anyways. Let's get specific! Let's get into the details. I'll start: web-based identifiers are administratively centralized (if you're going to invoke ICANN), but are technologically and politically decentralized (in many cases, MUCH more so than many of the ledger-based methods being proposed).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c-ccg/community/issues/65#issuecomment-487620269, or mute the thread https://github.com/notifications/unsubscribe-auth/AAZOITOZ7OEP3ETGAOST2W3PS4GCPANCNFSM4HGDRG7Q .

[dmitrizagidulin]

@talltree - Sure, I'm familiar with that argument, re DNS. I'd add two things to it though:

One, what you've described is just one dimension of centralization - administrative. There are other important dimensions, though - architectural, technological, political, financial, etc. And DNS doesn't stack up too badly, on those other ones.

Two - so when we say "under the control of the associated DNS registry" -- what do we mean by control? Do we mean "the DNS registry could deny service" / turn off a particular identifier? Plausible. Yet kind of a narrow definition (because this makes pretty much any system under the "control" of any DDOS script kiddie). Or do we mean that the DNS registry can alter the contents of the DID or a DID Doc without detection? That's a much more useful definition of control, and in that case, I would say that the did:web method (when paired with Hashlinks) provides full control to the user, not the DNS registry.

[talltree]

On Mon, Apr 29, 2019 at 9:09 AM Dmitri Zagidulin notifications@github.com wrote:

@talltree https://github.com/talltree - Sure, I'm familiar with that argument, re DNS. I'd add two things to it though:

One, what you've described is just one dimension of centralization - administrative. There are other important dimensions, though - architectural, technological, political, financial, etc. And DNS doesn't stack up too badly, on those other ones.

I agree that DNS involves the cooperation of a large number of registries, each of which is centralized. So the fact that there are many of these registries around the world, and that they all compete for business, does provide some degree of decentralization.

Two - so when we say "under the control of the associated DNS registry" -- what do we mean by control? Do we mean "the DNS registry could deny service" / turn off a particular identifier? Plausible. Yet kind of a narrow definition (because this makes pretty much any system under the "control" of any DDOS script kiddie).

I do not believe that's true. The decentralized networks I am familiar with (e.g., Bitcoin, Ethereum, Sovrin, Veres One, many other blockchains and DLTs) are much harder to deny access to—that's one of the primary features of their design.

Or do we mean that the DNS registry can alter the contents of the DID or a DID Doc without detection? That's a much more useful definition of control, and in that case, I would say that the did:web method (when paired with Hashlinks) provides full control to the user, not the DNS registry.

While that is true for an existing DID URL that contains a hashlink for the associated DID document (or other content), and for which the recipient can somehow already confirm the authoritative DID document. But that doesn't address a different attack: impersonation. If a DNS registry (or any other single authority that controls a registry) can substitute the DID document(s) for a DID—which a centralized authority can do because it has complete control over the registry—then that authority can replace the public keys in the DID document and now effectively control the DID. They can now create any number of new DID-URLs with new hashlinks that are entirely under the control of the attacker and no one can tell the difference because there is no cryptographically-verifiable history of the registry.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c-ccg/community/issues/65#issuecomment-487642027, or mute the thread https://github.com/notifications/unsubscribe-auth/AAZOITLPNXDYIINPKFI5TBLPS4MTZANCNFSM4HGDRG7Q .

[dmitrizagidulin]

@talltree - I completely understand your concern, that any DID method should be able to handle the impersonation attack. Would the did:web method have your support (as a work item in this CG), if the spec addressed that threat? (Because I'm confident that it can be accounted for, via the hashlink mechanism.)

[talltree]

On Mon, Apr 29, 2019 at 10:35 AM Dmitri Zagidulin notifications@github.com wrote:

@talltree https://github.com/talltree - I completely understand your concern, that any DID method should be able to handle the impersonation attack. Would the did:web method have your support (as a work item in this CG), if the spec addressed that threat? (Because I'm confident that it can be accounted for, via the hashlink mechanism.)

If the impersonation attack could be prevented, I could be persuaded. But right now I can’t see how hashlinks, which are under the control of the identity owner, can solve the problem if the registry—which is authoritative for the DID document—is under the control of another authority. I’d rather see a proof of that general architectural approach be a work item of the CCG before any particular DID method based on that architectural approach.

—

You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/w3c-ccg/community/issues/65#issuecomment-487672938, or mute the thread https://github.com/notifications/unsubscribe-auth/AAZOITMCTO2TWNSPT5BR4VTPS4WVJANCNFSM4HGDRG7Q .

[dmitrizagidulin]

@talltree Ok, so this is encouraging. :) Some clarifying questions though:

if the registry—which is authoritative for the DID document—is under the control of another authority.

What do you mean by 'authoritative for the DID document'? If the DID I give you contains its own cryptographic proof of the contents of its DID Document, in what way is any registry authoritative of it?

[talltree]

On Mon, Apr 29, 2019 at 10:51 AM Dmitri Zagidulin notifications@github.com wrote:

@talltree https://github.com/talltree Ok, so this is encouraging. :) Some clarifying questions though:

if the registry—which is authoritative for the DID document—is under the control of another authority.

What do you mean by 'authoritative for the DID document'? If the DID I give you contains its own cryptographic proof of its content, in what way is any registry authoritative of it?

If the DID you give me contains its own cryptographic proof of its content (I assume means a hash of the DID document), then you might as well just give me the DID document, which is what the Peer DID method does. In that case, what purpose does a DNS registry provide in that scenario?

My point is that, if there is any usage or reliance on an external registry of any kind for access to or verification of the DID document, then unless the DID controller has full cryptographic control of creation of and changes to that DID document on the registry, then it is subject to an impersonation attack.

—

You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/w3c-ccg/community/issues/65#issuecomment-487678777, or mute the thread https://github.com/notifications/unsubscribe-auth/AAZOITMBW52POC2XUNV52VTPS4YS5ANCNFSM4HGDRG7Q .

[dmitrizagidulin]

then you might as well just give me the DID document

Except that the DID / hash is much smaller than the full DID document :)

which is what the Peer DID method does

Yeah! It's very similar to the Peer method, actually.

then unless the DID controller has full cryptographic control of creation of and changes to that DID document

Agreed there -- the whole point I'm trying to make is that this method allows the DID controller to have cryptographic control of the DID Doc.

[dmitrizagidulin]

what purpose does a DNS registry provide in that scenario?

Well so that's the thing.. Although all of the discussion has been focused on DNS, it's actually completely incidental to this method.

[dlongley]

I think the main take away from the above did:web discussion should be that we can develop some basic tests for determining if a particular method would meet the decentralization requirements for DIDs, where decentralization refers to the notion of cryptographically verifiable independent control over a DID (and changes to its DID Document).

In other words, each DID created according to a given DID method must be controlled by its creator/controller, rather than all DIDs within that method being solely under the control of a central authority. Impersonation should be infeasible (up to the limits of the cryptographic methods used, loss of key material, so on).

I think that should be our standard for decentralization -- and we don't have to care how its done for a given method. If it can be done, great, the method meets the decentralization requirement. I suspect that we can get buy in from the community on this and that it will let us move on from the "decentralization" debate.

[peacekeeper]

the did:web method (when paired with Hashlinks)

@dmitrizagidulin This raises an interesting question; I was envisioning that a hl matrix parameter could be included in a DID URL for integrity protection of the resource that the DID URL dereferences to. But in this case, it sounds like the hashlink would be part of the method-specific-id of the DID, rather than a matrix parameter of the DID URL. I guess both has its uses, just thinking out loud.

[dmitrizagidulin]

@dlongley

each DID created according to a given DID method must be controlled by its creator/controller ... I think that should be our standard for decentralization -- and we don't have to care how its done for a given method.

Yes! 100% this.

@peacekeeper

it sounds like the hashlink would be part of the method-specific-id of the DID, rather than a matrix parameter of the DID URL. I guess both has its uses, just thinking out loud.

Yeah, that's a tough one! I could see it both ways, as well.

[nadalin]

@dmitrizagidulin That would work, as a DID:Facebook could be created by Facebook, so that matches your criteria

[dmitrizagidulin]

@nadalin Ha :) (When it comes time to put down actual criteria, we'll be careful to make it clear that controller == individual end user.)

[nadalin]

@dmitrizagidulin This will have to be non-normative since there is no enforcement and thus can be ignored

[peacekeeper]

Would the did:web method have your support (as a work item in this CG), if the spec addressed that threat? (Because I'm confident that it can be accounted for, via the hashlink mechanism.)

I agree with @dmitrizagidulin that a DID with an embedded hash can partially protect from impersonation by the DNS/web authority. However, I believe it could NOT prevent that authority from:

1. Presenting an earlier version of a DID Document as the current one (undoing any "update" operation performed by the DID controller).
2. Presenting a deactivated DID as an active one (undoing any "deactivate" operation performed by the DID controller).
3. Making a DID unresolvable (by turning off the DNS/web service).

Because of 1. and 2., the web method would only be partially "cryptographically verifiable". Because of 3., the web method would not be "decentralized".

[vipinsun]

@jandrieu wrote:

I suggest the DID spec is inconsistent.

Yes, it says

DIDs are fully under the control of the DID subject, independent from any centralized registry, identity provider, or certificate authority

Unfortunately, it also says

In a decentralized identity system, entities (in the sense of discrete identifiable units such as—but not limited to—people and organisations) are free to use any shared root of trust.

DIDs are fully under the control of the DID subject, independent from any centralized registry, identity provider, or certificate authority In a decentralized identity system, entities (in the sense of discrete identifiable units such as—but not limited to—people and organisations) are free to use any shared root of trust.

Which I believe is at the heart of the discussion: There is no inconsistency there.
DIDs are fully under the control of the subject. DID subjects can use any shared root of trust (including what we believe to be bad ones). That people make bad choices is a fact of life-does not contradict the statement above. Any other meta-data to help the subject make an "informed choice" (as many suggest); may sway the independent subject towards the "good". Vipin

[dlongley]

@peacekeeper,

I think you and I are on the same page with respect to how we'd like to see the "decentralized" requirement be better articulated. However, instead of trying to determine (in this thread) if did:web could specifically work or not, I think we should focus on what the technical requirements for "decentralized" must be for conformance. I think we're getting close to the original intent (and something technologically enforceable) when we talk about independent, cryptographically verifiable control.

To that end, it's fine to use did:web as a sort of naive foil for helping us tease those out, but it's more important that we find a way to articulate those intuitive requirements than us assuming did:web can't possibly meet them. Perhaps that's all you're trying to do, in which case, +1. If what's going on is we're saying we must define the requirements such that did:web can't be a viable method, -1.

If we can get those intuitive requirements articulated and agreed upon, we don't have to care about any potential DID method so much -- only that those requirements are met. For all we know, the did:web method could come up with some clever means by which to meet the requirements, (e.g., maybe some kind of "heartbeat" continuous update mechanism that would allow you to know something is up-to-date by the controller within a reasonable time window).

[ChristopherA]

I’m actually favor of did:onion:* or any other “specific-purpose top level domain” that like .bit. See RFCs:

RFC 6761 Special-Use Domain Names

https://tools.ietf.org/html/rfc6761

RFC 7686 The ".onion" Special-Use Domain Name https://tools.ietf.org/html/rfc7686

Draft Special Use P2P Names: https://tools.ietf.org/id/draft-grothoff-iesg-special-use-p2p-names-01.html

— Christopher Allen

[nadalin]

@dlongley Those would all be non-normative requirements which then could be ignored, if you have a finite set of methods that are documented, this would be the only way you could achieve your goal