This should be v0.1 based on the actual utility of the spec, just because it's been incubated for so long doesn't magically make it useful.
DIDs are fundamentally antithetical to privacy and will only enable a deeper and more obscure level of tracking to all applications that use them. They were originally inspired for mapping public blockchain use-cases, but IMO personal identity and related keys should _never_ be put on a public chain, who thinks this could ever be a good idea or architecture?
All of the suggested "workarounds" to layer on privacy to DIDs are just lip service in the spec, there's zero technical requirements for an implementation.
I worry that DIDs based on this spec will be deeply harmful if widely deployed with the multiple layers of abstraction, required dependencies on massively complex things like JSON-LD, and abundance of implementation-time choices. It's such an easy "spec" to embrace and extend by big tech, it has no teeth to prevent tracking abuse and it should develop those as hard normative implementation MUSTs before v1.0 versus the non-normative "Privacy _Considerations_" it has now.
> DIDs are fundamentally antithetical to privacy and will only enable a deeper and more obscure level of tracking to all applications that use them. They were originally inspired for mapping public blockchain use-cases, but IMO personal identity and related keys should _never_ be put on a public chain, who thinks this could ever be a good idea or architecture?
Functionally, how different would this be from the status quo? Between the FAANGs basically already having near-universal identifiers for all of us and everyone's information being leaked in a variety of breaches to where it's essentially public knowledge to any black hats or state actors I'm not sure how down the downsides are?
DIDs make use of public key encryption, which does not require storing private data on a public chain to be useful. All that's needed is a public key directory for public entities, everything else can be verified based on said pubkey of those entities who issue credentials
a new identifier (pubkey) can be created for each organization you engage with
OPs argument seems based on imagination has nothing to do with how DIDs are meant to work
Well DID spec doesn't tell us to put identity or related keys in public. DIDs coupled with the VC model (https://www.w3.org/TR/vc-data-model/) allows identity credentials issued by any "trusted" issuer to be validated. Here trusted means whoever the user trusts, be it government or big tech or anything else.
The issue is not other identity information in the DID, it is the identifier mandate itself is antithetical to privacy.
Having a global identifier as you go about the internet means that parties can correlate and share information about you.
Trying to solve that by isolation (using a DID per party you want to interact with) negative affects their usability and privacy properties with verifiable credentials.
Then there ought to be a way tp cheaply produce verified but ephemeral identities, which may be discarded after a particular transaction.
User: I want to use this site.
Site: we need your trusted identity.
User: Trusted Third Party, please make an anonymous identity for me.
TTP: I know you, user; here's your new identity.
User: Site, look here, TTP which you trust says I'm legit.
Site: OK, transaction completed. '
User: (destroys the identity's private key.)
It's not very different from TLS certificates, or OAuth tokens, or even ephemeral credit card numbers. The thing is to have a common Trusted Third Party, and somehow keep the number of such parties large enough.
> The thing is to have a common Trusted Third Party, and somehow keep the number of such parties large enough.
Aye, there's the rub. What's to stop most sites from only allowing Google/Facebook as the Trusted Third Party? And you also need to worry about security breaches, or one company quietly buying up all the independents, or governments legislating in back doors, or every service you use ganging up behind the scenes to try and collate your "anonymous" public keys back into a single identity.
Don't get me wrong, I do think there's a way forward, but it's not going to be easy.
It means: "TTP certifies that the user presenting identity X is indeed a user known to me, and is an acceptable user for the purposes that Site asked about: not a bot, not a spammer".
The idea that TTP certifies User against particular requirements of Site, and gives User an identity which User can give to Site. TTP keeps the "real" identity of the user hidden from Site, replacing it with a temporary identity.
TTP does not givel Site anything; User shares the temporary identity with Site. Then Site can check the identity, cryprographically and/or by asking TTP directly.
The identity should also be checked by a challenge-response protocol between Site and User, so that stealing it from User would be pointless. E.g. User keeps the private key and Site receives the public key, and Site asks to encrypt a random string, then tries to decrypt it.
> It means: "TTP certifies that the user presenting identity X is indeed a user known to me, and is an acceptable user for the purposes that Site asked about: not a bot, not a spammer".
How does the TTP know that the user isn't a spammer? Is there a backchannel for reidentifying users in case of abuse allegations? Does the TTP just refuse to issue credentials on behalf of the same user very frequently?
That's incorrect. DID make use of pubkey cryptography to create a new identifier for every entity one operates with... this argument is based on imagination
Where did you get the idea 'global' from?
Have you seen Peer DIDs? Most specifications advise you to create limited purpose identities. Use a widely known one when it suits you, like a LinkedIn profile, or Twitter page.
Exactly. DIDs don't need to be global identifiers. I can create multiple DIDs. Maybe one of them gets issued an identity VC. When required I may use that DID to prove my identity, otherwise use the other DIDs.
But what would be the solution? I've already played around with DIDs and Verifiable Credentials in the SSI-context and I like it from a tech perspective. I am also not sure if the spec should be held accountable to potential privacy misuses – the user should be. Additionally, you don't have to use the big tech solutions. The tech is inherently open, just look at the many DID methods.
But what I am concerned of are consortium (identity) networks like Sovrin which are run by a hand full of companies. At least in Germany, the government is starting to like what they are doing which is horrible imo. The identity layer of a state should not be governed by a consortium of private companies, no matter what fancy governance model they have.
The assumption that DID has to be in a public chain is flawed.
You should really look at DID use as a mechanism to decentralised the use of certificates. In my mind its definitely not not very different from PKI based certificates or any token based solution like OAuth. The difference is its potential to be decentralised.
DIDs do not specify keys should be written to a public chain, another commented mentioned the VC spec.
Another thing to look at is the did:peer method, it allows you to have a direct connection with a party for secure communication. Either party could root their did against a public key (eg a public organisation) but that is not required.
This spec is awesome for us. Much of the cannabis space in USA depends on these government systems that require a central authority (read: government software) to generate IDs and lot-identifiers for items in the system (or they charge $0.40 for single-use RFID tags). And those systems are buggy, offline, broken, errors, etc, etc, etc.
So, this distributed ID system would permit us to take the central generator OUT of the process -- and do so following a coming global standard (rather than the current attempts to try one-off "unique" methods).
We were already doing something very similar to what is in this document -- which is nice, validates some of what we were already thinking. And I think it will be easier for us to bring others in with some "official" specifications. (I know it's draft only right now).
If I recall correctly there is related work getting some traction in Canada too, which is on the whole further up the curve on some of this stuff due to federal legalization.
Especially in British Columbia. The government is way forward in implementing "TrustOverIP.org" type DID/VC/ETC systems for interacting with the government
You're both sorta correct; cannibis in Canada is covered by Health Canada who's still taking reports via CSV upload. It's like a 4k column thing. And no IDs
It's going to be a mix of federal, provincial, maybe even municipal government systems (e.g. business licenses for cannabis retail). I imagine they'll have a hybrid of new-, old-, and low-tech like many other areas. Somehow people will muddle through.
Generally speaking, In the model of VCs et al espoused by TrustOverIP... the user's "Did" is never publically exposed.
The only DID that goes into some sort of Trust Registry is the DID of a PUBLIC ISSUER. (eg. GLIEF, Good Health Pass Coalition", etc._
For the user's did, it is primarily exchanged off chain, in a unique pairwise manner. So the user has a different DID for each relationship, and that DID is not publically disclosed anywhere.
Great to see some progress with the standard. We’ve been working on generating DIDs for our upcoming users. We’re using IDX + Ceramic as our backend.
For our use case (making web3 profiles like https://shokunin.dns.xyz), it’s cool to have a DID as a chain agnostic ID. I’m curious what people here have been using DIDs for besides that.
It sounds like you understand enough about DID's to start incorporating them into an actual product. You'll have a bunch of users, and you want to give each of your users a DID.
Congratulations! I certainly wasn't able to get that level of understanding from the document.
In Section 1.1, it says the DID "did:example:123456789abcdefghijk" resolves to a DID document.
Would you then be running some software with all your users' DID's on some server identified by a subdomain, for example identity.dns.xyz? And then the DID for one of your users, let's call her Alice, would be "did:identity.dns.xyz:123456789abcdefghijk"?
And then if I run a totally different company, and Alice wants to use my website, instead of registering a separate account with my website, she can instead type "did:identity.dns.xyz:123456789abcdefghijk" into my website? Does my site's software then contact identity.dns.xyz to ask it something? Or is all the information my site needs to do its thing contained in the DID itself?
Is "123456789abcdefghijk" the hash of some document that's returned to my website by the identity.dns.xyz server? Or is Alice running some identity management browser extension that knows to present a document whose hash is "123456789abcdefghijk" to my website? Or instead of being the hash of a document, is "123456789abcdefghijk" the hash of a public key which signs something {returned by the identity.dns.xyz server | presented by Alice's software}? Or is "123456789abcdefghijk" just a string your webserver happened to generate to identify Alice uniquely that came from /dev/urandom or a PRIMARY KEY column in your database that has no cryptographic meaning?
If Alice's DID document is cryptographically linked to her DID, how does she update it? If the DID is the hash of the document, does that mean Alice gets a new DID whenever she edits her profile on dns.xyz?
What if Alice updates her dns.xyz profile because she accidentally pasted an Ethereum private key into a forum post, then generated a new address that wasn't compromised? How does my website know that the user presenting Alice's DID document is Alice sending her most up-to-date DID document, rather than Eve sending an outdated DID document with the compromised Ethereum address that once belonged to Alice, in an attempt to get my website to interact or send stuff to the compromised Ethereum address?
Is a DID like a generalized Bitcoin address, a generalized IPNS name, a generalized email address, or something else entirely?
It is preferable that users bring their own DIDs, rather than you assigning them DIDs as a service provider, to ensure user autonomy. However, you can create DIDs via websites as you are suggesting, using did:web [1].
DIDs are structured or namespaced by DID Methods: the part after "did:" is called the DID Method name, and each Method has its own specification and implementations. There is a registry of DID Methods [2], although it is not a requirement that DID methods be registered. There is a document comparing some DID methods using a Rubric: [3].
> [...] instead of registering a separate account with my website, she can instead type "did:identity.dns.xyz:123456789abcdefghijk" into my website?
It can obviate account registration per website, yes.
For usability reasons it is often considered desirable that users not have to know about DIDs, type them or see them. The functionality could instead be handled by the user's software. There is a browser standard and polyfill in development which can be used for this: Credential Handler API [4].
> Does my site's software then contact identity.dns.xyz to ask it something? Or is all the information my site needs to do its thing contained in the DID itself?
If you have "did:identity.dns.xyz:...", it would depend on what the "identity.dns.xyz" DID method is. If you don't know what the "identity.dns.xyz" DID method is, you could ask a DID resolver that you trust; but they might not know either. If instead you had "did:web:identity.dns.xyz:...", you would indeed contact `identity.dns.xyz` over HTTPS to request the respective DID document. If you instead have a "did:key:..." DID [5], you would indeed have all the information contained in the DID itself, as did:key encodes the public key. In other kinds of DID methods, you may need to contact a peer-to-peer network to resolve the DID.
> Is "123456789abcdefghijk" the hash of some document that's returned to my website by the identity.dns.xyz server?
It depends on the DID method. If you are using did:web, which is based on HTTPS as mentioned, there is no hash, although this could be handled using hashlinks [6], which is mentioned in the did:web specification as a TODO. In other DID methods, the method-specific-id (the "123456789abcdefghijk" part) is a hash which might refer to some static data or initialization state.
> Or is Alice running some identity management browser extension that knows to present a document whose hash is "123456789abcdefghijk" to my website?
Possibly, depending on the DID method and how it is implemented. But DIDs are generally expected to be public, globally resolvable, and highly available.
> [...] is "123456789abcdefghijk" the hash of a public key which signs something
Could be, again depending on the DID method. Some DID methods are based on decentralized ledger technologies where the method-specific-id represents an account id derived from public key hash, e.g. did:ethr [7] and did:tz [8].
> [...] {returned by the identity.dns.xyz server | presented by Alice's software}?
Yes, if you are authenticating the user with a DID, generally you would ask them to sign a challenge using authentication key material from their DID document. The DID document is what the DID resolves to, and it includes public keys. In the case of did:key, the DID document contains a single key as encoded in the DID. In the case of a DID method based on a public key hash, the public key must be provided or looked up somehow, or the signing algorithm must support public key recovery [9].
> Or is "123456789abcdefghijk" just a string your webserver happened to generate to identify Alice uniquely that came from /dev/urandom or a PRIMARY KEY column in your database that has no cryptographic meaning?
The DID method determines the structure and meaning of the method-specific-id (the "123456789abcdefghijk" part). If you are using did:web, the string is not cryptographic but corresponds to a HTTPS URL.
> If Alice's DID document is cryptographically linked to her DID, how does she update it?
She performs a DID document update operation [10]. If the DID method is based on a decentralized ledger technology (e.g. btcr [11], ethr, tz), she might publish a transaction to the corresponding network or make a call on a "smart contract". in the case of a did:key, the DID document cannot be updated.
> If the DID is the hash of the document, does that mean Alice gets a new DID whenever she edits her profile on dns.xyz?
If the DID method is static (basing the DID on the document hash entirely), it would probably have to be a new DID, but if it is only an initial document hash, the DID method could provide for verifying and applying updates somehow. There are also some properties for indicating equivalence between DIDs which might be useful [12].
A DID document could also be updated while still using hashes for integrity protection and referencing if the DID method uses the hash as the DID document version ID. A DID can be resolved at a given version ID using the versionId parameter [13].
For privacy, generally DID documents should not include personal data [14]. Edits to a profile on would then only affect DID documents if they are updating keypairs, or indicating relationships with other DIDs (e.g. using alsoKnownAs), or updating service endpoints, etc.
For decentralization and user autonomy, users should be able to update their DID documents with their software directly, rather than having a website in control of their DID and having to ask the website to update it. In the web context that may mean a browser extension or key management API. But there are institutional use cases where the website is expected to have control.
> How does my website know that the user presenting Alice's DID document is Alice sending her most up-to-date DID document, rather than Eve sending an outdated DID document with the compromised Ethereum address that once belonged to Alice [...]
Often DIDs are resolved publicly or by contacting a network rather than via asking the user (did:peer [15] is a different case). But the concern still applies. Updating a DID document to remove a compromised key is called revocation [16]. The DID method should have some protocol for how updates are performed, which may include how they are ordered, such as by being witnessed or confirmed by some entity or network. The question of the valid state of a DID document should be abstracted by your DID resolver [17].
> Is a DID like a generalized Bitcoin address, a generalized IPNS name, a generalized email address, or something else entirely?
More like a generalized Bitcoin address I think, although there are comparisons to be made with the others. Another idea: generalized PGP keys. It is primarily about identity, rather than about communication, storage or payments.
For more info I recommend checking out the Decentralized Identity Foundation (DIF)'s FAQ: "What is a DID?" [18].
Thanks so much for taking the time to write a detailed answer. I was going to do this after work, but you’ve completely outdone what I would have said.
Idk, maybe it's just because I've already gotten used to ENS addresses, but I'd rather not have something that works become fragmented because w3 who's been asleep at the wheel on this feels left out and wants to remain relevant.
How would DNS work with this? If it's chain agnostic then it doesn't seem possible to register names like you can now with them on Ethereum.
They’re different things. We generate the DID when the user creates an account. We use wallets to create that DID.
The issue of ENS is a side one. We do happen to have domains (and issue subdomains) on ENS, but that’s to have a pretty URL to resolve the DID. They’re not interdependent.
The DID could be updated to rotate keys without the need to notify anyone that is aware of it, with the random value, you need to share the new one with everybody, one implementation doing this is sidetree (https://identity.foundation/sidetree/spec/)
Not in DID, no, but can refer to DLT which is defined as:
> distributed ledger (DLT)
A non-centralized system for recording events. These systems establish sufficient confidence for participants to rely upon the data recorded by others to make operational decisions. They typically use distributed databases where different nodes use a consensus protocol to confirm the ordering of cryptographically signed transactions. The linking of digitally signed transactions over time often makes the history of the ledger effectively immutable.
Either your verifyable data registry is a blockchain or the thing should be called "root source of trust centralized, federated identifiers".
Because otherwise the thing is like a DOI, where you're relying on a bunch of organisations to hand out random 128bit values out to people.
its really hard for me to understand this document, it would be nice to have a section with better examples and relationship to things that are more widely known. how does this relate to http and similar protocols to get the documents, how is it related to foaf+ssl and webid. how is the cryptography part really done and what is the relationship to pgp. i know all these things are completely different but i could not explain in what way...
that explains a lot but also how would this even work? every solution that relies on generic did s would have to implement all supported methods? or is every method an incompatible namespace in which case what is even the point of did? i really don't get it...
TL;DR it remains to be seen if DIDs create more problems than they solve.
I think you got it correctly. "DID" is basically a qualifier for identifiers which can have metadata resolved about them using 'some mechanism', and there are 100+ mechanisms (DID methods). These all have varying technical and non-technical differentiating factors, partially described in the DID Rubrick https://w3c.github.io/did-rubric/ .
DID methods will not have consistent features nor will the metadata resolved by them consistently meet your data requirements, so you will be limited both in terms of methods you can accept for your use case, and DIDs you can accept within that.
One if the base ideas is that it puts users in control of their identity by "owning" a DID, presumably with a lot of local software assistance. This is likely not a single DID, both for interoperability and privacy reasons.
It is also likely the DID will be "controlled" by others in some cases - e.g. if a employer or bank accepts DIDs as an authentication system, they will want to be able to guarantee the authentication meets their standards/regulatory requirements.
and regarding ceramic : i tried finding out what the heck that was and had the same amount of luck as with did. is this written for a different species of developers? they seem to try solving the same problems of ipfs pubsub and ipns but without any hint how they solved it.
Is this a generalization of the SSL certificate authority system? An SSL certificate is a signature from a trusted authority that the corresponding private key of some signed public key is the owner of some domain, optionally with some address information as well.
Can DIDs be used to e.g. prove that my name is Rune Svendsen and that some provided profile picture is actually me? If so, it seems like this could be a decentralized replacement for Facebook, whose main function — in my opinion — is tying together a digital and physical identity.
> Is this a generalization of the SSL certificate authority system?
No, DIDs are a way to claim a decentralized identity but it doesn't prove any details related to our physical world, what you are mentioning about SSL is more-or-less Web of Trust, which DIDs do not support.
> Can DIDs be used to e.g. prove that my name is Rune Svendsen and that some provided profile picture is actually me?
No, anyone could easily claim that, and you need to be aware of who you trust.
No, it doesn't? Colon is a special character only in the hostname part of a URI to signify the port number. It's free to use anywhere else without escaping.
Yes - technically you don't need to escape : in most places, but many implementations will do so anyway as they use a single encoding method for all URI components. (And if you don't encode these things where they are not required then you'll soon find lots of downstream systems that break).
That's probably what someone would have said if they saw Facebook 20 years ago.
The intention here is to get out in front of FAANG before they can make their own, proprietary standards for ID. As terrifying as it is, personal identification is going to become a huge part of the next 10 years of computing, and potentially radically change the way we interact with the web.
The distinctive capability is offline auth. I guess we are still holding out that eventually it will get easy enough to write offline (aka p2p, user-agent only, interconnected apps) that having an auth standard becomes an accelerator.
If FB or some other big actor were to define identity standards, the standards would at least be friendly towards their operations, if not optimized for it.
Risks would include, privacy concerns, from obvious to not yet identified; the standards not being good at things other interested parties may like; mechanisms that encourage/require normal users to delegate some functions to private third parties; mechanisms that make it hard for normal users to use their identities as they choose; mechanisms that place more burdens on the user for retail fraud ("identity theft", for instance); the list goes on.
For more, consider the ways that ID is used against people today. Now apply automation and a world-wide attack surface, and do not consider mitigations that might have an effect on some big actor's bottom line.
The basis for identity is that the receiving party has to make a decision based on some sort of trust relationship.
Everything really winds up being direct, indirect, or brokered, eg. :
- direct: you have a pre-existing account on a website.
- indirect: you have an account with a Company, and I let that company's employees sign in with SAML etc
- brokered: certificate authorities issuing certs based on domain/email/etc validation, and I accept those certs by accepting those authorities
We won't see the indirect model get any broader than it already has - nobody is going to accept Sign in with Apple in lieu of a birth certificate.
What we _do_ see is the platforms (like iOS and Android) becoming wallets for identities issued by _others_ based on the indirect and brokered models. Adding mobile drivers licenses is upcoming for both mobile platforms.
but the reality is that for indirect/brokered, you have an issuer and you have parties who have made a decision to trust the identity. If Apple/Google mandate properties the issuers don't like, the issuers won't use it. If the issuers mandate behavior the verifiers don't like, they won't accept it.
And thats the same for any "user-centric" or "self-sovereign" identity system too. If bringing my own DID means that the issuer can't meet their identity verification/authentication mandates, they won't support it. If me using my own wallet means that a retailer is not getting identity assurance or is otherwise taking on additional risk, they won't accept it.
And obviously the people who do not like the overall properties will choose not to consume it.
What you imply is some nefarious function of big actor desires being baked into standards, I would just call 'understanding market requirements'.
I'd put it slightly differently. The infrastructure went part of the way. It needed several more iterations. The UX, as you point out, never went anywhere. At least now people are getting comfortable with the idea of using a private key, even if no one has yet cracked the problem of crypto UX.
When I say it was implemented, I mean at Netscape around 1999 we had projects with banks where they issued smart cards, used with USB readers, that facilitated SSL client cert auth. Similar to today's FIDO2/U2F. I don't know why these schemes were never widely adopted but it wasn't because the implementation was lacking.
"The risk" is a weird, ambiguous ghost in the machine. Maybe it's a result of digital paranoia setting in over the past decade, or maybe it's our response to digital rights abuse. In any case, it's always a good thing when mission-critical infrastructure is democratized like this.
Another area where this will be needed is digital identifiers for digitally owned and transferrable objects in AR/VR. The DID family of specs is designed to help make this a reality.
Full disclosure: I worked on the XDI and XRI specifications that paved the way for DID, and also very slightly on the DID specs (contributing thoughts and inputs, I did not author any part of the DID specs).
It's a good set of specs, written by people that know identity and have a good vision.
Correct me if I am wrong, but most of these services, such as the electronic signature, the electronic seals and the document exchange functionality outlined on that website are all dependent on a central authority are they not?
Your signature certificate is issued by your government (or an organisation working for said government). The seals are created with certificates that are, once again, created by a central authority.
The document exchange is really just a fancy way to store files on your device and send them.
As far as I can tell none of this is decentralised? I don't really see why they would want to decentralise it either, your digital identity as a citizen only exists because a central authority, a nation in this case, validated you to be a citizen ...
As mentioned, correct me if I am wrong, but as far as I can see all of these EU plans are basically just giving each EU citizen a cert that is issued by their government and some nice applications that build around those certs?
Sorry, I should have clarified. The EU commission is focused on digital identity. I haven't dug deeply, but yes, I suspect that they are not as interested in decentralized identity (as the original link was).
> As mentioned, correct me if I am wrong, but as far as I can see all of these EU plans are basically just giving each EU citizen a cert that is issued by their government and some nice applications that build around those certs?
Sure, but wouldn't that ubiquity be a game changer?
> Unless I miss something, this looks like a solution to nonexistent problem?
The generalizable answer to this is that almost always if some group of people has spent a good chunk of effort but you don't "get it", you have missed something.
The less you know about the domain, the larger and more diverse the group and the bigger the effort, the more likely this is to be true.
Of course there are exceptions, but they are rare.
> The general answer to this is that almost always if some group of people has spent a good chunk of effort but you don't "get it", you have missed something.
Sure, but that doesn't mean that the group of people has cogently explained their work for their target audience. In this case, the target audience would be developers, whom it seems from the comments are confused.
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.
Sounds like a PGP replacement in some ways.
Also possibly an alternative to SSN (for Americans).
DIDs are fundamentally antithetical to privacy and will only enable a deeper and more obscure level of tracking to all applications that use them. They were originally inspired for mapping public blockchain use-cases, but IMO personal identity and related keys should _never_ be put on a public chain, who thinks this could ever be a good idea or architecture?
All of the suggested "workarounds" to layer on privacy to DIDs are just lip service in the spec, there's zero technical requirements for an implementation.
I worry that DIDs based on this spec will be deeply harmful if widely deployed with the multiple layers of abstraction, required dependencies on massively complex things like JSON-LD, and abundance of implementation-time choices. It's such an easy "spec" to embrace and extend by big tech, it has no teeth to prevent tracking abuse and it should develop those as hard normative implementation MUSTs before v1.0 versus the non-normative "Privacy _Considerations_" it has now.
Identity is too important to have it done wrong.