20 ms·

Mozilla and Google Objections Overruled on “Decentralized Identifiers” by W3C

289 points by shiftingleft 4y ago

shiftingleft 4y ago
"Mozilla: 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)." "The Director concludes that the balance lies in favor of the DID developer community, encouraging it to continue its work and search for consensus on standard DID methods. The objections are overruled."
- cratermoon 4y ago
  Where have I heard this before? https://www.wired.com/2012/07/developer-quits-oauth-2-0-spec-calls-it-a-bad-protocol/ https://www.wired.com/2012/07/developer-quits-oauth-2-0-spec...
  - aidenn0 4y ago
    For those of us who aren't webdevs, what was the final fate of OAuth 2.0?
    - ukulele 4y ago
      It's very widely used. Most SSO providers are using it, including the biggest ones.
      - bawolff 4y ago
        Although personally i don't think its a great spec. Its a good enough spec (certainly better than saml, shudder) - "good" is not the same as works acceptably or popular.
        cratermoon 4y ago
        After extensive experience with SAML and other specs, I don't think it's better than SAML in a fundamental way. It's certainly better in that it doesn't require a mind-numbingly verbose blob of XML, but strip away the XML and all that verbosity, and you basically end up with... kerberos.
    - dathinab 4y ago
      OAuth 2.0 basically killed generic identity providers leaving us with a hand full of SSO providers you can use. It also instead of a simple generic OAuth 2.0 library we had (and still have) separate libraries for the various OAuth SSO providers. Through this has converged a bit since the initial days. But the initial days where enough to cause harm to the ecosystem. It also needs a variety of "extensions" you have to add to make it secure. But which can slightly differ between SSO providers. (Note sure but I thing some of this "extensions" have been added to the spec retrospectively.) In conclusion I would say while OAuth 2.0 is widely used it also was widely harmful and lead to a further centralization and to users being more dependent on a few mega corporations. In this context it has fully failed some of the initial ideas people had about it when it's design started. Just because something is widely used doesn't mean it's not harmful or well designed. Adaptation of technology is often not driven by what is the technological best solution especially wrt. web technology.
    - cratermoon 4y ago
      You may have heard the aphorism, "All problems in computer science can be solved by another level of indirection." This, or some variation of it, is known as the fundamental theorem of software engineering, variously attributed to Andrew Koenig, Butler Lampson, and David J. Wheeler. With oauth2, literally any sort of authorization (or, in theory, authentication) is possible, but first you have to ask some endpoint for the details. In the case of oauth2, the core concept for authorization is "scope", but nothing is prescribed in scopes. They can literally be anything the auth provider describes. In theory, it's not supposed to matter – a consumer is just supposed to be able to pass around scopes from providers and let them determine if access is allowed. In practice, there's no practical way to reason about scope+resource permssions. Oh, and despite the name, oauth2 is not about authentication, it's only about authorization. The OIDC spec, built on oauth2, provides authentication services, but again, there's no spec. Every auth provider does what it wants. It's sometimes said that oauth2 is great for consultants, because any organization wanting to deal with it must hire (or contract with) specialist who can sort out the ill-defined problem space.
      - tnzk 4y ago
        > despite the name, oauth2 is not about authentication, it's only about authorization OAuth is short for Authorization in the first place. https://datatracker.ietf.org/doc/html/rfc6749 https://datatracker.ietf.org/doc/html/rfc6749
        quickthrower2 4y ago
        What a brilliant and unambiguous abbreviation!
        cratermoon 4y ago
        Because this is my specialty, I long ago learned to specify either authn or authz. The OAuth spec should have been the OAuthz spec.
        tnzk 4y ago
- thsijustin 4y ago
encryptluks2 4y ago
Sure W3C, let's just add 30 new APIs to track users mouse activity, proximity, fonts, etc.
- deleted 4y ago
  [deleted]
Taek 4y ago
I've been following DID for a while and I really don't think its the right approach. The voices of concern from Mozilla and Google are spot on: the DID specs expect everyone to coordinate on finding the right structure for different types of data but the real world is messy and no "correct" structure exists. 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.
- deleted 4y ago
  [deleted]
