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.
So I've just scanned over this stuff, maybe someone can fill in some gaps for me.
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?
It's such a bad spec it'll never be implemented by anyone
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
So if I’m building a service that lets somebody login with a DID, and I’m using a DID library to verify your authN then that library needs a different code block for every one of those methods?? LOL. What could possibly go wrong? Or less sarcastically, how could this possibly be expected to work?
Yeah DID is a dumpster fire. It's a consulting company's dream spec. Anything is possible but almost nothing is required. It smells a bit like SAML all over again, wherein they try to satisfy every stakeholder and end up satisfying none.
To be fair, SAML was a victory at the time - in that they could even get the parties involved to agree to come to the table and write specs and agree to implement them.
IMHO, such consensus work improved in quality for a while after the WS-* dumpster fire was put out by JSON.
"that library needs a different code block for every one of those methods"
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.
That method registry is simply self-service way to register DID methods, so it functions like the latter -- "known" methods.
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.
Interesting that the announcement includes long lists of "testimonials" from W3C members and from "industry", but there are some glaring omissions. Why no endorsement from Apple, Microsoft, Google, or Mozilla? Even smaller players like Opera and Brave are missing.
well google did not outright reject, they said, it's not complete and the final should wait until the methods are implemented and used in practice (like most stuff is done nowadays)
Microsoft already has their own Decentralized Identity products in place. Check out https://www.microsoft.com/en-us/security/business/solutions/... They are and were also actively involved in the creation of standards and tooling, e.g. the did:ion sidetree-based DID method was created by them.
> 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.
This relies on public-key cryptography? If that is the case, then who is responsible for maintaining the private key? If that responsibility is with the user, then what happens if the user loses the private key? Does the user loses the identity as well? Is there a way to recover that?
It depends on the DID method that you're using. The DID method is kind of the identity management system for Decentralized Identifiers. Many DID methods are based on blockchains and with that there are usually no recovery mechanisms for DIDs in place - if you lose your private key the identifier can't be updated and you can't prove ownership over the identifier anymore which in turn renders associated credentials (see Verifiable Credentials https://w3c.github.io/vc-data-model/) unusable.
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.
This reminds me of web service/UDDI registries, that were supposed to come, and all the WS buzz in early 2000s. Some of them came indeed only to be shut down in a few years.
That's exactly the same comparison I've been making regards the W3C VC and DID specifications - we're basically repeating the bad parts of the WS specifications.
Somebody up above mentioned the land grab smell of the DID spec.
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.
The difference this time is that there are quite a number of blockchains who are very non-transparently attempting to become rent seekers.
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.
There are already some really simple solutions: for example https://keri.one specifies one of the most obvious solutions to the problem. Then proceeds to wrap it up in a lot of web3-inspired gobbledygook.
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.
We're already in use of dIDs on the chia blockchain, and it can be used to verify who issued an NFT to prevent fraud. People have already built games on this and used it to save character profiles (dIDs). Custody solutions are what save you, you can see Bram Cohen talk about it here https://odysee.com/@Chia:d/off-the-chain-Bram-Cohen-2022:5
> The Solid DID method specification is a specialisation of the Web DID method [DID-WEB] whereby write (create, update, delete) operations are more tightly specified. The Solid DID method is designed to be generic enough to be compatible with other Web-based systems which implement read and write operations using HTTP methods (RFC 7231). For this reason, we are considering whether to name the DID method did:https or did:rest or similar.
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?
There's still a lot to figure out in the space, and the blockchain adjacency always makes things feel like a land grab or first-mover obsessive. I don't think that much matters though. The majority of us will still keep our identity in centralized providers, but the real win is on the overhead of developers and the overall security model of identity on the web as the methods and registries get fleshed out.
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.
The idea behind DIDs and VCs (verifiable credentials, that go along with did's to prove claims about an entity) is fantastic.
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.
I assume you'll have a cryptographic key to state that a DID belongs to you. But what happens if that key get lost/stolen? You lose all you online presence with no way to recover it?
The only required property in a DID document is id, so that is the only statement guaranteed to be in a DID document.
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.
"Whatsmore, DIDs have the unique property of enabling the controller to verify ownership of the DID using cryptography."
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)."
I wonder if this drives a schism in Google's Chrome implementation of W3C recommendations, given Google's objections to the spec. I feel like they already have shown a willingness to diverge from the specs and do what they feel is best, with a large number of experimental chrome features not included in w3c.
DIDs support multiple storage mechanisms. Each storage mechanism defines how to create, read, write/update, and delete DIDs. Here's a list of the already implemented and published mechanisms: https://w3c.github.io/did-spec-registries/#did-methods. They range from no storage (e.g. did:key, you derive the DID from a public key but can't change/update anything about that DID) to stored on a webserver (e.g. did:web) to stored on a blockchain (e.g. did:ethr).
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.
So, I take it that the "decentralized" aspect of all this stuff really comes into play when all of the server hardware is surgically implanted into our limbs!
No, the cloud systems still need to be there (to track when you are trying to use your identity), but they will rely on private keys that you can surgically implant in your limbs.
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).
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.