[wg/did] change suggestion by @jyasskin

[pchampin]

This PR reflects a change originally proposed by @jyasskin at #448 (comment) .

This should set a more specific bar than just "open specification". @cwilso and I suggested over email that it be something like

@jandrieu responded:

We would oppose this.

None of the DID methods are at that level of maturity.

However, I agree that some further definition of "open" might be useful.

[pchampin]

@jandrieu no DID method is at that level of maturity yet, but we have until DID Resolution needs to exit CR to reach that point. Is it so unrealistic in your opinion?

[jyasskin]

@cwilso FYI. @hober @tantek, this is my attempt to keep the charter pointing toward interoperability even without the WG directly pursuing Methods. I'm trying to say that some group has to get some Methods to at least the Living Standard level before this WG can do more than maintain their existing publications. Is this enough to keep y'all at 'abstain' or better?

[rxgrant]

attempt to keep the charter pointing toward interoperability

@jyasskin

These words imply that DID Resolution is not a path to showing interoperability. Think about how that sounds to everyone else. Have you found any words to convince people of that without trying to slide it in as an implication? If not, why not?

This only adds risk that the WG cannot control, because there is no appropriate pressure for the WG to pick winning and losing DID Methods.

DCD strongly objects to this change.

[jyasskin]

@rxgrant, I have no hope of convincing you, but I'm not just implying that DID Resolution isn't a promising path to showing interoperability. I've said it directly, for example in https://lists.w3.org/Archives/Public/public-did-wg/2023Nov/0004.html.

[rxgrant]

@jyasskin

If you have a good argument, then it is best to maintain good faith and present it concisely, rather than blame individuals. Markus Sabadello, Daniel Hardman, and Christopher Allen all had insightful replies the last time you presented your worries about DID Resolution. Can you summarize your points in this public forum?

[rxgrant]

edit to the above: ...summarize your points against their replies in this public forum?

[hober]

@cwilso FYI. @hober @tantek, this is my attempt to keep the charter pointing toward interoperability even without the WG directly pursuing Methods. I'm trying to say that some group has to get some Methods to at least the Living Standard level before this WG can do more than maintain their existing publications. Is this enough to keep y'all at 'abstain' or better?

It's certainly better than what's currently there. I'd still prefer they do what Ralph asked them to do in the first place, though.

[cwilso]

I think that @jyasskin summarized our position quite well in https://lists.w3.org/Archives/Public/public-did-wg/2023Nov/0009.html: "[We] worry that partial standardization is the easiest way to this sort of centralization: one could sell to organizations saying "look, DID (core) is standardized", but part of the critical path is something only the seller
controls."

The point of having a web standard is to enable interoperability. If you think DID Resolution is a path to enabling system interoperability based on just the DID standard, then please, help us understand how that's so, and ensure that such will be a requirement for DID Recommendations. If it's NOT so - if it is true that part of the critical path can be someone only one seller, or a select set of sellers, controls, then I'm not convinced you're really building an open web standard.

Indeed, there have insightful responses - for example, Markus' post in https://lists.w3.org/Archives/Public/public-did-wg/2023Nov/0010.html. I'm not entirely certain that the list of things he said the DID community can offer is sufficient to demostrate practical interoperability; however, I don't think each and every one of those is currently a commitment from the DID community (particularly the last three).

Christopher Allen's response in https://lists.w3.org/Archives/Public/public-did-wg/2023Nov/0011.html isn't so much insightful as highlighting the problem. Yes, we should accept sometimes the answer is "untrusted" [or "unknown"] - but, much like URI schemes, we still need a defined core of interop.

As for Daniel's response (), I wanted to quote a section:

Giving an arbitrary DID to an arbitrary, unknown party that's also using DIDs, with an expectation that no interoperability impedance might arise, feels unrealistic and even undesirable to me.

I think this is where we differ. Yes, I agree, it's unrealistic. I'm not so certain about undesirable.

Differences between DID methods often reflect important ideological or market realities. ... Should interoperability
initiatives hide such considerations from users -- or let them wrestle the messy reality? My guess is that the optimal answer is somewhere in the middle.

There. at least, I think we agree; there will be different approaches in market realities. But I still feel there should be an overwhelming consideration of actually having an interoperable standard.

[iherman]

(I was not part of the earlier discussions, my goal is to help to find some middle ground...)

@cwilso @jyasskin, my feeling is that the problem seen by @rxgrant or @jandrieu is the requirement on the methods in question to be vetted by some formal standardization body (W3C or others). That is, at least, the only difference I see between the original text and the one proposed by this PR.

I was wondering about the following text instead (obviously, this would require some editorial work):

…methods with an open specification (i.e., accessible to all for implementaton and deployment) that is either at a CR snapshot level at the W3C (or a level with equivalent vetting and patent grants at another standard body) or has a large user community actively relying on that particular method.

I realize that "large user community..." is a bit vague, and we may have to find a more specific formulation, but the intention is that significant communities out there may agree upon a DID method without going through the administrative requirements of a formal organization. In other words, it would allow for grassroot communities to create DID methods bottom-up, that could come to the fore and would be significant enough to provide a proof for interoperability.

