minimum did method requirements are useless

[kdenhartog]

I've seen on more than a half dozen submissions for method registration state the following as their only privacy considerations:

 - All stored data in the DID Document is considered public.
 - A DID document does not include any personal information about the user.
 - The DID controller is fully responsible for the operations applied to their DIDs and DID documents.

While this does meet the bare minimum of defining a "privacy considerations" section it's doing just that only advocating for a bare minimum which is basically just a restatement of what's already being stated in the did-core spec. Specs aren't actually aligning to the spirit of this section which is to help implementors (that is the primary audience of the method specs right?) make tradeoff decisions on how to implement more or less privacy depending on the use case they're focused on. For that matter most of this methods aren't even trying to help implementers make a second implementation and instead advocate for just using some specific REST endpoint or some specific SDK.

I think we should do either one of two things:

1. Remove the privacy considerations requirements
2. State more clearly what the purpose of the privacy consideration is about and have a slightly higher amount of scrutiny for method registration.

Given we've had this debate numerous times from different angles and consistently every time we end up on "no more requirements" I'm thinking number 1 is the option that will be the final resting position of the WG. I think that's the wrong direction personally seeing how this strategy is actually working, but I figure that's the most likely will of the WG. Most WG members tend to think the "market" will advocate for better privacy controls, but it's become very clear to me that we're not seeing an emergence of better did methods that are more feature rich and adhering to strong principles (security/privacy/self-sovereignty/etc). Even the methods that are stabilised aren't really improving or making large leaps forward in terms of new features or improvements to their methods. In fact the opposite has happened over the past 5+ years since the draft report began to be worked on. Most of the methods that have the largest number of implementations, deployed instances, and users utilizing the method are the ones with either the largest historical running period or with large branding behind them. Nothing wrong with that, but I don't think the "market" is behaving how we actually expected it would.

In any case, we've not seen massive growth in this area and instead have seen an over-saturation of repetitive methods restating the same things, setting common requirements of defining around particular sdks or implementations, and overall not pushing the market forward in any meaningful way nor creating a greater level of competition in the space.

So at this point I'm left with the question, Why are we even setting requirements at all? I am, as an editor of the did-spec-registries, essentially just rubber stamping methods here that don't actually pass my smell test of a good method. But this is what the WG has approved so that's the path I take. I'd guess the other editors are basically doing the same thing too. Furthermore, if method authors took the time to see some of the suggested improvements the editors have put on previous reviews it would actually push things forward and we'd not be left asking for the same bare minimum requirements to be made on numerous separate methods.

So should we just get rid of all the requirements all together or is it time that we start pushing methods in the right direction since the "market base approach" doesn't seem to be working?

[peacekeeper]

While this does meet the bare minimum of defining a "privacy considerations" section

Since the did:id debate, I don't really know anymore what the "bare minimum" is for acceptance of new methods into the registry? I thought DID methods have to be DID Core compliant, but that wasn't required in that particular case.

Many of the privacy considerations sections we see don't actually say anything about the privacy aspects of the DID method, such as the did:id one or the copy&paste sections you mentioned. Such methods should not be accepted into the registry, just like DID methods with an invalid DID syntax definition section should not be accepted.

DID Core has clear requirements for DID method specifications. Those should be the "minimum requirements". It's really confusing that apparently there is some other arbitrary, nebulous concept of "minimum bar" for acceptance which isn't defined anywhere.

the "market" will advocate for better privacy controls

Definitely not. Again, as we have seen with did:id, some parts of the "market" don't care about privacy and just want to get their DID methods listed for marketing reasons.

Why are we even setting requirements at all?

We set requirements for syntax, method operations, security and privacy considerations, so that we get useful, interoperable DID methods. Removing requirements for DID methods really makes no sense to me.

[TallTed]

The Privacy Considerations, as with several other sections, are meant to help potential deployers of DID methods apply the DID Rubric to the DID methods under consideration. The bullets you quoted suggest "there is zero privacy in this method", and any other method under consideration that suggests "there is some privacy in this method" should rank higher in the Privacy section of the Rubric, but may well rank lower in other sections that are more important to some deployers (including the registrant of this method).

[kdenhartog]

It's really confusing that apparently there is some other arbitrary, nebulous concept of "minimum bar" for acceptance which isn't defined anywhere.

It's basically become

1. Does this method define all the appropriate sections?
2. Do all the sections reasonably help me to figure out how to use the method (not how to build an implementation of the method)?

[Tweeddalex]

@kdenhartog one of the next work items we want to start working on at ToIP Utility Foundry Working Group is looking at defining minimum privacy requirements and guidelines regarding DID Methods, Layer 1 Utilities and what can be written to the ledger. I worked on a document in 2020 on this topic - and we are planning to begin reworking/updating this into a more robust set of requirements for a ToIP compliant Layer 1, alongside the latest legal guidance and regulatory changes. I think this could align closely with strengthening the Privacy Requirements raised here: https://docs.google.com/document/d/11KkdraiY9oASjU-H91MGxJ7-mNyhnCsfNSG4MFq8Qec/edit#

[kdenhartog]

Sorry, I don't think that accounts for the purpose of this personally. Doing things elsewhere is useful, but this is specifically about setting the minimum requirements for registration in this W3C note.

As noted by The Registry Track we need to be defining these things. @peacekeeper points out that we did some aspects correctly where we defined them but encountered a lot of push back on the enforcement which led to where we're at today. Had we had and followed that process from the outset, we would have made this much easier. But alas, we're stuck with what we've got because the WG decided to go a different route and now it's much harder to get this registry back on track in my opinion.