- abernard1 4y ago
  > but the real world is messy and no "correct" structure exists. 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.
- fabrice_d 4y ago
  Maybe usage will converge on a few dominant methods (be it did:key, did:web or some other one), based on successful applications. This is pretty similar to URIs, which were defined very openly, and where for instance http(s):// took over gopher:// and ftp://
  - bawolff 4y ago
    > This is pretty similar to URIs, which were defined very openly, and where for instance http(s):// took over gopher:// and ftp:// 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.
bawolff 4y ago
A standard flexible enough where you can do literally anything is usually a bad standard. The point of standards is to write up some small-ish base that everyone can agree on so that people can talk to each other. A standard containing everything where each implementation implements a different incompatible subset, is a failure.
- RcouF1uZ4gsC 4y ago
  Also, too much flexibility ends up being a security nightmare. 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.
  - hinkley 4y ago
    I guess we'll find out if they have learned anything since the XML Signature specification. That was an adventure, trying to find a subset that actually did what it said it did.
    - bawolff 4y ago
      XMLSignature is one of the worst security standards i have ever read. Do we sign the bytes of the document? No, we canonicalize it first? How do we canonicalize? Multiple ways. Do all documents with the same canonicalization have the same DOM? No. Which part of the document do we sign? Up to you. Its a wonder there aren't more major saml breaches.
      - hinkley 4y ago
        The biggest problem is that getElementByID doesn’t fucking work. And then if you sign sibling documents, you essentially have most of the same problems you have with ensuring a zip file doesn’t have a malicious payload, because file cannonicalization is fraught with issues. It took me a couple pages of don’ts to nail it down, and I missed a big one that I didn’t see until pretty late in the project.
MBCook 4y ago
So if Google, Apple, and Mozilla all opposed this what are the chances it ever actually becomes useful? Just because something was given the stamp of approval by the W3C doesn’t mean they actually have to implement it.
- jgerrish 4y ago
  That use case chart is kind of interesting. 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?
- deleted 4y ago
  [deleted]
- denton-scratch 4y ago
  IETF recommendations have to have a working implementation. A paper standard with no working implementation is just onanism, whoever promulgates it. I think the W3C got lost in their XML dreams, and got huffed by WHATWG, whose standards I actively dislike.
teg4n_ 4y ago
I don’t understand the point of having a specification when 2 out of the 3 major browsers have objected. Who will implement it? Why bother with this?
- fabrice_d 4y ago
  The W3C doesn't produce only browser-related specifications. Service providers will implement, eg. instead of login with a user/password they will support some the DID methods. 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 https://www.w3.org/2022/03/did-fo-report.html for details) and a decision was made according to the W3C process. All good!
  - WkndTriathlete 4y ago
    Having read through the abstract and the first example of the specification I'm highly skeptical that the W3C process worked to produce something that is actually useful, in the sense that it ends up widely used. DID kind of strikes me as ASN.1 "with crypto/distributed ledger" stuff tacked on top of it.
- topspin 4y ago
  Because expecting standardization of DID methods at this point is unreasonable. A premature attempt to standardize DID methods would be both futile and likely harmful. 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.
jiggawatts 4y ago
Something that should be a bit of a warning flag is that I have two decades of identity-related experience but I still have no idea what DID even is. 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.
- A4ET8a8uTh0 4y ago
  I mean.. as I understand it, you read specs to understand something and as I kept reading it, I have absolutely zero idea what it is or even supposed to be. What is a problem it is trying to solve? I dislike it, because I immediately assume it cannot be good for me.
- topspin 4y ago
  I found it all pretty simple after looking at it briefly when I first learned about it. 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.
  - WhyNotHugo 4y ago
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
anon25783 4y ago
I may be suffering from a deficiency of reading comprehension. Can someone please explain to me in plain terms what a DID is and what it's for? It's a "globally unique persistent identifier that does not require a centralized registration authority"[1] - great, an identifier for what exactly? Is it just supposed to be an identifier for anything at all? Local and remote resources? People? Pokemon cards? [1] https://www.w3.org/TR/did-core/#terminology https://www.w3.org/TR/did-core/#terminology
- deleted 4y ago
  [deleted]