Would that be a route towards an acceptable consensus?

cc @pchampin @peacekeeper

[pchampin]

We already have two objections (from @jandrieu and @rxgrant) on the original PR. I'm including @iherman's change above in the hope of finding a consensus.

STRAWPOLL : please react to this post ("this PR" refers to changes up to 0a54c2b)
(superceded by #466 (comment))

• 👍 I support this PR
• 👀 I can live with this PR
• 👎 I object to this PR

[cwilso]

From a brief discussion - "has a large community" really doesn't define interoperability by itself. I think perhaps the wording here is just unclear, and I'm conservative; the requirement should be that the methods have open specifications (freely available specification, freely implementable), implemented by more than one implementation interoperably. I'm uncomfortable with saying "large community", because that still seems to leave open the possibility of a single implementer (with a large user community).

[jandrieu]

@pchampin wrote

@jandrieu no DID method is at that level of maturity yet, but we have until DID Resolution needs to exit CR to reach that point. Is it so unrealistic in your opinion?

Yes. One should expect that the chartering and lifetime of a DID Method working group should take at least as long as the DID WG. Call that 1-2 years to charter, 2-3 years in working group, at least 3-5 years. Meanwhile, the DID WG has a lifetime of only 24 months. It doesn't make any sense to imagine that an unformed WG would somehow be able to finish its work ahead of this one that we are chartering right now.

I think this language from @cwilso sets a good metric

The requirement should be that the methods have open specifications (freely available specification, freely implementable), implemented by more than one implementation interoperably.

That I agree with. In fact, I'd suggest using that language directly.

[pchampin]

the requirement should be that the methods have open specifications (freely available specification, freely implementable), implemented by more than one implementation interoperably.

@cwilson, @jandrieu
I rephrased it slightly to align with the rest of the paragraph.

STRAWPOLL : please react to this post ("this PR" refers to changes up to fa968f7)

• 👍 I support this PR
• 👀 I can live with this PR
• 👎 I object to this PR

[iherman]

The latest statement, i.e.,

   <p>In order for <a href="#deliverable-did-resolution">DID Resolution</a> to advance 
   to <a href="https://www.w3.org/Consortium/Process/#RecsPR" 
   title="Proposed Recommendation">Proposed Recommendation</a>, 
   it is expected that each of the independent implementations 
    mentioned above support at least two DID methods with 
   open specifications (freely available specification, freely implementable),
    and implemented interoperably by more than one
    of the independent implementations mentioned above.</p>

is a bit difficult to parse. I think what is defined by these criteria is that each CR implementation of Resolution must implement at least two "major" (I just added this term temporarily for this discussion) DID methods, where "major" means that they are open, and they are implemented by more than one Resolution implementations. I.e., if we have three methods (m1, m2, m3), each with open specifications, and we have, altogether, two Resolution implementations (R1 and R2), and if

• R1 implements m1 and m2
• R2 implements m1 and m3

then only m1 can be considered by "major" (because it is implemented by two resolutions), consequently the CR criteria fails.

I am actually fine with these criteria, but I am not sure we all agree this is what we all mean. And, if so, it is probably necessary to describe the criteria more explicitly to avoid discussions in the subsequent WG.

Also, again to be sure that we all have the same understanding, the original text in the original proposal included yet another, but different, criterion, namely:

It is also expected that each pair of the independant implementations mentioned above 
support at least one common DID method with an open specification.

which is not part of the current proposal.

If that rule was adopted, too, then the following setup:

• R1 implements m1 and m2
• R2 implements m1 and m3
• R3 implements m2 and m4
• R4 implements m3 and m4

would fail (because R2 and R3 have no methods in common) although it would pass without the last rule (all methods are "major").

I am neutral on also keeping the original, extra criterion, but, again, we should all have the same understandings of what we all want...

[pchampin]

@iherman you are correct. I was under the impression that the new wording implied the last sentence from the original one, but that is not the case. That being said, my preference would go with keeping it out, for the following reason :

In the current wording, the following situation would be ok:

• R1 implements m1 and m2
• R2 implements m2 and m3
• R3 implements m3 and m1
• R4 implements m4 and m1
• R5 implements m4 and m2

If we reintroduce the "each pair of implementation" criterion, it would not be ok (R2 and R4 have no method in common). However, it could be made ok by ignoring implementations R4 and R5, and reporting only R1, R2 and R3. Reporting less implementations for the sake of ticking a box sounds counter productive.

[philarcher]

I agree, there's a lot of room for interpretation here. Could an additional clarifying sentence be added thus:

This means that there will exist at least two openly-specified DID methods that are both implemented by at least two independent implementations.

[iherman]

I agree, there's a lot of room for interpretation here. Could an additional clarifying sentence be added thus:

This means that there will exist at least two openly-specified DID methods that are both implemented by at least two independent implementations.

That may probably be used as the basis of a replacement text, rather than a clarifying one, but we should also emphasize the "mutually independent" aspect of both the methods and the implementations.

But, before we go into such details, I would like to be sure that the general direction is fine with everyone (or not)...

[jandrieu]

The direction here looks promising.