– DRAFT –
DID Methods WG Charter Discussion

Wip: the goal is to discuss about the proposed charter for a DID Methods WG

<Wip> https://www.w3.org/2024/04/did-wg-charter.html

Wip: let's start with introductions

[everyone states their name, their affiliation and the place where they come from]
… who wants to start the conversation?

<msporny__> Here's the charter: https://w3c.github.io/did-methods-wg-charter/2025/did-methods-wg.html

msporny__: the DID WG is finalizing DID Core 1.1 and DID Resolution
… we made the concious decision to standardize any DID method in that WG, only the core mechanisms of all DID methods
… this charter, on the other hand, is focusing on a set of specific DID methods
… we heard that standard DID methods may help the adoption of DIDs
… we heard that from some W3C members who were unhappy that the 1st WG didn't do it
… and also from members who considered that the lack of standard methods was hurting DID adoption
… the charter has 3 proposed deliverable, with 3 categories of DID methods
… first one is "ephemeral DID method", which is a bad name for this
… it is for a method that does not have any external registry, the DID document is generated solely from the content of the DID
… usually they should be used for a short time; sometimes they can be for longer (with hardware binding)
… the second one is based on Web technology, with several input documents
… I don't think we will standardize all of them, but we will take good things from them and standardize probably just one
… [lists the input documents]
… the third one is "fully decentralized DID method", such as webdh, peer...
… there are the 3 general classes of DID methods proposed by the charter
… the WG will publish a global standard for at least one of each type
… that's basically it, the rest of it is largely boilerplate
… liaison, success criteria (2 implementations and test suite), decision process
… we have some concerns about the charter which we should discuss now

shigeya: I notice that webvh and scid are in both "web-based" and "fully decentralized", is it intended?

msporny__: good point, we didn't know exactly where to classify them

<Zakim> JoeAndrieu, you wanted to ask about decentralized "using web technology"

msporny__: note that they are not fully specified yet, there is still work to do
… it comes down to how we define "web based" and "fully decentralized"

JoeAndrieu: did:peer is fully decentralized, and does not use any Web technology, unless we adopt a very broad definition of Web technology

msporny__: it is meant to be very very broad; URIs are Web technology...

jay: do you intentionally limit the number of methods to 3, or could it grow to more in the future?

msporny__: the charter says that the WG will create at least one of each type, so it may be more than 3
… it is meant to give the WG flexibility on exactatly how many methods it creates

markus_sabadello: my understanding of the language "web technology" is also broad.
… It does not have to use HTTP.

tidoust: editorial comment: we are usually bad at "expected completion dates", but these ones are extremely optimistic, you might want to connect more
… also the text is not very clear that it is "one *or more*" method of which category.

denkeni: what about prioritization of the different methods?
… we have one input document for "ephemeral", but much more for the other ones

msporny__: to tidoust, the timelines are incredibly aggressive, partly because these work have been incubated for a long time
… did:key is almost ready, we can publish a FPWD straight away and have 10 implementations
… to denkeni, the expectation is that the WG will set priorities when starting
… we expect several subgroups to work on each category
… I agree that it will be hard to decide what features to include first

<Zakim> JoeAndrieu, you wanted to ask about selection mechanism

JoeAndrieu: I think it would be good to put in the charter the mechanism for deciding about this

<Zakim> shigeya, you wanted to ask why categorization is necessary

JoeAndrieu: concensus is going hard to find, we should cogitate about how to do that

shigeya: classifying DID methods is hard

<Zakim> msporny__, you wanted to speak to the categories and to speak to "how we choose" each DID Method

shigeya: maybe we need more specific categories. Where do these 3 categories come from?

msporny__: we went through this in the DIF, it took us months to come us with these categories
… they are not perfect, but they felt easy enough to understand
… to JoeAndrieu's point, I agree that we should cogitate about how we pick DID methods,
… but I'm not sure what language could convey that
… It could happen that people disagreeing with a given feature will object to the work being moved to Recommendation, or slow down the work
… if something is deeply centralized, I would expect some objection
… I'm guessing we can leave it to WG dynamics to figure out that, with the drawback that it might slow down the WG on controversial languages
… concrete language could be useful at this point, but I don't know what concrete language to put

dezell: a question and a suggestion.
… question: how controversial is this? I know that it was highly controversial for the DID WG.
… suggestion: we are exposing ourselves to criticism by having the same names in two categories. We should put them somewhere else.

