More General Comments

[nadalin]

"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. 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."

These don't have to be verifiable (since there is no verification mechanism specified" and they don't have to be under control of the DID subject, also there is no mechanisms stated to show "trustable interations"

I suggest a reword to make this more general and no statements about verification or trust since these are out of scope

[jcnelson]

These don't have to be verifiable

Yes they do.

since there is no verification mechanism specified

The method field specifies the mechanism.

they don't have to be under control of the DID subject

Yes they do. Otherwise it's not self-sovereign.

there is no mechanisms stated to show "trustable interations"

That we can agree on.

Determining the trustworthiness of claims in the DID document is outside the scope of this WG. However, what is in scope for this WG is ensuring that a given DID resolves to a DID document that could only have been produced by the DID owner (in the absence of key compromises, cryptographic breakthroughs, etc. -- the usual caveats).

I suggest a reword to make this more general and no statements about verification or trust since these are out of scope

No, you are wrong.

[nadalin]

@jcnelson There is no discussion about Self-Sovereign in the proposed charter.

Without specifying and/or defining a mechanism you can't impose any requirements such as has to be under the control of the DID.

The same with ensuring that the DID resolves to a DID document that could only have been produced by the DID owner.

[jandrieu]

@jcnelson There are no claims in a DID Document and "DID owner" is no longer in use as a term to describe the entity that controls a DID. That is a DID Controller.

However, you are correct that the DID resolution process ensures that the DID Document was in fact generated and/or posted by the DID Controller. That's the point. If a method can't cryptographically verify the DID Document, that definitely is out of conformance.

See Section 10.2 https://w3c-ccg.github.io/did-spec/#binding-of-identity

@peacekeeper I suspect this is probably the right framework for evaluating whether or not a DID method is suitably decentralized--without the complexity of defining decentralized. I believe this is similar to @ChristopherA's suggestion that keys are a more testable framework for ensuring individual control.

[peacekeeper]

@jandrieu You're confusing 1. "A DID Document is cryptographically verifiable" with 2. "A DID is cryptographically verifable".

ad 1.: As the reference you mentioned explains, a DID Document that is "cryptographically verifiable" (e.g. it has a signature) does not prove that it is the correct DID Document for a given DID. I agree with you that the (only) way to get the correct DID Document for a given DID is to go through the DID Resolution process.

ad 2: This means that not only the DID Document itself, but also the fact that a DID Document is correct for a given DID must be "cryptographically verifiable". In other words, the DID Resolution process must include some cryptographic mechanisms that ensure the DID was generated/updated/deactivated by the DID Controller (e.g. not the DID Document itself, but the operations that generate/update/deactivate the DID Document for a given DID could be signed).

In a web- or Facebook-based "DID", the web host provider or platform operator could simply replace the keys in a DID Document and add a new signature that looks valid, and nobody would know. Therefore such DID methods not only fail to achieve the "decentralized" and "persistent" properties of DID, they also fail on the "cryptographically verifiable" property.

[dlongley]

Thumbs up to what @peacekeeper said. DIDs are decentralized because there is "no single identifier creator or owner for all DIDs". This was the intention from 5 years ago when the term was coined and the idea was that there would be a single WebDHT for all DIDs (no DID methods). We've since added DID "methods" and changed "owner" to "controller", so this notion still applies but it reads more like "no single identifier creator or controller for all DIDs in a given method".

Decentralized identifiers have some kind of cryptographic mechanism that establishes control by the creator of the DID. There is also some method-specific verification mechanism that can carry any changes to the DID document (e.g., via some series of verifiable patch operations) forward to its present state in a way that demonstrates that the DID controller maintained control (modulo stolen keys and that sort of thing).

I think that if a "Web" or "Facebook" based "DID" can demonstrate that they are just holding onto some kind of chain of user controlled changes to a DID Document in this way, then they can be fully conformant, even if the primary way you find these chains is via a page on the Web (on Facebook or wherever). Such an identifier could continue to persist even if that website went away -- there would need to be an update to the resolvers to call out to a new website where they could be found instead.

[mrinalwadhwa]

A chain of signed updates (while significantly better than not having a chain) still leaves the possibility of presenting a stale chain leaving out recent updates ... for instance to make a revoked key / service endpoint appear valid.

I think that if a "Web" or "Facebook" based "DID" can demonstrate that they are just holding onto some kind of chain of user controlled changes to a DID Document in this way, then they can be fully conformant

A sufficiently decentralized store of DID documents mitigates against that possibility.

[dlongley]

@mrinalwadhwa,

+1 -- I wasn't trying to design a foolproof DID method via my comment, I was only trying to offer what I believe to be an important distinction wrt decentralization.

[nadalin]

@dlongley Why are you saying that this must be a chain? Nothing in the charter says anything about a chain.

[dlongley]

@nadalin,

Why are you saying that this must be a chain? Nothing in the charter says anything about a chain.

I'm not saying that; apologies if that was unclear.

It's up to the authors of any particular DID method to ensure that each DID (under that method) is independently controlled by its designated creator/controller. This is one way that DIDs are decentralized vs. other identifiers where the entire namespace and related resources are exclusively controlled by a central authority. This is related to the first point in the charter:

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

So, I was speculating about a partial solution that some potential domain-based DID method might consider. My point was that we shouldn't rule out such a method meeting user expectations, it just needs to do things like demonstrate that the identifier and changes to its related DID Document are made under the control of its creator and that it can survive things like a change or loss of domain (i.e. DIDs are not "leased"), provided that resolvers are updated.

These requirements, though, aren't part of the Data Model and Syntax specs. I don't see how they could be as it's just a data model. But, like many other successful designs, we're taking a layered and iterative approach here. So they would instead would fall under a higher layer, perhaps in the DID resolution space as @peacekeeper mentioned.

Right now, we're just starting out with the Data Model and Syntax specs to establish the first layer for interop. We're setting expectations that resolving a DID (through some mechanism defined in a "DID method spec") will result in a DID Document, as defined in the Data Model and Syntax specs. We need these specs as a basis for the other work.

So, we do expect that people will use the Data Model for DIDs because that's what it's designed for, though I do concede that someone on the Internet may try and use it for something else. I'm sure, with sufficient effort, someone can shoehorn cat pictures into it and still be compliant at the Data Model layer.

If people want to create something more useful, later specs will reference the Data Model and Syntax specs and add additional requirements for interop. So it's important for readers to understand where these specs fit into that vision and to set expectations. Even if we can't get agreement on producing additional specs in the future (though I believe we will), there are already various DID methods, implementations, and tools being written against the promise of this first layer.

[nadalin]

This specification needs to be able to work with existing Web Resources

[talltree]

If existing Web Resources (and existing URIs) did everything we have designed DIDs to do, then we wouldn't need DIDs. So while it's not a bad thing that the DID spec could be used with existing Web Resources, it's actually dangerous if an implementation uses it existing Web Resources in a way that makes it look like they are achieving the goals of the spec without actually doing so.

[nadalin]

@talltree How is it dangerous if that is what the user wants?

[kimdhamilton]

See #16

[msporny]

PR #50 is designed to address this issue. The "verification" and "trustable interactions" language should stay because:

• A DID Document contains verification methods (such as public keys) for verifying exchanges of digital information.
• A verification of a digital signature is a "trustable interaction".

Thus, it is true that DIDs provide both things.

[msporny]

We discussed this issue on the 2019-07-02 call and the group agreed to pull in PR #50 after changes suggested by the group have been made and close this issue after the PR is merged.