Baseline registration requirement for DID methods

[talltree]

For several weeks now we have danced around the issue of whether the DID Spec Registries editors (hereinafter just "editors") should make any type of judgement about the registration of a new DID method. @brentzundel put an exclamation point on this issue at the end of yesterday's DID WG call when he asked what the downside was to not making any judgement call at all, i.e., why couldn't we just accept any well-formed registration request?

The queue filled immediately with WG members pointing out the downsides of letting the DID Spec Registries fill with "junk" (which I will more charitably refer to as "bad faith registrations").

If indeed we have rough consensus that we want to prevent such degradation in registry quality, it follows that the editors will need to apply some judgement about whether a proposed DID method registration meets the registration criteria or not. Let's call this criteria the baseline registration requirement.

The purpose of this thread is to asynchronously discuss proposals for what the baseline registration requirement should be in the hope that we get far enough to pass a formal proposal on next week's (Dec 6) DID WG call.

I will start discussion off with this proposal:

PROPOSAL: The baseline registration requirements for a DID method registration are:

1. The registration PR (pull request) MUST include:
   1. All required data elements for a DID method registration.
   2. A detailed written self-assessment from the submitters explaining how:
      1. The proposed DID method specification conforms to the baseline requirements for a DID method specification in section 8 of the DID 1.0 specification.
      2. The registration PR conforms to other the registration policies listed in section 3 ("The Registration Process") of the DID Specification Registries.
2. At least two editors MUST agree that—in their good faith judgement—the written self-assessment adequately explains how conformance is achieved.

If the editor's determination is either...

1. That conformance has not been achieved, OR
2. That the written self-assessment does not adequately explain how conformance has been achieved,

...then the editors MUST deny the registration. The editors MAY suggest resubmission of a revised registration that will meet these requirements provided the editors believe the registrant is acting in good faith.

---

Note the new requirement that, in addition to the DID method specification itself (and the registration PR), the submission MUST include the detailed written self-assessment. The whole idea here is to raise the bar by making the registrant do the work to gather and explain the evidence of conformance rather than transferring the work to the editors. That kills two birds with one stone:

1. The registrant has to test their own spec for conformance AND provide their own written explanation satisfactory to the editors.
2. The editors can reject a registration just on the basis of the written self-assessment not being satisfactory. This should seriously limit the burden on the editors and minimize the judgement calls they actually have to make.

[peacekeeper]

What happens if the self-assessment says "this registration is fully conformant", but in fact it isn't?

In any case, whether or not we introduce the self-assessment, I think editors still need to do their own assessment to evaluate basic completeness and conformance of the registration, as they have always done in the past. It is clear that with limited resources this can only be done on a "best effort" basis.

[rxgrant]

A detailed written self-assessment

This could be combined with the earlier idea for an automated checklist of conformance factors, which might help separate the "do we have the resources?" question from the "is this about namespace collision or about acceptance signalling?" question.

As before, I'm inclined to accept critera that can't be abused by editors to censor submissions, but reject uncertain critera that depend on an editor's whim. Spec submissions could work around the intent of any automated tool that aims to offer conformance clarity, but raising the bar on the effort required to submit a conformant specification would still lower the tension surrounding this issue.

If there is a tool then the next question is whether it's fair to change the tool's requirements. I'm not sure this tooling would work, but willing to review submissions that propose it.

[talltree]

What happens if the self-assessment says "this registration is fully conformant", but in fact it isn't?

Then the editors deny the registration (with, optionally, comments on the PR about why the self-assessment is incorrect). The registrant can then decide to fix and resubmit, or abandon.

In any case, whether or not we introduce the self-assessment, I think editors still need to do their own assessment to evaluate basic completeness and conformance of the registration, as they have always done in the past. It is clear that with limited resources this can only be done on a "best effort" basis.

To be clear, the self-assessment is NOT supposed to replace the editors making their judgement call about whether the proposed registration meets the baseline registration requirements. The self-assessment is only to have the registrant to do as much of the work as possible, thus making the editor's job of making the judgement call as easy as possible.

[mprorock]

