Meeting minutes
plh: sent agenda in advance
… want to see if we can find common ground without forcing common ground on broader community
… decision remains with the director
… let's see if we can avoid the director stepping in
… some formal objections and one suggestion for changes
DiD methods status & interop, standardization
plh: let's discuss the technical issues today
… there were concerns that the status of DIDs methods was not clear
… the group charter prohibited the Working Group from standardizing did methods
… yet, given the implementation report, it was enough to convince the director that we were able to move forward with the specification
… manu sent many responses to the agenda items but we'll go through them one by one
brent: on the first agenda item: our success criteria were clear. 1. we would show interoperable uses of the DID syntax and data model 2. have sections detailing known security or privacy concerns, and 3. have a test suite to show producer/consumer evidence of implementation for all features.
… we have met success criteria after long work of the group, there may have been some confusion if people looked at the DID Method Registry, rather than the Implementation Report for evidence of interoperability. There is work we could do to clarify some fields in the DID Method Registry, but that is independent of the Implementation Report.
<manu> 47 DID Methods passing the test suite, DID Specification Registries
tantek: need link for charter survey results for charter
… want to understand history of how we got here
plh: here is the link for the Charter Announcement
plh: also includes responses to comments at that link
tantek: meta issue I have is to request that participants disclose any conflicts of interest
plh: don't understand
tantek: since we have raised issues regarding specific cryptocurrencies, we'd like to hear about ownership stakes in any of the cryptocurrencies in the did methods
… just a request
plh: want to hear responses to brent's comments on DID methods
… otherwise I assume you are fine with his comment
ekr: as i understand it, you have verified that the methods can be processed, but do you have interop?
brent: that goes beyond the success criteria in the charter, but we do have some evidence for certain did methods. you'll see that there are multiple implementations of at least 2 methods
… not required, but we have done some
… did:key and did:web, by memory
jyasskin: did:key and did:web should be standardized but are trivial.
… it's the other methods that make the spec interesting. if no interop there, why bother doing this.
<tantek> +1 to jyasskin's points.
jyasskin: if none of the interesting methods are good enough to standardize then we can't validate whether dids in general are worthwhile
brent: framing it as good enough to standardize is about choosing which ones to standardize
… it's not that they don't exist, it's that the community doing the work to specify hasn't come to consensus on which if any the implementers would like to bring to W3C. Not to say they're not sufficient
… conversation about which ones is ongoing. We've had this from the beginning, and always looking for input from those interested in joining
tantek: the point of any spec is to add demonstrable value.
… the two methods cited are not actually providing demonstrable value toward use cases outlined in charter
… so if not adding value, it's not worth standardizing
… to provide something demonstrating point of spec without interop, there's no point
… might be good proof of incubation.
… there's a community of interest, but short of demonstrating existence of interoperability which is solving the actual problem to solve
jyasskin: i wouldn't go that far, but they don't demonstrate all the complexity of the core spec
… our objection was to wait to bring to rec until community has found other methods that demonstrate complexity of did core
… wait until they are ready to standardize and show interop within method
<Zakim> Travis, you wanted to mention how establishing a baseline for starting experimentation does have some value.
Travis: appreciate that we are taking this in small chunks at a time.
… creating framework, and infrastructure, etc. like WebRTC took a long time
<Zakim> brent, you wanted to point out that DID Methods were specifically forbidden by the charter
Travis: doing this one piece has been helpful to us to have a stake in the ground we can begin working with
brent: according to our success criteria, we have achieved interop.
… to say that add'l criteria should be added at this point, specifically ones named as out of scope, is too late. The time for these comments was 2 years ago.
tess: I wasn't here two years ago.
<tantek> +1 to Tess, I too was not an AC rep two years ago
<manu> No, but Apple and Mozilla were involved two years ago.
ekr: what i heard travis say would cause you in IETF to send something to experimental.
… higher standard should be required than "i want to play around with it"
manu: W3C AC made a decision to do work in smaller chunks, not what happened with HTML and WebRTC. We are doing this in small chunks.
… Goal was to not do did methods at the time, not clear which ones would be adopted by the market… a little more clarity today, but definitely not clear which to select
… you may not personally have been around 2 years ago, but your companies were and gave their comments.
… doesn't matter who was the AC rep at the time.
… 35 companies approved of transition to Rec, being built into systems today, US govt, Canadian government, many others.
… this is far from experimental. incubated for 4 years, then 2 years of charter that we've been following to the letter
<ekr> I'm a bit surprised to see WebRTC being cited as an antipattern, given the huge number of calling minutes that it currently does.
<jyasskin> The charter poll results are available.
<Zakim> tantek, you wanted to discuss "success criteria in the charter"
<brent> +1 to manu
tantek: concerned to hear that there are governments looking to adopt, with only single implementation methods and non interop, sounds like lobbying may have occurred,
… advocating for single-implementation solutions that are centralized wolves in decentralized clothing
<cwilso> +1 to tantek's concern that governments are responding to lobbying attempts on non-interoperable methods
tantek: against W3C and did group's goals
… on DID WG charter success criteria, our AC rep did submit an answer. He pointed out some of the problems we see today.
… problems were ignored. "Despite the name, it's not clear to us that
this work will
produce something decentralized. The cost of reaching
interoperability on new DID methods makes this appear more
centralized than URIs, where the cost of registering a domain is
low and well-understood."
… concerned that govts relying on single method and thus not decentralized. our concern is coming true.
<cwilso> +1
tantek: if this is a thin layer of spec-ese that claims to be decentralized, when they are doing something more centralized than DNS, it's a failure
<tantek> direct charter results link for reference
<manu> I'd like to remind the group not to make ad-hominem attacks or ascribe motive to DID WG members -- "it seems that... lobbying attempts"
<manu> Specifically, tantek and cwilso ^^^. That is not appropriate per CEPC
plh: eric was surprised this work was allowed to start. Process does not require any particular level of development to begin.
<cwilso> If that was taken as a personal attack, I certainly apologize. It was not intended as such.
plh: always tradeoffs. Regarding lobbying claim, W3C is not in the business of declaring what should be used.
<Zakim> cwilso, you wanted to respond to assertion that we supported the charter
plh: can point to specific instances for some of the companies here lobbying for their tech.
<ekr> BTW, I'm not saying that I'm surprised this work was allowed to *start* but rather that people are saying that this should be made a REC so that it can be experimented with.
<manu> I don't think thats whats being said ekr
cwilso: i wasn't the rep 2 years ago, We had objected to similar charters and wore out. Although W3C doesn't declare what must be used, that is what we do.
<Zakim> brent, you wanted to talk about Rubric and to point out that Google joined the WG
cwilso: if not creating something that can be used to build interop, not sure what we're doing.
brent: in feb 2020 Google joined the DID WG, suggesting that someone at Google approved the charter, although the participant never attended.
… arguing centralized vs decentralized has been a major discussion since the beginning
… how does an implementer know how decentralized a method is?
<cwilso> I don't need to q for this: but joining a WG is not the same as supporting a charter.
brent: that's what the rubric document is. It gives criteria for individuals to analyze any given DID method for themselves.
<Zakim> jyasskin, you wanted to ask what this interoperability looks like in practice
brent: recently added criteria for sustainability. allows did users to decide for themselves
jyasskin: joining a WG doesn't mean endorsing the charter.
… what interop do we check?
… it appears to check that the did resolver can produce a doc that meets the rules. do the docs then get intercchanged, or just the did strings?
<Zakim> pam_, you wanted to define interoperability of this particular specification
Pam: we are generating a discovery document, interop is between reader of document and entity that has written it to the substrate.
… notion of cross-method interop is interesting, but key is if they can be resolved on multiple substrates.
jyasskin: makes sense. Worry that test suite is not demonstrating useful interop.
… doesn't sound like docs themselves get sent between different systems
… you need two different systems to implement support for same DID URL
Pam: in that case that interop occurs at a higher level as part of request and response spec not this one
… there is what you say, but that's DID:comm or OIDC
<Zakim> manu, you wanted to note the test suite checks the normative statements in the specification, some of which is DID URL processing, public key processing, etc.
manu: test suite tests every normative statement in spec, key formats, URLs, what keys can be used for what.
… each ensures that data structures are consistent and interoperable
… multiple implementers have consumed documents from different implementers.
… there are already library implementations that process docs from multiple products
… that is what we were aiming for.
plh: moving to "did we achieve decentralization?"
Did we achieve to make DiD decentralized, given centralized methods?
brent: there are practical limits to W3C enforcing how its tech is used.
… the DID WG has considered this deeply.
… how decentralized is decentralized enough? Is it decentralized and in a centralized manner say that a particular method is not good enough?
… that decision should not be in WG or W3C hands, but left to the users of DIDs. Implementers have a guide we've published.
<ekr> I didn't take the comments here to be that the WG should restrict code point assignment but rather that it ought to define some minimum set of decentralized methods
brent: Rubric provides criteria for users to determine whether a particular method is good enough for their use
… we have done what we can to guide users in a decentralized direction..
… we can' go any farther without being centralized.
manu: understand that people want us to pick 1, or 3, but reality is that everyone has different requirements.
… our rubric allows everyone to make their own decision, just like everyone chooses their own w3c web browser, which we don't think would be right
… through the rubric we have tried to encourage some
… we have even talked about DID:web but a number of folks consider the web to be too centralized to pick that one
… it seems simple but we have worked on this for a long time and have done what we can to encouraged greater decentralization but can't pick just one method to be the best for everyone
… everyone has different requirements. not everyone should be using google chrome.
… especially for the DLT-based mechanisms the market isn't there yet, just lke not just one browser.
<cwilso> "Everyone should be using Google Chrome" is not at all the same as "the vast majority of <video> scenarios are solved with these four video codecs"
ekr: bad analogy, since browsers are at software level. They will all work with the same input doc.
… no one is suggesting just one did method. question is whether there is practical interop, which requires set of methods that deliver what you promised and on which interop is shown
… if market is ready, then this is premature.
… WebRTC took so long to agree on codecs but that was needed.
<Zakim> manu, you wanted to then use the analogy of image formats in the IMG tag.
<cwilso> +1 to ekr
manu: agree bad analogy with browsers, IMG formats are better. I specifically said dlt-based methods.
<tantek> DLT = distributed ledger technology right? Which is AKA "blockchain" or are there others?
manu: we have demonstrated for did:key and did:web, we have demonstrations of those "codecs" to use your analogy.
… not part of the charter but we did it
<brent> tantek, there are technical differences. Not all DLT s are blockchains, but the difference may not be pertinent
manu: rubric is example that we knew about this need and are helping users to have nuance and differing requirements that lead to different decentralization decisions.
<ekr> This <img> is an interesting example. If we were standardizing <img> today, I find it hard to believe that we would do it if there were no interoperable image formats.
manu: dlt means distributed ledger technology (blockchain being one)
cwilso: core of objection is to use analogy of image formats. need a core set showing interop.
… there is a consistent but not closed yet that shows interop.
<Zakim> brent, you wanted to say the market isn't ready to standardize on DID Methods
cwilso: if we were standardizing img today, there would be a required set.
<ekr> I will concede that there was not standardization on how to pronounce "GIF"
brent: market is not ready to standardize on which did method yet. That's right, but that dosen't mean there aren't any in heavy use.
… we have produced a data model so any method can resolve to a consistent document format. we were chartered to do that and have
… we agree that piece is not sufficient to see the whole picture and want to do more work.
… but saying we have to do more before this first piece can be set doesn't make sense.
… need something to build on
<Zakim> jyasskin, you wanted to discuss analogy to URLs
plh: want to get to energy and JSON conversations
jyasskin: you have something reasonable to build on. if it stays where it is until you've defined specifi methods you can still build
jyasskin: analogy to URL schemes is interesting. Some ended up falling out of use, but initial spec had them as interoperable.
<Travis> gopher!
<Tess> +1000 to jyasskin
<Travis> file: (ugg--still working on that one)
jyasskin: DIDs should work the same way. some did methods that work the same way regardless of implementations.
<Zakim> pam_, you wanted to mention need for co-existence
Pam: decentralization vs centralization. spec is for discovery doc.
<tantek> +1 strong agreement with jyasskin, the proper analogy to URLs/schemes is *at the point of standardization*, not current / long-standing URL scheme registry vs a new proposed
Pam: all kinds of entities need to communicate. did:web uses DNS, which some considered centralized, is possibly a bridge to the tech.
… we are trying to help people to have crypto keys that are theirs, incl. companies.
<Zakim> tantek, you wanted to address the "charter entitlement fallacy"
Tess: thanks brent for explaining that methods aren't ready to be standardized, let's wait until it is, like jyasskin suggests.
tantek: when img, audio, video were standardized there were interoperable formats already
… if everyone uses same library that's an issue, still only one implementation
<Dan> WebRTC, anyone?
tantek: what are the proper interop goalposts?
… "but we did what was in the charter". Won't debate that, but to leap from that to assume we are entitled to go to Rec is a fallacy
… many examples of things outside of charter that come up in horizontal review
… that are sufficient to send docs back in process step
… disagree with "charter entitlement fallacy". Maybe the charter needs to be fixed and the work sent back to a working draft.
plh: aware of at least one rec that went with only one implementation: WOFF. Used by all of you guys in the browser world . Not unheard of
… let's move to energy point
… some methods trigger questions about energy use
brent: adding criteria at this point is inappropriate, esp. in context of energy usage.
DiD methods and energy requirements
brent: this is an area where experts disagree. we HAVE considered this.
… we have text for implementation guide and rubric on this.
… energy use and environmental impacts are of sufficient concern to review those impacts, then it should not only apply to the DID spec.
… if you want environmental review, require all specifications to do so and include in the process
jyasskin: we wanted to see methods go through this process so the group would think about energy use implications.
… not important to get through those details now, just for future charter.
ekr: disagree that all specs or no specs need environmental review. If a particular spec could do a lot of damage.
<jyasskin> +1
ekr: don't think that's the only alternative.
… we didn't get the cross area review needed for this kind of analysis
<Zakim> tantek, you wanted to respond to "experts disagree"
tantek: was disappointed to hear "experts disagree" as an argument regarding energy usage
tantek: sounds like arguments made against climate crisis and contributions from carbon, energy usage. This is no longer an issue of expert disagreement.
<tantek> Bitcoin Uses More Electricity Than Many Countries. How Is That Possible? - The New York Times
tantek: NYT posted another article about carbon footprint of bitcoin.
… look up # of did methods that depend on bitcoin blockchain
<manu> You should come to the group and debate your point, tantek, you will find that again, it's not as clear cut as you state /across DID Methods/ -- not everyone uses PoW
JSON, JSON-LD
<tantek> manu, as noted in our charter response, we don't actually have the resources to go to the group to debate this point, that's part of the problem. dissent should not require participation in the WG.
brent: we have spent many hours on this. participants at the time discussed heavily, with our f2f meeting largely devoted to this resulting in the abstract data model that can be serialized into a number of serializations.
<manu> tantek, that's fine... the point remains that we are documenting environmental concerns, and there are multiple experts engaged.
brent: had JSON and JSON-LD support. We originally had CBOR but there wasn't enough support.
<Zakim> hober, you wanted to mention New principle: Discourage polyglot formats
brent: not clear what changes should be made to the spec coming from those who did NOT participate in the discussion
<annette_g> I guess I won't get a chance to address the energy question, so I'll say here I'd prefer to see mention of it in the core spec, as we have for security and privacy concerns, and some method of comparison among methods in the rubric. I'm heartened to see the activity in github around the issue, but I think SOME mention belongs in the core spec.
Tess: open issue on TAG design principles doc on this kind of multi-processor approach. Believe this should be discouraged.
… strong endorse MSFT's recommendation to endorse one.
<jyasskin> +1 annette_g
plh: tess, are you part of the TAG?
Tess: sometimes
plh: did this come up in the TAG review?
Tess: don't remember
manu: your words made it sound like it was a TAG issue. Has been a topic of intense debate in Verifiable Credentials and DID work. We have reached our current state after many years of debate. Both WGs came to the current state.
<Zakim> tantek, you wanted to respond to s12y "should not only apply to the DID spec"
manu: you have to participate at some level and convince the group to go one way or another, but this is the result of our discussions.
tantek: question of where you get interop has not only been in groups that Manu mentions. We had the same discussions regarding this in the Social Web Working Group where I was a co-chair,
in particular on the Activity Streams and ActivityPub specifications.
… we came to a different conclusion. To achieve testable interop we went to JSON as required and JSON-LD as optional. This has been discussed in other WGs.
… disagree with any WG having the best answer for this.
… out of order to demand that TAG show up to a WG to discuss this. Should be other way around. Show up to TAG meeting to discuss.
… argument was made that sustainability concerns should apply to all specs, and I agree.
… this issue is on par with horizontal review requirements for internationalization and others.
… no other spec at W3C has the potential to magnify the effects of bitcoin, ethereum, other PoW processing.
… we are using DID spec as an example because no other spec has had such potential for environmental impact. Not just picking on DiD specification.
brent: queued to agree with tantek that horizontal review determination, JSON vs JSON-LD, etc. go beyond DIDs. We did our best and would like to have guidance from TAG. We responded to the guidance we received.
… there's a conversation in the DID WG about the environmental topic. I'm neutral, but my question is what is the environmental impact of CSS, what exchange are we making between processing power and beauty. WebRTC for requiring encryption? Some DID method developers believe that it is worth the energy expense to get decentralization.
… we have provided guidance in implementation guide and rubric, but conversation is much larger than our WG
<ekr> More that I love encryption than that I love WebRTC
<manu> Processing isn't free, and each spec makes tradeoffs there wrt. power consumption vs. security vs. pretty graphics
Pam: we do believe simpler representation is better. we madie that known but worked within the group to ensure that we had a JSON format that was usable.
<brent> for the record, I love CSS and WebRTC
Pam: we didn't object because we believe in a next charter this can be addressed. existing consensus is fine for now.
… regarding sustainability, we have accountability requirements in our org. We have collaborators in project that anchors on IPFS. We will work to change consumption and change the methods if needed.
… but we don't believe the spec has to be changed for that to occur
<tantek> thank you pam_ for that disclosure. greatly appreciated.
<ekr> FWIW, I dont think people are saying that it should not be possible to define did methods which are very energy wasteful (without taking a position on these methods). Rather, the question is the same one here as with interop
<ekr> Namely, is this specification achieving meaningful decentralization with acceptable energy consumption/interoperability
<manu> ekr, the answer to that question will boil down to the requirements around the different axes of energy usage and different axes of decentralization... there is no ONE answer.
<ekr> manu, well, if the W3C is endorsing it, then I think there is a minimum bar.
Next steps
plh: agreement that more work needs to be done in the DID space, but question is whether we can publish spec today and work later, or whether we need to wait on the current publication.
… accurate?
tantek: no one seemed to object to sustainability as a principle.
plh: no one objected to defining specific methods in next step either, and they were out of scope in the first step.
annette_g: since the discussion in GitHub has a considerable amount of activity even in the last few days, I don’t think the group is done discussing the issue, so I don’t think it’s fair to justify dropping the issue by claiming that the group has already thoroughly wrangled with it.
plh: if you have additional comments/questions, please reach out to me at any time