TL;DR it remains to be seen if DIDs create more problems than they solve. I think you got it correctly. "DID" is basically a qualifier for identifiers which ca

TL;DR it remains to be seen if DIDs create more problems than they solve. I think you got it correctly. "DID" is basically a qualifier for identifiers which can have metadata resolved about them using 'some mechanism', and there are 100+ mechanisms (DID methods). These all have varying technical and non-technical differentiating factors, partially described in the DID Rubrick https://w3c.github.io/did-rubric/ https://w3c.github.io/did-rubric/ . DID methods will not have consistent features nor will the metadata resolved by them consistently meet your data requirements, so you will be limited both in terms of methods you can accept for your use case, and DIDs you can accept within that. One if the base ideas is that it puts users in control of their identity by "owning" a DID, presumably with a lot of local software assistance. This is likely not a single DID, both for interoperability and privacy reasons. It is also likely the DID will be "controlled" by others in some cases - e.g. if a employer or bank accepts DIDs as an authentication system, they will want to be able to guarantee the authentication meets their standards/regulatory requirements.