I think that this may be better left to a future re-charter - not to say that it is not a good topic to discuss, and that that discussion can be ongoing, but I am reticent at this point to add any additional criteria other than the minimal criteria that exists for a basic list of methods that exists today

[iherman]

The issue was discussed in a meeting on 2021-12-07

• no resolutions were taken

View the transcript

#### 4.4. Add `did:id:` method (pr did-spec-registries#363) _See github pull request [did-spec-registries#363](https://github.com/w3c/did-spec-registries/pull/363)._ **Michael Prorock:** 363 the `did:id` method ... fantastic branding and naming. … changes requested from markus. **Markus Sabadello:** I have commented many times on this issue, i think its problematic registration of a centralized did method where the registry is controlled by one company, which is allowed, thats not forbidden.. … another challenge is the name, "id" sounds generic, and its also a "reserved property in the data model"... but that is also allowed.. … personally I feel like the combination of these facts, is potentially a violation of the rules. … it might be more reasonable for it to be named `mastercardid` or `mcid`... there is another requirement regarding privacy and security considerations. … the section does not sufficiently discuss specific threats, specifically the issues related to centralized did methods... I think the PR should be accepted without changes. … should not.. **Michael Prorock:** I think this is a dangerous road to go down, regarding gatekeeping, the company registering this method owns the trademark, I don't see any reason block registration.. **Manu Sporny:** markus there is an option in the current process, that allows us to annotate entries with warnings... if we are concerned we can add warnings... we could annotate the registry entries.... … I don't think we have ever enforced all these rules on registration.. **Markus Sabadello:** first time I heard about the warnings... don't think we have ever done that... we have not approved registrations that do not meet requirements... I think this registration does not meet the requirements.. … I don't see what this has to do with trademarks or value judgement... just requirements. **Orie Steele:** I'm an Editor of this specification, I do think this entry meets the registration requirements to the best of the registrants abilities. I think it meets the requirements. I don't see an alternate path forward other than requesting concrete changes or closing PR, then merging. Markus, I heard you say concretely if they added a couple of sentences to Privacy/Security Considerations, they would meet the registration requirements. What concrete changes. > *Manu Sporny:* would be needed for them to meet requirements?. **Markus Sabadello:** happy to add a comment. **Daniel Burnett:** it may be appropriate for us to annotate entries that the WG has concerns with.... … we can always annotate this entry, we might say something regarding a "trademarked term".... > *Ryan Grant:* +1 to an annotation disclaiming the use of "id". **Daniel Burnett:** so folks have the context regarding this.. > *Manu Sporny:* The registration process currently states -- "Entries that are identified to cause interoperability problems MAY be marked as such at the discretion of the maintainers of this registry, and if possible, after consultation with the entry maintainer.". **Manu Sporny:** I was wrong, we don't have an ability to apply annotate.. … we might be able to update the process to highlight any concerns.. … when people register, we are not applying the did method section consistently... I don't think we can push back on this particular entry for those reasons.. > *Michael Prorock:* I have strong concern on any value judgement in the registry, even if from the WG. **Markus Sabadello:** we have text that says "the normative requirements for a method spec, did methods that don't meet these requirements must not be accepted". … therefore this method should not be accepted... but if they added a few sentences, the PR should be accepted.. > *Michael Prorock:* they have a reasonable privacy section - [https://github.com/Mastercard/did-methods/blob/master/id.md](https://github.com/Mastercard/did-methods/blob/master/id.md) - can those sections be better? yes always, but should that block this PR, likely not. **Orie Steele:** I don't think the DID Spec registries is a "values included" registry -- the registry is about defining terms/methods and a place to find the specs for those. It is not meant for environmental/economic/ concerns -- we shouldn't be annotating specific DID Methods. I do appreciate what Markus said wrt. concrete change requests... if we convey that to them, they'll be able to meet those requirements.. **Drummond Reed:** is there a baseline requirement or not? feels like mastercard registration request is forcing this issue... and we will have to apply this to all entries. > *Justin Richer:* +1 to drummond about there not being a choice but to address this. _See github issue [did-spec-registries#382](https://github.com/w3c/did-spec-registries/issues/382)._ > *Michael Prorock:* +1 text should reflect process. **Manu Sporny:** couple points, markus makes a good point, we can refuse methods that don't meet requirements.... but we have a lot of things to fix then.. … looks like we will need to address this...and we may need to extend past 30 days. **Daniel Burnett:** the 30 day requirement is to avoid the case where nothing happened... its not to force a decision.. > *Manu Sporny:* +1 to burn's reading of what we decided.. **Justin Richer:** I want to push back against this notion that there is an unbiased technology, thats the entire purpose of having a gated registry... we are applying bias every time we do anything.. … I see a lot of well meaning and naive folks.... the WG signed up for this when we agreed to have a registry... we don't need to "de-register".... we can mark things as provisional.... … i am saying, we have solutions to these problems.. > *Manu Sporny:* I think what the group is saying is that we don't want to do /more/ value judgement than we're already doing.. > *Manu Sporny:* (although, that's not coming across in the words people are saying). **Daniel Burnett:** do we need to discuss anything else before we do to rubric?. > *Manu Sporny:* We need to get to issue 382 :). > *Manu Sporny:* We need a resolution for this. > *Drummond Reed:* Yes, we need to do that. **Orie Steele:** I think I mostly agree with what Justin is saying -- we are inherently biased, my bias is to minimize bias -- I want the registry to just be terms and URLs and not spend a lot of time debating whether someone chose a good name for their DID Method.. … The extent to which they implement the normative requirements for the DID Specification, if we apply those rules unevenly, I'm not comfortable with being an Editor. I do have a bias, absolutely, regarding DID Core requirements, they need to be consistently applied. I'm not opposed to deregistering, and not allowing anything else if they don't follow all mandatory requirements in DID Core.. > *Justin Richer:* Orie: you are specifically asking for a lighter hand for this spec to avoid the did core requirements. > if we don't cross t's and dot i's then it's just a bunch of l's and nobody knows what you're saying. > hard disagree with Orie on this point: it is absolutely fair to start making things better now. > it's bugfixing the process. > *Michael Prorock:* +1 orie - consistency is key here. **Orie Steele:** We can't get out of admitting some responsibility out of this registry -- the requirements are subjectively applied -- Editors don't always agree, even if single objection, we won't merge. Concretely speaking, Markus' change suggestion raises the question on "what should we do with these other entries". It's not fair to this author to make changes for the registration process in flight. Or we have to admit we're not being consistent. I'm fine w/. > *Manu Sporny:* saying "we're not consistent", but I won't be an Editor if that's going to be the WG's approach.. **Orie Steele:** I want same rules to be applied to all methods. Or we can accept registrations that make good faith effort. Relax requirements, move value judgement elsewhere. My bias will be contributed to any work I participate in.. **Markus Sabadello:** we should not accept did methods that are not conformant... thats easy.... we should reject all did methods that are not conformant.. … we have to acknowledge that editors are not going to apply these rules consistently, and entries are not all fully conformant... if there is a "known issue" they they should not be accepted or they should be removed.. > *Justin Richer:* +1 -- we don't keep making our old mistakes just because we made them in the past. **Markus Sabadello:** we should remove entries that are not consistent. … or that don't meet the requirements. > *Drummond Reed:* Or we can use a Status label to differentiate between Provisional status and another status reflecting Conformant. > +1 to Markus' point - this is why I'm saying we need to make a decision about issue 382. > This is also why I am suggesting the role of the self-assessment in this process.. > *Manu Sporny:* I'm going to step away as an Editor for this document if we are going to say "DID Method Registrations MUST conform to all DID Method requirements".. > *Ted Thibodeau Jr.:* do we have a disclaimer on the registry, that basically says that users are expected to perform their own due diligence; the registry is just a helpful step on that road?. > *Manu Sporny:* I'm going to step away as an Editor for this document if we are going to say "We are going to unevenly apply registration criteria".. **Daniel Burnett:** looks like no resolution will happen, but we should discuss. … 382. > *Orie Steele:* To be clear, I am also considering resigning over how the WG is choosing to address this issue (382).. **Drummond Reed:** the question comes down to are we going to make a conformance judgement here or not.. … can we introduce registration requirements for a "self assessment"... seems like a useful artifact that we can use to force the folks doing the registration work to make our jobs easier.. … if they don't conform they are not registered.. **Manu Sporny:** the amount of work that is being suggested is not sustainable... checking a did method is conformant is more work than can be done. … we will find even more exceptions and value judgments the more work we as editors to do. **Orie Steele:** Concretely speaking, it sounds like we have two proposals on the table --. … Proposal #1 is to accept this `did:id` method as-is and merge over objections that are asking for more specific objections to DID Core (override Markus). … Proposal #2 -- indeed, all registered DID Methods must be apply to DID Core normative requirements -- analyze each of those methods for normative methods, yes, it'll be a lot of work, but maybe folks want to do that sort of work?. … As an Editor, I'm willing to apply principles consistently -- but I expect no one will want to be an Editor once they see what kind of work that requires. We can wish something, but if we don't have enough people to do the work, it's not going to happen.. > *Drummond Reed:* Agreed, Justin, we just need to decide about the process we will apply. > *Ryan Grant:* -1 to having Orie (and a coeditor) make these judgement without a lot more process set up.. > *Drummond Reed:* We need to have a call dedicated to this topic.. > *Michael Prorock:* +1 rgrant - this kind of thing would require a ton more process setup and definition as a group. **Orie Steele:** This is also going to create a political issue, DID Methods being de-registered are going to be unhappy. I already know of a number of them that don't meet the requirements.. **Daniel Burnett:** I strongly suggest we decide this issue today. > *Drummond Reed:* We don't have to "de-register", we just need to apply a Status tag to registrations.. **Daniel Burnett:** thanks. > *Drummond Reed:* I will not be able to attend next week - on holiday. ---