chunming: in the DID methods registries, we have several methods linked to a particular ID system. Another question is, is there any chance for other DID methods in the registry to be brought into discussion of this WG?

<Zakim> JoeAndrieu, you wanted to suggest language like rank order voting

chunming: we don't have a category for them. those are quite centralized, do we want to discourage them?

<Zakim> msporny__, you wanted to note fully centralized method would probably fail to get adopted.

JoeAndrieu: my proposal for language about the methods is "rank order voting"

msporny__: I like dezell's suggestion to move out the input documents from the categories
… we should anticipate the possible objections to rank order voting. Some people may formerly object to the #1 choice.
… to chunming's question: I expect immediate objection for full centralized DID methods
… but if there is a DID method that has a fair amount of deployment, we should consider putting it in the list
… consider the did:plc (Bluesky), it has several million DIDs out there, but it is not on the list...

identitywoman: could we just put it on the list? why not?

chunming: it would be good to have a process to bring new DID methods to bring into our group

JoeAndrieu: I think chunming's right, the purpose is not to restrict the WG to this list
… the language should be improved

pchampin: I think it's good to consider -- not a closed list, but also don't want to give impression that this WG is the only place where DID Methods can be standardized. This group is not creating the only valid DID Methods.

msporny__: +1 to that
… other things that we would change in the charter: "this is an non-exhaustive list of input documents"
… there are IPR issues, though
… if after 1 year we adopt a new specification, some members may object "I didn't sign up to standardize this method"

<Zakim> denkeni, you wanted to comment on the selection criteria and inclusion for more DID methods

<denkeni> https://github.com/decentralized-identity/did-methods/tree/main/selection-criteria

denkeni: above is a link from DIF, about selection criteria
… this can be used for later reference
… msporny__ mentioned a long discussion in DIF
… if we want to standardize methods developed in other places (such as DIF) we need people from these places

JoeAndrieu: I appreciate my IPR issue.
… There are a few things that I don't like about the charter, one of them is that it is up to the group to chose what method will come out of it.
… One solution would be to name the methods specifically in the charter.
… The FPWD is what triggers the IPR process.

Wip: I expect that people will show up in the group based on whether their favorite DID method is going to be picked up by the group

msporny__: well, the way things get done in WG is when people do the work
… this is a natural selection process
… the rank order voting is a first signal
… I like JoeAndrieu's answer to the IPR issue that it will trigger when the FPWD is done.
… So the charter feels well balanced to me.

Wip: we have until 12:30, what's our goal.
… Is there consensus on the charter? Objections?

JoeAndrieu: I do have a number of issues.
… I would like the output DID methods to be explicitly named, to make IPR clearer.

<jay4> nick jay

JoeAndrieu: I also don't like that the group is chartered for several methods. We had this discussion in the DID WG.
… Finally, I don't think any web-based DID method fits the bill for DIDs.

msporny__: which of these objections will lead to formal objections on the charter?

msporny__: which of these objections will lead to formal objections on the charter?
… would it address it if we named exactly one DID method in each category?
… Or does the FPWD process address your IPR issue?

JoeAndrieu: we both had a long discussion yesterday, I'm still thinking about it, so I don't have a strong response now.

pchampin: the WG is not going to rubber stamp the input documents anyway, so naming only one does not even solve the problem

markus_sabadello: to comment on the concern about multiple DID methods in the WG risking to contaminate each other
… not everyone in the WG has to work on all DID methods, there can be some logical separation in the group, alternating schedule...

JoeAndrieu: regarding IPR, it is healthier in the W3C process to get FOs from the AC now rather than after 3 years of work
… we are avoiding them by not naming the methods now

msporny__: the way to do that would be to name those methods explicitly
… I agree that waiting for FOs is not great if we anticipate they are coming
… do we believe that the WG will work on anything else?
… I'm hesitant to say that the WG will happily adopt any new DID method that comes later, there is momentum when the group starts
… It is possible, but not an easy thing

pchampin: A suggestion -- could we name one main input document in each category -- and then list a few others as good for input documents.

<denkeni> +1 to pchampin

pchampin: Maybe we have documents popping out in different places -- second category might be difficult (web-based) -- maybe this is a good middle ground?

msporny__: that is where we started, and it quickly got ugly
… there are people with competing choices
… this is actually the best we could get to

<Zakim> JoeAndrieu, you wanted to suggest more time

JoeAndrieu: +1 to the note of the potential difficulty of getting a new method in
… deadlines are sometimes used to cut short discussions, so adding more time to the charter can help

