Meeting minutes
<Wip> Agenda: DID Extensions
<manu> christine: Hi Christine, new to IRC, please add me -- working w/ W3C with the legal group. Happy to be part of the team.
<markus_sabadello> Wip: Topic today is broadly DID extensions
<markus_sabadello> Wip: Main topic we wanted to bring up is duplicates, do we allow duplicate method names in the registry
<Wip> w3c/
<markus_sabadello> Wip: This links to multiple similar issues
<markus_sabadello> Wip: This came after the challenge of did:tdw, related to trademarks
<markus_sabadello> Wip: Do we allow people to register multiple methods under the same name? If not, what's our approach? First come first serve?
<Zakim> manu, you wanted to provide some background
<markus_sabadello> manu: +1 to this topic
<markus_sabadello> manu: Some background.. Currently you know we have this DID extensions set of documents, for properties, for DID resolution, for DID methods.
<markus_sabadello> manu: Those have been split up and published, thanks Pierre Antoine.
<markus_sabadello> manu: We have a good structure, now the question is what are rules for inclusion of DID methods.
<markus_sabadello> manu: We're trying to increase interoperability. In order to do that, when someone claims a DID method like did:foo, ideally you'd only want one of these. If you have two, people would be confused which one to implement.
<markus_sabadello> manu: This is one view, to increase interoperability we have have only one method by name.
<markus_sabadello> manu: The other view is we shouldn't even be in the game of picking one, we should leave this to market dynamics.
<markus_sabadello> manu: As long as there are no legal issues, we could list multiple methods.
<markus_sabadello> manu: There will be strong negative consequences if anyone registers a duplicate method, harms interop. The core of what this group is doing is fundamentally decentralized.
<markus_sabadello> manu: Compared to e.g. IETF where registrations are more strict, we wanted to be less formal.
<markus_sabadello> manu: Just because you have something in the registry, it doesn't mean people will follow it.
<markus_sabadello> manu: Proposal 1: First-come, first-serve, Proposal 2: Just allow multiple registrations.
<markus_sabadello> manu: From a perspective of setting up the registry, both proposals would be really easy. E.g. in the case of did:tdw.
<markus_sabadello> manu: Stephen Mccown proposed something good how we could deal with assertions of trademark violations. We could do what ICANN does, i.e. if you think someone is violating your trademark, you have to work it out in your jurisdiction. Once you get a judgement from a court or other legal assertion. Only at that point do we replace or remove an entry
<markus_sabadello> in the list.
<markus_sabadello> manu: You first have to assert your trademark in your jurisdiction, then we would take action. The only caveat could be if it's some giant known brand like Coca Cola. In that case we could probably deny the registration.
<markus_sabadello> manu: My light preference is to allow multiple registrations. For the trademark topic, use the ICANN approach.
<Wip> pchampin
<markus_sabadello> pchampin: I have a concern with the multiple entry approach. It's not ideal for interop, and we know that the formal objections had a lot to do with demonstratable interop.
<Zakim> Wip, you wanted to add that registry is not final.
<markus_sabadello> Wip: The DID method registry isn't final. We don't require people to register methods in the registry. There's nothing stopping anyone from creating a DID method and not registering it. It's not in the DID Core spec.
<Zakim> manu, you wanted to note can someone FO a list of extensions? If they do, what does that mean?
<markus_sabadello> manu: What would they formally object to? It would have to be on the DID extensions document. What would it mean to object to a WG Note? The document gets auto-published.
<markus_sabadello> manu: The list of extensions is reflecting reality. If there are multiple implementations of method names, we can't police that. In that case, wouldn't it be better to "know" that multiple methods with the same name exist, instead of people being surprised when they find out?
<markus_sabadello> manu: I'm trying to figure out if the FOs would hold up the DID Core or DID Resolution specs. I can't see how.
<markus_sabadello> manu: If we make this decision now, we still have 6 months to a year to get feedback.
<markus_sabadello> pchampin: The FOs of DID Core were mentioning the registry a lot. The argument was DID Core is not allowing interoperability.
<markus_sabadello> pchampin: The registry may provide arguments.
<markus_sabadello> ivan: I don't remember if we had this discussion and what the conclusion was. Did we decide if this will be a formal W3C registry or not? If it is a formal registry, then there is an AC vote and potential FO about the process (not the content) of the registry. This could backfire.
<manu> I think we decided that it is NOT a formal W3C Registry.
<Zakim> manu, you wanted to note that we're working on a standardized set of DID Methods, and we'd have interop demonstrations w/ resolver for multiple DID Methods.
<markus_sabadello> Wip: My memory is we decided to experiment with W3C registry.
<markus_sabadello> manu: I think we said we didn't want to be another "guinea pig" on this W3C process, so let's do it as a Note. People said it doesn't really matter. Let's not make this more complicated, to follow the core of the philosophy of this group about this being a decentralized technology.
<Wip> We did decide to use W3C Registry btw. See resolution - https://
<markus_sabadello> manu: Last time the FOs was that we didn't standardize any DID method, and that there were so many of them. I think what's different this time is there is a clear indication that we are working on a concrete set of DID methods that we will bring to W3C. This is what's happening in DIF, CCG, others.
<markus_sabadello> manu: 30+ people are showing up on those meetings, and this will result in a set of specs that could be taken on a standards track on W3C.
<markus_sabadello> manu: The other thing this time is that we have the DID Resolution spec, and we have some preliminary test infrastructure. So we can show that there are interop test suites and multiple resolvers.
<markus_sabadello> manu: The other concerns were about shared features of DID methods, and we can show that they share how to process verification methods, services, JSON-LD contexts, etc. Those things are truly interoperably across all DID methods.
<pchampin> Note that I'm not personally against the "multiple entry" option; I appreciate the rationale. I'm just trying to anticipate how others may react...
<markus_sabadello> manu: So I think we have all three arguments covered this time. But do have to do work, i.e. getting test suites with multiple implementations out there.
<markus_sabadello> manu: I think we are in much better shape this time than last time. The same arguments of the FOs will not work this time.
<markus_sabadello> manu: FOs against the registry couldn't achieve much other than falling back to a first-come, first-server policy. I think we should try for the "ideal".
<Wip> https://
<Zakim> JoeAndrieu, you wanted to say we did say registry
<manu> I thought we undid that resolution? :)
<markus_sabadello> JoeAndrieu: I remember we said we do want to be a "guinea pig".
<manu> It says: "The two repositories are likely to be managed as W3C Registries" <-- doesn't say we will do that...
<markus_sabadello> JoeAndrieu: I think the registry is not salient to the objections. Whether or not we have a registry doesn't affect if we have interoperable methods.
<manu> It says "likely".
<markus_sabadello> JoeAndrieu: What we're trying to do here is something like DNS without a centralized anchor of authority.
<markus_sabadello> JoeAndrieu: All the centralization semantics of a registry, we need to be careful about that.
<markus_sabadello> JoeAndrieu: If people are happy with multiple listings, that's okay.
<markus_sabadello> JoeAndrieu: Trademarks are a jurisdicational issue. Something protected in one place may not be protected in other places. It's not the right place for us .
<markus_sabadello> JoeAndrieu: I'm trying to prepare what we need for the Rubric.
<markus_sabadello> JoeAndrieu: The discussion of the rules imply if the process is for uniqueness.
<markus_sabadello> JoeAndrieu: To Ivan's point, we're going to put together a set of rules and put them in front of the AC.
<markus_sabadello> JoeAndrieu: It's necessarily going to AC for a decision.
<Zakim> manu, you wanted to ask if I'm misremembering the decision on Registry.
<Wip> https://
<markus_sabadello> manu: The general question is am I misremembering about the W3C Registry. I thought we had that discussion before we re-published the documents as FPWDs and Notes.
<markus_sabadello> manu: One concern I have about the registry is that we will have a lot of process discussions.
<JoeAndrieu> we don't
<markus_sabadello> manu: I expect this to be potentially be used as a political argument by other groups about how to run a registry.
<markus_sabadello> manu: The question is do we want to invite that. It's a political concern.
<markus_sabadello> manu: +1 to JoeAndrieu. The purpose of the registry is to list all known implementations, it's not about providing uniqueness. But we'll be the guinea pig at W3C to show if we are using the W3C Registry process correctly.
<Zakim> bigbluehat, you wanted to ask if we can use (most) of the registry process without claiming to follow if exactly?
<markus_sabadello> benjamin young: I'm fine with allowing duplicate entries, maybe call it "directory" or "index", rather than "registry". Regarding W3C process about Registry, maybe we can cherry-pick by following it as closely as we can, without "formally" being a W3C Registry. We will abide by those pieces, just use the parts that make sense.
<markus_sabadello> decentralgabe: I differ in my opinion, I do think it should be a registry, have a place that reduces conflict. We don't say you need to register a method, but the method can still serve to have a clear process for resolution of conflicts.
<rigo> arguing against that there will be only ONE registry. And arguing for discussion about criteria
<markus_sabadello> decentralgabe: The point is to maintain uniqueness and avoid confusion and help adopters.
<markus_sabadello> rigo: Rigo Wenning of W3C legal council, here with Christine. If W3C maintains a registry, it doesn't mean no one else can do another one. EBSI will certainly have its own registry of authorized methods. Gaia-X will also have it's own registry. This is a service for the community. We should talk less about this will be, and more about the criteria
<markus_sabadello> we want to apply. I would be concerned if there was an index where anyone can just write their own cryptocurrency DID methods for ripping of process, getting credibility.
<markus_sabadello> rigo: When you do something under W3C, you also have to consider W3C credibility. I would encourage you to discuss the criteria. Regarding naming conflicts, whether you decide for allowing duplicated or not, the conflict between duplicates will remain the same. But if we define criteria, the W3C processes will help to resolve conflicts. I
<markus_sabadello> congratulate you on how you handled did:tdw.
markus_sabadello: I'm undecided. I could agree with Rigo, there will be multiple communities. they can decide which DID methods they support. in our registry (or index), if we allow duplicates, some groups will consider this a weakness of DIDs, as Gabe pointed out this will lead to confusion. DIDs will be even less interoperable.
<Zakim> JoeAndrieu, you wanted to say this is not a neutral place
markus_sabadello: on the other hand DIDs are meant to be decentralized. we always said it's an optional, informative list. allowing duplicates could be a good thing if we say it's an informative list. say this is not a list of mandatory DID methods. if we allow multiple DID methods to conflict we need to explain this
<markus_sabadello> JoeAndrieu: Rigo I disagree with some things you said. I think this was one of the best arguments against a registry. W3C shouldn't take a positions on which DID methods are "good". This would be like having a registry of websites that are "good". This is not the role of W3C to mediate.
<markus_sabadello> JoeAndrieu: Middle ground could be to help people understand and educate. If we stand at the point of credibility, then we will be a point of centralization.
<markus_sabadello> JoeAndrieu: Regarding Gabe, I think the arguments of the FOs were largely illegitimate. I think most people in the W3C leadership think about things in the way how we think about it. We're trying to fix e.g. some things about DNS.
<markus_sabadello> JoeAndrieu: We're in a very contentious context. It would be dangerous if we start acting like this organization was the place were we "bless" something. I think how we handled did:tdw was atrocious.
<markus_sabadello> JoeAndrieu: The fact that this was allowed to be shamed out of submission was wrong. We shouldn't be in a position to resolve those kinds of issues.
<markus_sabadello> dmitri: I agree with Joe's conclusion. We should not be in the business of authoritative decision, due to resources, staffing, etc. It would be ideal to have a registry somewhere to maintain unique names and about developer conclusion. The easiest way to do that is first come first server, but that leads to name squatting. The best approach may be
<markus_sabadello> the ICANN approach. I don't think we as WG don't have the moral authority and have the staffing to enforce that.
<markus_sabadello> dmitri: I think getting away with not having a list would be good, but I think we can't do that.
<markus_sabadello> dmitri: So I think the least harmful way is to allow duplicated.
<markus_sabadello> TallTed: Let's leave aside discussion how we name the registry. The way how we handle things is another topic.
<markus_sabadello> TallTed: The way how people will build DID methods in the wild matters. Short strings are desirable, especially memorable. Having all 17 DID method "abc"s in our "registry" is a value point. To say someone new in the field, maybe I shouldn't name my method "abc".
<markus_sabadello> TallTed: It makes it easier for people building resolvers, I only need to handle methods listed in the registry. I don't have to worry about the other methods.
<markus_sabadello> TallTed: We do want them all to be listed, it's kind of a whitepages thing. It shows that this is actually doing what we want, in that it's decentralized. People can do things that are colliding. Only the strong survive.
<markus_sabadello> TallTed: I think that these arguments will serve well in the event we have to respond to a FO, to get them overruled.
<Zakim> manu, you wanted to comment on "directory" vs. "index" -- thought we decided this too -- it's a "list of extensions". :) -- what if we allow duplicates but strongly discourage them and request that the registrants figure it out? and to agree that some W3C Members (external to this group) are hostile to this work and we shouldn't empower that sort of hostility.
<markus_sabadello> manu: I thought we said this is just a "list of extensions", not a registry.
<JoeAndrieu> +1 to list of extensions having been our naming discussion
<markus_sabadello> manu: I'm rather strongly against the formal registry process.
<markus_sabadello> manu: We allow multiple registrations, but we will raise an issue, and we expect the registrants to sort it out among themselves.
<markus_sabadello> manu: It takes us out of the critical path.
<markus_sabadello> decentralgabe: A centralized registry doesn't mean that DIDs are centralized.
<markus_sabadello> decentralgabe: It just means we choose a centralization point to interop. If it introduces confusion, which defeats the purpose of having a registry in the first place.
<markus_sabadello> decentralgabe: We don't have a process for resolving registry issues. Maybe find another organization to run a registry on our behalf.
<markus_sabadello> decentralgabe: I don't think we should list duplicates
<TallTed> change "frowned upon" to "potentially problematic"
<TallTed> zero-cost first-come-first-served lends itself to squatting
<Zakim> JoeAndrieu, you wanted to suggest removing frowning and to mention persistence of registry v NOTE
<markus_sabadello> JoeAndrieu: I don't think we should do "frowning".
<TallTed> +1 remove "frowning" (as typed earlier)
<markus_sabadello> JoeAndrieu: We shouldn't have lists of names that you shouldn't name your child. My argument for W3C Registry is that otherwise it doesn't persist beyond this working group. If we expect this registry to be updated over time, then I think we need to use the W3C process.
<Zakim> bigbluehat, you wanted to say the central tension seems to be about arbitration vs. information provision
<markus_sabadello> markus_sabadello: I think if we allow duplicates, then the first one should be highlighted.
<markus_sabadello> benjamin young: We shouldn't be an arbiter of what is good and bad, this is different from just being a source of information.
<TallTed> manu -- as I typed above, `change "frowned upon" to "potentially problematic"`
<manu> +1, can do that ^
<TallTed> technical, not judgemental
<markus_sabadello> benjamin young: As we have already seen, attemping to arbitrate conflict is not something this group is prepared to do. Stepping into that is risky. Anything we can do to lean it to "information provision" should help keep us out of the critical path.
<Zakim> rigo, you wanted to indicate that it is NOT necessarily the WG that runs the registry, but creates the criteria
<manu> /me DRAFT POLL: Allow multiple registrations in the DID Methods extensions list but make it clear in the registration process that doing so is potentially problematic (due to interop concerns), an issue will be raised to try to discuss the concern, and the expectation is that the registrants will figure it out between themselves (issue will be linked from entry in the list).
<decentralgabe> +1 Rigo
<Zakim> manu, you wanted to ask if we can run the polls to get data?
<markus_sabadello> rigo: This is new to W3C, W3C has no experience with registries. Having a registry doesn't mean this group had to arbitrate. The group needs to define criteria. W3C doesn't say what's good or bad. I expect the EU Commission to be very restrictive what DID methods will be allowed. A W3C registry should just be indicative.
<markus_sabadello> Wip: Let's run those polls
<manu> POLL: Do not allow duplicates in the DID Methods list; registration is first-come first-served.
<decentralgabe> +1
<Wip> -1
<JoeAndrieu> -1
<bigbluehat> -1
<TallTed> W3C Registry is maintained by a group specified by its creating group (and successors). It would be bad for many groups to expect the W3C Team (the ultimate fallback) to maintain many Registries.
<manu> -1
<markus_sabadello> 0
<TallTed> -1
<pchampin> 0
<ivan> -1
<manu> DRAFT POLL: Allow multiple registrations in the DID Methods extensions list but make it clear in the registration process that doing so is potentially problematic (due to interop concerns), an issue will be raised to try to discuss the concern, and the expectation is that the registrants will figure it out between themselves (issue will be linked from entry in the list).
<Wip> +0.5
<manu> +1
<JoeAndrieu> +1 but would want edits in a proposal
<bigbluehat> +1
<pchampin> +0.5
<ivan> +1
<decentralgabe> -0
<markus_sabadello> +0.5 if methods are listed chronologically, first registered is highlighted, and strong guidance for implementers is provided
<TallTed> +0.8 might need further refinement, but going in the right direction
<markus_sabadello> Wip: Seems like the right direction, but we'll need more time for this.
<markus_sabadello> Wip: Thanks all