- duskwuff 4y ago
  It's an attempt to put a "standards-compliant" veneer of legitimacy on "Web 3.0" blockchain nonsense. The list of supported methods at https://www.w3.org/TR/did-spec-registries/#did-methods https://www.w3.org/TR/did-spec-registries/#did-methods should make clear who this is really for.
  - outsomnia 4y ago
    Baidu's did is literally "ccp:" ...
  - canadaduane 4y ago
    I think this is an unfair generalization. The core of the DID spec was developed by the folks at the Internet Identity Workshop, who have been discussing identity far longer than blockchain even existed. 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).
  - 4y ago
O__________O 4y ago
The objections by Mozilla & Google make sense if you assume by denying their requests that the methods should be define prior to moving forward, but to me, the core as defined is more than enough to move forward and the next step is to define the methods. 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/ https://identity.foundation/peer-did-method-spec/ If there’s an significant issue with moving forward, I am not understanding it.
aasasd 4y ago
Wow, the person who wrote that text has some talent for bureaucratese. It's comparatively rare to see that in English, since the language tends toward clear verbs and the active voice. But here I had to re-read a bunch of sentences to figure out what refers to what, while wondering if I need to take a coffee break. I would say that the author probably moonlights as a writer for NYT or something—if the dryness of the document wasn't quite outstanding, beyond what is still considered fit for consumption.
- IceHegel 4y ago
  > It is not questioned that any single DID method might fail to achieve one or more of these properties. The consideration here is whether the proposed DID identifier syntax and associated mechanisms has been sufficiently shown to have defined an extensible class of identifiers that has these properties. 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.
  - quickthrower2 4y ago
    Maybe like saying any HTML element alone can’t build you say… Slack, but with a bunch of them you can. Tldr: it is lego?
valray 4y ago
The notion of decentralized identity has been an enchanting vision since Christopher Allen first articulated it in 2016. Since then, DID spec has been around for years in draft form, and there are at least a dozen vendors and/or projects producing DID-compatible or DID-relevant technology. 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).
- dmitriid 4y ago
  > Of course, these different packages are not (yet) compatible 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
- chrisco255 4y ago
  The SIWE movement probably will win out, imo. Brave already supports it natively, and services like ENS are growing in popularity and use cases. And MetaMask itself is already at 50 million installs. Most other smart contract blockchains are Ethereum compatible, so you can use the same account (via MetaMask or wallet of your choice) across blockchains pretty easily. It's also dead simple to implement as a web developer, and it's a pleasure to use as a user.
no_circuit 4y ago
My TLDR. DID is already a registered URI scheme [1]. The method on a DID [2] is more or less a URI sub-scheme / protocol. Its for the blockchain / web3 crowd for something like the definition of a NFT. Most of their startups will shut down in a year or two anyways. Won't really matter. No one is going to manually type these in, or understand them by reading them. I'd agree that there really isn't a point of declaring it a standard as the DID scheme is already registered. [1] https://www.iana.org/assignments/uri-schemes/prov/did https://www.iana.org/assignments/uri-schemes/prov/did [2] https://www.w3.org/TR/did-core/#methods https://www.w3.org/TR/did-core/#methods
vivegi 4y ago
There is validity in the W3C position as well as the objections raised by the various parties. However, the respective positions of the parties are on different axes. 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.
georgia_peach 4y ago
W3C has been on the sidelines for a while now. WHATWG--mostly Google people--calls the shots.
DavideNL 4y ago
An "Explain Like I'm Five" of what DID is (for those who don't know, like me): "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." https://www.w3.org/TR/did-core/ https://www.w3.org/TR/did-core/
- TuringTest 4y ago
  So, it's like business cards? 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.
- xeromal 4y ago
  How does one prove they own the DID?
  - NoGravitas 4y ago
    That's up to the 'method' part, which is what all the fuss is about.
    - xeromal 4y ago
      Ok, so if I show my did to someone's they're going to reach out to the method and ask for verification. How does the method place know that the person using the did is the right person? I assume it's some kind of federation? They send me over to the method place, I authenticate, and get kicked back?
      - 4y ago
smarx007 4y ago
As a user, I am very happy that W3C has overruled the objections. As a developer, it may a bit of a PITA, albeit a necessary one. 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 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 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).
- barbarbar 4y ago
  Isn't BankID only used in Sweden? At least I have not heard that it is used in Norway, Finland or Denmark.
  - dagw 4y ago
    Sweden and Norway both use BankID and I believe they are compatible. Finland and Denmark have very similar systems. 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.
  - jgilias 4y ago
    Having lived in both Sweden and Norway, I can say for sure that it's used in both places. I'm not sure though if I could've used my Swedish bankid to log into a Norwegian bank.
