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.
By who?
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.
Do you mean "developers didn't use XHTML"?
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.
[1] https://html.spec.whatwg.org/multipage/introduction.html#htm...
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.
Although you are right that the issue was more user acceptability and not implementor willingness.
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.
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 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.)
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
Yes, two different keys are more secure, but they have some pretty severe usability problems.
Most methods are based on blockchain networks.
But there are some that work without blockchains. Like IOTA, IPFS, p2p, web, etc.
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.
Sounds like a big piece to chew, but I think the main hurdle is replacing HTTP(S) on the client side.
Link? Or an explanation as to what this means?
> before it becomes available in a shop nearby
Meaning what exactly?
If you're saying Microsoft will implement DIDs, my question is, "Which of the 50+ methods?"
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.
So I went and had a look. There's no specification there that I could see - is there a more specific link I missed?
The white paper was issued in 2018. Is that what there is?
The product is Entra Verified ID - which turns out to be a directory service on Azure. https://docs.microsoft.com/en-us/azure/active-directory/veri...
This appears for all the world like a centralised product marketing itself as "decentralised".
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.
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).
You can get block headers with very lightweight download work from peer-to-peer network.
azure-identity==1.7.1
azure-digitaltwins-core==1.1.0
azure-cognitiveservices-vision-face==0.5.0
azure-cognitiveservices-anomalydetector==0.3.0
azure-communication-identity==1.0.1The quote is “a jack of all trades is a master of none, but oftentimes better than a master of one.”
Wikipedia says “there are no known instances of this second line dated to before the twenty-first century”:
https://en.wikipedia.org/w/index.php?title=Jack_of_all_trade...
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.