14C/ Formal Objections on the DID Spec

From IIW

DID Spec Formal Objections

Wednesday 14C

Convener: Brent Zundel

Notes-taker(s): Drummond Reed, Markus Sabadello

Tags for the session - technology discussed/ideas considered:

DIDs, W3C, standards

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps: 

Not recorded for more open discussion.

Mostly a Q,A format. Please raise your hand

  • DID working group began 2 years ago—defining proposed specification (https://www.w3.org/2020/12/did-wg-charter.html)

    • Did URL

    • Did method implementers

  • In September, DID Core moved to "Proposed Recommendation" status

  • 2 independent implementations of each feature

Wide review of W3C Advisory Committee

  • Three formal objections were raised by Google, Apple and Mozilla

  • Suggestions for changes (not formal objections) from Lawrence Berkeley and Microsoft

Formal Objection Text:

==== Google:
“DID-core is only useful with the use of "DID methods", which need their own specifications. These specifications are listed in the did-spec-registries WG Note, but none has made it past "PROVISIONAL" status, and the Note doesn't even define what its Status column means. It's impossible to review the impact of the core DID specification on the Web without concurrently reviewing the methods it's going to be used with. As the DID WG's charter states, we should follow the precedent set by the development of URLs, in which RFC 1738 standardized 10 schemes at the same time as it standardized URLs in general. ====

We strongly support the goal of decentralizing identifiers, but a review of a few of the provisional methods raises questions about how effective and ethical DID will be at accomplishing this. Some, like did:ccp:, are centralized under a single server. Many rely on proof-of-work cryptocurrencies, which fail the sustainability goals of the Ethical Web Principles. The process of advancing a few of the best methods through the Recommendation track will help focus review on them, and is likely to reveal places the did-core specification should change to fit the ways they improve.

We suggest holding off on advancing did-core to REC status until at least 3 or more methods are also ready to advance to REC.”

Anonymous:

“We agree in full with the concerns raised by Google in their Formal Objection. The specification should have at least one, interoperable method that works out of the box, either (preferred) included or (less preferred) registered. To borrow Microsoft's words, the Working Group must take up "the challenge of defining a[...] fully interoperable DID method that meets industry use cases and can be specified as a mandatory to implement[...] method."

Lawrence Berkeley National Laboratory requested adding a requirement "to provide a system- and processor-independent assessment of the energy requirements of a DID method." Whatever this mandatory method is, it must not be unsustainable / in violation of the Ethical Web Principles.

The spec should not move to REC until such a method is in place.

Additionally, we agree with Microsoft's compatibility concerns re: JSON and JSON-LD.”

Mozilla:

Summary:

  • No practical interoperability.
  • Encourages divergence rather than convergence.
  • Centralized methods allowed, in contradiction to WG & spec goals & name.
  • Proof-of-work methods (e.g. blockchains) are harmful for sustainability (s12y).

No practical interoperability. As Microsoft & Google expressed, the DID “Core” spec has not demonstrated any degree of practical interoperability, instead delegating that to a registry of 50+ “methods”, none of which themselves have interoperable implementations. We agree with the analogy to URLs & schemes, as Google noted: “precedent set by the development of URLs, in which RFC 1738 standardized 10 schemes at the same time as it standardized URLs in general”. The Web has similar experience with the img tag & image formats, and the video tag & video formats. In each of those cases, there were multiple interoperable formats before the tags themselves were standardized. In addition, we agree with the comments made by Microsoft to “recommend that implementers use the simpler JSON representation, to enhance interoperability and avoid complications and incompatibilities arising from JSON-LD processing.”

Encourages divergence rather than convergence. The DID architectural approach appears to encourage divergence rather than convergence & interoperability. The presence of 50+ entries in the registry, without any actual interoperability, seems to imply that there are greater incentives to introduce a new method, than to attempt to interoperate with any one of a number of growing existing methods. Note this is in contrast with prior examples given (URL schemes, image & video formats). Thus, whether intended or not, the DID specification (and perhaps its inherent architecture) is designed in such a way that encourages divergence of implementations, rather than convergence & interoperability.

The lack of restrictions on the registry are allowing methods diametrically opposed to the principles of the group & spec, and methods which are actively globally harmful to sustainability. In particular:

  • Centralized methods allowed, in contradiction to WG & spec goals & name. As Google noted, some methods in the registry such as did:ccp use a single server, and thus any interop with such a method would bias toward centralization, and likely be literally centralized rather than decentralized. Centralization might be at an architectural level, or – at a minimum – a service level, even if multiple “implementations” claimed to support it.

Lawrence Berkeley National Laboratory suggested “the registry should include a requirement to provide system- and processor-independent assessment of the energy requirements of any methods being registered.” We don’t think this goes far enough.

We (W3C) can no longer take a wait-and-see or neutral position on technologies with egregious energy use. We must instead firmly oppose such proof-of-work technologies including to the best of our ability blocking them from being incorporated or enabled (even optionally) by any specifications we develop. If anything we should pursue the opposite: develop specifications that supersede existing specifications, but with much less power consumption. We believe this is consistent with the TAG Ethical Web Sustainability principle (<https://www.w3.org/2001/tag/doc/ethical-web-principles/#sustainable>).

For these reasons we believe the DID specification may not be fixable (MUST NOT become a Recommendation). We suggest returning the specification to Working Draft status.”

Suggestions for changes (not formal objections):

Lawrence Berkeley:

“The document looks well thought out and comprehensive, but there is one area of significance that probably ought to be addressed in the requirements for DID method specifications, and that is energy consumption. Including a requirement to provide a system- and processor-independent assessment of the energy requirements of a DID method (e.g., a specific computational complexity analysis) would enable comparisons and hence selection of more energy efficient methods. I recognize that this was not included in initial requirements for the document, but waiting to include it in a future version will prevent its application to methods that are described based on the initial document.”

Microsoft:

“Microsoft has implemented and plans to use the W3C DID-core specification in our products, and we support the publication as a W3C Recommendation.

We also have additional feedback that we would like to see addressed in future work (if such work is taken up):

  • Interoperability could be improved with a single foundational key representation. We would prefer implementers to use JSON Web Key for representing cryptographic keys. We believe JSON Web Key would be a great baseline of support that could be extended with additional formats. Any additional formats included in the spec text should include the appropriate usage context. Related to: DID-Core Section 5.2.1.
  • We recommend additional non-normative guidance on cross-compatibility between the JSON and JSON-LD representations in Section 6. We further recommend that implementers use the simpler JSON representation, to enhance interoperability and avoid complications and incompatibilities arising from JSON-LD processing.
  • We would like the Working Group to take the challenge of defining a new fully interoperable DID method that meets industry use cases and can be specified as a mandatory to implement reference method.”

Background blog post on the whole issue published by Evernym yesterday: ​​https://www.evernym.com/blog/w3c-vision-of-decentralization/

W3C process begins with Charter.. Then the group agrees on a "First Public Working Draft". WGs are encouraged to start with documents that have been incubated. In our case, there was a DID Spec document from the Credentials Community Group. DID WG iterated over this for 1,5 years, then entered "Candidate Recommendation", when we requested "wide review" and "horizontal review" (this if for specific groups in W3C, such as Privacy, Security, Internationalization, Accessibility, TAG).

We got feedback from each of these group. We addressed all feedback as well as all issues that were raised on our repo. We adhered to the process, made changes in response to feedback and implementation results.

As soon as we had implementation results, we moved to "Proposed Recommendation". Then the process continued.. Call for review, received Formal Objections.

W3C team convened meeting between Objectors and DID WG representatives.

https://www.w3.org/2021/09/21-did10-minutes.html

We were not able to come to consensus with objectors on path forward. Next step is for the decision to be given to W3C Director. This means the W3C team looks at it, Ralph is "acting director".

W3C is trying to figure out how to act without a Director. Various committees and councils try to create consensus-based standards for the Web. W3C Council is composed of Advisory Board and TAG.

Question: About the objection of interoperability. This also has to do with data portability. In the Charter, there is a point about portability. DID spec doesn't define the way how you can independently move between DID methods. Is this taken into consideration?

There are numerous levels were interoperability could be shown. The Charter specifically outlines interop on the DID URI and data model level, along with an interface for DID Resolution. Out of scope were particular DID methods, so we couldn't show interoperability there. The type of interoperability you mentioned in the question I believe is addressed by having DID documents that are resolvable and understandable by consumers. The statement about data portability can be interpreted as being about Verifiable Credentials.

Question: The Charter didn't have in scope data portability in the sense of moving between networks, but in the sense of interaction.

We achieved interoperability on the data model level. Because specific DID methods were out of scope, we felt that showing interop between multiple implementations of particular DID methods was also out of scope.

Some DID migration mechanisms have been proposed, but they require protocols, not just data models. What's the typical migration mechanism for the web? 301 or 302 redirect, but this is a protocol. Such functionality was out of scope in our Charter.

Question: It seems to me one course of action is to pick 2 (or small number) of DID methods that don't use blockchain, and define them quickly. Is this doable? Any estimates how complicated this would be, technically, politically?

Technically, it might take longer than we think. Fitting this into W3C process, it would take at least a year. Politically, there seems to be relative agreement. Changing the scope of our work right now would be strange considering that we are the end of our timeline. The DID WG may support standardizing did:web and did:key.

If you read the minutes of the meeting with objectors, it could be that did:web and did:key would not be acceptable to them. It could take much longer than we would want to. We feel like we did good work and provided a solid foundation for other future standardization work.

Why are we being asked to do something now that wasn't in our charter?

The "customer" here is the WG. W3C approved the Charter 2 years ago. Now there is frustration, since the WG fulfilled all its requirements. Three W3C members (who happen to be the largest browser vendors) are saying they don't want this to go forward.

Now this goes to the Director to decide. We try to explain why we think the objections are not well-grounded, and how they are really motivated.

If the Director doesn't approve, we can request a simple-majority vote by all W3C members.

The argument that we "do not achieve interoperability" misses a major design principle of DIDs. DIDs are designed for interoperability. There are >100 DID methods that can be resolved to the same data model.

Question: Is the W3C of the opinion that DID Core should go back to draft status?

Only one organization (Mozilla) suggested this. This is an opinion by one member, not an opinion by W3C as a whole.

Question: What are the things that may have non-maliciously down the path to assume that we didn't achieve what we were supposed to do? Is it about the data model and a browser API? Do we also need to define a DID Resolution architecture, plus a few methods?

From the perspective of objectors, next step for the group could be to define specific methods. From the perspective of some WG member, we need to define the Resolution process. This may be related to defining specific DID methods. If we define a DID Resolution process, any compliant resolver would have to stick to.

Question: The objection came at a late stage, it's a pity that it comes so late in the process. Were they not aware of how this is shaping?

Mozilla is one of the organizations that nearly objected to the Charter, they strongly requested changes and were concerned from the beginning. None of the objectors participated by filing issues or actively contributing to the conversation.

Question: Microsoft also had substantive comments on concerns about lack of interoperability. I've never worked on a spec before where there was not a mandatory-to-implement set of features. This is a problem for interoperability. The bigger goal should be to have broader acceptance. It's a big red flag that all browser vendors except for Microsoft objected. We would be better off if we collaboratively work with them. Having a narrow victory in the face of objections doesn't serve the working group. Winning hearts and minds is more important.

About DID Resolution.. It's intentionally defined as an abstract interface, it's not a concrete protocol (like DNS). Details are dependent on the DID method.

It's key to address recommendations that objectors made. How can we get them to agreement, so that we get them to support the specification. We're upset about comments, but there has to be a way to address them. If we get the spec adopted without browser vendors, it's not a huge victory.

We were told by powerful companies that what we did is not good enough. This is similar to the "go get me a rock" problem (get me a bigger one, or a shinier one, etc.). The frustration has to do with lack of participation by objectors.

The DID spec may not be perfect, but we believe it is ready to be made into a Recommendation. If objectors believe we should re-charter to get DID methods specified, and if they will help do the work, that would be a different conversation.

We haven't seen any indication of that. Their objections didn't feel like they have serious understanding of DID architecture and objectives. It seems more like they are trying to find ways to delay it.

Comment: I'm a big believer in Charters, since they constrain what you do. Objections go beyond what's in the Charter. This may or not be fair. They say, we want to see a functioning ecosystem. There is not a single DID method that everybody supports. There is not a single key representation that everybody supports. They may feel that if we add a major new piece of functionality of the web, the expectation may be that the browsers implement this. There is no such expectation for DIDs. We should not try to read into people's motives. We should rather try to constructively engage, such as addressing the JSON vs. JSON-LD interop problem, or reducing key representations. There is a reason that major organizations like OASIS, W3C, OpenID Foundation have a broad review at the end. So that those who were not able to participate have a chance to object. They say it is bad for the ecosystem. It's not a process violation to participate at the end of the process. It's not a coincidence that so many important players are saying that there is something really wrong here. We ignore this at our peril.

Comment: I got some input on how much we should talk about objectors' potential motivations. It's dangerous, but also relevant. We act as if those objections are the bar. We miss the larger picture. When you have 112 different implementers, you can't say there is something wrong with the ecosystem. It's a sign of a very vibrant ecosystem. I personally think the political issue that there are so many DID methods will be solved by the market. See URIs, they were also standardized before the set of various concrete URI schemes was defined. Question should be turned around: What is the harm of going ahead with this first step of work, so that the 112 implementers can do their work?

Comment: There may be a middle ground here. Tension may come from immaturity of the ecosystem? If you look at certain methods, some of them are (.. not good ..). Once we find philosophical alignment, where do we go with it in technical terms. Objectors may think that allowing things to go forward may be a slippery slope. I saw what happened with Sidetree, where there was philosophical alignment, but still it took a long time to come to good technical interoperability. We should close gaps and work together, and ultimately try to get DIDs into the browsers.

Comment: As an innovator. .The DID spec represents a new paradigm, it's the future of the Internet. Everyone here knows that. The arc of decentralization is hitting every aspect of our life. It's challenging because it requires a new business model. It's a distribution that incumbents typically don't welcome. There are many books about the friction between the present and where the future goes. How we do privacy on the web needs to change. The current pathway is very dystopian. Here we are innovations and we stand for values. I love the large organizations, but I see their flaws. Apple doesn't take risks on new techn until they are confident that they can own the aspect. Google enables surveillance capitalism that created many problems today. I'm really confused by Mozilla, I understand why. Maybe they lost their innovation edge. I'm confident 100% that this is the future. Do we really need to ask for permission? This isn't going to die even if they kill the spec. Those organizations should open their minds to the future. It's a huge opportunity for them to innovate their business models. We got to look bigger. This is the future. If they put obstacles in front of us, we will still continue to do it. These organizations should be aware that they need to get on board. If they don't they will get disrupted.

We got a good conversation, recorded several viewpoints. We look forward to working with the Advisory Council if they should take up the issue.

Next steps are.. Right now there is an ongoing conversation on the AC mailing list. All W3C participating companies can interact. The conversation is at a more meta-level than about DID Recommendation. It's about the organization of the Advisory Council, what should the rules of recusal be, should there be better guidelines for reviews.

There are conversations about Ethical Web Principles, next steps, what should priorities be, etc. Should this serve as normative guidance for spec implementers. There is discussion about the Charter process. It's raising a lot of W3C process-level concerns and conversations. All of that is happening.

The Advisory Board will decide whether or not to form a Council to look at the formal objections. Either that will happen or it won't. Then the Acting Director will make a decision. Whichever way the decision goes, the next step could be an appeal to the W3C membership (the body of the AC). It would be a majority vote whether or not to uphold the Director's decision.

The DID WG has been extended until end of December. It's possible it may get extended longer.

Thank you for coming, this was a very valuable conversation.

Retrieved from "https://iiw.idcommons.net/index.php?title=14C/_Formal_Objections_on_the_DID_Spec&oldid=23999"