It's such a bad spec it'll never be implemented by anyone

In a round about way W3C successfully did the opposite of what they claimed they where trying to do, killing the entire concept and ensuring it won't ever actually happen

That's the list of methods; and yes, there is very much a land grab going on right now.

No, there's nothing stopping you making your own methods. But will anyone actually use it?

So if I’m building a service that lets somebody login with a DID, and I’m using a DID library to verify your authN then that library needs a different code block for every one of those methods?? LOL. What could possibly go wrong? Or less sarcastically, how could this possibly be expected to work?

Yeah DID is a dumpster fire. It's a consulting company's dream spec. Anything is possible but almost nothing is required. It smells a bit like SAML all over again, wherein they try to satisfy every stakeholder and end up satisfying none.

To be fair, SAML was a victory at the time - in that they could even get the parties involved to agree to come to the table and write specs and agree to implement them.

IMHO, such consensus work improved in quality for a while after the WS-* dumpster fire was put out by JSON.

Oh 100% SAML over WS-*. At least SAML can be made to work across vendors. I've never seen anything WS work outside of MSFT products.

"that library needs a different code block for every one of those methods"

Yes, and that is trusted code - even with isolation, an compromise of that method's resolution code would result in malicious parties being able to impersonate anyone else using that method.

There are use cases where you don't want correlation, in which case the decentralized identifier might exist only for you to log into a single web site. At that point, it might be easier to use a method like did:key or did:jwk which encode all of their information into the URL itself, and forego the ability to rotate or revoke keys.

> there is very much a land grab going on right now.

Where and how?

Edit: I just saw the list. It's very land grabby feeling.

Where is the list?

That method registry is simply self-service way to register DID methods, so it functions like the latter -- "known" methods.

There's no editorial/curation aspect to this registry; that's out of scope. The requirements are simply basic DID method conformance -- specify how the create/read/update/write methods are implemented, security considerations, and so on.

The land grab concern you mention is real, but would likely not be addressed at this level (again, it would be considered out of scope), but could happen in a different standards group.

Some relevant work includes defining criteria by which to evaluate DID methods -- i.e., does it support update operations (e.g., did:key doesn't), does it rely on a blockchain and if so, is it permissioned, and numerous other factors. Probably the most comprehensive treatment of these are the DID method Rubric [1]

With Verite, our considerations were mostly around no/low cost, interoperable/open source implementations for the open source implementation (although anyone can use any method they like). The ones we're most likely to add open source implementations for next are did:pkh and did:ion.

[1] https://www.w3.org/TR/did-rubric

[2] https://verite.id/verite/patterns/identifier