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.
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.
The document "Use Cases and Requirements for Decentralized Identifiers" [1] lays out the following summary of what they are trying to achieve:
"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.
(Disclaimer - I work in this space, but these words are my own).
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.
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.
I have a similar background, and I also know some of the people active in the DID community, and I spent a couple of years trying to get them to explain to me what problem it solved or show me a working application using the tech.
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.
Azure Active Directory is on its way to use DIDs [0]
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 :)
As far as I understand it (from skimming through a couple of docs and presentations), DIDs are similar to specs for assertions and/or attributes which are stored in a blockchain which functions as federation metadata datastore and IdP at the same time.
Conceptually, those solutions that you’ve worked with are about account principals and access management. When you deployed a smartcard, the human identity of the person you were assigning an account principal to was established offline, ultimately linked to proof of birth and residence.
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.
> 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.
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?
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.
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."
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.
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.
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 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).
> "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."
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 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?
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 should make clear who this is really for.
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)?
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).
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.
> 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.
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:
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.
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.
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.
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.
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."
[+] [-] jiggawatts|3 years ago|reply
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.
[+] [-] topspin|3 years ago|reply
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.
[+] [-] aasasd|3 years ago|reply
[+] [-] Communitivity|3 years ago|reply
"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.
[1] https://www.w3.org/TR/did-use-cases/
[+] [-] WaylonKenning|3 years ago|reply
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.
[+] [-] A4ET8a8uTh0|3 years ago|reply
[+] [-] dboreham|3 years ago|reply
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.
[+] [-] rufasterisco|3 years ago|reply
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...
[+] [-] high_5|3 years ago|reply
[+] [-] Spooky23|3 years ago|reply
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.
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] WFHRenaissance|3 years ago|reply
[+] [-] nl|3 years ago|reply
[+] [-] k__|3 years ago|reply
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.
[+] [-] tossacctpls|3 years ago|reply
[+] [-] godmode2019|3 years ago|reply
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.
[+] [-] capableweb|3 years ago|reply
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.
[+] [-] shiftingleft|3 years ago|reply
[+] [-] cratermoon|3 years ago|reply
[+] [-] thsijustin|3 years ago|reply
[deleted]
[+] [-] bawolff|3 years ago|reply
[+] [-] RcouF1uZ4gsC|3 years ago|reply
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.
[+] [-] vxNsr|3 years ago|reply
[+] [-] rambojazz|3 years ago|reply
[+] [-] Taek|3 years ago|reply
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.
[+] [-] smarx007|3 years ago|reply
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).
[+] [-] csmpltn|3 years ago|reply
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.
[+] [-] cle|3 years ago|reply
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).
[+] [-] eldenwrong|3 years ago|reply
[+] [-] barbarbar|3 years ago|reply
[+] [-] MBCook|3 years ago|reply
Just because something was given the stamp of approval by the W3C doesn’t mean they actually have to implement it.
[+] [-] anon25783|3 years ago|reply
[1] https://www.w3.org/TR/did-core/#terminology
[+] [-] duskwuff|3 years ago|reply
[+] [-] semiquaver|3 years ago|reply
It's blockchain bullshit that you can ignore.
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] ixxie|3 years ago|reply
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/
[2] https://w3c.github.io/did-core/
[3] https://www.w3.org/TR/vc-data-model/
[+] [-] valray|3 years ago|reply
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).
[+] [-] aasasd|3 years ago|reply
[+] [-] IceHegel|3 years ago|reply
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.
[+] [-] O__________O|3 years ago|reply
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.
[+] [-] vivegi|3 years ago|reply
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.
[+] [-] teg4n_|3 years ago|reply
[+] [-] Communitivity|3 years ago|reply
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/
[+] [-] unreal37|3 years ago|reply
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.
[+] [-] no_circuit|3 years ago|reply
[1] https://www.iana.org/assignments/uri-schemes/prov/did
[2] https://www.w3.org/TR/did-core/#methods
[+] [-] DavideNL|3 years ago|reply
"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/
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] georgia_peach|3 years ago|reply