Fwd: Report for the DiD Formal Objections

for public archival purposes. forwarded with authorization.

-------- Forwarded Message --------
Subject: Re: Report for the DiD Formal Objections
Date: Wed, 2 Mar 2022 14:51:34 -0500
From: Philippe Le Hegaret <plh@w3.org>
Organization: World Wide Web Consortium
To: Chris Wilson <cwilso@google.com>, Jeffrey Yasskin <jyasskin@google.com>
CC: Ivan Herman <ivan@w3.org>, Pierre-Antoine Champin 
<pierre-antoine@w3.org>, Ralph Swick <swick@w3.org>

On 3/2/2022 1:14 PM, Chris Wilson wrote:
> First, a side note - in the future please be sure to include alternate 
> AC reps as well. I was on vacation last week, and didn't get to this 
> until Monday (I think Jeffrey was out of the office for much of that 
> time too, so probably need more of a heads up this is coming in the 
> future, which I expect we can build into expectations.)

Good catch. It's not the first time I'm making the mistake not to 
include alternate AC Reps :(.

I added a note about this in our AB/W3M objection handling. It can 
either be a heads up or we need to give a longer response time than just 
one week. The current handling of formal objections guidelines[1] don't 
say anything about a report so it's harder to tweak it.

[1] https://www.w3.org/2017/12/formal-objections.html

> I think the core of our objection is getting lost; maybe because the 
> first two points are (to us) the same core objection (“Lack of 
> demonstration of interoperable methods” and “Lack of demonstration of 
> practical interoperability”).  The lack of demonstration of 
> interoperable methods is LEADING to the core problem. Mozilla stated 
> this better as "has not demonstrated any degree of practical 
> interoperability" - that any interoperability that might be enabled by 
> the current DID Core 1.0 is only enabled by reliance on other 
> specifications that are not yet standardized.

My thinking is to quote your answer in the section where I respond to 
Mozilla's point.

>   When you mentioned "the 
> Director assessed that the DID Working Group demonstrated adequate 
> implementation experience of DID 1.0 Core and interoperability on 
> existing methods", the Director was probably mistaken: while some DID 
> documents do interoperate assuming that the two implementations have 
> de-facto standardized a method (which in practice always seems to be 
> did:key: or did:web:), 1) the Proposed Recommendation and its normative 
> references aren't enough to write those interoperable implementations, 
> and 2) did:key: and did:web: don't use all aspects of DID documents, and 
> the remaining unused aspects haven't been shown to interoperate.

Noted. I will not modify the report for that but I will however add your 
remark as an addendum.

> The WG compares DID Methods to URI schemes, and we think this is an 
> appropriate comparison, but we think the way the WG's FAQ presents the 
> comparison is misleading in several ways, which have been propagated 
> into the Team-endorsed text in the document:
>  1.
>     The Team's document ought to acknowledge that there are a small
>     number of URI schemes that DO enable core interop across systems
>     (e.g. HTTP).  If URIs were just a identifier syntax for app-specific
>     URIs and the like, they would have considerably less interop impact.

I did not go through the list of URI schemes [1] to evaluate their 
interop across systems so I'm reluctant to acknowledge that in the 
document. But again, I'm happy to quote your statement in the addendum.

[1] https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml

>  2.
>     As this is a discussion of the initial standardization of DID
>     technology, the Team's document should cite RFC 1738 (which included
>     definitions of 10 schemes) instead of RFC 3986. Following RFC 3986's
>     model of referring to other standards will be appropriate once there
>     are some other standards defining DID methods.

I concur for a large part and will modify the document accordingly. One 
reservation however since I wrote

"Similarly to RFC3986 (Uniform Resource Identifier (URI): Generic 
Syntax) with schemes, DID 1.0 does not constrain the DID methods."

I believe this remains correct and changing that reference back to RFC 
1738 would be not helpful. RFC 7595 only provides limited guidelines.

>  3.
>     Similarly, the Team should compare the ~112 DID methods registered
>     at its first standardization with the ~15 URL schemes defined or
>     imagined at its first standardization, not the 346 schemes
>     registered almost 30 years later.

That's a fair and appropriate remark as well. I will modify the document 

> We'd like to double-check that the Team is presenting the WG's FAQ to 
> the Director as opinion rather than fact?

That's correct. I just did not want to include the FAQ as a big quoted 
text in the document, thus my reference. I will

> The Team's document characterizes all three objections as asking for 
> "truly decentralized" methods, but we don't know what that would mean 
> and don't insist on it. We want to see the WG figure out its own design 
> constraints for "good" methods (as the Rubric starts to do) and 
> standardize some of those. As the Team's document says, it seems clear 
> that did:key: and did:web: aren't sufficient for the WG's own goals. 
> Note that we were not expressing concern over allowing "bad" methods 
> into the registry; just a desire to see interoperable implementations of 
> some that the WG considers "good".

Noted. I will not modify the report for that but I will however add your 
remark as an addendum.

> On the registration of DID methods that are harmful to sustainability, I 
> would point out that the TAG did not REVIEW any methods - because they 
> aren't part of the DID Core, and are thus outside the scope of their review.

That's a good point and will modify the report accordingly.

> (Several links, including the link to the TAG's "wide review", have 
> %-escaped the "#" that's meant to separate the fragment. For example, 
> the wide review link points to 
> https://github.com/w3ctag/design-reviews/issues/556%23issuecomment-763900128 
> <https://github.com/w3ctag/design-reviews/issues/556%23issuecomment-763900128> 
> instead of 
> https://github.com/w3ctag/design-reviews/issues/556#issuecomment-763900128 
> <https://github.com/w3ctag/design-reviews/issues/556#issuecomment-763900128>, 
> and the Ethical Web principles Sustainability link should point to 
> https://www.w3.org/2001/tag/doc/ethical-web-principles/#sustainable 
> <https://www.w3.org/2001/tag/doc/ethical-web-principles/#sustainable>.)

Will fix.

> One last point - in the 2019 Charter Review section, the text should 
> mention that Google did not respond to the charter vote, Apple 
> abstained, and Mozilla objected without raising a Formal Objection.  
> (The text of Mozilla’s response is clearly an objection, but they stated 
> up front that they simply didn’t have the bandwidth to make the argument.)

Will do.


Received on Thursday, 10 March 2022 17:22:36 UTC