Remove mention of DID Methods from the charter

[brentzundel]

Remove mention of DID Method specification text from the charter and add deliverables for DID Resolution and DID Dereferencing.

---

Preview | Diff

[rxgrant]

@TallTed do you have a technical reason to file a FO if stuck working on DID Resolution instead of DID Methods?

[TallTed]

@rxgrant — I think that by putting all possibility of DID method development out of scope, we may be (1) setting ourselves up for a repeat of the FOs on and associated delays of TR status for Decentralized Identifiers (DIDs) v1.0 (which FOs may not this time be overridden by the Director or his successors) and (2) making it more difficult to successfully specify DID resolution, as well as (3) making it more difficult to develop a proper DID test suite, which in turn makes interop and the like more difficult to ensure.

(Note that FOs, which I have not said I would be lodging in any case, need not have a technical basis. Also note that the Director and successors are to "resolve issues [including FOs] in a way that is in the best interests of the Web" which may not always be in the technically "best" way, which itself is often difficult if not impossible to measure.)

[rxgrant]

@TallTed

which FOs may not this time be overridden by the Director or his successors

Can you help me find a citation for this?

edit: One way to read the above claim is that the FO might or might not be overridden by the Director. When I read it that way then I don't think a citation is needed. I do have one to offer, however, with some emphasis added:

https://www.w3.org/2021/Process-20211102/#WGArchiveMinorityViews [...] An individual who registers a Formal Objection should cite technical arguments and propose changes that would remove the Formal Objection; these proposals may be vague or incomplete. Formal Objections that do not provide substantive arguments or rationale are unlikely to receive serious consideration.

[TallTed]

By may not this time be overridden, I meant that there was a risk that they might not be overridden, though of course, that only being a risk, they also might be overridden again. It's a gamble of sorts.

It may also be helpful to read the Formal Objections section of the current draft of the ever-evolving Process, as this section is substantially clarified (and minimally changed) by the current draft. If you consider anything in this draft problematic, you're welcome (and encouraged!) to participate in its evolution via the W3C Process Community Group (which anyone can join).

[jandrieu]

