Decentralized Identifiers – DIDs

Does anybody care what the W3C think anymore? I was under the impression that the WHATWG was formed due to the browser developers’ frustrations with the W3C and they now mostly ignore what W3C says or does. So, what are the chances of this actually catching on?

Even better, a phone DID is a very centralized identifier, whereas this refers to a decentralized identifier.

I don't think this is very well-known, at least among people who haven't worked on telephony implementations (? I have no idea where this is commonly used). Never in my life has someone asked me for my DID instead of my phone number.

It's fairly plausible that the people working on this specification were unaware of this pre-existing acronym (which ranked after Defense In Depth, when I searched it), and just said "Oh, we're making Distributed IDentifiers. Let's call them DIDs! That's easy to remember."

When used in verbal conversation, is it generally spelled out like CPU (dee eye dee), or said as a word like RAM (did)?

I don't know in particular how they intend to portray Idemix, but both Hyperleger and Sovrin are heavily involved in the development of the spec, so I'm pretty sure they're thinking of it.

Generally speaking, keys are embedded in a DID document in a standard text format and proofs are published as a signature using one of the published keys.

Great video! Thx, for sharing.

"Horsepower - The term was adopted in the late 18th century by Scottish engineer James Watt to compare the output of steam engines with the power of draft horses."

So let's stick with horses for now :)

DIDs are different beasts than UUIDs, with different design goals [0]. Is why they need this specification.

Whether the specification is any good, is a topic of discussion, of course..

[0] https://w3c-ccg.github.io/did-spec/#design-goals

Interesting. Could you provide some links to relevant reading materials?

Unfortunately, much of the information we interact with every day is ever-changing and published by someone specific, which is not a feature provided by content-addressable storage.

I may be wrong, but are you thinking of DIDs as an ID for an object, like CIDs in IPFS. If so, then you are confusing what DIDs are for. They're created as a method of using some distributed network as a backend for a entity (could be a Human, could be another machine) to store their identifiers on. These entity's can take actions, like signing a doc and uploading it to a blockchain. The DID in this instance is the record of verifying who this entity is, and if they should be trusted to do that action.

Content addressable IDs, or CIDs in IPFS are used to identity a document or object.

So the distinction here is objects (some record of data) vs entities (something that can take actions).

Contend addressed documents wouldn't fit directly into what DID is trying to accomplish. A DID is supposed to be a unique id to identify an identity, such as a Person, a company or even your pets. A DID maps to a DID Document that may change overtime, e.g.: the public keys listed in it. If we were using content-addressing for the identifiers, they would be changing over time, which will be hard to use in a variety of systems.

This doesn't mean that we cannot use content-addressing. For instance, in IPFS world, the DID could actually be using IPNS to point to a CID. This allows to have a persistent DID pointing to CIDs at different times. There's actually a DID method called IPID (based on IPFS), that uses a strategy similar to this.

I am wondering about this too. The spec says:

> Because DIDs reside on a distributed ledger, each entity may serve as its own root authority—an architecture referred to as DPKI [0] (decentralized PKI).

There is a whole bunch of related docs in the WebOfTrust github repo's, many of which are related to blockchain (which does not have my interest, ATM).

The spec continues:

> Note that DID methods may also be developed for identifiers registered in federated or centralized identity management systems. For their part, all types of identifier systems may add support for DIDs. This creates an interoperability bridge between the worlds of centralized, federated, and decentralized identifiers.

Then later on there is a chapter on DID Resolvers [1] but this does not have much detail. So, I guess, the actual resolving mechanisms are out of scope of the spec.

[0] https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust...

[1] https://w3c-ccg.github.io/did-spec/#did-resolvers

The DID system doesn't use any central registrars. Connecting a key with an entity consists of the entity represented by the DID publishing the key in their DID document. That document is then published on some ledger (can be blockchain but could also be, e.g., IPFS) so that others can discover it.

"So... how, exactly, do they propose tying together a human being with a public key, thus creating a DID, without the use of a central registrar?"

The answer, as you might expect, is with a blockchain.

There was a booth last week at the decentralized web summit for the "BTCR DID Method" which I believe is sponsored by W3C. You can read about it by going here:

https://decentralizedweb.net/science-fair/

Here you are:

"The Bitcoin Reference DID method supports DIDs on the public Bitcoin blockchain The Bitcoin Reference DID method (did:btcr) supports DIDs on the public Bitcoin blockchain. The Bitcoin Reference method has minimal design goals: a DID trust anchor based on the Bitcoin blockchain, updates publicly visible and auditable via Bitcoin transactions, and optionally, additional DID Document information referenced in the transaction OP_RETURN data field. No other Personal Identifiable Information (PII) would be placed on the immutable blockchain.

A secondary intent of the BTCR method is to serve as a very conservative, very secure example and some best practices for creating a DID method. The use cases for BTCR are focused on anonymous and pseudo-anonymous identities, web-of-trust style webs of identity, and absolute mimimal personal information disclosure. Other DID methods will likely need to loosen these standards.

Some aspects of the BTCR method will not be practical if inappropriately scaled — for instance, there is a transaction cost to update keys and DDO object, potential UTXO inflation (i.e. one additional unspent output for every BTCR-based identity), and even if segwit isn't used it could cause blockchain bloat. However, identities using the BTCR method can be a strong as Bitcoin itself -- currently securing billions of dollars of digital value."

I mentioned Keybase's use of DID's in another comment in this thread. They've done a great job of demonstrating how a fairly non-technical user can generate their own PGP keys and cross reference these keys to various social identities and attestations. The records for each user's attestations and identity claims are written to the bitcoin blockchain, which gives users the ability to continue use of these identity claims, even if Keybase were to cease existing. Blockstack's identity model has some similar features, and in general, I've found the successful use of DID's to be blockchain agnostic, which is (IMHO) the way it should be.

Would be great to hear a bit more about your experiences, or maybe provide some pointers?

Good point about identity being relationship-based. I've found DID's to be quite effective in providing cryptographically verifiable social proofs that are powered by our relationships. Keybase has an excellent integration of DID's and social proofs. I've verified my Hacker news identity and linked this identity to my Keybase identity, along with my Twitter, FB and github identity. If you know me on one of these platforms, you can cross-reference my identity and see that I've attested to my identity across multiple platforms. When you go to my Keybase profile, you can see I am currently in control of these identities, and I can revoke the keys I've created as provable links between my various profiles. This layering of social proofs is powerful in a variety of ways.