-
Notifications
You must be signed in to change notification settings - Fork 6
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
Remove mention of DID Methods from the charter #29
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Brent Zundel <[email protected]>
Signed-off-by: Brent Zundel <[email protected]>
Signed-off-by: Brent Zundel <[email protected]>
Signed-off-by: Brent Zundel <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-1 for reasons listed here: #27 (comment)
I would not FO if the WG chose to go this direction though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can only disapprove by saying I'm requesting changes, but the changes I'd request on this would basically be to change it to #27.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I personally prefer #27, but I won't object to this one if it helps moving forward.
Co-authored-by: Pierre-Antoine Champin <[email protected]>
@TallTed do you have a technical reason to file a FO if stuck working on DID Resolution instead of DID Methods? |
@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.) |
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:
|
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). |
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:
And,
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. |
Ah... I did not see these arguments before my previous comment. Allow me to respond.
This is a political argument and not suitable for this discussion.
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.
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. 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. |
@@ -79,8 +79,7 @@ <h1 id="title"><i class="todo">PROPOSED</i> Decentralized Identifier Working Gro | |||
The <strong>mission</strong> of the | |||
<a href="https://www.w3.org/2019/did-wg/">Decentralized Identifier Working Group</a> | |||
is to maintain the <a href="https://www.w3.org/TR/did-core/">Decentralized Identifiers (DIDs)</a> | |||
specification and related Working Group Notes. The WG will also seek consensus | |||
around the specification of DID Methods and DID Resolution. | |||
specification and related Working Group Notes. The WG will also seek consensus around the best way to achieve effective interoperability. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer the note about did resolution and dereferencing, see my comment on #27 (comment)
I don't think defining methods is required to achieve interoperability.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
If recharter happens now, it would be appropriate to respect the above and mention DID methods in the charter.
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. 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 slightly prefer #27 (see my comment #27 (comment)) but could also live with this here. |
I agree with this. |
I read the ruling differently (as quoted by @pchampin #27 (comment))
That is a suggestion, not a MUST.
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?
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.
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 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 #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. |
@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) 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. |
Yes, please do. I took your comments at face value. You said
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:
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:
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:
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?
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
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
In his own words, @peacekeeper said he could live with #29. If there's a technical objection, I missed it. |
Ahh I thought by me requesting changes that signaled that I have technical objections to the direction.
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.
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.
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.
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 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). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've reviewed the language proposed by @brentzundel as a counterpoint to #27. I'm requesting changes to clearly specify that DID Resolution is in scope as a normative specification.
The <a href="https://w3c-ccg.github.io/did-resolution/">Draft Community Group Report</a> may serve as a starting point. | ||
</p> | ||
<p> | ||
It is not intended that DID Resolution and DID URL Dereferencing will advance beyond <a href="https://www.w3.org/2021/Process-20211102/#RecsWD">Working Draft status</a>. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is not intended that DID Resolution and DID URL Dereferencing will advance beyond <a href="https://www.w3.org/2021/Process-20211102/#RecsWD">Working Draft status</a>. |
@@ -182,9 +177,8 @@ <h2>Scope</h2> | |||
<p>The Working Group may also publish new Working Group Notes that may be necessary to clarify, help the deployment and usage, or propose new features to the Group’s main recommendation-track deliverable.</p> | |||
<p> | |||
The Working Group may also publish new Working Group Notes, Editors Drafts, or |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Working Group may also publish new Working Group Notes, Editors Drafts, or | |
The Working Group may also publish new Working Group Notes as appropriate. |
Working Drafts for DID Resolution or DID URL Dereferencing. Any new documents | ||
intended for Recommendation will be limited to the Working Draft maturity level. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Working Drafts for DID Resolution or DID URL Dereferencing. Any new documents | |
intended for Recommendation will be limited to the Working Draft maturity level. |
@jandrieu just so I understand your intention:
#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:
I personally am pro 1, and against 2 and 3... this is why I approve #29 and request changes on #27. |
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. Now, regarding the other open PRs, #29 and #30:
|
Given the decision by the chairs, I suggest this PR should be closed. |
Remove mention of DID Method specification text from the charter and add deliverables for DID Resolution and DID Dereferencing.
Preview | Diff