(Note that FOs, which I have not said I would be lodging in any case, need not have a technical basis.

That's correct. FOs can be completely political and have no meritorious basis in fact, as was true for FOs against the DID Core specification itself.

However, consensus of working group decisions is to be determined through technical discussion:

A group should only conduct a vote to resolve a substantive issue after the Chair has determined that all available means of reaching consensus through technical discussion and compromise have failed.

And,

Groups should favor proposals that create the weakest objections. This is preferred over proposals that are supported by a large majority but that cause strong objections from a few people.

If you have such a technical reason to object, we would love to hear it. Because perhaps we can address your concerns. So far, I have only seen political objections, which do not have a place in reaching consensus.

If you object to this PR strongly enough to commit to a Formal Objection should it prevail, it would be useful if you can state that for the record. At the moment, we must interpret your informal objection as your clearly stated position, but one which is not as strongly held as would justify a Formal Objection.

[jandrieu]

@rxgrant — I think that by putting all possibility of DID method development out of scope, we may be (1) setting ourselves up for a repeat of the FOs on and associated delays of TR status for Decentralized Identifiers (DIDs) v1.0 (which FOs may not this time be overridden by the Director or his successors) and (2) making it more difficult to successfully specify DID resolution, as well as (3) making it more difficult to develop a proper DID test suite, which in turn makes interop and the like more difficult to ensure.

(Note that FOs, which I have not said I would be lodging in any case, need not have a technical basis. Also note that the Director and successors are to "resolve issues [including FOs] in a way that is in the best interests of the Web" which may not always be in the technically "best" way, which itself is often difficult if not impossible to measure.)

Ah... I did not see these arguments before my previous comment. Allow me to respond.

(1) setting ourselves up for a repeat of the FOs on and associated delays of TR status for [Decentralized Identifiers (DIDs) v1.0

This is a political argument and not suitable for this discussion.

(2) making it more difficult to successfully specify DID resolution,

If you mean that it would be easier to impose the resolution mechanisms of one method on all DID methods if we focus on just a single DID method, I agree with you. But that would be a failure of our decentralized goals. What is more important is to successfully specify interoperable DID resolution that works across the largest number of actual DID methods. Designing Resolution based on a single method is not going to help with interoperability unless you accept the organizational violence of demanding that all DID methods do it the same way as the chosen one.

(3) making it more difficult to develop a proper DID test suite

Again, if you mean that it would be easier to develop a DID test suite if all DID methods did things the same way as the chosen DID method, I agree with you, but this is an anti-goal of this work. We already have a test suite that tests the current points of interoperability: did syntax and did documents. Since, by design, every VDR defines its own approach to CRUD operations, there will never be interoperability beyond the Resolver interface.

The test suite that matters is the Resolver (and Registrar). As long as every DID method provides a resolver that satisfies a common interface for DID method operations, we will have DID method interoperability. The way that we get a "proper DID test suite" for protocol-level interoperability is to add Resolution and Registration tests based on the proposed DID Resolution specification. THAT will allow every DID method to put forth a resolver and registrar that satisfies the interface using the syntax of DIDs and the data model of DID documents, which can participate in ecosystem-wide interoperability testing.

There is a bizarre (to me) pull to think that it is desirable for there to be just a few DID methods. This is not at all desirable. What is desirable is the ability for anyone to be able to create a DID method and for every DID-aware software to have a reasonable path to supporting that DID method.

Think about this like URLs, html, http, and back-end website functionality.

o URLs provide a standard syntax that describes where to get content from anywhere on the web, such as HTML. That's DIDs. o HTML provides a standard document model that describes how to structure any kind of content on the web, such as streaming media, social networking, or published documents. That is DID documents. o HTTP provides a standard protocol that describes how to retrieve any resource from anywhere on the web, That's DID resolution. o back-end website functionality, like node.js, CGI, perl, python, go, Cold Fusion, IIS, Apache, MongoDB, Redis, ChatGPT, and (insert your favorite back-end tool) enables anyone to use any approach they want to process incoming protocol requests (http) to return standard content (html) at specific URLs. DID methods are the back-end functionality of Decentralized Identifiers. It is vital to the architecture that methods based on bitcoin and ethereum and keri and indy and veres one can all solve their own problems in their own way.

In short, claiming that we MUST develop a formal DID method specification is like claiming that Sir Tim Berners Lee MUST have developed a formal specification for his NeXT-based server code before completing the HTML and HTTP specs. It just isn't correct.

What's important is finding the consensus commonality between real, working DID methods and the way to do that is through standardize resolution and registration, NOT through elevating any given method above all others.

[peacekeeper]

I slightly prefer #27 (see my comment https://github.com/w3c/did-wg-charter/pull/27#issuecomment-1407499611) but could also live with this here.

[OR13]

More implementation experience should be gathered before this WG is rechartered so that what is in scope or not can be decided based on concrete interoperability hurdles faced by multiple at-scale implementations.

I agree with this.

[jandrieu]

there were formal objections and comments made to DID-CORE 1.0 expressing concerns around DID methods. but those objections were overruled with a comment that those concerns will be addressed in the future work.

I read the ruling differently (as quoted by @pchampin https://github.com/w3c/did-wg-charter/pull/27#issuecomment-1387145604)

The concluding paragraph of the Director's decision start with

In its next chartered period the Working Group should address and deliver proposed standard DID method(s) and demonstrate interoperable implementations.

That is a suggestion, not a MUST.

If recharter happens now, it would be appropriate to respect the above and mention DID methods in the charter.

I can respect that your position that you would prefer to defer to your interpretation of the Director's suggestion.

However, I believe the Director's suggestion was based on a flawed understanding of how the architecture works (as were the FOs). I have never seen anything from the Director--in any context--suggesting that protocol and data model work requires a priori standardization of those applications which use those protocols and data models. It certainly wasn't true for HTML and HTTP.

What is required is multiple, interoperable implementations of the specification. I imagine that, explained in the proper light, that the Director would in fact support developing a standard protocol before focusing on standardizing any particular method. Perhaps @timbl could chime in to the conversation directly.

That said, do you have any technical objections to this PR?

However, looks like such agreement to add DID methods cannot be reached at this moment and reading the discussion, I don't believe that rechartering should happen now.

I agree with you. If a DID WG must, for political reasons, specify DID methods, we should wait to recharter. We are too early for that work. No one has every suggested that we are ready. Instead, people have argued that, for political reasons, we have to.

Not only do we not have consensus on including DID methods in the scope of a chartered WG, we ALSO do not have consensus on any particular DID method to standardize. What has been proposed is a blank check for the group to work on any method it finds appealing. IMO, this is an abuse of the chartering process. I should hope the Directory, staff, and the AC avoid this unprecedented blank-check authority to develop unspecified methods.

More implementation experience should be gathered before this WG is rechartered so that what is in scope or not can be decided based on concrete interoperability hurdles faced by multiple at-scale implementations.

If such implementation experience shows that DID WG working on DID methods does not help with interoperability, I would be ok that not being in scope. However, it has not even been a year since DID-Core was published and I don't think the industry really knows what is the best for the interoperability of DIDs just yet.

I argue that we have excellent implementation experience, with currently 164 methods listed in the DID Specifications Registry. And, as such, we have seen how DID core does and does not provided interoperability. The DID syntax has worked great and the DID document data model has also been used successfully. DID URLs still suffer from /path, ?query, and #fragment components being "DID method specific". And resolution, in general, is all over the place with different solutions defined on an as-needed basis.

In fact, what we've seen is that it is interoperability between DID methods that needs improvement, not interoperability within one or a few chosen DID methods.

Several of us believe that DID Resolution is the next proper step. At @TallTed's suggestion, @ChristopherA created an issue to advance that directly https://github.com/w3c/did-wg-charter/issues/28

I'd much rather see a DID Resolution WG chartered at this point in time than have the flawed DID WG charter as currently proposed.

[kdenhartog]

@jandrieu do you believe it's necessary to address these technical arguments around why I don't believe this is the correct path for the WG to take? https://github.com/w3c/did-wg-charter/pull/27#issuecomment-1403019706

I've seen you've engaged on the political arguments a few times, but not these technical arguments yet from @peacekeeper and myself in the other thread.

[jandrieu]

@jandrieu do you believe it's necessary to address these technical arguments around why I don't believe this is the correct path for the WG to take? #27 (comment)

Yes, please do. I took your comments at face value. You said

While I'm not actively invested in this discussion

Apparently, I mistook that to mean that you do not have technical objections to this PR. If you have technical objections, clarifying them here would be appreciated. As I re-read your note, it seemed more like an argument for standardizing resolution than anything else, with the examples from different DID methods highlighting quite clearly the need for standardizing DID resolution. Your conclusion was the opposite, but I did not follow from the one through to specific technical objections to why this PR should not advance.

Here's a note that could be construed as a technical objection, please correct me if I'm misinterpreting:

The point here is to bring out that even if did resolution and did dereferencing was perfect and simple because of the vast differences between methods you'll still end up with non-interoperable solutions unless the caller of the resolver/deferencer is doing content sniffing of the actual object returned.

This I don't understand. The caller of the resolver, the client of resolution, is always going to do "content sniffing" of the actual object returned. That's how the web works. Use a URL to dereference a resource, you get a representation of that resource, which you then "sniff" to understand if its a 404 not found, a image/jpeg, or text/html. Sometimes you can get the details from the media-type header, other times you have to parse the resource before knowing.

If we define resolution and dereferencing with a standard interface, then all of the apparent confusion you reference in your list of divergent methods literally goes away.

You also said:

I find it hard to believe that you'll be able to constrain this enough if you only define resolution and dereferencing and believe you'll be required to shrink the "big tent" in order to make this actually work interoperably.

Do you also find it hard to believe that http and html can actually be used in a "big tent" manner? I think that is exactly how the web works. Define the protocol and content data models and the browser can weave it all together. Those protocols and content on the cutting edge may not be supported by all browsers, but the vast majority of the web that uses common features, allow website owners to produce just about any kind of service imaginable within those constraints.

You also said:

Say for example we only defined an HTTP method for DID resolution and DID dereferencing (for the sake of the argument) we'd still end up with a problem around interoperability because the caller is unlikely to be able to parse the results returned by resolution or dereferencing algorithms because the methods are too wildly different.

This doesn't make sense to me. A conformant resolver will return conformant DID documents, which can all be parsed in the standard way. Dereferencing follows the exact same flexibility as the web itself. Any URL can return any facet of the resource. The caller should be able to handle that, just as a browser has to be able to deal with a 404 response when an image/png is expected. We already have excellent interop at the DID document level. How is the result from a conformant resolver going to be anything other than conformant?

I've seen you've engaged on the political arguments a few times, but not these technical arguments yet from @peacekeeper and myself in the other thread.

Indeed. I took your comments as a statement of preference rather than a technical objection to this PR.

As for @peacekeeper's comments in #27

1. This PR mentions TWO possible ways how practical interoperability could be demonstrated (DID resolution OR DID methods).
2. Brent explained that no DID methods will even begin the process of being developed if the WG can't agree on any DID methods.
3. The documents will not advance past Working Draft.

None of these are technical objections to this PR. The first point is merely a restatement of the dispute. The second is a deferral to leadership promises. The third is, IMO, adoption of a position that is itself an abuse of the W3C chartering process. All of which describe @peacekeeper position wrt PR#27. His only comment on this PR so far has been

I slightly prefer https://github.com/w3c/did-wg-charter/pull/27 (see my comment https://github.com/w3c/did-wg-charter/pull/27#issuecomment-1407499611) but could also live with this here.

In his own words, @peacekeeper said he could live with #29. If there's a technical objection, I missed it.

[kdenhartog]

Apparently, I mistook that to mean that you do not have technical objections to this PR.

Ahh I thought by me requesting changes that signaled that I have technical objections to the direction.

As I re-read your note, it seemed more like an argument for standardizing resolution than anything else, with the examples from different DID methods highlighting quite clearly the need for standardizing DID resolution.

That's correct, but I also make the argument that I don't believe only resolution will go far enough because the content that can be returned by a DID document is arbitrary and loosely defined. I think you'd argue that this is a feature not a bug, but in my experience integrating a common interface across 4 different did methods this leads to some wildly underspecified logic that causes divergence in interoperability for callers of resolution. I then go on to provide 3 examples with 3 different did methods to support this argument.

The caller of the resolver, the client of resolution, is always going to do "content sniffing" of the actual object returned

This is correct, but I don't think you're understanding the level of content sniffing that goes into a caller library that's trying to abstract across multiple did methods. DID resolution cannot resolve this, it can only be solved via a more structured definition of DID Core. Just as a simple example theres no way to signal whether a DID document is intended to be used as a structured map of dereferencable URLs to retrieve a different resource, or whether the DID document contains the actual data and so the DID document is the actual resource.

That's how the web works. Use a URL to dereference a resource, you get a representation of that resource, which you then "sniff" to understand if its a 404 not found, a image/jpeg, or text/html. Sometimes you can get the details from the media-type header, other times you have to parse the resource before knowing.

Do you also find it hard to believe that http and html can actually be used in a "big tent" manner? I think that is exactly how the web works. Define the protocol and content data models and the browser can weave it all together.

Not quite and this is the point that matters here. If we go ahead and proceed with your analogy of HTTP and HTML then the analgous for this would be HTTP = DID Resolution and HTML = DID Document.

In this case, a perfectly defined DID Resolution specification would only account for half the implementation. My hunch tells me, we're not going to get anywhere near a perfect solution either because it will likely be over abstracted to account for "in memory" resolvers, "HTTP" resolvers, and then there's bound to be one person who shows up with like some sort of niche resolver like a XMPP resolver. HTTP works so well because there's not a variety of different structures that have to be abstracted around. Instead, it specifically defines a byte structure to transport messages over only a TCP socket. It's not been designed to support TCP and UDP.

On the other hand, HTML is a bad example to compare DID Documents with in my opinion. A better analogy would be XML. This is because when the HTML shows up there's a well defined structure of which tags are allowed and the only way in which new tags can become supported in HTML is via a standardization process to coordinate web content providers and browsers.

A conformant resolver will return conformant DID documents, which can all be parsed in the standard way.

When it comes to DID Documents, "conformance" is rather subjective because of the open world model approach we took. So I'd say your analogy works better with saying the content in the message body is just XML not HTML. This is because in a DID document the only required attribute is @id. I'm sure you've seen how browsers render arbitrary XML. It's basically just text with a few collapse capabilities and that's all we'll be able to do unless we add structure to the properties that can be supported in a DID Document. Additionally, there's no way to detect whether a DID document fits within a structure that's useful or not to the parser to do cool things like display an interactive web page. Instead, from the callers side it's like dealing with arbitrary XML. It is heavily extensible and wildly divergent. We should be striving to get HTML not XML.

Hence, I do not believe that just adding DID resolution is just enough to build a solution. Looking back at your analogy what it seems we're trying to achieve is to build a browser (in the actual since we're trying to build a library that can parse and meaningfully use a DID and DID Document) that supports TCP HTTP, UDP HTTP, and Gopher protocol (because we're not going to end up with a clean well defined DID Resolution spec based on past output of this WG) while trying to render XML. If we want to achieve a workable solution that's well specified we need to be able to structure not only the protocol of how the content arrives, but we also need to have meaningful structure to the content itself. Otherwise, we won't end up with interoperable "browsers" (DID supported libraries).

[OR13]

@jandrieu just so I understand your intention:

1. prevent the DID WG from defining resolution and dereferencing (again)
2. encourage the working group to define a specific did method (was added based on previous objections, this PR removes it).

29 (this PR) is about using did resolution and dereferencing to define interop, and NOT have specific did methods in scope.

27 is about using did resolution and dereferencing and specific did methods to define interop.

You have not requested changes on 27, but you are requesting changes on 29.

It is possible I am confused, having these 2 PRs open at the same time makes it hard to understand the subtle difference between them.

In my view the intention of the chair is:

Give the working group permission to do any / all of the following:

1. define resolution and dereferencing
2. define a specific did method
3. define both.

I personally am pro 1, and against 2 and 3... this is why I approve #29 and request changes on #27.

[brentzundel]

The DID WG chairs have met. We have concluded that merging PR #27 will produce a charter that best represents the consensus of the DID Working Group participants over the past year. Despite many, many discussions, no other proposal within the group has garnered as much support as this one has for the creation of a new DID Working Group, which will focus on maintaining Decentralized Identifiers (DIDs) v1.0 and publishing errata updates to that specification. The charter also permits the next DID WG to begin work on DID Methods and DID Resolution, but does not require it, e.g., the group that forms may do as much or as little work on these optional topics as desired.

Now, regarding the other open PRs, #29 and #30:

1. The predominant concern raised has been with the inclusion of DID Methods as optional work in this charter. The inclusion of DID Methods in the next chartered DID WG was part of the W3C Director’s decision to overturn the Formal Objections raised against the publication of Decentralized Identifiers (DIDs) v1.0. The chairs feel that that decision represents the consensus of the W3C and as such the inclusion of DID Methods as optional work in this charter is absolutely necessary. So we have concluded that PR #29 is no longer relevant to this discussion. We are leaving it open for comments, but they will not change the decision at this point.
   2. There have been suggestions for an alternative group focused exclusively on DID Resolution. We support the effort to create a DID Resolution Working Group that focuses entirely on DID Resolution, as that will strongly support the work of the DID Working Group, which must focus on the DID Specification. We encourage the proponents to develop their proposal and present it to W3M and the AC Forum as a new Working Group. However, because it would not be a DID Working Group, we have concluded that PR #30 is no longer relevant to this conversation. We are leaving it open for those who wish to continue designing a separate DID Resolution-focused WG, but we do not expect such work to change the decision at this point.

[OR13]

Given the decision by the chairs, I suggest this PR should be closed.