I was initially pretty hyped when I read the abstract for DIDs, bookmarked the spec and read it later. The "spec" is a bunch of buzzwords and vague generic "concepts". The DIDs themselves mean basically nothing, it's the "methods" that actually must have their own specification and actually "do something".
Another feeling you can quickly get from DIDs is that they're blockchain centric.
The entire concept is "jack of all trades, master of none". I actually hope to be wrong, and see some more fully fledged implementations/examples of real world use-cases, because I love the idea of federated/decentralized identity.
Funny to see Google and Mozilla siding on ethical issues. It really seems like the W3C has finally lost its compass and now wants to venture into the blockchain. Only positive thing is to see Google loosing once in a standards fight, however, I think it might just have been the wrong anarchist endeavour inside the W3C. In the end we will get more centralisation because looks like nobody except the big ones can push standards on a technical decent level (indirectly pushing their agenda).
> Funny to see Google and Mozilla siding on ethical issues
It's not the first time Google and Mozilla sided together against the W3C on web standards, and the last notable time resulted, over time, in the W3C ultimately being displaced from any role in the HTML and DOM standards.
The standards group that implementers listen to (which, for some reason, seems to be the one that listens to implementers, when there are competing options) is the only one that matters, in practice.
> It's not the first time Google and Mozilla sided together against the W3C on web standards, and the last notable time resulted, over time, in the W3C ultimately being displaced from any role in the HTML and DOM standards.
> Only positive thing is to see Google loosing once in a standards fight
It is far from the first time. For instance, Google was involved in the WHATWG, which developed the HTML standard while the W3C pushed XHTML.
The standards war, itself, is only lost when nearly nobody uses the standard, which is what happened to XHTML, which lost to WHATWG’s HTML when browsers simply didn’t use XHTML.
It sounds like a lot of cryptocurrency companies wish to prop up this standard, but it is not clear to me that actual people would use it for a non-circular goal.
All browsers implement XHTML. It's referred to as "the second concrete syntax for HTML" in the WHATWG spec.[1]
Indeed many websites do use XHTML, the HTML application of XML. However, since proper documents render identically, you won't be aware that you're visiting an XHTML site - that is, unless you check the source.
Fun history side note: Browsers like Netscape and Internet Explorer didn't agree on how to parse HTML in the past. They handled omitability differently, for example, in overlapping hierarchies (<p><b></p></b>). To fix this mess, Sir Tim asked well-respected SGML practicioners to create a clean subset of SGML and define a document type definition (DTD) for HTML. They came up with XML, the clean subset, and XHTML, the DTD. [2]
Basically, XHTML was the first actual standardization of HTML. Unfortunately, minor syntax errors will prevent a XHTML document from rendering, which, to some degree, is probably why it was never widely accepted by developers.
Internet Explorer did not. It completely refused to render XHTML pages served with an XML MIME type (application/xhtml+xml). It would only display pages if they were served with the text/html MIME type, which meant that none of XML’s vaunted features (such as strict parsing) came into play, and such pages were effectively treated as “HTML with syntax errors.”
A big part of why WHATWG was able to dethrone W3C was W3C’s insistence on dropping HTML in favor of XHTML when the overwhelmingly dominant browser of the time had zero support for it.
> They came up with XML, the clean subset, and XHTML, the DTD. … Basically, XHTML was the first actual standardization of HTML.
No, the first formal HTML standard was 2.0 (RFC 1866), which was released in November 1995 and had a DTD that among other things disallowed overlapping hierarchies. XML’s first draft was released a full year later (November 1996), and the first W3C spec was XML 1.0 in 1998. Later that year came the initial drafts for XHTML 1.0, which was a straightforward translation of HTML 4.0 to XML.
The outcomes of decentralization sound good until you realize it means you’re either running your own server, or using a blockchain and need to protect a private key somehow. But normal humans want nothing to do with either of those responsibilities and always rely on a centralized service.
If this ID standard included a way to use a centrally-controlled email address (the defacto ID standard today that works just fine for most legal activities) or a social login then maybe some of the bigger players would be onboard and it would take hold. As is it seems like it’s just gonna be another crypto fad.
Yes, but the universal ability to create authentic sources of data means people will use what is convenient but always have the option to go to the base layer without permission should they dislike their service.
I don't buy this idea that average people can't manage a keypair. Humans already manage secrets in the form of passwords, it's not that much different.
In the worst-case scenario in which users defer to some weak/centralized system, how is that categoricially worse than the centralized systems we already have?
> Humans already manage secrets in the form of passwords, it's not that much different.
Humans are bad at this which is why we recommend password managers.
That said, I do think keypairs are the way forward, I just also think they need either strong integrated software support in whichever device is being used, or strong external hardware support.
(Yubikeys are nice because they kind of extend the “key” metaphor that people are already used to, but I wish they shipped with a paired backup key that was provisioned with the same key material. Maybe colored red to distinguish it.)
> but I wish they shipped with a paired backup key that was provisioned with the same key material
Two identical keys, is less secure, for those who would otherwise have bought many different keys.
If you instead buy two different keys, then, when you lose the first, you can know it's safe to continue using the second one. And you can block the first one, without locking yourself out.
Maybe getting two different keys would be a good idea
The trouble with this is that you need the second key present each time you need to enroll it to an account, meaning you can’t stash it in a safe deposit box as a backup. And you have to remember to add it to each and every account or it’s not really functional as a backup.
Yes, two different keys are more secure, but they have some pretty severe usability problems.
I mean, let's be real here. IOTA is a blockchain in all but name, IPFS is substantially blockchain-adjacent, "p2p" is vague to the point of meaninglessness (and isn't actually a registered method), and "web" is silly (a web site is already identified perfectly well by its URL).
My point is that P2P isn't a single thing -- it's a whole multitude of things, many of which don't make sense to create a DID for. Gnutella is a perfect example of where it wouldn't make sense: the Gnutella protocol didn't provide any way to create a persistent reference to a file that was being shared, and it'd make even less sense to tie an identity to such a file.
It's a bit like comparing monkeys and apes though. Yes they're all primates but the family tree does matter and you can't just mash them together.
IPFS resembles many previous attempts at distributed file storage, which did not use blockchain. They had other ways to encourage fairness, which appears to be the primary use of blockchain in IPFS. The existence of the concept of Merkle trees, named or unnamed, lead to blockchain, not the other way around. And it has other children, like some digital signature specs.
I think the idea is that it (or some future incarnation of it) eventually replaces most static web hosting, FTP, Bittorrent, and quite a bit of dynamic web hosting. Oh, and maybe messaging stuff like IRC.
Sounds like a big piece to chew, but I think the main hurdle is replacing HTTP(S) on the client side.
Location independent stable identifiers for immutable docker images that allow you to cache them wherever you want (including in airgapped envs) and still don't require users to patch your image names with kustomize/helm/whatever
Microsoft has already lined up the tech in their products. So I'm confident that it's just a matter of time before it becomes available in a shop nearby.
I haven't used their implementation yet but Microsoft initiated the did:ion method. I guess they'll support it :-D In general, the idea with DID methods is that you can support many methods without too much effort - for example the Universal Resolver implements already a good bunch: https://dev.uniresolver.io/
However, pointing in the direction of the many DID method implementations, I agree with you that they're confusing. Many people try their hands on implementing a new method. Most of the methods will not amount to much. I recommend focusing on simple methods like did:key or did:web to get started and high throughput methods like did:ion, did:elem, did:orb (all sidetree based) for production. did:ethr is also a good starting point for a public blockchain DID method that doesn't require a transaction to create the DID, i.e. no expenses required. did:ethr is also one of the oldest methods and can easily be used in existing Self-Sovereign Identity software solutions.
DID resolution is a security operation and has to be done by a trusted component. The document you get back does not have any additional integrity protection on it, so a resolver that lies will basically let the malicious party impersonate anyone.
The resolution process for DID methods also vary in their processing and storage requirements. Some method implementations may result in gigabytes of local data.
For these and other reasons, I don't believe real-world deployments will resolve more methods than they deem necessary. Of course, that would mean that between implementer networks you have far less portability and interoperability for DIDs.
Ok, I'll have to look more in-depth into the Microsoft link, they link to many more pages including a whitepaper.
Regarding all the blockchain centric DID methods, would someone wanting to validate a DID (eg: did:thecoin:whatever_would_go_here), need to hold a copy of the blockchain? (in a scenario where one doesn't want to be dependent on a third party for blockchain interactions).
For most of blockchains you can do light client validation without the full chain (or full node). Light client needs to only know the block headers to validate a truth.
You can get block headers with very lightweight download work from peer-to-peer network.
Depends on the implementation and the blockchain, but for many cases there are ways to make such resolutions provably correct, such that you don't have to hold the copy of blockchain and you don't have to trust that a third party did the resolution correctly.
Another feeling you can quickly get from DIDs is that they're blockchain centric.
The entire concept is "jack of all trades, master of none". I actually hope to be wrong, and see some more fully fledged implementations/examples of real world use-cases, because I love the idea of federated/decentralized identity.