Better imho to ask: what user problem is DID solving?
Because: if it's truly decentralized then there's no need to publish it. But publication is a core aspect of DID. That it must be published is a jedi mind trick that allows in "on a blockchain". Now we see the real problem being solved (not a user problem): need something published on a blockchain.
Decentralization | Eliminate the requirement for centralized authorities or single point failure in identifier management, including the registration of globally unique identifiers, public verification keys, services, and other information.
Control | Give entities, both human and non-human, the power to directly control their digital identifiers without the need to rely on external authorities.
Privacy | Enable entities to control the privacy of their information, including minimal, selective, and progressive disclosure of attributes or other data.
Security | Enable sufficient security for requesting parties to depend on DID documents for their required level of assurance.
Proof-based | Enable DID controllers to provide cryptographic proof when interacting with other entities.
Discoverability | Make it possible for entities to discover DIDs for other entities, to learn more about or interact with those entities.
Interoperability | Use interoperable standards so DID infrastructure can make use of existing tools and software libraries designed for interoperability.
Portability | Be system- and network-independent and enable entities to use their digital identifiers with any system that supports DIDs and DID methods.
Simplicity | Favor a reduced set of simple features to make the technology easier to understand, implement, and deploy.
Extensibility | Where possible, enable extensibility provided it does not greatly hinder interoperability, portability, or simplicity.
In short, if the large platforms like Facebook, Google, Apple, Microsoft et al started using DIDs, we could start using logins across platforms instead of creating new accounts for each one.
Basically, the specification is trying to come up with a way of offering federated authentication ala OpenID, but without locking down the storage mechanism of the ID itself.
> In short, if the large platforms like Facebook, Google, Apple, Microsoft et al started using DIDs, we could start using logins across platforms instead of creating new accounts for each one.
Not a chance really.
First, DIDs define a method behind resolving data be it use a website, use bitcoin classic, etc. There are over 100 defined, and only "web" and "key" (inlined data in the URI) have achieved interoperability.
Second, if DIDs define authentication then your Apple/Facebook/Google account will require to own the DID so that they can make sure the authentication requirements aren't rewritten to be too weak to qualify.
Third, DIDs used in that way are less privacy preserving than the existing system, since it is now a global identifier shared with everyone.
First,which DID methods will be successful is a question of time, additional your wallet app could support multiple of these DID methods.
Second, DID and the corresponding keys are supposed to be owned by the user or managed by a platform, any indivdual can make the choice whteher he wants convience of managed keys or full privacy under his own control
Third, you can have a seperate DID for every service and they issue you an login credential for that particular service.
The user problem- for those who see it that way- is that right now, digital stuff related to a person, is tied up primarily with the person's email address, or in some cases with the person's phone number.
(For the purposes of this discussion, call the email address or phone number an "identifier".)
Why is this a problem? Two reasons:
1. People don't "control" those identifiers
Many email addresses used in this context are controlled by employers, and the person's right to use them ends when they leave employment. Or they are controlled through expensive commercial arrangement between the person and the platform, and the person may lose access if they are no longer able to afford the platform. Or, they are free, offered by large data harvesting/advertising platforms, who mine data stored on the platform, and as below, linked to those identifiers from other platforms, to create advertising and propaganda targeting profiles.
2. Those identifiers are used by others to contact the person, and are therefore long-lived, which means they are also a vehicle for correlating an individual's activity across internet platforms who are necessarily presented with those identifiers by the person when they engage with the platform.
DIDs are an attempt to have identifiers that are controlled by people that:
* are inexpensive
* can be short-lived and "rotated"
* can be specific to the relationship between a person and a particular platform
* can support more tailored association of personal data to identifier
* can better support the person's management and correlation of their platform relationships, while minimizing if desired that the correlation of identifiers back to a person by the platforms themselves
* and support other use cases
In terms of "decentralization" and "publishing"- there is definitely a need to publish identifiers in some cases. People want to find others, and want to be found. Whether that publishing constitutes centralization is nuanced.
But the key issue is that right now it is hard to impossible for a normal person to engage with a small or large platform that does not involve a widely used identifier.
[EDIT: whether normal users consider this to be a problem is an open question, and as is whether they would if a solution existed to the problem...]
Somebody introduces a new technology to address these concerns every couple years and it doesn't go anywhere. These aren't actually problems to a lot of users. That's the real problem that needs to be solved - awareness. And that's a lot harder than taking the identity solutions we came up with in the Identity 2.0 days and adding a blockchain.
> Somebody introduces a new technology to address these concerns every couple years and it doesn't go anywhere.
That's the problem, we need protocols and standards, then laws to enforce those, not _technology_. The DID specification is a "old" attempt at this, I remember first coming across DIDs back in 2015-2016 sometime, so DIDs are hardly new.
> we came up with in the Identity 2.0 days and adding a blockchain
Good thing no one has suggested to add any blockchains! Commentators here on HN would do themselves a service by reading the actual specification before commenting, seems to be a common misconception that DIDs has something to do with blockchains.
While of course it is just one of many (alongside e.g. “just use a public key”(or hash of one or something. I don’t know the details), and “just use a github username”, when looking at the example resolver, and trying to read the docs, my impression was that a fair proportion of the examples given were blockchain related?
So, that could be part of the reason for the misconception.
I was first introduced to it by the, bold post on the Protocol Labs (the people behind IPFS) blog, about ION as a particular type of DID (sorry, “type of” is probably not quite the right terminology, but I’m not sure what the preferred terminology is) which appears to use the Bitcoin chain (but in a way that involves only very few transactions and very little on-chain data).
Personally I found the FAQ page for DIDs to be a little,
well, it isn’t particularly focused on assisting the reader in evaluating “should I care about this”?
I guess in some ways it seemed a third of the from being a normal FAQ and being a specification, or, not a specification but a, documentation of policy and plans etc.
> Somebody introduces a new technology to address these concerns every couple years and it doesn't go anywhere. These aren't actually problems to a lot of users.
> 2. Use Cases: Online shopper, Vehicle assemblies, Confidential Customer Engagement, Accessing Master Data of Entities, Transferable Skills Credentials, Cross-platform User-driven Sharing, Pseudonymous Work, Pseudonymity within a supply chain, Digital Permanent Resident Card, Importing retro toys, Public authority identity credentials (eIDAS), Correlation-controlled Services
And then, IIUC W3C Verifiable Credentials / ld-proofs can be signed with W3C DID keys - that can also be generated or registered centrally, like hosted wallets or custody services. There are many Use Cases for Verifiable Credentials: https://www.w3.org/TR/vc-use-cases/ :
> 3. User Needs: Education, Retail, Finance, Healthcare, Professional Credentials, Legal Identity, Devices
> 4. User Tasks: Issue Claim, Assert Claim, Verify Claim, Store / Move Claim, Retrieve Claim, Revoke Claim
> 5. Focal Use Cases: Citizenship by Parentage, Expert Dive Instructor, International Travel with Minor and Upgrade
> 6. User Sequences: How a Verifiable Credential Might Be Created, How a Verifiable Credential Might Be Used
There's probably already a good way to bridge between sub-SKU GS1 schema.org/identifier on barcodes and QR codes and with DIDs. For GS1, you must register a ~namespace prefix and then you can use the rest of the available address space within the barcode or QR code IIUC.
DIDs can replace ORCIDs - which you can also just generate a new one of - for academics seeking to group their ScholarlyArticles by a better identifier than a transient university email address.
It solves the problem of Microsoft not having a mobile platform in which to lock you in. Unlike their competitors in identity: Apple iOS and Google's Android.
Therefore MSFT now needs an open-ish standard so that it's not dead in the water.
It's a way for a decentralized service to provide a publicly-resolvable self-sovereign identifier for a user. "Publicly-resolvable" means that anyone can query your public identity state, given your DID. "Self-sovereign" means that you and only you can alter your public identity state (i.e. you own the private keys).
A blockchain isn't strictly necessary. You could build a DID method for your PGP key that relies on the world's set of keyservers to resolve your DID's state, for example. You could similarly have DID methods that resolve your public key via Keybase, via DNSSEC, via certificate authorities, and so on. As long as the underlying system is decentralized -- i.e. it spans multiple peer administrative domains -- it doesn't matter whether or not it's a blockchain.
Not necessarily is DID connected to publishing something on a blockchain. First: DID does not make any statements to the underlying infrastructure, this can be a completely decentralized public, permissionless blockchain but also public, permissoned ledger(also decentral but a little less) or the did Methods using a central server as referenced in the w3c mozilla response.
DID for example solves/enables some aspects of the 10 principles of SSI, e.g. portability
Because: if it's truly decentralized then there's no need to publish it. But publication is a core aspect of DID. That it must be published is a jedi mind trick that allows in "on a blockchain". Now we see the real problem being solved (not a user problem): need something published on a blockchain.