msporny__: I agree, but some AC reps don't like long charters
… rechartering is always an option
… 2 years is the standard duration nowadays

<Zakim> denkeni, you wanted to suggest to pick one ephemeral DID Method and one fully decentralized DID Method, leave others for parallel task forces

denkeni: following pchampin's suggestion, it seems that there would be more consensus about picking a main method for "ephemeral" and "fully decentralized"
… then go for parallel work for "web-based"
… this would help us fullfill the promise of delivering 3

Wip: to JoeAndrieu's 3rd point, about web-based DID method, what can be done?

JoeAndrieu: as long as there is domain binding, we don't have a decentralized identifier.
… and without domain binding, this is not a web-based DID methods.
… We do have another kind of identifiers: Controlled Identifiers (CID -- I think the "C" stands for "centralized")
… If anything, this should be part of CID 2.0

identitywoman: if I want to create a DID based on a blockchain, I still need to pay some money

JoeAndrieu: it is not about paying money, it is about paying it to a blessed party

msporny__: IIUC, the only way out of a FO from Legendary Requirements is to not have web-based methods in the charter, right?

JoeAndrieu: currently yes.

<Zakim> jay, you wanted to ask the decision process for clear understanding

jay4: I want to know what the best way is to select the appropriate DID method?

msporny__: if your question is "are we going to categorize all of the 200+ methods in the registry", the answer is no.
… if we were to do that, we would be asking for the people registering the DID method to do the categorizing.
… there is some work at DIF around "DID traits". Also JoeAndrieu's work on the DID Rubric.

<Zakim> JoeAndrieu, you wanted to mention did traits and rubric

msporny__: but not one of this WG's tasks.

JoeAndrieu: +1, DID traits would help us categorize DID methods.
… We have had good progress on the DID traits and the DID rubric.
… So that DID traits could be used to filter and sort the DID methods registry.
… Wip has been driving this work in our company.

Wip: we are a system almost ready. The harder part will be to integrate it with the did-extension registry.

msporny__: to go back on the list of objections
… we may be ok on the IPR thing (TBD)
… the web-based objection is a hard one.
… about last one (multiple methods), the rationale was that there is a limited amount of people working on these topics, and a limit amount of staff resource
… those are the driving reasons; in an ideal world we could split it, although I'm not convinced that splitting the expertise is the way to go
… I do agree that the negative outcome may be to give the impression that this is the only place where DID methods can be standardized
… based on that, are those concerns leading to FOs

JoeAndrieu: not sure yet, actually some of your explanations made things worse.
… I don't think it is good for a handful of expert to decide which methods to build.

msporny__: one of the things that gives value to our work is the sharing of ideas.
… what you see as a negative I see as a positive.

identitywoman: one challenge of decentralized identifiers is legibility.
… do institutions and groups who may adopt this technology understand it?
… one of the things this WG is trying to address is legibility.
… for centralized institution who may fully or partly adopt these technologies, this is useful.
… having a group of people working on legibility for multiple DID methods is a good thing

JoeAndrieu: I agree that having multiple people sharing ideas is good.
… What I think is the bad things is votes. I've been contacted to people proposing to support my DID method if I supported theirs.

msporny__: I agree, but I don't see an alternative. Splitting the group is not solving the problem.
… A single group will have higher chance of success.

JoeAndrieu: I appreciate that you don't like the splitting, but you are actually making the point that it is a better option.

identitywoman: I was in another WG meeting this morning, and they got the name of Decentralized Identifiers wrong.
… Not that it is our job, but we should think about clear communication of technology.
… Beyond standardizing these things, let's think about making things known.

pchampin: At this point we ave a charter proposal, all issues but one are closed. Only remaining issue is more of discussion that call sfor action.

pchampin: a number of isues were opened during this meeting, so we have checked all the boxes to send the charter to the AC review now -- I need green light from people on team; heard about changes during call right now -- and then I'm a bit concerned now because depending on how deep changes are made, we did not invalidate horizonta review that happened before?

pchampin: If we change order - move input documents into separate place will cause an issue. Minor change, not concerning.

pchampin: What else do we need to do?

Manu: Ranked choice voting mention?

pchampin: I can push button and send to AC Review

Wip: There are possible objections on the charter.

pchampin: Joe, we've had the discussion on the charter before so I think the disagreement is clear, can write that up to W3C Council to see if objection stands or is overridden. I think we can do that quite quickly after AC Review -- if this is the only objection we get, it might move more quickly.

Wip: This is the end of this meeting, we won't be meeting after lunch.