For reference, I've worked with three vendors' implementations of LDAP, several versions of SAML, OAuth, JWT, Okta, Azure Active Directory, etc, etc... I've even deployed Smart Card authentication in the field several times.
I literally have no idea, not a clue what DID is supposed to be in a practical sense, despite having read a significant volume of material on a subject.
Like, okay, it's "identity"... somehow? How? What? Where?
The documentation is impenetrable buzzword-compliant gibberish that makes SAML's documentation look like crystal-clear poetry in comparison.
A DID URI is a URI with a 'method' and globally unique part: did:method:somegloballyuniqueid.
The "did" part is literal; a standardized URI namespace. The method part is some symbol that specifies how the unique id resolves and its representation (JSON, whatever.) The method part is what this story is about; W3C has declined to enshrine a set of methods in the standard.
Instead, W3C is delegating to a registry of methods. This registry has already grown to a sizeable number.
The idea is that you will apply a DID URI using its method and obtain a DID 'document'. This document has claims, credentials, etc. The DID owner can cryptographically prove the document represents them and relying parties can cryptographical verify claims in the document.
The actual workflow is more involved than described here but that's the gist of it.
BTW, your list of identity schemes you've had experience with roughly correspond to 'method's, although they aren't 'distributed' in the DID sense.
That reminded me of proof of domain ownership, where we point a registrar to an arbitrary field in our domain records to prove it’s ours.
Sadly I also don’t have enough imagination to see any practical use for that. It feels like an abstraction above every other systems we have today, except any provider would still need to support both this and the underlying actual protocol…
Or perhaps my question is more general. What problem does this particular common standard address that individually standardised uri-schemes would not?
As somebody interested in solving for decentralization and previously unaware of the W3C DID effort I formed my own proven solution to this problem 3 years ago. This was one of the less challenging and trivial aspects of the problem space.
Basically it's like a urn, but every sketchy blockchain startup gets their own namespace.
"1. there should be no central issuing agency;
2. the identifier should be inherently persistent, not requiring the continued operation of an underlying organization;
3. it should be possible to prove control of the identifier cryptographically;
4. it should be possible to discover metadata about the identifier."
Additional capabilities got tacked on during discussions, and I think are handled in different specs, such as DID-Messaging, but at it's core the above are the primary requirements.
My understanding is DIDs are a unique identifier. There's a few methods that can be used regarding the construction of the identifier. It could be a unique key (did:key- https://w3c-ccg.github.io/did-method-key/). It could be using web infrastructure (did:web - https://w3c-ccg.github.io/did-method-web/). It could be using blockchain infrastructure (did:ion).
Whatever it is, it becomes an identifier used to receive credentials and send messages to. For example, your digital wallet can have a DID which can be used to store credentials. Your digital wallet can have many DIDs which can be useful to avoid correlation of identities.
The credentials (and the identities they represent) themselves are normally bundled into things like Verifiable Credentials (https://www.w3.org/TR/vc-data-model/) which have to be issued to something - like a DID.
It all makes sense now! It's yet another attempt at making Web 3.0 happen.
Sigh...
My take is that it is a) X.509 re-born with different encoding (JSON-LD vs BER or PEM) and b) a scheme to promote use of certain blockchains for a purpose that blockchains don't suit well.
The forces in place here seems to be:
- distributed ledgers allow a different (decentralized) paradigm for identity management, where users own their identities and service providers authorize and authenticate them through verifiable credentials
- years of blockchains and even more years of web certificates have created processes to handle cryptographic material, that service providers supposedly find more secure than "username and password" to manage the identities issuing the verifiable credentials
- in realpolitik, Microsoft (Azure) is expanding in the cloud market by trying to establish a presence in niches (ie: Intel SGX, DIDs) [1]
I understand the overall skepticism about blockchain related technologies, but the intrinsic advantages that I see in them are:
- (for a service provider) having a tamper-proof log of all the auth changes for an identity
- (for a service provider/user) relying on cryptographic signatures allows for a private validation of an identity/claim
- (for a user) provided this is not EEE allover again, a greater degree of choices on how to manage your identity
I do not have as much experience as you do, so maybe there is some wheel-reinventing that I am not aware of :)
0. https://docs.microsoft.com/en-us/azure/active-directory/veri...
1. https://techcommunity.microsoft.com/t5/identity-standards-bl...
Typically your company will validate those credentials to some level for employees. At a minimum, you establish what you need to know for payroll, in other cases you do extensive background investigations. For the public, however, we’re stuck with rudimentary solutions for ID verification (bank/credit accounts, mailing letters, etc) or unreliable and invasive solutions like ID.me.
The idea of things like DID and sovereign identity is that the human has agency and can provide or not provide credentials to establish who they are. That could include a verifiable, signed representation of your birth certificate, a professional license or some other credential. Think of it as a new iteration of 90s “web of trust” concepts.
Seemed to me that DIDs are a more general version of blockchain addresses.
Like, you create a DID from a public key, and everyone who handles DID related stuff can ensure only who controls the related private key is the real owner.
They removed the core part of the DID standard where they made it expire after 6months.
I was told they requested the DID standard as it was needed for future projects.
I'm not sure this is the "flex" you wanted it to be. A cursory look at the specification gave me a pretty good idea what DID are supposed to be, and for (and I would only say I know enough identity-related stuff in order to implement things in my own services, but not over two decades). The use cases are relatively easy to understand, and there is bunch of implementations in the wild as well.
Maybe it would also help by looking at some of the proposed DID methods that are more similar to the approach you're used to. While not centralized, maybe DNS is something you're more familiar with, so you can link it together with existing knowledge?
In that case, the specification for the `did:dns` method, using DID together with DNS might be helpful for you: https://danubetech.github.io/did-method-dns/
What exactly is it you don't understand? Maybe your knowledge about centralized identity management is not helping you in this case, but making it harder to understand.
For Google, it makes sense for them to request at least some "standard" methods. If the number of DID methods is sufficiently large, Google won't be able to use their network effect to dominate any of them. Surprise, that's the aim of the spec.
For Mozilla, it makes sense to support a small set of DIDs, their resources are not infinite.
As a user, I want to use the DID method that works for ME. For example, https://en.wikipedia.org/wiki/BankID is used universally in Scandinavia and I would not see why would anyone use DID for identifiers of "real world" things if a govenrment-accepted mechanism cannot be used (eg "did:bankid:*") for signing those identifiers etc. Because I already use BankID for all important authn things in my daily life. In Estonia, ID cards are used for legally binding signatures since forever, I can totally see how they might want to use that to sign their DIDs: https://en.wikipedia.org/wiki/Digital_signature_in_Estonia
Regarding Web 3.0 garbage in the registry: just ignore it, nobody is going to use it seriously. Those entries are just marketing by those projects. If it was up to me, I would split the registry into two sections: registries with significant stakeholder backing (BankID and the likes) and everyone else (so that you can ignore them).
It's not immediately clear what DIDs are, what problems they're solving (and what value they're providing to the ecosystem), why they're better than other options in the same space, and how they'll function and scale years into the future. That's a legitimate cause for skepticism.
That the objections brought on by the two largest browser vendors are dismissed entirely, without further addressing the concerns stated, is unsettling.
I thought it was just someone crying about how the big browsers just didnt understand their brilliance.
Overruling them just makes you look stupid. They won't implement it. W3C pulls this bullshit all the time.
Fighting for relevance.
Some other interesting entries in this same vein, that are already in the DID registry, are Mastercard (https://idservice.com) and SecureKey (https://securekey.com).
> [Verifiable data registries] include distributed ledgers, decentralized file systems, databases of any kind, peer-to-peer networks, and other forms of trusted data storage.
The garbage part is that 9 of 10 (give or take) methods registered on https://www.w3.org/TR/did-spec-registries/#did-methods are from crypto-hyper-cosmos-nonsense.
The reason is that serious organizations like MasterCard or BankID will only begin considering registering a method once the spec is a W3C Recommendation. At this stage, only insignificantly small or heavily invested parties registered a method on a draft standard (which is what a "proposed recommendation" roughly means).
Edit: nope, I was wrong, Mastercard has one https://github.com/Mastercard/did-methods/blob/master/id.md
Edit: Norway and Sweden both use a system called "BankID" that does the same thing in a compatible way, but they seem to be developed and managed by two separate companies.
This building so much flexibility into protocols seems like a 90s holdover.
We are realizing that the more moving parts you have, the more edge cases you have, and the more attack surface area.
Also, those specs all have a degree of interoperability, which is a pretty significant difference. Like many thunderbolt 3 docks can actually also just run when connected to usb-c w/ dp-alt mode, although they lose out on the thunderbolt extras of course. Something that seems to be missing here.
DID in my opinion is unlikely to succeed. Real builders don't use it, because it is cumbersome and requires agreeing with (a step up from collaborating with) other opinionated developers who have different specific use cases in mind.
Then why would we expect Mozilla or Google or anyone else on that committee to ever determine one? Or to object to a free-for-all naming scheme if the problem is inherently ad-hoc?
Whether or not this standard succeeds, one can see the very real threat of standard capture here. Which has happened before, on numerous occasions, when a canonical implementation arrives that just so happens to prioritize their interests.
Probably a few big tech companies will form a consortium and use their weight for setting a de-facto standard.
I mean, not all of the Internet is accessed through a browser but if Chrome and Firefox don't support DIDs, even if Safari would, who would use DIDs in a context exposed to browsers?
Urls were defined way after all those things, and were predominately created by the http people. I don't think its similar at all, and regardless, compared to the actual http (or gopher or ftp) protocol, the url syntax is the least interesting part.
Some of their members (e.g. Sovrin, Evernym) only very reluctantly included blockchain as a piece of the solution, and only then when they saw how certain aspects of blockchain were desirable for credentials and revocations without a central, controlling cabal.
Using Sovrin as an example, they did not create a token sale, NFT, or defi anything, which I think speaks volumes about their motives. Instead, they created a non-profit that was funded through traditional means.
IMO some of these founding members are legitimately trying to solve the very difficult problem of digital identity (including privacy, decentralization, and compatibility).
On the one hand, it seems like this is going to be (and/or is currently being) used by NFT peddlers, but on the other hand it's not like we'll be seeing less NFTs and cryptocurrency garbage if this spec dies.
However, I also can't think of any interesting use-cases for this that don't involve cryptocurrency/NFT garbage. Some of the example use-cases seem range from being consumer rights and privacy nightmares, to being just uninteresting ideas that can be implemented without DID.
The Transferable Skills Credentials[1] case for example seems to be trying to make a case for adding an NFT/minting schemes as a middle-man for certification programs. What value could that possibly add? Certification programs are centralized by design, so the only "gain" would be that the certification authority doesn't need to maintain a database of the certifications it gives out...or something like that?
Also the "Cross-platform User-driven Sharing"[2] one reads like some sovereign citizen wet dream (in semi-broken English). Franklyn is a military war veteran with two young daughters and he is very concerned about protecting their privacy online, so he writes HIS OWN terms of service that companies need to agree with if they want to do business with him. After a long probationary period, he decides to share more information with services (like a shopping list!), but he keeps his finger on the trigger at all times (the delete my DID button) in case the company gets any ideas.
I didn't realize the W3C had become such a clown show.
It's blockchain bullshit that you can ignore.
I would say that the process worked as intended. There was disagreement among members, things got discussed (see https://www.w3.org/2022/03/did-fo-report.html for details) and a decision was made according to the W3C process. All good!
DID kind of strikes me as ASN.1 "with crypto/distributed ledger" stuff tacked on top of it.
It's futile because the future universe of DID methods can't be anticipated now, so whatever wrong set of DID methods W3 promulgated would include both poor choices and omit good choices. It's harmful because whatever future methods might emerge will relegated to a second class for having failed to 'get in' on the initial standard.
Better to avoid prematurely enshrining some arbitrary set of methods and allow a consensus to emerge via practice and exposure. At some point, as the inevitable shake-out of bad ideas and nefarious actors occurs, DID methods can be standardized in a useful way. Yes, the lack of a simple list of SHALLs will impede the immediate adoption of DID for all conceivable purposes, but better that struggle than the next to impossible task of loosening the grip of beneficial parties that have a standards document to wave around.
It's almost like they've learned something over the last quarter century.
Beyond that, some of this is just odd. " It's harmful because whatever future methods might emerge will relegated to a second class for having failed to 'get in' on the initial standard."
Good. We can deal with that in v2.0.
Trying to design this kind of thing to anticipate every possible future good thing that might come along is a folly. If you can't standardize them yet because you don't even know, then i go back to the first sentence i wrote :)
Beyond that, your optimism in what will happen (shakeout of bad ideas and then harmonious replacement with standards) seems ... mostly misplaced.
Assume it takes off - what will instead happen is that you will be stuck supporting tons of non-standard methods developed between now and when anyone standardizes them forever. It will likely hamstring your future development as well. I cite as evidence - literally the history of everything :)
There was 100% no reason to standardize this now other than wanting to feel good about themselves. It isn't needed to push forward. It should have waited until someone had any idea what good looks like.
Or maybe it's just too soon to try to carve a "standard" into the w3c process stone. A half-baked protocol is worse than no protocol at all.
That's how standard bodies are supposed to work: by finding consensus. If there are many objections, the spec should be adjusted until people agree.
However, if you have enough clout, you can try and still ram it through. See hardware APIs. 2 out of 3 major browsers have objected.
"Decentralized identifiers (DIDs) are a new type of identifier that enables verifiable, decentralized digital identity. A DID refers to any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) as determined by the controller of the DID. In contrast to typical, federated identifiers, DIDs have been designed so that they may be decoupled from centralized registries, identity providers, and certificate authorities. Specifically, while other parties might be used to help enable the discovery of information related to a DID, the design enables the controller of a DID to prove control over it without requiring permission from any other party."
They represent your identity, have a relatively standardized format, but anyone can issue them, decide what to put on them and where the contact methods point, and you can have as many number and different versions as you wish.
The DID Core spec has not demonstrated any degree of practical interoperability, instead delegating that to a registry of 50+ methods.
The DID architectural approach appears to encourage divergence rather than convergence & interoperability. The presence of 50+ entries in the registry, without any actual interoperability, seems to imply that there are greater incentives to introduce a new method, than to attempt to interoperate with any one of a number of growing existing methods.
The lack of restrictions on the registry are allowing methods diametrically opposed to the principles of the group & spec, and methods which are actively globally harmful to sustainability.
[W]e believe the DID specification may not be fixable (MUST NOT become a Recommendation)."
Just because something was given the stamp of approval by the W3C doesn’t mean they actually have to implement it.
Like, it's not a flat URI scheme leaving structure up to controllers. But it's also not a fully defined ontology.
Pick a use case description in section three. Any one. Each one could provoke an entire domain-specific organization into heated arguments about subrequirements and subsubrequirements.
Even if this recommendation doesn't make it, it's neat.
Any way you turn you walk into this system, right?
I think the W3C got lost in their XML dreams, and got huffed by WHATWG, whose standards I actively dislike.
Of course, these different packages are not (yet) compatible, but that's not the problem. The problem is that, after a good 4 or 5 years, it's hard to find a single project that uses DID protocols at scale in a worthwhile and effective manner.
There are tons of pilot projects and PoCs. A few go into production at limited scale, languish for a while, and then do a slow fade.
I agree with other commenters that DID does not seem to address real-world pain points. I also think that the spec appears murky, abstract, overly complex and hard for developers to work with. I have tried to use DID in projects a couple of times, and found myself sidelining or pushing it into a corner of the system, because it did not seem to serve a useful purpose.
There's a recent alternative to DID, which is narrower in scope and more pragmatic. That is "login with Metamask" or "sign-in with Ethereum" (or something similar in the case of other blockchain platforms).
You say this is not a problem, and immediately say this:
> it's hard to find a single project that uses DID protocols at scale in a worthwhile and effective manner.
Of course it's hard. For a protocol to operate at scale its implementations have to be compatible
This paragraph gave me temporary brain fog. I think it's saying that so long as the proposed syntax is flexible enough that one or more DID methods can satisfy... and then I'm lost again.
Tldr: it is lego?
That seems to me like Mozilla trying to push their social justice goals down into tech standards now.
It's like Mozilla are saying "We have centrally planned the number of carbon credits that may be spent by each technology, and determined that blockchains are a forbidden technology. We will therefore undermine any efforts of other people to implement standards where using blockchains is even a possibility."
Regardless of the legitimate issues raised by objectors, I am happy to have some W3C standard to build on. Methods may be underdefined, but as consensus is reached I could pivot to it. And even if no consensus is ever reached, I can at least try and reach consensus with the communities I care about.
Coupled with ActivityPub [1], this feels like a much safer foundation for building a DApp than anything else I have been able to find. The only thing that confuses me is the relationship between DID [2] and the Verifiable Credentials [3]. Can anybody explain how they relate, and how they should be used together (or not)?
[1] https://www.w3.org/TR/activitypub/
Worst case, the core is flawed and the specs are revised to align to what has been learned flushing out the methods or it is abandoned for whatever reason. Mozilla & Google saying they object based on everything not being defined sounds like the opposite of progress to me.
The core already lays out specs for methods and clearly they’re good enough for other workgroups to already be moving forward refining methods for specific use cases. Here’s an example:
https://identity.foundation/peer-did-method-spec/
If there’s an significant issue with moving forward, I am not understanding it.
It is helpful to look at the DID-core as the WHAT with the methods of the DID to specify HOW.
The methods set is left open by W3C (i.e., an item in the method registry) and rightfully so. The objectors want it to be a defined, possibly closed set before it moves to Recommendation track.
To see why this makes sense, suppose I am a service provider and I need identity services to authenticate and authorize. If I define the data elements that constitute identity (eg: name+phone or emailaddr or nationalid etc.,) in my application. The then DID allows the server and the client to agree on identity by exchanging the DID document and verifying the claims in it using the methods in the DID document.
If we need flexibility in the set of dataelements that constitute identity, then the methods MUST be kept open. The method is only an interface contract that specifies how to validate a specific DID.
Suppose there is a method that relies on nationalid then any future service that also supports the method should be able to interoperate. Whether a service implements that interface or not is a choice that the service can make.
By decoupling the WHAT from the HOW, I could have a fully decentralized identity system (perhaps with services provided by the OS or apps) and sharing only zero-knowledge-proofs with the counterparties without sharing underlying information (or only information necessary for the transaction).
I think this makes sense and is a step in the right direction.
Decentralized Identifiers (DIDs) are important because a decentralized global network with fully decentralized versions of things like Facebook, with users controlling their own data, may not be possible without them.
There is a lot in the DID specs. They are perhaps best viewed as an abstraction layer for decentralized authentication, authorization, rights management, and messaging. There are many ways of implementing these standards, and this is accomplished by allowing many different DID methods. Some methods, like 'peer', do not use public sources of truth like blockchains. Many of the various methods use some given blockchain as a public source of truth. Some use a distributed file system like IPFS. The abstraction in the DID specs should allow all of these methods to interoperate (e.g., have a IPFS DID document with a btcr controller, btcr being one of several DID methods using the Bitcoin blockchain).
DID methods are not a wild west however, despite the picture painted by some. There are registries for recognized DID methods that impose controls on DID method specs before they can be listed in the registry [1].
Also, I think any DID support will likely require a plugin mechanism. The app implements the DID abstraction layer and DID common functionality, then offloads DID method specific functionality to an available plugin for that method or signals an error if no plugin for that method is available. It is ironic to me that Mozilla raised the objection here, because in my mind the plugin system that made people aware of plugins is the Firefox plugin system.
We've all been there. Coding is complete, but QA comes back with some fundamental issue that might require us to redo the design of the program. We'd rather not.
Winners ship.