Decentralized Identifier: "Decentralized" in working group name

[nadalin]

So I'm going to question the name of this WG as I don't think that this identifier mandates "decentralization", that seems mandate the usage, the usage should be up to the deployment

[brentzundel]

At this point I'd say the DID is called a decentralized identifier because that's what it's been called for years, and because the system in which it was considered valid at the time was conceived was a decentralized one.

I would love to consider the ways it may still be considered decentralized to see if there is a legitimate reason for keeping the name, otherwise it may make more sense to call it a User Controlled Identifier (UCID?) or something like that.

Does the fact that anyone may establish a method specification for the identifier make it decentralized? Can it be argued that the guarantees needed for trusting the DID Document can only come from a decentralized system? Does the DID's lack of required reliance on a centralized authority make it decentralized?

[nadalin]

@brentzundel It does not have to be user controlled or decentralized you are forcing a implementation detail upon a name

[brentzundel]

@nadalin, I am not forcing anything. (Please do not assuming we are disagreeing just because we have elsewhere :)

I am trying to explore the meaning of the word decentralized and posing questions to see if there are legitimate reasons to keep it. I should have been more clear that the questions I posed were not for you, they are for the community. If legitimate reasons cannot be supplied, I agree that decentralized should be dropped from the name of the WG.

Your assertions that the identifier doesn't have to be user-controlled nor decentralized are intriguing. It makes me wonder what remaining qualities a DID might posses that would make them desirable. In my view a DID has the following positive attributes:

1. A user may prove control of a DID based on the contents of the DID document. (As you point out, this may not be a requirement, but it is still a valuable capability).
2. There is a means of resolving a DID to obtain a DID document. (Whether a user can trust that the DID Document supplied is actually the correct one depends on the trust the issuer has in the method)
3. The DID controller controls the contents of the DID document. This allows the DID holder to specify contact endpoints and public keys (according to the method spec).

I'm curious, what positive attributes do you feel a DID possesses?

[peacekeeper]

There are discussions here and here and here and here on what "decentralized" means and whether that property of DIDs should be sacrificed.

Personally, I find it unbelievable that this discussion is even taking place. In a time of surveillance capitalism, digital slavery, and massive state-sponsored surveillance, after years of work on DPKI, RWoT, and the global SSI movement, decentralization and user control are now "implementation details"?

[jandrieu]

DIDs are decentralized quite simply because the DID method allows you do specify the root of trust.

http URIs are centralized because you either provide an IANA-issued IP address or a DNS host name based on specific root authorities.

Decentralized doesn't mean decentralized all the way down--that would be distributed. That's not what we are doing here.

What we are doing is allowing any valid root authority to offer a method for discovering the cryptographic material and the service endpoints for trusted interactions with the DID subject.

The majority of the methods under development are, in fact, implementing on top of distributed systems so their particular method is even further decentralized, but at the core, decentralized identifiers are independent of any single operational platform authority. They are only dependent on the specification of DIDs, DID Documents, and in the future, protocol specifications for resolution, authentication, etc. There is no operational central authority for DIDs in the way there is for IANA and DNS.

That's a big deal.

[nadalin]

@jandrieu If I want to make FaceBook the root of trust I should be able to, this also does not mean that I can't have a central root of trust if I so desire

[jandrieu]

I'm not following. @nadalin I'm in favor of did:facebook and it's like. But the second half of the sentence didn't parse:"this also does not mean that I can't have a central root of trust if I so desire." What you can't do is force every DID to use a central root of trust the way http URLs do. That's the centralization we are replacing. HTTP URLs require a central trust in IANA and DNS. DIDS have no operational equivalent. Just the specifications.

[peacekeeper]

+1 to the statement "If I want to make FaceBook the root of trust I should be able to".

-1 to calling a FaceBook username a "Decentralized Identifier".

If we want to change course and now standardize a syntax and discovery format for any kind of identifier, not just decentralized, then I agree with @nadalin's original comment in this thread that the WG should have a different name, and the scheme should not be "did", but rather maybe id:facebook:markus.sabadello, id:sov:WRfXPg8dantKVubE3HX8pw, etc.

[nadalin]

@jandrieu I agree you can't force but the identifier should allow if that is an implementation I choose, how I implement the did:facebook is nothing the specification should deal with since it's only a data model/schema.

[jandrieu]

Again, I'm not sure why it seems you think you're disagreeing with me. We both seem to disagree with Markus... I'm saying DIDs allow any root of trust and that is what decentralized identifiers do.