[selfissued]

The working group has already decided not to assign value judgments to registrations. Therefore, there should be no additional registration column that could be construed by some as a value judgement. We already intentionally deleted the one such column that used to exist.

The only criteria that should be applied is whether there's an actionable definition provided of the item to be registered that meets the normative requirements of the specification. If so, we should register it. If not, not.

I agree with @mprorock that if we want to start imposing value judgements on registrations, we should do so only after rechartering with an explicit mission and reason to do so.

[talltree]

The only criteria that should be applied is whether there's an actionable definition provided of the item to be registered that meets the normative requirements of the specification. If so, we should register it. If not, not.

@selfissued What you just defined in that sentence, Mike, is the "baseline registration requirement" being discussed here. Nothing more, nothing less. The issue has been how much of a burden it will/won't be on the editors to decide whether the "item to be registered" (in this case a DID method specification) meets the normative requirements of the DID 1.0 spec (section 8).

Some in the WG consider that decision to be a "value judgement". Others do not. What's your view on that?

[kdenhartog]

I think it's worth pointing out that while the section 8 requirements set a good base of the structure of a method specification it doesn't delve in any way into the contents necessary to produce a method that can be defined to encourage interoperability between the various specs. For example, a method spec theoretically could require the usage of a particular verification method suite such as JsonWebKey2020 where as another method may require the usage of something like postQuantumCryptoSuite2025. I think this is acceptable and I believe most people would agree with this even if it means that technically the methods aren't quite interchangeable with each other and therefore lack in the ability to be "interoperable" category.