ixxie 4y ago
Decentralization is a legitimate and important topic that is confused by the hype-driven blockchain bandwagon: a flock of a thousand red herrings. When searching for actual foundations to build a DApp on, you typically find libraries published by Crypto-startup-of-the-Week LTD. Why should I trust them? 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/ https://www.w3.org/TR/activitypub/ [2] https://w3c.github.io/did-core/ https://w3c.github.io/did-core/ [3] https://www.w3.org/TR/vc-data-model/ https://www.w3.org/TR/vc-data-model/
deleted 4y ago
[deleted]
Communitivity 4y ago
Caveat: I know several people involved in the DID standards development and consider them friends. 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. [1] https://www.w3.org/TR/did-spec-registries/ https://www.w3.org/TR/did-spec-registries/
tgsovlerkhgsel 4y ago
From Mozilla's objection: "The lack of restrictions on the registry are allowing methods ... which are actively globally harmful to sustainability." That seems to me like Mozilla trying to push their social justice goals down into tech standards now.
- dane-pgp 4y ago
  That's a rather flamebaity opinion, but you have a point. 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."
unreal37 4y ago
My take is that the Director of the DID working group is tired and wants this to be over. They want to enjoy a few months break and some future Working Group can deal with the problems. 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.
justcodin 4y ago
Hopefully this heaping festering pile of droppings called Decentralized Identifiers will go away.
fmajid 4y ago
Seems it's going to flop as hard as the Semantic Web and RDF, if not harder, given Google and Mozilla are not going to implement it, and Apple never implements anything anyway,
tuch 4y ago
Great post

289 points by shiftingleft 4y ago

"Mozilla: 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)." "The Director concludes that the balance lies in favor of the DID developer community, encouraging it to continue its work and search for consensus on standard DID methods. The objections are overruled."

cratermoon 4y ago
Where have I heard this before? https://www.wired.com/2012/07/developer-quits-oauth-2-0-spec-calls-it-a-bad-protocol/ https://www.wired.com/2012/07/developer-quits-oauth-2-0-spec...
- aidenn0 4y ago
  For those of us who aren't webdevs, what was the final fate of OAuth 2.0?
  - ukulele 4y ago
    It's very widely used. Most SSO providers are using it, including the biggest ones.
    - bawolff 4y ago
      Although personally i don't think its a great spec. Its a good enough spec (certainly better than saml, shudder) - "good" is not the same as works acceptably or popular.
      - cratermoon 4y ago
        After extensive experience with SAML and other specs, I don't think it's better than SAML in a fundamental way. It's certainly better in that it doesn't require a mind-numbingly verbose blob of XML, but strip away the XML and all that verbosity, and you basically end up with... kerberos.
  - dathinab 4y ago
    OAuth 2.0 basically killed generic identity providers leaving us with a hand full of SSO providers you can use. It also instead of a simple generic OAuth 2.0 library we had (and still have) separate libraries for the various OAuth SSO providers. Through this has converged a bit since the initial days. But the initial days where enough to cause harm to the ecosystem. It also needs a variety of "extensions" you have to add to make it secure. But which can slightly differ between SSO providers. (Note sure but I thing some of this "extensions" have been added to the spec retrospectively.) In conclusion I would say while OAuth 2.0 is widely used it also was widely harmful and lead to a further centralization and to users being more dependent on a few mega corporations. In this context it has fully failed some of the initial ideas people had about it when it's design started. Just because something is widely used doesn't mean it's not harmful or well designed. Adaptation of technology is often not driven by what is the technological best solution especially wrt. web technology.
  - cratermoon 4y ago
    You may have heard the aphorism, "All problems in computer science can be solved by another level of indirection." This, or some variation of it, is known as the fundamental theorem of software engineering, variously attributed to Andrew Koenig, Butler Lampson, and David J. Wheeler. With oauth2, literally any sort of authorization (or, in theory, authentication) is possible, but first you have to ask some endpoint for the details. In the case of oauth2, the core concept for authorization is "scope", but nothing is prescribed in scopes. They can literally be anything the auth provider describes. In theory, it's not supposed to matter – a consumer is just supposed to be able to pass around scopes from providers and let them determine if access is allowed. In practice, there's no practical way to reason about scope+resource permssions. Oh, and despite the name, oauth2 is not about authentication, it's only about authorization. The OIDC spec, built on oauth2, provides authentication services, but again, there's no spec. Every auth provider does what it wants. It's sometimes said that oauth2 is great for consultants, because any organization wanting to deal with it must hire (or contract with) specialist who can sort out the ill-defined problem space.
    - tnzk 4y ago
      > despite the name, oauth2 is not about authentication, it's only about authorization OAuth is short for Authorization in the first place. https://datatracker.ietf.org/doc/html/rfc6749 https://datatracker.ietf.org/doc/html/rfc6749
      - quickthrower2 4y ago
        What a brilliant and unambiguous abbreviation!
        cratermoon 4y ago
        Because this is my specialty, I long ago learned to specify either authn or authz. The OAuth spec should have been the OAuthz spec.
        tnzk 4y ago