To require that all DIDs are based on specific technologies, like DLTs, has never been part of the consensus. However, all of the DID methods that have consensus support are, in fact, based on distributed technologies.

[nadalin]

@jandrieu OK, I was misreading your reply, that is my understanding also, so yes we both disagree with Markus.

[jcnelson]

I am 100% with @peacekeeper on this.

DIDs do NOT have a root of trust. You will notice no DID methods specify an administrative domain to process DID resolution. THIS IS BY DESIGN.

If you want your identity resolution protocol to specify a root of trust, use an OpenID URL. DIDs do not, and will never identify an administrative domain for resolution.

[OR13]

To me the most important part of the word "decentralization" regarding the spec, is the idea that a user might control some or all keys in a document. There could be a never ending debate regarding how decentralized any network technology is, even public crypto economic incentivized blockchains like bitcoin and ethereum have geographic centralization, any technology that relies on DNS, IANA, BGP, etc... I think its dangerous to view "decentralization" as a fundamental requirement for method implementation, because we are unlikely to be able to agree what it actually means. However, I do think its totally fair to argue that one DID method is more decentralized than another, based on how many networked systems the user must trust, who operates them, and where are they located.

Users should be able to add keys which only they control, and revoke keys which may have been added by a centralized authority or device when the identity was first created.

If a user wants to add a recovery key that is managed by a trusted central authority, that should be ok. However, It clearly means that the user is trusting a central authority.

This is different than trusting a central authority to manage DID resolution. Here is an example which we built and are moving to the DIF, that will probably be triggering for some, but I think it highlights some of the issues we're discussing:

https://github.com/transmute-industries/github-did

(link may change when it moves to the DIF)

High level, it uses github to store DID documents, and relies on github for resolution.

did:ghdid:${user}~${repo}~${kid}

Here a github user controls their github account, repos, and has the ability to add JSON-LD documents identified by KID.

A github user can alter the repo write permissions, and suddenly anyone with access can update these did documents.

Github could go down, and nobody would be able to resolve a DID unless they had cloned the repo.

Github and the user / organization must both be trusted to use this setup, but its free, and easy to see how it works, and we use it for testing signatures suites, json libraries and DID integrations without needing to run a ledger, IPFS, or other complicated technologies.

You could build a similar system on top of pretty much any version control or software package system.

As @jcnelson pointed on here, and elsewhere: https://github.com/w3c-ccg/did-wg-charter/issues/16

We might might want to say that any method that relies on a particular administrative domain for handling resolution, cannot be considered a did.

But certainly there will be other examples created like the one we use for testing above. I'm happy to change the name of github-did to not include the word did or call it pseudo-did, weak-did or centralized-did, and just to be clear, its a test method, and we have not even bothered attempting to register it because we're still experimenting with it.

[nadalin]

@jcnelson " DIDs do not, and will never identify an administrative domain for resolution." Since this is just a data model you can't enforce your opinion

[rhiaro]

I think its dangerous to view "decentralization" as a fundamental requirement for method implementation, because we are unlikely to be able to agree what it actually means. However, I do think its totally fair to argue that one DID method is more decentralized than another

+1, I think this is at the heart of the issue. Certainly seems from all the discussion over the past weeks that different people have different ideas about what is "decentralized", or decentralized enough.

[nadalin]

So I will go back to the main question, if you can't agree on "decentralized" then why is this a "decentralized" identifier, this is just a identifier as there are no specific methods specified and I can make my method do anything it wants, DID:Facebook

[ChristopherA]

Decentralized is a continuum, not a binary “is” or “is not”. Even what I believe to be the most decentralized method, BRCR based on Bitcoin, would not qualify as being as fully decentralized as even Bitcoin is, and Bitcoin itself is not completely decentralized either.

But I do believe can define a rubric where methods can be compared side-by-side to the level of decentralization they offer.

[nadalin]

Interesting spin

[peacekeeper]

One obvious rubric could be: Has the technical infrastructure been designed to distribute consensus of the state of the identifier across multiple independent entities? (Or similar wording)

did:web and did:facebook would say "false", whereas did:btcr, did:uport, did:v1, did:sov would say "true"

[kimdhamilton]

see #16

[msporny]

The group discussed this on the 2019-06-27 call and agreed that "Decentralized" was the right word to use for the WG and also agreed to define what the word "Decentralized" means through a rubrics deliverable that the WG will produce. This change was made in PR #28. Closing.