First impression from someone who implements lots of Web specs: it reeks of bull crap. I don't see the point in standardising a new URI schema. The example shown at <https://w3c.github.io/did-core/#parts-of-a-did> comes with much expense: verbosity, dereferencing (i.e. network round-trip) to get a document with additional required information and drags in the json-ld spec for no good reason.
If I were in charge of minting identifiers, I would always just use the http URI schema; the controller/verification stuff could be simply appended right there. With just a modicum of care and planning, the URIs will last as long as the Web itself. http://enwp.org/PURLhttp://w3id.org
Imagine you run a community college and want to identify students, but wish to do so in a privacy-preserving manner. Keep in mind you need to identify them from the high schools or other colleges they are transferring from as well as you'll need to identify them to the colleges they transfer to after.
DIDs allow for creating network wide identifiers that can be digitally verified. They work great in conjunction with verifiable credentials. So now you can keep and share records on students using their DID. You can create a unique DID for each student, even a unique id for each record which maps back to the student's DID.
It may not seem like much, but it forms the basis for creating systems where identity can be kept private, even from the individuals administering the system.
It's mentioned in the "How DIDs Differ from Other Globally Unique Identifiers" section.
> The need for globally unique identifiers that do not require a centralized registration authority is not new. UUIDs (Universally Unique Identifiers, also called GUIDs, Globally Unique Identifiers) were developed for this purpose in the 1980s and standardized first by the Open Software Foundation and then by IETF RFC 4122.
> As a rule, however, UUIDs are not globally resolvable and URNs – if resolvable – require a centralized registration authority. In addition, neither UUIDs or URNs inherently address a third characteristic – the ability to cryptographically verify ownership of the identifier.
TLDR: We've used UUIDs for a while now, they're cool and all but don't work in a distributed network as they assume location-addressing to one central, verifying server. Instead, DIDs work via content-addressing, making them more ideal in distributed networks as they're easier to verify.
A lot of time you don't need to identify people, you just need unique accounts. There is no fundamental need to have one identity linked on HN, reddit, Facebook.
Agree! None of these specifications are required to be implemented. They are there to cover the use cases outlined in the specifications themselves, so feel free to pick and chose which ones to follow. Obviously it's better for the open web if you use them when you're implementing something for your use case, rather than coming up with a new specification that is similar but incompatible.
But as you say, if you're implementing something that doesn't require global identifiers in a decentralized/distributed context, don't use DIDs :)
If I were in charge of minting identifiers, I would always just use the http URI schema; the controller/verification stuff could be simply appended right there. With just a modicum of care and planning, the URIs will last as long as the Web itself. http://enwp.org/PURL http://w3id.org