Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

General: current language precludes DIDs/methods leased from an authority #16

Closed
nadalin opened this issue Apr 9, 2019 · 15 comments

Comments

@nadalin
Copy link

commented Apr 9, 2019

"DIDs are controlled by individuals, organizations, and machines, not leased from an authority (e.g. DNS Registrars). "

You can't preclude that I don't want to have a DID controlled only by a individual, so

"DIDs maybe controlled by individuals, organizations, and machines"

@kimdhamilton

This comment has been minimized.

Copy link
Contributor

commented Apr 17, 2019

I agree to the "are controlled by" -> "may be controlled by" change.

We may have to soften the latter part of the sentence too, e.g. "not necessarily leased from an authority". (But there's probably a better way to express that...)

@nadalin

This comment has been minimized.

Copy link
Author

commented Apr 17, 2019

@kimdhamilton My point is that someone may want a DID from a central authority, this specification should not exclude that

@jandrieu

This comment has been minimized.

Copy link
Contributor

commented Apr 19, 2019

FWIW, there's significant opposition to this from the spec editors. I don't happen to agree, but we should bubble up the debate to see if we can get consensus. w3c-ccg/community#65

@peacekeeper

This comment has been minimized.

Copy link
Member

commented Apr 19, 2019

@kimdhamilton My point is that someone may want a DID from a central authority, this specification should not exclude that

If people want identifiers from a central authority, no problem. Verifiable credentials, agents, data stores, etc. should be open to work with any kind of identifier people want to use. But it's not a "Decentralized Identifier" (DID) if it's from a central authority.

@mitfik

This comment has been minimized.

Copy link

commented Apr 19, 2019

@kimdhamilton My point is that someone may want a DID from a central authority, this specification should not exclude that

If people want identifiers from a central authority, no problem. Verifiable credentials, agents, data stores, etc. should be open to work with any kind of identifier people want to use. But it's not a "Decentralized Identifier" (DID) if it's from a central authority.

Agree with @peacekeeper you can easily connect your DID to existing centralize identity through Verifiable credentials by asking for centralize authority to verify that you are in control of that DID. This way you can easily achieve kind of bridge between centralize and decentralize identity. For example we are planning to do that with certificates issued by government to create verifiable credential for newly created DID with platforms compatible wiht eIDas. Many countries especial in Europe already have similar systems in place.

Allowing centralize entity to generate DID for their customers/employees/citizens miss the point of DID effort. If you want to do that you can easily relay on existing systems like CA. If the Identifier is in control of someone else than the entity which is using it there is no point of using DID for that at all in my opinion.

@jcnelson

This comment has been minimized.

Copy link

commented Apr 19, 2019

@nadalin Did you create an account just to troll this working group?

@jcnelson

This comment has been minimized.

Copy link

commented Apr 19, 2019

@mitfik It's not a DID if it mandates a particular administrative domain for handling resolution.

@nadalin

This comment has been minimized.

Copy link
Author

commented Apr 19, 2019

@jcnelson This is not a WG, please review what is a WG and what is not https://www.w3.org/Consortium/activities

@jcnelson

This comment has been minimized.

Copy link

commented Apr 19, 2019

I'll take that as a "yes."

@kimdhamilton

This comment has been minimized.

Copy link
Contributor

commented Apr 20, 2019

I think we are all speaking past each other.

There's the question of whether the Decentralized Identifier specification should enable interop with centralized systems. In my understanding, the "yes" camp believes interop will contribute to the success of Decentralized Identifiers, but this comes with an associated risk of being dominated by centralized approaches.

There is healthy debate happening on this in the context of proposed method specs like did:https and did:facebook, as Joe mentions above. These are more extreme examples, and there's a slightly more nuanced discussion forming in #20.

My claims:

  • There's no consensus on what constitutes "decentralized" vs "centralized" (not a binary value)
  • There's no consensus on how to measure it (not even a scalar value)
  • The latest comments in issue #20 are a good start at articulating precise risks introduced by certain DID methods (e.g. lack of cryptographic verifiability, censorship), but these mostly chip away at the more extreme examples
  • We are still exploring the relevant components of decentralization, and we need a more nuanced approach. E.g. some may think permissioned ledgers are inherently not "decentralized", yet valuable for certain use cases.

I personally think these are difficult questions for the DID working group to tackle, and that's it's premature to rule out the option of bridging with "centralized" systems.

However, if the ongoing debate has progressed to a concrete proposal, it should be presented for consideration.

Update: I see a better discussion happening in w3c-ccg/community#65

Let's move that specific debate there. This thread has turned into a dumpster fire because it lacks context

@nadalin

This comment has been minimized.

Copy link
Author

commented Apr 22, 2019

@kimdhamilton Would be better for discussion to continue here as there are folks that are not part of CCG

@jandrieu

This comment has been minimized.

Copy link
Contributor

commented Apr 22, 2019

Good point, Tony.

This charter is developed under the CCG IPR. You really should join if you would like to make substantive contributions.

@Joachim16

This comment has been minimized.

Copy link

commented Apr 24, 2019

@kimdhamilton I can see your points... 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 that 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"

@kimdhamilton kimdhamilton changed the title General General: current language precludes DID/methods leased from an authority Apr 29, 2019

@kimdhamilton kimdhamilton changed the title General: current language precludes DID/methods leased from an authority General: current language precludes DIDs/methods leased from an authority Apr 29, 2019

@kimdhamilton

This comment has been minimized.

Copy link
Contributor

commented May 16, 2019

clearly define the ideal, point to rubrics as reference for analyzing (these are input that will be refined during WG). Use this to describe how we may need to vary for bridging to existing methods

@msporny

This comment has been minimized.

Copy link
Contributor

commented Jun 27, 2019

The group discussed this on the 2019-06-27 call and agreed with the change. The group merged #27 to effect the change. Closing.

@msporny msporny closed this Jun 27, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.