There's also the question of whether what's been defined in the method spec is adequate to meet the requirements defined in section 8.2. For example, is this DID Document Registration section adequate to meet the definition of how to implement the DID Create operation? To me it only defines what happens(the key distinction being how helps you implement the method and what helps you understand the method) and is an example of a method that probably shouldn't have been admitted.

[iherman]

The issue was discussed in a meeting on 2021-12-14

• no resolutions were taken

View the transcript

### 1. Baseline registration requirement for DID methods (issue did-spec-registries#382) _See github issue [did-spec-registries#382](https://github.com/w3c/did-spec-registries/issues/382)._ **Manu Sporny:** Chairs and editors talked about this, we think we can propose something that addresses what we discussed.. … We are effectively wrapping up in the group, doing anything drastic might be not great at the end of the charter.. … There are a couple of requirements from the group.. … Some have said we're uncomfortable with some of the DID methods that are getting in.. … Others have said making a higher level of value judgement might be a large amount of work.. … Some people are saying we should make certain value judgments and we shouldn't allow "bad" methods.. … And then there are variations, e.g. two lists, etc.. … One proposal without strong objections seemed to be: We have a registration process with a checklist. Editors check this on a high level, then allow registrations on a first-come first-serve basis.. … The proposal is to continue to do that in this WG, and then work on something new in the next WG.. … Then we will have a more thorough checklist of things to check.. … We would expand the list into more items.. … Question then is what do we do with the currently registered methods.. … In the new WG, we we tell all DID methods that we are planning to increase the requirements for registrations, to improve the quality. We will give method authors time (e.g. 6 months) to meet the new requirements. Then there will be a warning phase, and then methods will get de-listed from the registry.. … For now, we will continue to do a light check.. **Daniel Burnett:** I believe you covered everything. This is an initial proposal that will be discussed in a new WG.. … This specific proposal is not a mandatory decision, the group will take this up again.. **Ivan Herman:** I have no problem with what was said, I just have the practical fear that memories will fade over Christmas. Manu it would be great to do a PR on the new charter.. > *Manu Sporny:* yes, Ivan, I took an action to do that last week and failed to do so -- it's still on my "to do" list.. **Ivan Herman:** We haven't touched the charter for a long time, but I think this should be in the new charter text.. **Michael Prorock:** Alongside this, we would open an issue on the charter that we will re-visit the registries.. … Also, this would give us time to review registries from a W3C perspective.. **Ivan Herman:** The current charter proposal already refers to the new process, including reference to the registry mechanism.. … We already say it will be a registry per the new process.. **Markus Sabadello:** I also think this is good, so I wouldn't add anything. I agree that we shouldn't make drastic changes or increase burden or workload on anyone, light checking that we've been doing makes sense to continue that.. … The question is still with `did:id` registration, what do we do there... if there is a registration that doesn't meet normative requirements, would we allow it for now or not?. **Manu Sporny:** Taking the case of `did:id`, I think you asked for specific changes, the assumption is we can then merge it if those changes are addressed.. … More generally speaking, we haven't asked many other DID methods to make such changes, do we want to be so stringent?. … Our light checking so far has not been about checking every single normative statement. We believe the vast majority of DID methods don't meet that.. … In a future process, we will require all normative statements to be met.. … If we pull in `did:id` now, we will then revisit it in the future process.. … In that case, the process would address the concern in time, just not immediately.. **Joe Andrieu:** manu were you saying right now the editors shouldn't apply the normative rules? They did that in `did:earth`. **Manu Sporny:** We're trying to apply the same rules to everyone when they register.. … I think there was another issues `did:earth` about it being a meta DID method.. **Joe Andrieu:** It was a better method than many that are currently listed.. **Manu Sporny:** In that case we should have registered it.. … The general question you ask, what are the criteria now, and what should they be in the future.. … Today there is a checklist when you open a PR.. … Many registrations are provisional. Many security+privacy sections are single lines.. … We're saying now we probably should have had a higher bar, and in the future we want a higher bar but also give people plenty of fair notice, and give them several months to improve their method spec.. **Markus Sabadello:** I agree, in the past we have definitely registered DID Methods that don't meet requirements. We have DID Methods that have weaker specifications than some other methods that we may have rejected at some point. There is inconsistencies both ways.. … We have allowed DID Methods that we allowed, we rejected DID Methods that are stronger than some of the other DID Methods. We do have a statement in DID Spec Registries -- new registrations must meet normative requirements, but as Manu mentioned, we haven't applied this consistently. In general, +1 to new process with higher bar in the future. The thing is that if we don't enforce these normative rules, what's the basis on which the. > *Manu Sporny:* Editors allow/reject specifications?. > *Justin Richer:* +1 to enforcing the normative rules. > *Joe Andrieu:* +1 to enforcing the normative rules, across the board. **Markus Sabadello:** If there is a proposed method, like `did:id`, I don't think we should allow it with the current process. We shouldn't increase workload, but if there isn't a registration that meets the requirements, I don't think we should allow it.. **Justin Richer:** It seems the primary issue is that entries that were added to the registry before the registry itself was finished.. … So there is now an expectation that earlier registrations need to be honored in some way and kept in there.. … I think that is an absurd expectation. … I completely understand it's a lot of work to clean up; that said, I agree with Markus that unless the registry is actually following some rules, what's the point. … The structures are here to show that the rules have been followed by someone (the editors themselves). … We should have an additional column for "preregistered" methods.. … Saying that we decided to keep this here, but we are not actually saying they passed a structured review. That can be a boolean.. **Manu Sporny:** On justin_r 's point, we had that field called "provisional". Members of the WG argued to remove it, we had consensus about that.. > *Justin Richer:* those members are wrong and the WG is wrong. **Manu Sporny:** People felt strongly about removing it. That was the "provisional" tag.. … I think the Editors have been consistent with those provisional registrations.. … E.g. are 3 bullet points enough on privacy and security considerations?. … I think there has been consistency with provisional registrations, there was an understanding that such registrations are work-in-progress.. … Everything in the registry today is under the notion that it's provisional.. … Removing existing registrations may not be received well in the community. Doing it right now at the end of the charter would send a wrong signal to the community.. … The suggestion is to continue processing as we have, and then in the next charter we will be applying all normative statements. The community will need time to internalize that.. **Brent Zundel:** Realistically, what we have right now (it's not an official W3C registry), it should be understood that the registry itself is provisional.. … Some registrations were written before some normative requirements existed.. … We plan to transition this note to an official W3C registry. Then all the current, provisional registrations can be transitions, but the time is not now.. **Daniel Burnett:** This amounts to a +1 to the last 2 comments. The proposal is acknowledging the fact that there will be a future version. We need to declare this done, this doesn't mean requirements aren't applied as best as we can, but there is a timing issue.. … It's better to have this happen in the chartered group, rather than to revisit previous registrations.. … But we will everyone know that this is coming and that they have to clean up their methods or be removed.. **Orie Steele:** At this point I'm +1 to the proposal.. … The tendency to say that we need registered methods to be flawless is not going to work, and not consistent with other W3C work.. … I agree strongly with Justin+Markus, but the best time to address that is in the new charter.. … As I read the Web Payments specification, this seems to be the same direction they are taking with identifiers.. … Strongly in favor of addressing this as a proposal in the new charter.. **Joe Andrieu:** I'm really concerned this group thinks is appropriate to apply new rules.. … It's not appropriate for new entries in the space to be treated differently.. > *Manu Sporny:* Agree with Joe's last statement.. > *Justin Richer:* it is entirely appropriate to apply new rules. The world changed.. **dmitri:** I'd like to make a proposal. We were discussing as if we consider that registries have an obligation to be backwards consistent.. … No other registry (IANA etc.) have that requirement. All registries have forward consistency, but no backward consistency. … My reluctant counter proposal is what if we don't wait until rechartering and just reenforce the fact that if a WG comes to a new criteria decision, it should be applied to new registrations including those that are in PR right now.. **Markus Sabadello:** I'm also not favor at this point to revisit any existing registrations and we shouldn't introduce new columns, tags, or lists, or change the process. I'm supportive of Manu's proposal, we should do all of that in a new Charter, that sounds really good, so I fully support that.. … I like what Dmitri said, in new charter, in general it could be appropriate to allow what Dmitri said, allow new criteria to come up and apply to new registrations. We did have this discussion about method names, being indicative of what a Method does or how an infrastructure works. New requirements could come up over time that could apply to new registrations.. … I like what Manu said and what Dmitri said.. **Brent Zundel:** Can we have a decision now, or do we need more time to discuss this?. **Joe Andrieu:** I like what dmitri said about forward compatibility.. … Manu do you mean new registrations?. **Manu Sporny:** Yes. **dmitri:** Just to clarify, `did:id` is a new registration, or accepted?. **Manu Sporny:** New, currently in process. > *Orie Steele:* Please review `did:object` as well : [https://github.com/w3c/did-spec-registries/pull/383](https://github.com/w3c/did-spec-registries/pull/383). **Manu Sporny:** If this proposal passes, we will process `did:id` under the same rules as in the past. **Markus Sabadello:** I think this proposal is good. I think we should pass that.. … I don't think it means we will accept `did:id` as it is right now without the requested changes, so I don't think it changes anything about whether we should support this proposal.. **Joe Andrieu:** Is the current process to check conformance of all statements?. **Manu Sporny:** No, we have never done that for any other DID method to date. So we would continue to not do that until we have a new WG.. … There is a checklist currently when you register a new method. If you can't check each one of them, you can't be registered.. … The problem is that you can look at these, and one person could say you meet the requirements, and another person could say you don't meet them.. … With `did:earth` I think there is a misunderstanding.. **Joe Andrieu:** It definitely got a different review that it would have gotten 6 months ago.. … what's the checklist and how do we adjust it?. > *Ryan Grant:* i need a link to the checklist. **Orie Steele:** There is a link in IRC to a method that has the checklist checked. **Manu Sporny:** That list is what we had consensus on in the group. If we wanted to change that, the group would have to have a discussion and come to consensus. **Joe Andrieu:** Are there conformance requirements in the spec that are not in checklist?. **Manu Sporny:** Yes. … Markus is pointing to some older text that says you have to meet all normative requirements in DID Core.. **Joe Andrieu:** Just trying to understand the gap between what's in the spec, and what's in our current process. **Manu Sporny:** Dmitri do you want to write down your counter-proposal.. > *Joe Andrieu:* +1 to supporting manu's registration proposal given the checklist. > *Manu Sporny:* JoeAndrieu -- this section contains the normative statements IN ADDITION TO what's currently required for registration -- [https://w3c.github.io/did-core/#methods](https://w3c.github.io/did-core/#methods). **Brent Zundel:** Any suggested changes to the first proposal?. > *Joe Andrieu:* I care, Justin. **Justin Richer:** A lot of comments are about "we can't apply this, because we haven't done it in the past". The mistakes of the past should be learned from, not repeated.. … dmitri's proposal is functionally the same as mine, with slightly different flavor. **Joe Andrieu:** Those are slightly different. **dmitri:** I think there's a slight difference in that mine introduces new criteria.. > *Justin Richer:* the difference JoeAndrieu points out is not intentional, I agree with Dmitri's details. **dmitri:** manu's proposal is apply normative criteria after the new charter.. > *Joe Andrieu:* mprorock's is good for me too. **Manu Sporny:** My understanding of your proposal is we would de-register everything. **dmitri:** No, just going forward. We would have more stringent criteria for `did:id` and future registrations.. **Justin Richer:** I agree with dmitri's point that we need to apply the rules about conformance and compliance now, and we cannot sit on this stance "oh well we allowed everything in, so we also have to do it now". … Ultimately it's about being useful to the people reading the registry.. **Joe Andrieu:** I do think there is general consensus for moving forward with regard to not apply the current rules to new registrations. … If we were to start applying conformance requirements now, that would be a huge change to the process. > *Justin Richer:* I am not asking to not do that.. **Joe Andrieu:** justin_r says use the registry process which will change. … I don't think there is support for going to conformance right now. **Daniel Burnett:** We need to decide what we do now, not decide what the future group will do. … I believe we can reach consensus on applying today's rules. … The next group may change the rules. **dmitri:** I agree with burn and ivan said. Should we suspend adding new methods while in maintenance mode?. > *Joe Andrieu:* -1 to altering the entire registry process at this point. > *Manu Sporny:* agree. > *Justin Richer:* +1 to that -- if the group is going to punt everything to the next group anyway we should. > *Manu Sporny:* -1 to altering the registration process at this point in time... in the future, sure.. > *Daniel Burnett:* -1 for pausing registrations or changing the current process. > *Brent Zundel:* -1 to altering the process right now. > *Joe Andrieu:* Operating the registry doesn't need a WG. Only changes to process need a WG.. > *Brent Zundel:* -1 to suspending. > *Ryan Grant:* +1 to a consistent punt. > *Manu Sporny:* Happy holidays folks! :). **Brent Zundel:** During the discussion there were several points where it seemed we were close to consensus.. **Brent Zundel:** Conversation can continue in the Github issues.. … Happy holidays, thanks to all scribes, it's a pleasure working with all of you, see you next year!. ---