DID's claim to be truly decentralized is not quite accurate. Its methods registry needs to be managed (it should be) to insure that methods are globally unique. Without this, DIDs would not be able guaranteed unique as methods could be duplicated across multiple DID providers. The method registry is no different from a DNS name and it seems that they will used as branding with all the disadvantage that this entails when you try to guarantee persistence. DID claims to be persistent but persistence is not a really a technical issue (unless you have a really bad design (ex: URIs and brand names in DNS…). Persistence is mostly a product of social and organizational contracts. These social contracts need to be public and their policies known for them to be trusted. DID does not (yet) require social contract between DID providers. When a DID provider fails there will be a very high chance for all the DID's under that provider to disappear. Because of the method, it is unlikely that other providers with difference methods would claim that other company’s method. Because there is an explosion of DID methods, there will be a commensurate explosion of non-persistent DIDs. In many respects DIDs do not solve the good old URLs 404 problem from 30 years ago. DIDs are mostly a naming convention with the addition of a specific data model which is too complicated for its own good. The specific technical approach for storing the ID is inconsequential from a user's perspective. Blockchain, SQL, gerbils spinning wheels.... Do you care what DB amazon uses? No, you care about the services it provides. In the end, why pick a DID provider over another? Price, availability, performance, and consistency. If your DID service provider fails, you made a mistake in your DID provider selection process. Clearly not all DID will be the same which means that DIDs does not solve the persistence problem. Organizations have been using DOIs (Based on the Handle System technology) for a long time for their persistence. With DOIs there is a social contract for persistence and a guarantee that a failure of one provider will result in that provider’s DOIs (handles) to be taken up by the other DOI members. The handle system (an implementation of DO-IRPV3.0 standard which invalidated RFC 3650, 3651, and 3652) has pioneered many of DID's features but purposely remained generic in nature to maximize its ability to be used for something else. The handle system It can easily incorporate the DID data model and could easily be integrated as a DID. T The DONA Foundation operates the Global Handle Registry in collaboration with a set of global Multi-Primary-Administrators which are exclusively responsible for managing their names space. (Cryptographic validations of each namespace operation are required but the MPA who has credentials to do so). The GHR is NOT centralized. In the future, we can already predict that there will be many non-resolvable DID as the same issues that affect URIs will affect DIDs. Moving forward that it could be that DIDs will be equated with broken unreliable identifiers. A system is only as reliable as its weakest chain and DIDs are as weak as their weakest method provider. In future, like todays persistent URI, the DIDs that will continue to work reliably with be those based on the handle system identifiers such as DOIs, EIDRs, as well as other identifiers run by large corporations and government that have either social contracts for the long term. While imitation is the nicest of compliment, it took W3C 20 years to admit that URL/URIs do not cut it when it comes to PIDs. It is disappointing that W3C's internal politics prevented it to work with CNRI decades ago when they did not want to have anything to do with the Handle System as it was an non URL compliant system (Because of the intrinsic limitations of the URL RFC and URI RFCs). Unfortunately, it seems that this lack of interest in collaborating with organizations that have a proven track record of persistence for that last 20 year is still prevalent. That is a shame.
![[DRAGON BALL LEGENDS REVEALS ＆ STUFF] LEGENDS FESTIVAL 2024 Special Edition Part 2](http://i.ytimg.com/vi/af0phKxitX8/mqdefault.jpg)
Thank you so much for such a clear description!
Thank you. Very helpful.
Do you have any example repos for demo DID?
Thank you, this is very helpful!
Thank you Ivan
Really clear!! Thank you Ivan
Excellent ! Thank you Ivan
DID's claim to be truly decentralized is not quite accurate. Its methods registry needs to be managed (it should be) to insure that methods are globally unique. Without this, DIDs would not be able guaranteed unique as methods could be duplicated across multiple DID providers. The method registry is no different from a DNS name and it seems that they will used as branding with all the disadvantage that this entails when you try to guarantee persistence.
DID claims to be persistent but persistence is not a really a technical issue (unless you have a really bad design (ex: URIs and brand names in DNS…). Persistence is mostly a product of social and organizational contracts. These social contracts need to be public and their policies known for them to be trusted.
DID does not (yet) require social contract between DID providers. When a DID provider fails there will be a very high chance for all the DID's under that provider to disappear. Because of the method, it is unlikely that other providers with difference methods would claim that other company’s method.
Because there is an explosion of DID methods, there will be a commensurate explosion of non-persistent DIDs.
In many respects DIDs do not solve the good old URLs 404 problem from 30 years ago. DIDs are mostly a naming convention with the addition of a specific data model which is too complicated for its own good.
The specific technical approach for storing the ID is inconsequential from a user's perspective. Blockchain, SQL, gerbils spinning wheels.... Do you care what DB amazon uses? No, you care about the services it provides. In the end, why pick a DID provider over another? Price, availability, performance, and consistency.
If your DID service provider fails, you made a mistake in your DID provider selection process. Clearly not all DID will be the same which means that DIDs does not solve the persistence problem.
Organizations have been using DOIs (Based on the Handle System technology) for a long time for their persistence. With DOIs there is a social contract for persistence and a guarantee that a failure of one provider will result in that provider’s DOIs (handles) to be taken up by the other DOI members.
The handle system (an implementation of DO-IRPV3.0 standard which invalidated RFC 3650, 3651, and 3652) has pioneered many of DID's features but purposely remained generic in nature to maximize its ability to be used for something else. The handle system It can easily incorporate the DID data model and could easily be integrated as a DID. T
The DONA Foundation operates the Global Handle Registry in collaboration with a set of global Multi-Primary-Administrators which are exclusively responsible for managing their names space. (Cryptographic validations of each namespace operation are required but the MPA who has credentials to do so). The GHR is NOT centralized.
In the future, we can already predict that there will be many non-resolvable DID as the same issues that affect URIs will affect DIDs. Moving forward that it could be that DIDs will be equated with broken unreliable identifiers. A system is only as reliable as its weakest chain and DIDs are as weak as their weakest method provider.
In future, like todays persistent URI, the DIDs that will continue to work reliably with be those based on the handle system identifiers such as DOIs, EIDRs, as well as other identifiers run by large corporations and government that have either social contracts for the long term.
While imitation is the nicest of compliment, it took W3C 20 years to admit that URL/URIs do not cut it when it comes to PIDs. It is disappointing that W3C's internal politics prevented it to work with CNRI decades ago when they did not want to have anything to do with the Handle System as it was an non URL compliant system (Because of the intrinsic limitations of the URL RFC and URI RFCs). Unfortunately, it seems that this lack of interest in collaborating with organizations that have a proven track record of persistence for that last 20 year is still prevalent. That is a shame.
Thank you
does it really have to be "decentralized" if once chooses not to implement it using the DLT/IPFS etc... ?
You can pick any method on the spectrum of centralization.
awesome