Decentralized Identifiers (DIDs) v1.0 Becomes a W3C Recommendation
w3.org
w3.org
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.
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...
There's a list of DID methods "in development" [1]. Is this the list of methods, or is there a centralized registry, or are these just "known" methods?
If there's a centralized registry -- then this isn't really "decentralized" is it? On top of that there's a land-grab that's already begun for the method names, and isn't that going to kill the spec? com, nft, object, web, are already registered by private orgs.
But if it's not centralized, then it's not unique. What stops me from making my own "verifiable registry" [2] for eg `did:nft:internet` which cryptographically proves I own the internet? "Ceramic Network" (the owner of "nft" on the w3c site) says they own it in their registry .. but who's correct?
[1] https://w3c.github.io/did-spec-registries/#did-methods
[2] https://www.w3.org/TR/did-core/#dfn-verifiable-data-registry
In a round about way W3C successfully did the opposite of what they claimed they where trying to do, killing the entire concept and ensuring it won't ever actually happen
No, there's nothing stopping you making your own methods. But will anyone actually use it?
IMHO, such consensus work improved in quality for a while after the WS-* dumpster fire was put out by JSON.
Yes, and that is trusted code - even with isolation, an compromise of that method's resolution code would result in malicious parties being able to impersonate anyone else using that method.
There are use cases where you don't want correlation, in which case the decentralized identifier might exist only for you to log into a single web site. At that point, it might be easier to use a method like did:key or did:jwk which encode all of their information into the URL itself, and forego the ability to rotate or revoke keys.
Where and how?
Edit: I just saw the list. It's very land grabby feeling.
There's no editorial/curation aspect to this registry; that's out of scope. The requirements are simply basic DID method conformance -- specify how the create/read/update/write methods are implemented, security considerations, and so on.
The land grab concern you mention is real, but would likely not be addressed at this level (again, it would be considered out of scope), but could happen in a different standards group.
Some relevant work includes defining criteria by which to evaluate DID methods -- i.e., does it support update operations (e.g., did:key doesn't), does it rely on a blockchain and if so, is it permissioned, and numerous other factors. Probably the most comprehensive treatment of these are the DID method Rubric [1]
With Verite, our considerations were mostly around no/low cost, interoperable/open source implementations for the open source implementation (although anyone can use any method they like). The ones we're most likely to add open source implementations for next are did:pkh and did:ion.
> Write out your DID document according to the data model in [DID-CORE]. Include properties from [DID-CORE], and any other metadata you deem suitable. You MAY type it out and print it onto your paper, you MAY hand write it in pen or pencil or crayon, you MAY use finger painting or cut out and glue small pieces of paper. Express yourself however you like. You SHOULD NOT use glitter or food.
did:key Not Supported
did:web ???
did:ion
https://www.w3.org/TR/2022/REC-did-core-20220719/#verificati...
9.7 Verification Method Rotation
Not all DID methods support verification method rotation.
The did:key Method v0.7
5.1 Key Rotation Not Supported
This section is non-normative.
???
* Proof-of-work methods (e.g. blockchains) are harmful for sustainability
(s12y).Custodial services are a good way out. Another option with DIDs is that you can add more than one key to DID. This way you can have one key that is stored away somewhere safe and is only used for recovery purposes.
So what's different this time? gRPC, protobuf and GraphQL are out there vs. SOAP or CORBA? Some new thing about to rev up? Just plain old loss aversion?
Lambda? We need a FrontPage or Macromedia ColdFusion for that...
I guess that's it, somebody else from the Roblox generation can pick that up.
There's a chance for someone to earn $x per ID card or verifiable credential issued; you're essentially becoming a TLD operator only with something 95% of the population of developed countries will use.
Have you ever used 2FA systems where you can create various printed "back-up keys". Take that idea then run with it a little and you have KERI.
From this paragraph it seems pretty messy that there's both did:web and did:solid. Is the idea that every random company under the sun writes their own slightly different did-url to https mapping? And that every user-agent implements all of them?
Something important to track is the OIDC-SIOP v2 spec [1]. As this gets adopted by libraries and services that people are already using to handle their auth, it becomes effectively easier to "turn on" self-custody of identities for your users. I imagine there will be a lot of different options in terms of methods and registries to choose to accept, and the centralized providers of today will probably have a large say in what methods and registries get accepted.
Ultimately there are a lot of use cases enabled by deferring to the user for their identity and potentially other verifiable claims about themselves. The most obvious use case is phones using their secure elements to actually provide a password-less UX on the web while also allowing developers to skip dealing with user authentication. Less obvious (to most people) are things like verifying you own some NFT, or verifying that you have Bitcoin in some escrow so you're likely not a bot willing to get blacklisted on some platform.
This is the step that's required to create the real land grab over semantic User space - where "JoeSchmoe" really is the one and only.
[1] https://openid.net/specs/openid-connect-self-issued-v2-1_0.h...
Decentralize and normalize global IDs! Have ways to express data about them that contains the proof of ownership of the ID embedded.
The issues are with the execution in my opinion: the spec is too complex, the did methods are not nearly mature enough / constrained enough (some don't even use PKI...), and verifiable credentials / presentations are hard to get going.
For this to take off, they need to overcome a 3 sided market cold start (issuers, holders, controllers), with no clear monetization behind it.
I hope it works but I'm guessing we're not quite there.
Issuers of credentials can ensure that they have an experience date, so you can get a new cred issued with a new key, after the old is lost.
Also, there are services that help to recover your key.
The did:peer: method, for example, encodes the did document directly in its URI.
I must be too old, I do not understand the interest of this stuff compared to controlling a domain.
DID is little more than list of defined names and their intended usage. It's not automatically bad, but it's just a skeleton without any meat. In some sense, DID is pre-emptive standard template. If new identity protocols write their standard to be convertible to DID, then they end up having systems that can interact (after some testing) if when their methods intersect.
Content-based identifiers (CIDS) for IPFS also verify content with cryptography, so not unique. CIDS are also decentralized. However, the following looks promising:
* 4) DID metadata can be discovered (resolvable)."
Often, a DID is created from a public/private key pair that is used to sign a transaction that's specific to the DID method. The DID then becomes publicly visible with the associated configuration, e.g. multiple key pairs associated with the DID, service endpoints that allow an interaction with the DID, etc.
In fact a more realistic (but symbolically equivalent) scenario is that you'll be expected to carry around a device with you at all times that is biometrically linked to your limbs, and auto-updates its code (and the EULA that you agreed to in perpetuity).