thsijustin 4y ago

encryptluks2 4y ago

Sure W3C, let's just add 30 new APIs to track users mouse activity, proximity, fonts, etc.

deleted 4y ago
[deleted]

Taek 4y ago

I've been following DID for a while and I really don't think its the right approach. The voices of concern from Mozilla and Google are spot on: the DID specs expect everyone to coordinate on finding the right structure for different types of data but the real world is messy and no "correct" structure exists. 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.

deleted 4y ago
[deleted]
abernard1 4y ago
> but the real world is messy and no "correct" structure exists. 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.
fabrice_d 4y ago
Maybe usage will converge on a few dominant methods (be it did:key, did:web or some other one), based on successful applications. This is pretty similar to URIs, which were defined very openly, and where for instance http(s):// took over gopher:// and ftp://
- bawolff 4y ago
  > This is pretty similar to URIs, which were defined very openly, and where for instance http(s):// took over gopher:// and ftp:// 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.

bawolff 4y ago

A standard flexible enough where you can do literally anything is usually a bad standard. The point of standards is to write up some small-ish base that everyone can agree on so that people can talk to each other. A standard containing everything where each implementation implements a different incompatible subset, is a failure.

RcouF1uZ4gsC 4y ago
Also, too much flexibility ends up being a security nightmare. 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.
- hinkley 4y ago
  I guess we'll find out if they have learned anything since the XML Signature specification. That was an adventure, trying to find a subset that actually did what it said it did.
  - bawolff 4y ago
    XMLSignature is one of the worst security standards i have ever read. Do we sign the bytes of the document? No, we canonicalize it first? How do we canonicalize? Multiple ways. Do all documents with the same canonicalization have the same DOM? No. Which part of the document do we sign? Up to you. Its a wonder there aren't more major saml breaches.
    - hinkley 4y ago
      The biggest problem is that getElementByID doesn’t fucking work. And then if you sign sibling documents, you essentially have most of the same problems you have with ensuring a zip file doesn’t have a malicious payload, because file cannonicalization is fraught with issues. It took me a couple pages of don’ts to nail it down, and I missed a big one that I didn’t see until pretty late in the project.

MBCook 4y ago

So if Google, Apple, and Mozilla all opposed this what are the chances it ever actually becomes useful? Just because something was given the stamp of approval by the W3C doesn’t mean they actually have to implement it.

jgerrish 4y ago
That use case chart is kind of interesting. 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?
deleted 4y ago
[deleted]
denton-scratch 4y ago
IETF recommendations have to have a working implementation. A paper standard with no working implementation is just onanism, whoever promulgates it. I think the W3C got lost in their XML dreams, and got huffed by WHATWG, whose standards I actively dislike.

