search

w3c-ccg / did-wg-charter

An EXPERIMENTAL charter for the W3C Decentralized Identifier Working Group
https://w3c-ccg.github.io/did-wg-charter/
Other
10 stars 4 forks source link

Decentralized Characteristics Rubric v1.0 #63

Open nadalin opened 5 years ago

nadalin commented 5 years ago

"Decentralized Characteristics Rubric v1.0 The Working Group will develop a rubric of decentralized characteristics for DID Method specifications. This rubric will provide reference points according to which a DID Method specification may self-certify, or an independent third party may evaluate, the DID Method specification's level of adherence to principles of decentralization. "

Since actual DID methods are out of scope of the charter and certification is out of scope for the W3C and this charter, this potential deliverable does not make sense. I suggest that this be removed and if this is desired that another organization create a governance and or certification methodology that implementors could adopt if they so desire.

msporny commented 5 years ago

Since actual DID methods are out of scope of the charter and certification is out of scope for the W3C and this charter, this potential deliverable does not make sense. I suggest that this be removed and if this is desired that another organization create a governance and or certification methodology that implementors could adopt if they so desire.

The Rubrics are not a DID Method, nor are they a certification method (in an official sense). They are meant to codify what the community that created DIDs, as well as the DID WG means when they say decentralized.

Note that this deliverable was added to address two things that you requested in the specification: 1) to allow centralized DID methods, and 2) to clarify what is and is not possible with a DID:

https://github.com/w3c-ccg/did-wg-charter/issues/22

This deliverable of the WG does just that and was partly a result of other issues that you raised. We also have broad buy in on this deliverable and I doubt the group will want to remove it at this point. Suggest that we keep the deliverable, as it's non-normative, and won't have the effect of establishing an official certification mechanism.

nadalin commented 5 years ago

@msporny The text says this is for DID METHOD SPECIFICATIONS, It also says for SELF-CERTIFICATION. I agree the text was added to address an issue I opened but it does not address the issue. I disagree with the resolution and the issue should not have been closed

nadalin commented 5 years ago

@msporny I don't think anyone would also understand what a rubric in this sense.

msporny commented 5 years ago

@nadalin wrote:

The text says this is for DID METHOD SPECIFICATIONS

Yes, and since the group is working on the following as in scope, it is perfectly reasonable to talk about expectations related to DID Methods. Note that this has nothing to do with actually defining a DID Method (which would require the specification of protocol, which is out of scope):

Recommend a set of requirements for DID Method specifications that are conformant with the data model and syntax(es). The DID Method specification authoring requirements will recommend a list of mandatory and optional operations, with associated descriptions, which are expected to be defined in DID method specifications.

@nadalin wrote:

It also says for SELF-CERTIFICATION.

It says the following:

This rubric will provide reference points according to which a DID Method specification may self-certify, or an independent third party may evaluate, the DID Method specification's level of adherence to principles of decentralization.

The document is non-normative. It states that DID Method specifications may self-certify, again, through no action of the WG. It also mentions that an independent third party may evaluate the rubrics against a particular implementation (again, the WG will not be certifying).

I agree the text was added to address an issue I opened but it does not address the issue. I disagree with the resolution and the issue should not have been closed

We'll put it to the group for discussion.

nadalin commented 5 years ago

@msporny I don't agree that this would be in scope as written since there are no DID method defined in this proposed WG, it should not talk about self-certification since there is no certification in this proposed WG, so why bring in things into charter that are out of scope, this adds no clarity to charter it just confuses things.

msporny commented 5 years ago

@nadalin wrote:

I don't agree that this would be in scope as written since there are no DID method defined in this proposed WG, it should not talk about self-certification since there is no certification in this proposed WG, so why bring in things into charter that are out of scope, this adds no clarity to charter it just confuses things.

As I mentioned above, we'll put this to the group and see what they say.

nadalin commented 5 years ago

@msporny This also applies to item 4 of the Scope

jandrieu commented 5 years ago

I'd agree with removing the language about self-certifying, but the rest is a requirement of the work. There is too much confusion around what "decentralized" might mean and passionate voices from multiple sides of the debate have a agreed that codifying what "decentralized" means for people in this community is vital to shape the work ahead.

However, I expect many of the rubrics will be too subjective to be used for "certification", self- or otherwise. Instead, they can be evaluated by those considering various DID methods (or those building DID methods) in context of their own requirements.

To wit: "prove control" will always have limits on the applicability of the proof. So, depending on the risk involved in accepting that proof, a relying party can judge a particular method on its merits, e.g., is mathematical proof of access to a private key sufficient to prove that a particular an update to a DID document is legitimate? In most cases, yes. But in some cases, a second factor might be appropriate. Such complexities become even more subtle when looking at potential attack vectors of different recovery mechanisms.

We chose rubrics precisely because it can accomodate this sort of subjective evaluation.

nadalin commented 5 years ago

@jandrieu Since this is a data model specification and no protocols or mechanisms specified the usage is up to the implementor/deployer and anyone should be able to use this data model as they see fit since the design is based upon the URI specification.

jandrieu commented 5 years ago

@nadalin Think of the rubrics like use cases. They are both non-normative documents that capture the purpose of the community developing the spec. The role of both is to illustrate the thinking behind the normative work. Just like use cases, rubrics help flesh out the point of the work so those working on the details in the specification have a common language and set of expectations about the goals and situations that affect technical choices. And just like use cases, they will bring in ideas and commentary that are non-normative. That's why they are, in fact, non-normative.

csuwildcat commented 5 years ago

Can we strike a compromise where we all agree to include in the spec's non-normative Introduction section the purpose of Decentralized Identifiers (things like self-owned/controlled IDs that are not severable by third parties), and point to 'more information' that links to a set of rubrics an org like DIF could define (and I'd argue is a prime place to do so). I am prepared to argue that I am a radically pro-decentralization person, probably more so than even folks on this thread, but I have to admit that adding some non-normative set of rubrics will probably just make life harder for us in getting this thing done. What does this do for us that cannot be done having either DIF or the CCG create the rubric?