teg4n_ 4y ago

I don’t understand the point of having a specification when 2 out of the 3 major browsers have objected. Who will implement it? Why bother with this?

fabrice_d 4y ago
The W3C doesn't produce only browser-related specifications. Service providers will implement, eg. instead of login with a user/password they will support some the DID methods. 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 https://www.w3.org/2022/03/did-fo-report.html for details) and a decision was made according to the W3C process. All good!
- WkndTriathlete 4y ago
  Having read through the abstract and the first example of the specification I'm highly skeptical that the W3C process worked to produce something that is actually useful, in the sense that it ends up widely used. DID kind of strikes me as ASN.1 "with crypto/distributed ledger" stuff tacked on top of it.
topspin 4y ago
Because expecting standardization of DID methods at this point is unreasonable. A premature attempt to standardize DID methods would be both futile and likely harmful. 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.

jiggawatts 4y ago

Something that should be a bit of a warning flag is that I have two decades of identity-related experience but I still have no idea what DID even is. 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.

A4ET8a8uTh0 4y ago
I mean.. as I understand it, you read specs to understand something and as I kept reading it, I have absolutely zero idea what it is or even supposed to be. What is a problem it is trying to solve? I dislike it, because I immediately assume it cannot be good for me.
topspin 4y ago
I found it all pretty simple after looking at it briefly when I first learned about it. 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.
- WhyNotHugo 4y ago

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]

anon25783 4y ago

I may be suffering from a deficiency of reading comprehension. Can someone please explain to me in plain terms what a DID is and what it's for? It's a "globally unique persistent identifier that does not require a centralized registration authority"[1] - great, an identifier for what exactly? Is it just supposed to be an identifier for anything at all? Local and remote resources? People? Pokemon cards? [1] https://www.w3.org/TR/did-core/#terminology https://www.w3.org/TR/did-core/#terminology

deleted 4y ago
[deleted]
duskwuff 4y ago
It's an attempt to put a "standards-compliant" veneer of legitimacy on "Web 3.0" blockchain nonsense. The list of supported methods at https://www.w3.org/TR/did-spec-registries/#did-methods https://www.w3.org/TR/did-spec-registries/#did-methods should make clear who this is really for.
- outsomnia 4y ago
  Baidu's did is literally "ccp:" ...
- canadaduane 4y ago
  I think this is an unfair generalization. The core of the DID spec was developed by the folks at the Internet Identity Workshop, who have been discussing identity far longer than blockchain even existed. 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).
- 4y ago

O__________O 4y ago

The objections by Mozilla & Google make sense if you assume by denying their requests that the methods should be define prior to moving forward, but to me, the core as defined is more than enough to move forward and the next step is to define the methods. 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/ https://identity.foundation/peer-did-method-spec/ If there’s an significant issue with moving forward, I am not understanding it.

aasasd 4y ago

Wow, the person who wrote that text has some talent for bureaucratese. It's comparatively rare to see that in English, since the language tends toward clear verbs and the active voice. But here I had to re-read a bunch of sentences to figure out what refers to what, while wondering if I need to take a coffee break. I would say that the author probably moonlights as a writer for NYT or something—if the dryness of the document wasn't quite outstanding, beyond what is still considered fit for consumption.

IceHegel 4y ago
> It is not questioned that any single DID method might fail to achieve one or more of these properties. The consideration here is whether the proposed DID identifier syntax and associated mechanisms has been sufficiently shown to have defined an extensible class of identifiers that has these properties. 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.
- quickthrower2 4y ago
  Maybe like saying any HTML element alone can’t build you say… Slack, but with a bunch of them you can. Tldr: it is lego?

valray 4y ago

The notion of decentralized identity has been an enchanting vision since Christopher Allen first articulated it in 2016. Since then, DID spec has been around for years in draft form, and there are at least a dozen vendors and/or projects producing DID-compatible or DID-relevant technology. 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).

dmitriid 4y ago
> Of course, these different packages are not (yet) compatible 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
chrisco255 4y ago
The SIWE movement probably will win out, imo. Brave already supports it natively, and services like ENS are growing in popularity and use cases. And MetaMask itself is already at 50 million installs. Most other smart contract blockchains are Ethereum compatible, so you can use the same account (via MetaMask or wallet of your choice) across blockchains pretty easily. It's also dead simple to implement as a web developer, and it's a pleasure to use as a user.

no_circuit 4y ago

My TLDR. DID is already a registered URI scheme [1]. The method on a DID [2] is more or less a URI sub-scheme / protocol. Its for the blockchain / web3 crowd for something like the definition of a NFT. Most of their startups will shut down in a year or two anyways. Won't really matter. No one is going to manually type these in, or understand them by reading them. I'd agree that there really isn't a point of declaring it a standard as the DID scheme is already registered. [1] https://www.iana.org/assignments/uri-schemes/prov/did https://www.iana.org/assignments/uri-schemes/prov/did [2] https://www.w3.org/TR/did-core/#methods https://www.w3.org/TR/did-core/#methods

vivegi 4y ago

There is validity in the W3C position as well as the objections raised by the various parties. However, the respective positions of the parties are on different axes. 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.

georgia_peach 4y ago

W3C has been on the sidelines for a while now. WHATWG--mostly Google people--calls the shots.

DavideNL 4y ago

An "Explain Like I'm Five" of what DID is (for those who don't know, like me): "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." https://www.w3.org/TR/did-core/ https://www.w3.org/TR/did-core/

TuringTest 4y ago
So, it's like business cards? 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.
xeromal 4y ago
How does one prove they own the DID?
- NoGravitas 4y ago
  That's up to the 'method' part, which is what all the fuss is about.
  - xeromal 4y ago
    Ok, so if I show my did to someone's they're going to reach out to the method and ask for verification. How does the method place know that the person using the did is the right person? I assume it's some kind of federation? They send me over to the method place, I authenticate, and get kicked back?
    - 4y ago

smarx007 4y ago

As a user, I am very happy that W3C has overruled the objections. As a developer, it may a bit of a PITA, albeit a necessary one. 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 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 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).

barbarbar 4y ago
Isn't BankID only used in Sweden? At least I have not heard that it is used in Norway, Finland or Denmark.
- dagw 4y ago
  Sweden and Norway both use BankID and I believe they are compatible. Finland and Denmark have very similar systems. 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.
- jgilias 4y ago
  Having lived in both Sweden and Norway, I can say for sure that it's used in both places. I'm not sure though if I could've used my Swedish bankid to log into a Norwegian bank.

ixxie 4y ago

Decentralization is a legitimate and important topic that is confused by the hype-driven blockchain bandwagon: a flock of a thousand red herrings. When searching for actual foundations to build a DApp on, you typically find libraries published by Crypto-startup-of-the-Week LTD. Why should I trust them? 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/ https://www.w3.org/TR/activitypub/ [2] https://w3c.github.io/did-core/ https://w3c.github.io/did-core/ [3] https://www.w3.org/TR/vc-data-model/ https://www.w3.org/TR/vc-data-model/

deleted 4y ago

[deleted]

Communitivity 4y ago

Caveat: I know several people involved in the DID standards development and consider them friends. 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. [1] https://www.w3.org/TR/did-spec-registries/ https://www.w3.org/TR/did-spec-registries/

tgsovlerkhgsel 4y ago

From Mozilla's objection: "The lack of restrictions on the registry are allowing methods ... which are actively globally harmful to sustainability." That seems to me like Mozilla trying to push their social justice goals down into tech standards now.

dane-pgp 4y ago
That's a rather flamebaity opinion, but you have a point. 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."

unreal37 4y ago

My take is that the Director of the DID working group is tired and wants this to be over. They want to enjoy a few months break and some future Working Group can deal with the problems. 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.

justcodin 4y ago

Hopefully this heaping festering pile of droppings called Decentralized Identifiers will go away.

fmajid 4y ago

Seems it's going to flop as hard as the Semantic Web and RDF, if not harder, given Google and Mozilla are not going to implement it, and Apple never implements anything anyway,

tuch 4y ago

Great post